From weiler+secdir@watson.org Fri Oct 1 08:19:30 2010 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 0E22D3A6EBD for ; Fri, 1 Oct 2010 08:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 NQUodR2Yef8C for ; Fri, 1 Oct 2010 08:19:29 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 015683A6DF7 for ; Fri, 1 Oct 2010 08:19:28 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o91FKGHt018173 for ; Fri, 1 Oct 2010 11:20:16 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o91FKGAp018170 for ; Fri, 1 Oct 2010 11:20:16 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 1 Oct 2010 11:20:16 -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.2.3 (fledge.watson.org [127.0.0.1]); Fri, 01 Oct 2010 11:20:16 -0400 (EDT) Subject: [secdir] Assignments 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, 01 Oct 2010 15:19:30 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Scott Kelly is next in the rotation. For telechat 2010-10-07 Reviewer LC end Draft Rob Austein T 2010-09-27 draft-ietf-grow-bgp-graceful-shutdown-requirements-04 Alan DeKok T 2010-09-27 draft-ietf-v6ops-cpe-simple-security-14 Steve Hanna T - draft-ietf-csi-dhcpv6-cga-ps-04 Love Hornquist-Astrand T 2010-10-07 draft-ietf-tsvwg-sctp-chunk-flags-01 David McGrew T 2010-08-05 draft-ietf-pce-manageability-requirements-11 Juergen Schoenwaelder TR2010-09-01 draft-ietf-ccamp-gmpls-ethernet-pbb-te-06 For telechat 2010-10-21 Reviewer LC end Draft Shawn Emery T 2010-10-11 draft-arkko-townsley-coexistence-05 Phillip Hallam-Baker T 2010-10-11 draft-zeilenga-ldap-dontusecopy-08 Last calls and special requests: Reviewer LC end Draft Stephen Farrell 2010-09-28 draft-ietf-avt-rapid-acquisition-for-rtp-15 Dan Harkins 2010-10-04 draft-ietf-dime-capablities-update-05 Sam Hartman 2010-10-04 draft-ietf-netconf-with-defaults-11 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Jeffrey Hutzelman 2010-10-13 draft-ietf-mpls-ldp-upstream-08 Charlie Kaufman 2010-10-12 draft-ietf-storm-ifcpmib-05 David McGrew - draft-ietf-ecrit-framework-11 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-03 Glen Zorn 2010-09-16 draft-ietf-l3vpn-mvpn-spmsi-joins-01 From dharkins@lounge.org Fri Oct 1 17:08:26 2010 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 94E653A6DF4; Fri, 1 Oct 2010 17:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.616, 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 VbzJuUX0qd23; Fri, 1 Oct 2010 17:08:25 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B7B663A6DBD; Fri, 1 Oct 2010 17:08:25 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1B3A62008E; Fri, 1 Oct 2010 17:09:15 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 1 Oct 2010 17:09:15 -0700 (PDT) Message-ID: <751201d5100f5b9560a3833b20d0c8b1.squirrel@www.trepanning.net> Date: Fri, 1 Oct 2010 17:09:15 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dime-capabilities-update.all@tools.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 Subject: [secdir] review of draft-ietf-dime-capabilities-update 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, 02 Oct 2010 00:08:26 -0000 Hello, 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 defines a new Diameter application to allow dynamic update of a Diameter peer's capabilities without having to tear down existing connections. It is a simple 2 message, request-response, protocol. The Security Considerations are quite brief, stating that the Security Considerations of the Diameter Base Protocol apply to this document, but given the nature of this application it seems fine. I found not issues with the draft. regards, Dan. From shanna@juniper.net Fri Oct 1 20:04:19 2010 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 98C7B3A6C59; Fri, 1 Oct 2010 20:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.153 X-Spam-Level: X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 KT3139eWznD5; Fri, 1 Oct 2010 20:04:18 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id E3DE73A6BBA; Fri, 1 Oct 2010 20:04:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTKahYTCggBOgQGB9ff1qt5xtSTt/geye@postini.com; Fri, 01 Oct 2010 20:05:08 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 1 Oct 2010 19:56:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 1 Oct 2010 22:56:25 -0400 From: Stephen Hanna To: "ietf@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org" Date: Fri, 1 Oct 2010 22:56:24 -0400 Thread-Topic: secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.txt Thread-Index: Acth3WZtFoUbk+23ReaFVG39Xm1qzw== Message-ID: 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 Subject: [secdir] secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.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: Sat, 02 Oct 2010 03:04:19 -0000 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 treat =20 these comments just like any other last call comments. This document discusses several ways that DHCPv6 can be used with Cryptographically Generated Addresses (CGA), pointing out benefits and concerns. While the document does discuss security issues in several places, it often lapses into vague terminology like "one should carefully consider the impact on security". Given that the primary benefit of using CGAs is to improve security by providing address validation without complex key distribution, carefully analyzing security issues seems necessary for this document. On the other hand, the Document Shepherd Write-up for this document says "The WG was not very energetic on this document. The document describes possible applications of CGAs and DHCP interaction and when the WG was asked whether there was enough interest to work on solutions, the reply was silence. As such, the consensus is based on most of the WG being indifferent." So maybe this document is only intended as a sketch of possible issues that can be explored later in a more in-depth document if someone is interested in doing so. If that's the case, maybe it's OK to not fully analyze all the security implications. However, in that case, I think the Security Considerations section should state clearly that this document does not contain a complete security analysis and any further work in this area should include such an analysis. Nobody should implement the techniques described in this document without conducting that more thorough analysis. I noticed a few typos. On page 6, the word "certificated" should be "certified". Three sentences later, "depend on policies" should be "depending on policies". And the draft names in the Change Log say "dhacpv6" instead of "dhcpv6". Thanks, Steve From j.schoenwaelder@jacobs-university.de Sun Oct 3 10:33:29 2010 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 011AB3A6C5A; Sun, 3 Oct 2010 10:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.97 X-Spam-Level: X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 1tPfXZPCSHAr; Sun, 3 Oct 2010 10:33:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 81EAF3A6C1D; Sun, 3 Oct 2010 10:33:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AC0EC0004; Sun, 3 Oct 2010 19:34:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9dqdO0yuY+s0; Sun, 3 Oct 2010 19:34:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42A1AC000D; Sun, 3 Oct 2010 19:34:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4C9A915038E7; Sun, 3 Oct 2010 19:33:41 +0200 (CEST) Date: Sun, 3 Oct 2010 19:33:41 +0200 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ccamp-gmpls-ethernet-pbb-te.all@tools.ietf.org Message-ID: <20101003173341.GA16738@elstar.local> Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ccamp-gmpls-ethernet-pbb-te.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.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: Sun, 03 Oct 2010 17:33:29 -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 -05 and my editorial comments have been addressed in the -06 version. My other comments have apparently not been acted on nor did I receive any response from the authors. The comments were: Security wise, this document essentially refers to other documents, namely RFC 4872 amd RFC 4873. These documents again refer to other documents and ultimately to IPsec as a security solution. If this is correct, perhaps this could be made clearer so people like me do not have to recursively resolve security considerations to find out how things are protected. The security considerations of this document also refer to 802.1AE Media Access Control Security for the protection of "transport" Ethernet. It is not clear what "transport" Ethernet is, perhaps it is the Ethernet traffic carried over the paths. If my interpretation is correct, I would argue that this pointer does not really belong into the security considerations of this document since this specification deals with a part of the signaling plane, not the data plane. Section 5 states that "configuration should be consistent". What happens security wise if configuration is not consistent? This might deserve some discussion in the security considerations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tobias.gondrom@gondrom.org Sun Oct 3 12:45:17 2010 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 3D0FD3A6D5B for ; Sun, 3 Oct 2010 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.953 X-Spam-Level: X-Spam-Status: No, score=-94.953 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPeNz0zp8mHb for ; Sun, 3 Oct 2010 12:45:16 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 813AE3A6D16 for ; Sun, 3 Oct 2010 12:45:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=nqVMJDU/4IDodJtM/cgtzRRCmhMfjpmZPsSMZ4nuaqYjzLCDIUY0hMzplHEGlKvpwyhD0MsxdT2ueO1xlk+fwv57Q7jAJnoeuQm3Fz9jrvZ3uYL6u83k1Zc5nAc1Y2mz; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 3384 invoked from network); 3 Oct 2010 21:45:42 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Oct 2010 21:45:42 +0200 Message-ID: <4CA8DDAC.3050801@gondrom.org> Date: Sun, 03 Oct 2010 20:46:52 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Sriganesh Kini References: <4CA081F7.60304@gondrom.org> <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDE903@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDE903@EUSAACMS0703.eamcs.ericsson.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "swallow@cisco.com" , Wenhu Lu , "secdir@ietf.org" , "draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "iesg@ietf.org" , "adrian.farrel@huawei.com" , "loa@pi.nu" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-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: Sun, 03 Oct 2010 19:45:17 -0000 Answers inline [tg] BR, Tobias On 10/01/2010 09:08 PM, Sriganesh Kini wrote: > Hello Tobias, > > Pls see inline at [Sri]. > > Thanks > >> -----Original Message----- >> From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] >> Sent: Monday, September 27, 2010 4:37 AM >> To: iesg@ietf.org; secdir@ietf.org >> Cc: draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org; >> Sriganesh Kini; Wenhu Lu; swallow@cisco.com; loa@pi.nu; >> adrian.farrel@huawei.com; martin.vigoureux@alcatel-lucent.com >> Subject: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04 >> >> >> 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. >> >> >> draft-ietf-mpls-ldp-igp-sync-bcast-04 >> LDP IGP Synchronization for broadcast networks >> >> the draft updates RFC 5443 (LDP IGP Synchronization) It basically >> proposes the following mechanism: "If an interface is not a 'cut-edge' >> then the updating of the LSA with that link to the pseudo-node is >> postponed until LDP is operational." >> >> The document states that there would be no security considerations >> beyond RFC5443. >> I am not certain of that. Although the idea behind bcast is good, it >> adds a new mechanism beyond 5443. >> To make sure the security considerations are accurate, I'd like to >> raise two questions for the authors/WG: >> 1. Which security implications does the WG see for removing a coming >> up link from the LSDB? > [Sri] Since the link is only delayed from being added to the LSDB we don't believe there are any new/additional security implications. [tg] still the delay is in theory not time limited, but based on the condition of LDP of the link. In combination with #2 (below) that the cut-edge of the network may actually be calculated falsely, can this be exploited or lead to unreachability? Note: although your remark is right regarding similarities with 5443, the criteria in 5443 is much weaker as it only increases its metric, but does not remove it from LSDB/hold back its entry. Again, I am not an expert on that layer, but I am still uncertain that no security considerations derive from that. Did you consider this scenario when you wrote the draft? Is it unrealistic that it could be exploited with bad intentions? If not, which would be the underlying implied pre-conditions to be met to avoid such or under which pre-conditions could such a problem occur? (potential input for the security considerations section) >> 2. Can there be a gap between the algorithm to determine "cut-edge" >> and TTL (e.g. may not qualify for "cut-edge" and thus be removed from >> LSDB, but have a large number of links and effectively not be >> reachable)? > [Sri] This problem is not unique to this draft. Even in RFC 5443 when the link has high metric, an alternate path with num hops > 255 (but a lower path metric than the directly connected link's max metric) can result in unreachability. > >> and three minor editorial comments: >> - section 3, last paragraph: >> s/Since A's cost to reach B not high/Since A's cost to reach B is not >> high > [Sri] Accepted > >> - Appendix A: Computation of 'cut-edge' >> there should be an informative reference for mentioned "Dijkstra's >> algorithm" > [Sri] Accepted. Will refer to RFC 2328 sec 16.1 > >> - abbreviation "SPF" should list the its expanded term (Shortest Path >> First) at first mentioning. > [Sri] Accepted. > >> Best regards, Tobias >> >> >> >> >> From Adrian.Farrel@huawei.com Mon Oct 4 08:50:54 2010 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 241033A6CE1; Mon, 4 Oct 2010 08:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, 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 pX4BTdxvlPGw; Mon, 4 Oct 2010 08:50:53 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id B026A3A6C9D; Mon, 4 Oct 2010 08:50:52 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9R00JFJW27QM@usaga01-in.huawei.com>; Mon, 04 Oct 2010 08:51:43 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9R00A5BW24EL@usaga01-in.huawei.com>; Mon, 04 Oct 2010 08:51:43 -0700 (PDT) Date: Mon, 04 Oct 2010 16:51:29 +0100 From: Adrian Farrel To: "Fedyk, Donald (Don)" , Juergen Schoenwaelder , iesg@ietf.org, secdir@ietf.org, draft-ietf-ccamp-gmpls-ethernet-pbb-te.all@tools.ietf.org Message-id: <7B88DDE4B8FF4613B501B2CD57DE5424@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20101003173341.GA16738@elstar.local> Subject: Re: [secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 15:50:54 -0000 Additions in-line... --- 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 -05 and my editorial comments have been addressed in the -06 version. My other comments have apparently not been acted on nor did I receive any response from the authors. The comments were: Security wise, this document essentially refers to other documents, namely RFC 4872 amd RFC 4873. These documents again refer to other documents and ultimately to IPsec as a security solution. If this is correct, perhaps this could be made clearer so people like me do not have to recursively resolve security considerations to find out how things are protected. [DF] This is correct. This is also the way we have documented for some time with many documents referring backwards. Ultimately for control plane it comes down to some form restricted access/private networks or some mechanism such as IPSec to protect public exposed portions of signaling. [AF] I believe that RFC 5920 provides the global view that Juergen is looking for, and is referenced from the Security Section. The security considerations of this document also refer to 802.1AE Media Access Control Security for the protection of "transport" Ethernet. It is not clear what "transport" Ethernet is, perhaps it is the Ethernet traffic carried over the paths. If my interpretation is correct, I would argue that this pointer does not really belong into the security considerations of this document since this specification deals with a part of the signaling plane, not the data plane. [DF] transport Ethernet is a term that we use to describe Ethernet technologies that offer similar service typically associated with L1 transport networks (OAM (monitoring, tracing, integrity checking, fault signaling), protection switching). PBB-TE is one type of transport Ethernet. MACSEC can be used between the elements of the Ethernet network providing transport. If signaling is inland then MACSEC could be providing part of the security for the signaling. If the signaling is out of band over other technologies then IPSEC or other may ultimately be providing protection. [AF] The term and concept are discussed in draft-ietf-ccamp-gmpls-ethernet-arch. Maybe a reference could be inserted? Section 5 states that "configuration should be consistent". What happens security wise if configuration is not consistent? This might deserve some discussion in the security considerations. [DF] When configuration is not consistent it is normal for the connection simply not to come up. The dual ended nature of the configuration requires the source must match the destination. This draft is currently is covering PBB-TE which is defined for a single administrative domain so the result of the misconnection is that the signaling will report some form of failure through the management plane. [DF] In my opinion these items have been covered at a level that is consistent with GMPLS documents in the past but if there additional text or clarification we need on any of these points please indicate and I will work with the authors, chairs and ADs to correct. Regards, Don /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From stephen.farrell@cs.tcd.ie Mon Oct 4 09:58:08 2010 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 DA9773A6D7B; Mon, 4 Oct 2010 09:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.801 X-Spam-Level: X-Spam-Status: No, score=-102.801 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, 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 b2s7mJplI-VL; Mon, 4 Oct 2010 09:58:05 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 1E8A53A6ED0; Mon, 4 Oct 2010 09:57:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 40C333E40F4; Mon, 4 Oct 2010 17:58:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1286211532; bh=cHsGZOymHPq5NdWI5eygUwWS 9AYSzlFr27LPUcIrHvU=; b=wtjvR9PsZCxmJxzvsyG9CITdHCodj2M7Z4SrpHgH 9Ru96pCeMSTS3xPLHEzmI8INN47ypb2LrZaqh9lb03xwkqqnjc5FuwXrlu12cA8F U0u6gGtfX5soSjiqivBbQre2NFkysU/xwKJAdNdk7kYXhNZfoiqQkAyQhApb96e5 m2GY2ackRz+pvxu1wKfVOnIniWyxCNFO/IYm2G3tfdE/46LZjoHhtqOcz8RxSwBj 9HBJaBp6VwYYHgNMXT1FdQjNJyk2J83BEzP4IXMIdIw4FJJSLqrEEV1UdIj6C5aJ SlKzE4jPPuPTL+LLDMXtT08hJxTwhnthrEt6bjOjphc+cQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id wFyOwBvi0Xqb; Mon, 4 Oct 2010 17:58:52 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DE6A13E40F0; Mon, 4 Oct 2010 17:58:50 +0100 (IST) Message-ID: <4CAA07C8.4030806@cs.tcd.ie> Date: Mon, 04 Oct 2010 17:58:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org, sec-ads@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: avt-chairs@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15 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, 04 Oct 2010 16:58:08 -0000 #include This document defines a way for multicast receivers (e.g. IPTV clients) to rapidly acquire the reference information required to make sense of the session data. Reference information is usually only sent periodically within the session, so this document defines how to setup a new unicast session with a server that transmits the reference information to the client on request so as a result the client doesn't have to wait so long. Overall, I'm a bit concerned that this might create new DoS exploit potential, but I could be wrong (don't know enough about multicast) and I see there has been a separate thread on ietf-discuss that had some mention of that. (I've not read that thread in detail.) If an off-path attacker could insert RAMS-* messages with values that are likely to result in things happening then that, I think, would be quite bad, but I'm not quite sure. Detailed security-related issues/questions: - How does the client know that it has the right FT/BRS? (Does it always get that from SDP?) What would happen if it has a bogus FT/BRS? (Is that likely?) - P17 says that the BRS may reject the RAMS-R request. Are there security reasons that might cause rejection? If so, what? - P18 says that the BRS can replace the SSRC from the RAMS-R with something else. Wouldn't that allow a bad BRS to redirect an RTP_Rx to some dodgy stream, instead of the one requested? Should the RTP_Rx react to that somehow? - How are updated RAMS-R and RAMS-I related to originals? Is there a way to insert these (maybe from off-path?) If there is, could a fake RAMS-I mount a DoS on the RTP-Rx? (E.g. by supplying crap information.) - Could I send a fake RTCP BYE pretending to be from some RTP_Rx in order to DoS that client? - Could I send a RAMS-R requesting a very high bitrate for a burst as a way to DoS someone local to the (claimed) source of the RAMS-R? (The max is 2^64 I guess) - p31: the Min RAMS buffer fill requirement seems to allow RTP-Rx to request almost 50 days (2^32ms) of content in the unicast burst. That seems too much, from the p-o-v of potential DoS exploits. Maybe say that the BRS SHOULD impose some limit as part of DoS mitigation? - p35: the earliest join time is also a 32 bit millisecond counter. Should the RTP_Rx also have some kind of sanity check if asked to wait days? Same comment wrt burst duration. - p42: Saying "adequate" security measures are "RECOMMENDED" to protect SDP description, without saying what they might be, is very vague. What's an implementer supposed to do? - p43 mentions SRTP as a SHOULD. How widely is that deployed and does it make sense for this use-case? I think that should be clear. (If SRTP isn't really used, or if its not going to be used here, then its not a real countermeasure.) - p43 says RAMS itself brings no new attacks, but surely it does create some new off-path DoS potential, if messages could be guessed? - p43: what does "consider the security of such SRTP key sharing mean?" I think this spec should say. Nits/Non-security things: - p8: CNAME is used without being defined. - p15: AVPF is used before being defined/expanded. - p18: Saying "If the RTP_Rx will issue a ..." seems confusing. Would that be clear to an implementer? In other words ought the spec say SHOULD somewhere here? (In which case, it'd also presumably say when its ok not to follow the SHOULD.) - p19: This says that if the BRS has given a 504 etc. reject, then the RTP_Rx MUST NOT retry. Does that mean just for this stream or for any stream? Its not clear to me if the "MUST NOT" is scoped to one "channel change" button press, or many, and if many, how that'd ever be reset, though that might be my ignorance of the use-case and multicast in general:-) - p20 says the BRS "can" use the updated RAMS-R - that's not 2119 language, so I assume you mean "MAY" and the intent is to allow implementers to handle updated RAMS-R in whatever way suits best, given their internal state when the update arrives? - p21 says "there is no need" to send RAMS-T for rejected stuff. Maybe that'd be better as a MUST NOT or SHOULD NOT? - p21: the mix of SHALL and MUST looks odd, I at least, would prefer just MUSTs. - p21, typo s/and started/and has started/ - p21, OSN-minus-one as a signal for the BRS to stop - can that OSN wrap around? - p34: what are "the regular wrapping rules" for MSN and how does that work with an 8 bit field that is only zero when a new RAMS-R is received? - p38: saying support for rfc5576 "can also be needed" seems vague. Better to specifically say when its needed. Regards, Stephen. From donald.fedyk@alcatel-lucent.com Mon Oct 4 08:29:48 2010 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 A7C353A6D1F; Mon, 4 Oct 2010 08:29:48 -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 bZ2J9pUOlHgj; Mon, 4 Oct 2010 08:29:46 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id B30B53A6CCF; Mon, 4 Oct 2010 08:29:46 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o94FUd0W022174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Oct 2010 10:30:40 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o94FUc5q020486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Oct 2010 10:30:39 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.139]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Mon, 4 Oct 2010 10:30:38 -0500 From: "Fedyk, Donald (Don)" To: Juergen Schoenwaelder , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ccamp-gmpls-ethernet-pbb-te.all@tools.ietf.org" Date: Mon, 4 Oct 2010 10:30:36 -0500 Thread-Topic: secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt Thread-Index: ActjPW+YZ7uXqIAuTFy/jHSeU+GqtgAk5P5w Message-ID: References: <20101003173341.GA16738@elstar.local> In-Reply-To: <20101003173341.GA16738@elstar.local> 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-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 X-Mailman-Approved-At: Mon, 04 Oct 2010 11:36:00 -0700 Subject: Re: [secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.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, 04 Oct 2010 15:29:48 -0000 Hi Juergen Sorry. When I updated I first consulted with the authors, chairs and ADs to= address comments. And then we agreed to post corrections. But it seems I = missed the step where I close the loop with SecDir & GenArt. My apologies.= =20 So to your comments, see [DF] inline (All please feel free to correct me below if I miss speak.) -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Sunday, October 03, 2010 1:34 PM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ccamp-gmpls-ethernet-pbb-te.= all@tools.ietf.org Subject: secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. I have reviewed -05 and my editorial comments have been addressed in the -0= 6 version. My other comments have apparently not been acted on nor did I re= ceive any response from the authors. The comments were: Security wise, this document essentially refers to other documents, namely RFC 4872 amd RFC 4873. These documents again refer to other documents and ultimately to IPsec as a security solution. If this is correct, perhaps this could be made clearer so people like me do not have to recursively resolve security considerations to find out how things are protected. [DF] This is correct. This is also the way we have documented for some time= with many documents referring backwards. Ultimately for control plane it = comes down to some form restricted access/private networks or some mechanis= m such as IPSec to protect public exposed portions of signaling.=20 The security considerations of this document also refer to 802.1AE Media Access Control Security for the protection of "transport" Ethernet. It is not clear what "transport" Ethernet is, perhaps it is the Ethernet traffic carried over the paths. If my interpretation is correct, I would argue that this pointer does not really belong into the security considerations of this document since this specification deals with a part of the signaling plane, not the data plane. [DF] transport Ethernet is a term that we use to describe Ethernet technolo= gies that offer similar service typically associated with L1 transport netw= orks (OAM (monitoring, tracing, integrity checking, fault signaling), prote= ction switching). PBB-TE is one type of transport Ethernet. MACSEC can be u= sed between the elements of the Ethernet network providing transport. If si= gnaling is inland then MACSEC could be providing part of the security for t= he signaling. If the signaling is out of band over other technologies then = IPSEC or other may ultimately be providing protection.=20 Section 5 states that "configuration should be consistent". What happens security wise if configuration is not consistent? This might deserve some discussion in the security considerations. [DF] When configuration is not consistent it is normal for the connection = simply not to come up. The dual ended nature of the configuration requires= the source must match the destination. This draft is currently is coverin= g PBB-TE which is defined for a single administrative domain so the result = of the misconnection is that the signaling will report some form of failure= through the management plane. [DF] In my opinion these items have been covered at a level that is consist= ent with GMPLS documents in the past but if there additional text or clarif= ication we need on any of these points please indicate and I will work with= the authors, chairs and ADs to correct. Regards, Don=20 /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sriganesh.kini@ericsson.com Fri Oct 1 13:09:20 2010 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 326613A6E04; Fri, 1 Oct 2010 13:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 OsKPYln8A3J6; Fri, 1 Oct 2010 13:09:18 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id EE1CC3A6E26; Fri, 1 Oct 2010 13:08:00 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o91K7sHi006247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Oct 2010 15:08:34 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.219]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 1 Oct 2010 16:08:21 -0400 From: Sriganesh Kini To: Tobias Gondrom , "iesg@ietf.org" , "secdir@ietf.org" Date: Fri, 1 Oct 2010 16:08:20 -0400 Thread-Topic: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04 Thread-Index: ActeOEH0nE1Z3sFDSQGL1ipD7jocMgDa/Icw Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDE903@EUSAACMS0703.eamcs.ericsson.se> References: <4CA081F7.60304@gondrom.org> In-Reply-To: <4CA081F7.60304@gondrom.org> 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-Mailman-Approved-At: Mon, 04 Oct 2010 11:35:57 -0700 Cc: "swallow@cisco.com" , Wenhu Lu , "draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org" , "adrian.farrel@huawei.com" , "martin.vigoureux@alcatel-lucent.com" , "loa@pi.nu" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-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: Fri, 01 Oct 2010 20:09:20 -0000 X-List-Received-Date: Fri, 01 Oct 2010 20:09:20 -0000 Hello Tobias, Pls see inline at [Sri]. Thanks > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > Sent: Monday, September 27, 2010 4:37 AM > To: iesg@ietf.org; secdir@ietf.org > Cc: draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org; > Sriganesh Kini; Wenhu Lu; swallow@cisco.com; loa@pi.nu;=20 > adrian.farrel@huawei.com; martin.vigoureux@alcatel-lucent.com > Subject: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04 >=20 >=20 > 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 treat these comments just like=20 > any other last call comments. >=20 >=20 > draft-ietf-mpls-ldp-igp-sync-bcast-04 > LDP IGP Synchronization for broadcast networks >=20 > the draft updates RFC 5443 (LDP IGP Synchronization) It basically=20 > proposes the following mechanism: "If an interface is not a 'cut-edge' > then the updating of the LSA with that link to the pseudo-node is=20 > postponed until LDP is operational." >=20 > The document states that there would be no security considerations=20 > beyond RFC5443. > I am not certain of that. Although the idea behind bcast is good, it=20 > adds a new mechanism beyond 5443. > To make sure the security considerations are accurate, I'd like to=20 > raise two questions for the authors/WG: > 1. Which security implications does the WG see for removing a coming=20 > up link from the LSDB? [Sri] Since the link is only delayed from being added to the LSDB we don't = believe there are any new/additional security implications. > 2. Can there be a gap between the algorithm to determine "cut-edge"=20 > and TTL (e.g. may not qualify for "cut-edge" and thus be removed from=20 > LSDB, but have a large number of links and effectively not be=20 > reachable)? [Sri] This problem is not unique to this draft. Even in RFC 5443 when the l= ink has high metric, an alternate path with num hops > 255 (but a lower pat= h metric than the directly connected link's max metric) can result in unrea= chability. >=20 > and three minor editorial comments: > - section 3, last paragraph: > s/Since A's cost to reach B not high/Since A's cost to reach B is not=20 > high [Sri] Accepted > - Appendix A: Computation of 'cut-edge' > there should be an informative reference for mentioned "Dijkstra's=20 > algorithm" [Sri] Accepted. Will refer to RFC 2328 sec 16.1 > - abbreviation "SPF" should list the its expanded term (Shortest Path > First) at first mentioning. [Sri] Accepted. >=20 > Best regards, Tobias >=20 >=20 >=20 >=20 >=20 From sriganesh.kini@ericsson.com Mon Oct 4 11:07:15 2010 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 76EF73A6FFC; Mon, 4 Oct 2010 11:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 6EQzMKp2xxcO; Mon, 4 Oct 2010 11:07:14 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id C5FF03A6FF9; Mon, 4 Oct 2010 11:07:13 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o94IMB6X007521; Mon, 4 Oct 2010 13:22:16 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.219]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 4 Oct 2010 14:07:06 -0400 From: Sriganesh Kini To: Tobias Gondrom Date: Mon, 4 Oct 2010 14:07:05 -0400 Thread-Topic: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04 Thread-Index: ActjM5K4miiYsgj3RMC+lHpzGTWhyQAuuYUg Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDEF1A@EUSAACMS0703.eamcs.ericsson.se> References: <4CA081F7.60304@gondrom.org> <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDE903@EUSAACMS0703.eamcs.ericsson.se> <4CA8DDAC.3050801@gondrom.org> In-Reply-To: <4CA8DDAC.3050801@gondrom.org> 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-Mailman-Approved-At: Mon, 04 Oct 2010 11:36:00 -0700 Cc: "swallow@cisco.com" , Wenhu Lu , "secdir@ietf.org" , "draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org" , "martin.vigoureux@alcatel-lucent.com" , "iesg@ietf.org" , "adrian.farrel@huawei.com" , "loa@pi.nu" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-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: Mon, 04 Oct 2010 18:07:15 -0000 Explanation inline @ [Sri] Thanks - Sri =20 > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org]=20 > Sent: Sunday, October 03, 2010 12:47 PM > To: Sriganesh Kini > Cc: iesg@ietf.org; secdir@ietf.org;=20 > draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org; Wenhu=20 > Lu; swallow@cisco.com; loa@pi.nu; adrian.farrel@huawei.com;=20 > martin.vigoureux@alcatel-lucent.com > Subject: Re: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04 >=20 >=20 > Answers inline [tg] > BR, Tobias >=20 > On 10/01/2010 09:08 PM, Sriganesh Kini wrote: > > Hello Tobias, > > > > Pls see inline at [Sri]. > > > > Thanks > > > >> -----Original Message----- > >> From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > >> Sent: Monday, September 27, 2010 4:37 AM > >> To: iesg@ietf.org; secdir@ietf.org > >> Cc: draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org; > >> Sriganesh Kini; Wenhu Lu; swallow@cisco.com; loa@pi.nu;=20 > >> adrian.farrel@huawei.com; martin.vigoureux@alcatel-lucent.com > >> Subject: Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04 > >> > >> > >> I have reviewed this document as part of the security=20 > directorate's=20 > >> ongoing effort to review all IETF documents being processed by the=20 > >> IESG. These comments were written primarily for the=20 > benefit of the=20 > >> security area directors. > >> Document editors and WG chairs should treat these comments=20 > just like=20 > >> any other last call comments. > >> > >> > >> draft-ietf-mpls-ldp-igp-sync-bcast-04 > >> LDP IGP Synchronization for broadcast networks > >> > >> the draft updates RFC 5443 (LDP IGP Synchronization) It basically=20 > >> proposes the following mechanism: "If an interface is not=20 > a 'cut-edge' > >> then the updating of the LSA with that link to the pseudo-node is=20 > >> postponed until LDP is operational." > >> > >> The document states that there would be no security considerations=20 > >> beyond RFC5443. > >> I am not certain of that. Although the idea behind bcast=20 > is good, it=20 > >> adds a new mechanism beyond 5443. > >> To make sure the security considerations are accurate, I'd like to=20 > >> raise two questions for the authors/WG: > >> 1. Which security implications does the WG see for=20 > removing a coming=20 > >> up link from the LSDB? > > [Sri] Since the link is only delayed from being added to=20 > the LSDB we don't believe there are any new/additional=20 > security implications. > [tg] still the delay is in theory not time limited, but based=20 > on the condition of LDP of the link. In combination with #2=20 > (below) that the cut-edge of the network may actually be=20 > calculated falsely, can this be exploited or lead to unreachability? > Note: although your remark is right regarding similarities=20 > with 5443, the criteria in 5443 is much weaker as it only=20 > increases its metric, but does not remove it from LSDB/hold=20 > back its entry. Again, I am not an expert on that layer, but=20 > I am still uncertain that no security considerations derive=20 > from that. Did you consider this scenario when you wrote the=20 > draft? Is it unrealistic that it could be exploited with bad=20 > intentions? > If not, which would be the underlying implied pre-conditions=20 > to be met to avoid such or under which pre-conditions could=20 > such a problem occur? > (potential input for the security considerations section) [Sri] The weaker criteria of RFC 5443 does not ensure that the problem does= not exist there. In fact the problem exists in a plain IP network with lin= k-state IGP. If the directly connected path has a higher metric than an alt= ernate path with TTL (say > 255) hops then the standard SPF will conclude t= hat the shortest path is the alternate path although through this path the = neighboring node is unreachable. Note that in this case the link is adverti= sed with its normal metric yet there is unreachability in the network. > =20 > >> 2. Can there be a gap between the algorithm to determine=20 > "cut-edge"=20 > >> and TTL (e.g. may not qualify for "cut-edge" and thus be=20 > removed from=20 > >> LSDB, but have a large number of links and effectively not be=20 > >> reachable)? > > [Sri] This problem is not unique to this draft. Even in RFC=20 > 5443 when the link has high metric, an alternate path with=20 > num hops > 255 (but a lower path metric than the directly=20 > connected link's max metric) can result in unreachability. > > > >> and three minor editorial comments: > >> - section 3, last paragraph: > >> s/Since A's cost to reach B not high/Since A's cost to=20 > reach B is not=20 > >> high > > [Sri] Accepted > > > >> - Appendix A: Computation of 'cut-edge' > >> there should be an informative reference for mentioned "Dijkstra's=20 > >> algorithm" > > [Sri] Accepted. Will refer to RFC 2328 sec 16.1 > > > >> - abbreviation "SPF" should list the its expanded term=20 > (Shortest Path > >> First) at first mentioning. > > [Sri] Accepted. > > > >> Best regards, Tobias > >> > >> > >> > >> > >> >=20 > = From housley@vigilsec.com Mon Oct 4 12:16:21 2010 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 BA7C23A6E38; Mon, 4 Oct 2010 12:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4JcvnnssxnZn; Mon, 4 Oct 2010 12:16:16 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 080633A6C09; Mon, 4 Oct 2010 12:16:16 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 0D58CF2404D; Mon, 4 Oct 2010 15:17:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id yE2gOOq069no; Mon, 4 Oct 2010 15:17:02 -0400 (EDT) Received: from [192.168.1.3] (pool-96-231-149-87.washdc.fios.verizon.net [96.231.149.87]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 40030F2403D; Mon, 4 Oct 2010 15:17:15 -0400 (EDT) Message-ID: <4CAA283F.7010708@vigilsec.com> Date: Mon, 04 Oct 2010 15:17:19 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Stephen Hanna References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.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, 04 Oct 2010 19:16:21 -0000 I entered a DISCUSS balot position on this document. I said: > The direction suggested by this document will undermine the privacy > features associated with host-generated CGAs. In general, CGAs are > not used in the same environment as a DHCP server, and I do not see > a justification for this to change. > > Without providing a reason, this document asserts that local a > administrator ought to manage CGA generation parameters. I am > guessing that the concern is the computation burden, but this is not > compelling. Further, RFC 3315 already allows a DHCPv6 server to > reject a CGA generated with unacceptable parameters. > > This document discusses the use of DHCPv6 to assign certificates to > CGA address owners. CGA 'ownership' can already be validated with > the private key, so the need for a certificate is unclear. > > This document states: "... the generation of the Modifier field of a > CGA address is computationally intensive." RFC 3972 seems indicate > otherwise for most key sizes. In general, RSA key pair generation is > not a big concern on modern processors. It might be a mild concern > on mobile devices, but some detailed explanation is required. My biggest concern is raised in the first paragraph. I think we need a compelling reason to erode the privacy properties of CGAs, and I did not find such a reason in the document. Russ On 10/1/2010 10:56 PM, Stephen Hanna 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 discusses several ways that DHCPv6 can be used with > Cryptographically Generated Addresses (CGA), pointing out benefits > and concerns. While the document does discuss security issues in > several places, it often lapses into vague terminology like "one > should carefully consider the impact on security". Given that the > primary benefit of using CGAs is to improve security by providing > address validation without complex key distribution, carefully > analyzing security issues seems necessary for this document. > > On the other hand, the Document Shepherd Write-up for this document > says "The WG was not very energetic on this document. The document > describes possible applications of CGAs and DHCP interaction and > when the WG was asked whether there was enough interest to work on > solutions, the reply was silence. As such, the consensus is based > on most of the WG being indifferent." So maybe this document is > only intended as a sketch of possible issues that can be explored > later in a more in-depth document if someone is interested in > doing so. If that's the case, maybe it's OK to not fully analyze > all the security implications. However, in that case, I think the > Security Considerations section should state clearly that this > document does not contain a complete security analysis and any > further work in this area should include such an analysis. Nobody > should implement the techniques described in this document without > conducting that more thorough analysis. > > I noticed a few typos. On page 6, the word "certificated" should be > "certified". Three sentences later, "depend on policies" should be > "depending on policies". And the draft names in the Change Log say > "dhacpv6" instead of "dhcpv6". > > Thanks, > > Steve From hartmans@mit.edu Tue Oct 5 17:35:29 2010 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 1A2BA3A709D for ; Tue, 5 Oct 2010 17:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 kjjTeQPJgOtD for ; Tue, 5 Oct 2010 17:35:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 15CDA3A6ED7 for ; Tue, 5 Oct 2010 17:35:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4A65C201B0; Tue, 5 Oct 2010 20:36:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9C30B41DD; Tue, 5 Oct 2010 20:36:24 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org Date: Tue, 05 Oct 2010 20:36:24 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-netconf-with-defaults@tools.ietf.org, netconf-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-netconf-with-defaults 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, 06 Oct 2010 00:35:29 -0000 I've reviewed this document. I see no issues as a secdir reviewer nor any general issues I choose to raise. This document defines how default values are handled within netconf and forces servers to adopt one of three strategies: * Always expand default values into the configuration ** Always trim default values * Indicate which values are default and which values have been set by a *user --Sam From gcamaril@gmail.com Tue Oct 5 00:32:12 2010 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 1CA533A6EC8; Tue, 5 Oct 2010 00:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.574 X-Spam-Level: X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0y-LnHRqZmQ; Tue, 5 Oct 2010 00:32:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 09E7F3A6E2C; Tue, 5 Oct 2010 00:32:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7cbfae00000264e-17-4caad4b12de7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 45.2A.09806.1B4DAAC4; Tue, 5 Oct 2010 09:33:05 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Oct 2010 09:33:05 +0200 Received: from [131.160.126.165] ([131.160.126.165]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Oct 2010 09:33:05 +0200 Message-ID: <4CAAD4B0.2080807@gmail.com> Date: Tue, 05 Oct 2010 10:33:04 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Oct 2010 07:33:05.0168 (UTC) FILETIME=[8C7A3100:01CB645F] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 06 Oct 2010 06:26:37 -0700 Cc: Cullen Jennings , Ted Hardie , The IETF , "secdir@ietf.org" , "ben@estacado.net" , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch 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, 05 Oct 2010 07:32:12 -0000 Hi, Christer has submitted a new revision of this draft: https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ Those of you who sent IETF LC comments on this draft, could you please have a look at the new version and let Christer know if he has addressed your concerns? Thanks, Gonzalo On 31/08/2010 8:39 PM, Christer Holmberg wrote: > Hi, > > The purpose of this e-mail is to address the secdir comments given by Richard > Barnes and Ted Hardie. Due to summer vacations, standardization meetings > etc it took a while to put the e-mail together, and we appologise for that. > > GENERAL > ======= > > First, the draft does NOT propose any changes to the TLS authentication > procedures – that will be clarified. The changes are only related to the > procedure for matching an incoming MSRP message to an MSRP session that > has been negotiated using SDP – once any TLS authentication procedure has > already taken place. > > So, in case of TLS and name based authentication, if an SBC/ALG modifies > the a=path MSRP URI, the TLS authentication WILL fail. That is the current > behavior, and sessmatch doesn’t change that. > > We understand that this fact needs to be clearly indicated in the draft. > > Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs > and SIP aware firewalls can be in the SIP signaling path without acting as > MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays > the SBC/ALG needs to act as MSRP B2BUA, as today. > > Sessmatch aims to extend the usability of MSRP peer to peer communication to > scenarios where simple ALGs/SBCs are used, and at least in our experience > customer interest for standard MSRP has grown (from more or less zero) > dramatically due to sessmatch. And, OMA, which previously used a *non-standard* > version of MSRP (with no interoperability with standard MSRP), has also agreed > to switch to sessmatch (even if it required a number of changes in their > specifications). > > Second, the intention of sessmatch is not to modify the MSRP URI matching rules, > but rather to not use MSRP URI matching for session matching. > > Please also note that when we talk about SBCs/ALGs, we refer to entities that > normally do NOT have the capability to act as MSRP B2BUAs. > > We will comment the individual comments based on the assumptions above. > > > Comments from Richard > ===================== > >> 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 changes the URI matching algorithm used in MSRP. MSRP sessions >> are typically initiated using SDP bodies in SIP. These SDP >> bodies contain MSRP URIs that the peers use to contact each other. >> When one peer receives a request to initiate a session, he verifies that the >> URI being requested is one that he initiated in SDP, thereby using the URI as a >> shared secret to authenticate that the originator of the session actually >> received the SDP body in question. >> >> According to the current SDP specification, this comparison is performed over >> the whole URI; this document restricts the comparison to the "session-id" >> component, omitting the host, port, and transport components. The goal of the >> document is to facilitate a certain class of man-in-the-middle attack, namely >> to allow a signaling intermediary to insert a media intermediary. The >> restriction on the URI comparison is needed in order for the media intermediary >> not to have to modify URIs in MSRP packets to reflect the modifications to URIs >> in SDP bodies performed to redirect traffic through the media intermediary. > > When an MSRP UA receives an MSRP packet it performs msrp session matching in order > to verify that the msrp packet belongs to an existing SDP negotiated msrp session > at the UA. RFC4975 prescribes that URI matching should be used for session matching. > We argue that the namespace scoping of the session-id values that use of URI matching > brings is unnecessary. The 80-bit randomness of the session-id and the fact that it > was the UA itself that decided on the session-id value and can ensure that it is > unique within the UA makes the session-id sufficiently unique for session matching. > Sessmatch is not changing the MSRP URI matching algorithm, it is changing the session > matching algorithm not to use MSRP URI matching. > >> I have a few significant reservations about this document: >> >> 1) This extension makes it more difficult for MSRP entities to secure their >> communications against attackers in the signaling path. The current model >> provides a basic integrity protection, in that signaling intermediaries cannot >> redirect traffic to an arbitrary third party; they must at least advise the >> third party about how to modify MSRP packets. The proposed modification would >> remove even this cost. > > If we do not introduce the sessmatch change then the only alternative for MSRP > connections to be able to be set up when SBCs or SIP aware firewalls are in the > SIP signaling path is for these to introduce MSRP B2BUA support. This is probably > not feasible for most SBCs and SIP aware firewalls, and if it actually were > feasible then it would mean as big a security problem, or even bigger, than > sessmatch. The choice is thus to not use MSRP at all in presence of such devices > or to introduce sessmatch. Not to fix this probably would mean that use of MSRP > will be marginalized. > >> 2) Moreover, it raises the cost of providing integrity protection to messages, >> since Alice must now employ both integrity and confidentiality protections on >> an end-to-end basis; if her messages are only integrity-protected, then a proxy >> can remove the integrity protection and redirect traffic without it being >> observable to Alice. >> >> The document needs to clarify what the impacts are for authentication in secure >> modes of MSRP. In particular: >> -- The distinction between "self-signed" and "public" certificates is >> inappropriate. The proper distinction is between the name-based authentication >> in Section 14.2 of RFC 4975 and the fingerprint-based authentication in Section >> 14.4. > > We cannot find the terminology “name-based” authentication in RFC 4975. The RFC talks > about TLS authentication using either certificates from well-known certificate > authorities, or using self-signed certificates together with certificate fingerprints. > > Having said that, however, we DO agree that the terminology you suggest is more > appropriate than what we have used and we will introduce this terminology and explain > it in the Convention section of the sessmatch draft. > >> -- In either case, changing the host name need not result in an authentication >> failure, since the media intermediary can simply authenticate as itself to both >> endpoints, having changed the respective MSRP URIs appropriately. > > A media intermediary can only do this if it is an MSRP B2BUA, and sessmatch was > introduced just to avoid most SBCs and ALGs having to implement an MSRP B2BUA in order > to allow standard MSRP deployment. > >> -- There is currently no requirement that an endpoint identity in the To-Path >> URI matches the endpoint identity authenticated at the TLS layer, because these >> two are required to be the same. This document changes that assumption, and >> should note that these two identities can differ. > > We will explicitly mention this. > >> The document also precludes any name-based multiplexing, where a single MSRP >> process (single IP address and port) directs requests to different virtual >> recipients based on the domain name in the To-Path header. (In analogy to >> Host-based multiplexing in HTTP, which is very widely deployed.) Since with >> this extension, the domain in the To- Path is completely unpredictable from the >> recipient's perspective, it is useless to the recipient. > > That is correct, but there should be no problem for a single MSRP process (single > IP address and port) to direct requests to different virtual recipients - based > on the session-id instead. It is only needed for the different virtual recipients > to inform the receiver process on which session-ids that are currently negotiated > instead of informing it on which domain name the virtual recipient shall be > associated with. > >> The document has no backward-compatibility. MSRP implementations that do not >> support this extension will not be able to receive MSRP sessions from >> implementations that do. In that regard, this document seems more like a new >> version of MSRP rather than an update. > > It is not true that there is no backwards compatibility. If there are no > SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem for MSRP > implementations that do not support the sessmatch extension to receive MSRP > sessions from implementations that do. > > MSRP implementations that do not support the sessmatch extension are however not > able to establish MSRP end to end conversations if there are ALGs/SBCs in the > session path (unless these implement MSRP B2BUA) and sessmatch does not change this > fact – it will not work disregarding if the other endpoint supports sessmatch or not. > >>>> I also note that the security considerations, in addition to having >>>> some fairly disingenuous language about the impact of this change, >>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>> would have on them. >>> >>> There are no impacts to MSRPS URIs. I assumed it would be implicitly >>> understood since MSRPS URIs are not mentioned in the draft. >>> >>> However, we could explicitly make it clear by modifying the first >>> sentences of section 5: >>> >>> "The change of session matching procedure does not impact the >>> format of MSRP URIs, disregarding if the "msrp" scheme or the "msrps" scheme >>> is used. However, MSRP endpoints can only check that the session-id part of >>> the MSRP URI..." >> >> The conflict here is that with MRSPS authentication, the name in the >> certificate is checked against the domain name in the URI, which was OK when >> the URI in the message was required to be the same. By allowing the domain >> name in the message to change, this draft removes man-in-the-middle protection >>from MSRPS. >> >> The document notes that a SIP MitM can already direct the user to another >> destination. However, if the peers use MSRPS with the current authentication >> scheme, the MitM will not be able to be a part of the resulting MSRPS session, >> since he can't authenticate as one of the endpoints. If only the session ID is >> used in comparisons, the MitM can patch himself in by changing the domain in >> the MSRPS URI. (Which actually seems to be the intended use case for this >draft.) >> >> So the current document does introduce a new MitM vulnerability to MSRPS. > > Sessmatch does not change the fact that name based TLS authentication for MSRPS > will fail if an SBC or ALG has modified the hostname value in the MSRP URI in the > SDP a=path attribute without also acting as MSRP B2BUA. > > > Comments from Ted > ================= > >> I join Richard in believing that this document makes changes beyond that which >> could be understood as "updating" the MSRP URI scheme processing. >> >> ... >> >> I also note that the security considerations, in addition to having some fairly >> disingenuous language about the impact of this change, seems to fail to mention >> MSRPS URIs and what, if any, impact this would have on them. > > We will clarify what impacts there are. > > ------- > >>>> To highlight one particular aspect, RFC 4975 does not require >>>> session-ids to be present, a fact noted both in the ABNF and in this >>>> text: >>>> >>>> 4. The session-id part is compared as case sensitive. A URI without >>>> a session-id part is never equivalent to one that includes one. >>>> >>>> A matching scheme which relies on a URI section which is not >>>> guaranteed to be present has some interesting problems ahead of it. If >>>> this effectively makes their use mandatory, that requires a change to >>>> the fundamental ABNF and text. >>> >>> An MSRP URI in an SDP offer or answer for an MSRP session MUST include a >>> session-id part, so I believe the comment is >>> based on incorrect assumptions. >> >> This is not indicated in the URI matching section > > We will clarify that sessmatch conformant UAs do not use MSRP URI matching in > order to perform MSRP session matching. > >>> Section 6 of RFC 4975 says: >>> >>> "The session-id part identifies a particular session of the >>> participant. The absence of the session-id >>> part indicates a reference to an MSRP host device, but does not refer to a >>> particular session at that device." >>> >> >> The full section from which that quote is taken is: >> >> The MSRP URI authority field identifies a participant in a particular >> MSRP session. If the authority field contains a numeric IP address, >> it MUST also contain a port. The session-id part identifies a >> particular session of the participant. The absence of the session-id >> part indicates a reference to an MSRP host device, but does not refer >> to a particular session at that device. A particular value of >> session-id is only meaningful in the context of the associated >> authority; thus, the authority component can be thought of as >> identifying the "authority" governing a namespace for the session-id. >> >> This proposal changes the concept of a namespace authority present in the URI >> matching section of RFC 4975. I am sorry if my wry reference to this in my >> previous message was hard to follow; I should have known better. >> >> To be more plain, this proposal fundamentally changes the matching semantics of >> the URI set out in RFC 4975, by requiring a match on only a portion of the URI. >> At a bare minimum, this would require noting a normative update to section 6 >> and 6.1 of RFC 4975, which this draft does not do. In reality, this is >> unlikely to be sufficient, as URI matching semantics do not generally have the >> concept of ignoring the authority in providing a match (at least in my reading >> of the RFC 3986 "ladder of comparison" text). That means you'd have to special >> case the MSRP matching semantics, rather than have the URI be parsed and >> compared using a standard library. > > Sessmatch removes the URI matching as a means to do MSRP session matching, and > replaces it with a pure session-id matching. There is no need to create a new > URI scheme that does not re-use the authority component. We believe the minimum > 80-bit randomness of the session-id, together with the fact that the UA itself > generates the session-id it matches on, to be enough for the session-id to be > unique in the scope of the sessions that are active at the UA. > > Also, the security of the matching is not particularly decreased, since it is > relatively easy to find out the authority name anyway. > >>>> I also note that the security considerations, in addition to having >>>> some fairly disingenuous language about the impact of this change, >>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>> would have on them. >>> >>> There are no impacts to MSRPS URIs. I assumed it would be implicitly understood >>> since MSRPS URIs are not mentioned in the draft. >>> >>> However, we could explicitly make it clear by modifying the first sentences of >>> section 5: >>> >>> "The change of session matching procedure does not impact the format of MSRP >>> URIs, disregarding if the "msrp" scheme or the "msrps" scheme is used. >>> However, MSRP endpoints can only check that the session-id part of the MSRP >>> URI..." >>> >> This doesn't seem to me to actually work, based on Richard's comments, unless >> what you mean to say is "if MSRPS is in use, nothing in this draft can be >> used". That gives you different matching semantics for MSRPS (authority must >> be present and must be matched using TLS semantics) vs MSRP (only session-id is >> checked) which is at the very least a violation of the principle of least >> surprise (no other foo over TLS protocol works that way that I know of ). > > Session matching is done when receiving MSRP packets on an already established TCP > or TCP/TLS connection, and there will not be any different session matching procedure > depending on if the connection uses TLS or plain TCP. > > Regards, > > Christer > From hallam@gmail.com Wed Oct 6 17:42:34 2010 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 E597D3A7015; Wed, 6 Oct 2010 17:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.201, 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 Zt1hiaDhdvUU; Wed, 6 Oct 2010 17:42:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0543A3A6EB3; Wed, 6 Oct 2010 17:42:31 -0700 (PDT) Received: by wwj40 with SMTP id 40so143677wwj.13 for ; Wed, 06 Oct 2010 17:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=6oluo8mEUCOg46O90oBTlK0LgvM2qsKzVrlytsRAWyQ=; b=t20vu5mpCioBetpElSt5FY61DAlE9x4BTuzO2hOPAtyRO5z4+pUpK1iWTuDTlrZ8Sx 6tgN1qwTUlGLs/MniCKt8w5IoIa2v49aw0fJrQ2HyppLOL08I0vBv5iIh95qM2qNtmbR rovJuCYcY5QtPiQscUe9s/n7tgmCLO4fGgj70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dpYlaMBajTpp5/XIYtVp686U/Osp+a6C3r9jXyzQfvzpgWg8wPBt4+FHqXdU1UrqjN mwezfRmjbcBB7nUeXqhvu1lLwcYH5Gd+058i5UTPHPt3ljBAGKvhrCuHB5VPbckiKmfc PaxeSVTa1no+mvS8P/1aFVKTAzvnGpNKz0l9o= MIME-Version: 1.0 Received: by 10.216.186.207 with SMTP id w57mr1572015wem.19.1286412192266; Wed, 06 Oct 2010 17:43:12 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Wed, 6 Oct 2010 17:43:12 -0700 (PDT) Date: Wed, 6 Oct 2010 20:43:12 -0400 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, iesg@ietf.org, Kurt.Zeilenga@Isode.COM Content-Type: multipart/alternative; boundary=001485f1e2e8c13a4d0491fc2d56 Subject: [secdir] SECDIR Review of draft-zeilenga-ldap-dontusecopy-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: Thu, 07 Oct 2010 00:42:35 -0000 --001485f1e2e8c13a4d0491fc2d56 Content-Type: text/plain; charset=ISO-8859-1 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 what is essentially a 'send original, not cached flag' for LDAP. Only security issue I can see here is that the following does not give the purpose very clearly. 4. Security Considerations This control is intended to be provided where providing service using copied information might lead to unexpected application behavior. Designers of directory applications should consider where it is appropriate for clients to provide this control. Designers should consider whether use of copied information, in particular security and policy information, may result insecure behavior. I would suggest the following instead 4. Security Considerations This control is intended to be provided where providing service using copied information might lead to unexpected application behavior. Use of the Don't Use Copy control may permit an attacker to perform or amplify a Denial of Service attack by causing additional server resources to be employed. LDAP is frequently used for storage and distribution of security sensitive information, including access control and security policy information. Failure to use the Don't Use Copy control may thus permit an attacker to gain unauthorized access by allowing reliance on stale data. The meaning is unchanged, but the additional context might help the reader. -- Website: http://hallambaker.com/ --001485f1e2e8c13a4d0491fc2d56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I = have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. =A0Thes= e comments were written primarily for the benefit of the security area dire= ctors. =A0Document editors and WG chairs should treat these comments just l= ike any other last call comments.

This document describes what is essentially a 'send original, = not cached flag' for LDAP.

Only security issue= I can see here is that the following does not give the purpose very clearl= y.

4.  Security Considerations

  This control is intended to be provided where providing service using
  copied information might lead to unexpected application behavior.
  Designers of directory applications should consider where it is
  appropriate for clients to provide this control.  Designers should
  consider whether use of copied information, in particular security and
  policy information, may result insecure behavior.
=
I would suggest the following instead

4.  Security Considerations

  This control is intended to be provided where providing service using
  copied information might lead to unexpected application behavior.
Use of the Do= n't Use Copy control may permit an attacker to perform or amplify a Denial of Service attack by causing additional server resources to be employed.
  LDAP is frequently used for storage and distribution =
of security
  sensitive information, including access control and security policy
  information. Failure to use the Don't Use Copy control may thus
  permit an attacker to gain unauthorized access by allowing reliance
  on stale data.
The meaning is unchanged, but the a= dditional context might help the reader.

--001485f1e2e8c13a4d0491fc2d56-- From sra@hactrn.net Thu Oct 7 07:03:34 2010 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 E20463A6F33; Thu, 7 Oct 2010 07:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, LONGWORDS=1.803, NO_RELAYS=-0.001, 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 v7Sp-S9fRXO7; Thu, 7 Oct 2010 07:03:34 -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 B1A933A6F34; Thu, 7 Oct 2010 07:03:33 -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-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 89A1F28441; Thu, 7 Oct 2010 14:04:34 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2BA3C22829; Thu, 7 Oct 2010 10:04:34 -0400 (EDT) Date: Thu, 07 Oct 2010 10:04:34 -0400 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org, draft-ietf-grow-bgp-graceful-shutdown-requirements.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20101007140434.2BA3C22829@thrintun.hactrn.net> Subject: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-requirements-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: Thu, 07 Oct 2010 14:03:35 -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 discusses requirements for a proposed BGP extension to allow graceful transition between redundant sessions during planned maintenance windows. Unexpected failures are out of scope, the point of the exercise is just to minimize avoidable traffic loss. While the draft does not say so in so many words, a high-level description of the desired mechanism might be the ability to give a neighbor some advance notice of a planned change along with a hint of what the normal BGP data will look like after that change, so that the neighbor can prepare for the change. As far as I can tell, the required mechanism is likely to be harmless, assuming it can be kept simple: as described, the protocol extension would be a conversation between adjacent routers, either of which could bring down the session or inject garbage into the session anyway, so the probability that the extension would introduce a new attack vector seems low. In theory an evil neighbor might do something nasty by providing misleading advance information, but again, said neighbor could do the same thing now and have it take effect immediately, so there's no obvious gain here for an attacker. The security considerations section is weak, although as this is a requirements document it is not entirely unreasonable to postpone real security considerations until the discussion of solutions. A paragraph (like the preceding one in this review) giving a brief explanation of why this kind of mechanism is likely to be harmless would be nice, but given the lateness of this review (mea culpa) I will leave it up to the IESG to decide whether to ask for this. I have no serious security concerns regarding this document. From sra@hactrn.net Thu Oct 7 10:42:36 2010 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 0F4913A6F9C; Thu, 7 Oct 2010 10:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Unmsjppo+PFr; Thu, 7 Oct 2010 10:42:35 -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 DEE1B3A6F35; Thu, 7 Oct 2010 10:42:34 -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-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id A10AB28441; Thu, 7 Oct 2010 17:43:34 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 46F4122829; Thu, 7 Oct 2010 13:43:34 -0400 (EDT) Date: Thu, 07 Oct 2010 13:43:34 -0400 From: Rob Austein To: bruno.decraene@orange-ftgroup.com In-Reply-To: References: <20101007140434.2BA3C22829@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20101007174334.46F4122829@thrintun.hactrn.net> Cc: draft-ietf-grow-bgp-graceful-shutdown-requirements.all@tools.ietf.org, zubair.ahmad@orange-ftgroup.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-requirements-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: Thu, 07 Oct 2010 17:42:36 -0000 At Thu, 7 Oct 2010 18:36:36 +0200, Bruno Decraene wrote: ... > If this is fine for you and the IESG, I can commit the change in the > document. Otherwise, comments are welcomed. Proposed update would satisfy me. Whether you should make that change, hold off on it, fold it into a paper airplane and sail it out the window, ... would be for your AD or WG chairs to decide, not me. From weiler+secdir@watson.org Sun Oct 10 06:25:28 2010 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 992043A67FA for ; Sun, 10 Oct 2010 06:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 418kPnLQWDXA for ; Sun, 10 Oct 2010 06:25:27 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 621823A67B1 for ; Sun, 10 Oct 2010 06:25:27 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o9ADQa0M022600 for ; Sun, 10 Oct 2010 09:26:36 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o9ADQZq8022596 for ; Sun, 10 Oct 2010 09:26:35 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 10 Oct 2010 09:26:35 -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.2.3 (fledge.watson.org [127.0.0.1]); Sun, 10 Oct 2010 09:26:36 -0400 (EDT) Subject: [secdir] Assignments 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: Sun, 10 Oct 2010 13:25:28 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Barry Leiba is next in the rotation. For telechat 2010-10-21 Reviewer LC end Draft Shawn Emery T 2010-10-11 draft-arkko-townsley-coexistence-05 Phillip Hallam-Baker T 2010-10-11 draft-zeilenga-ldap-dontusecopy-08 Tero Kivinen T 2010-10-19 draft-ietf-netlmm-lma-discovery-06 Last calls and special requests: Reviewer LC end Draft Richard Barnes 2010-10-21 draft-ietf-xmpp-3920bis-17 Richard Barnes 2010-10-21 draft-ietf-xmpp-3921bis-15 Richard Barnes 2010-10-21 draft-ietf-xmpp-address-05 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Jeffrey Hutzelman 2010-10-13 draft-ietf-mpls-ldp-upstream-08 Charlie Kaufman 2010-10-12 draft-ietf-storm-ifcpmib-05 Scott Kelly 2010-10-21 draft-ietf-avt-rtp-h264-rcdo-07 Stephen Kent 2010-10-21 draft-ietf-sipcore-reinvite-06 Julien Laganier 2010-10-22 draft-ietf-avt-rtp-svc-23 David McGrew - draft-ietf-ecrit-framework-11 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-3920bis-17 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-3921bis-15 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-address-05 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-03 Glen Zorn 2010-09-16 draft-ietf-l3vpn-mvpn-spmsi-joins-01 From shengjiang@huawei.com Fri Oct 8 19:40:13 2010 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 49D4D3A679F; Fri, 8 Oct 2010 19:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 LQidKQGPXRb9; Fri, 8 Oct 2010 19:40:12 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0BA173A677C; Fri, 8 Oct 2010 19:40:12 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA000LP24SJNN@szxga01-in.huawei.com>; Sat, 09 Oct 2010 10:41:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA0006RI4SJDW@szxga01-in.huawei.com>; Sat, 09 Oct 2010 10:41:07 +0800 (CST) Received: from j66104a ([10.110.98.46]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA000JDB4SION@szxml06-in.huawei.com>; Sat, 09 Oct 2010 10:41:07 +0800 (CST) Date: Sat, 09 Oct 2010 10:41:08 +0800 From: Sheng Jiang In-reply-to: To: 'Stephen Hanna' , ietf@ietf.org, iesg@ietf.org, secdir@ietf.org, draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org Message-id: <005601cb675b$6dbe1610$2e626e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acth3WZtFoUbk+23ReaFVG39Xm1qzwFeQ3IQ X-Mailman-Approved-At: Sun, 10 Oct 2010 08:25:44 -0700 Subject: Re: [secdir] secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.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: Sat, 09 Oct 2010 02:40:13 -0000 Hi, Stephen, Sorry for the late reply. We was in Chinese National Holiday. Please see my reply below. Best regards, Sheng > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Saturday, October 02, 2010 10:56 AM > To: ietf@ietf.org; iesg@ietf.org; secdir@ietf.org; > draft-ietf-csi-dhcpv6-cga-ps@tools.ietf.org > Subject: secdir review of draft-ietf-csi-dhcpv6-cga-ps-04.txt > > 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 discusses several ways that DHCPv6 can be used > with Cryptographically Generated Addresses (CGA), pointing > out benefits and concerns. While the document does discuss > security issues in several places, it often lapses into vague > terminology like "one should carefully consider the impact on > security". Given that the primary benefit of using CGAs is to > improve security by providing address validation without > complex key distribution, carefully analyzing security issues > seems necessary for this document. > > On the other hand, the Document Shepherd Write-up for this > document says "The WG was not very energetic on this > document. The document describes possible applications of > CGAs and DHCP interaction and when the WG was asked whether > there was enough interest to work on solutions, the reply was > silence. As such, the consensus is based on most of the WG > being indifferent." So maybe this document is only intended > as a sketch of possible issues that can be explored later in > a more in-depth document if someone is interested in doing > so. If that's the case, maybe it's OK to not fully analyze > all the security implications. However, in that case, I think > the Security Considerations section should state clearly that > this document does not contain a complete security analysis > and any further work in this area should include such an > analysis. Nobody should implement the techniques described in > this document without conducting that more thorough analysis. I guess that's the case. I am fine to add the statement you suggested into the security considerations. > I noticed a few typos. On page 6, the word "certificated" > should be "certified". Three sentences later, "depend on > policies" should be "depending on policies". And the draft > names in the Change Log say "dhacpv6" instead of "dhcpv6". Thanks. We will fix it with other comments in the future version. Regards, Sheng > Thanks, > > Steve > From rogaglia@cisco.com Thu Oct 7 03:56:24 2010 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 BCECC3A7021; Thu, 7 Oct 2010 03:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.916 X-Spam-Level: X-Spam-Status: No, score=-9.916 tagged_above=-999 required=5 tests=[AWL=0.682, 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 LStCYjdXrTdx; Thu, 7 Oct 2010 03:56:22 -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 9CA713A6A03; Thu, 7 Oct 2010 03:56:20 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsIANNErUyQ/khLgWdsb2JhbACES4FIlBsBiBYVAQEWIiKnFJxGAoVFBIFdiGM X-IronPort-AV: E=Sophos;i="4.57,297,1283731200"; d="scan'208,217";a="66053839" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2010 10:57:21 +0000 Received: from dhcp-10-55-80-224.cisco.com (dhcp-10-55-80-224.cisco.com [10.55.80.224]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o97AvKAG020636; Thu, 7 Oct 2010 10:57:21 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-280-1051710693 From: Roque Gagliano In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC3D015B@nemo.columbia.ads.sparta.com> Date: Thu, 7 Oct 2010 12:57:52 +0200 Message-Id: <634F9C92-61D0-4D17-AA80-D02A02AFB676@cisco.com> References: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> <241F9803-ED2F-48B2-B192-2AC02B280433@cisco.com> <4C8E41F6.906@it.uc3m.es> <4C8F90D4.3040301@ieca.com> <5ABE30CE099A524CBF95C715D37BCACC3D015B@nemo.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 10 Oct 2010 08:25:44 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, =?iso-8859-1?Q?Garc=EDa?= , draft-ietf-csi-proxy-send.all@tools.ietf.org, Ralph Droms , marcelo bagnulo braun , csi-chairs@tools.ietf.org, IESG IESG Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-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: Thu, 07 Oct 2010 10:56:24 -0000 --Apple-Mail-280-1051710693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Sandra, Both document have now been updated to include the new EKU. I believe = that you can now re-visit your review. Regards, Roque Ref:=20 http://www.ietf.org/id/draft-ietf-csi-send-cert-08.txt http://tools.ietf.org/html/draft-ietf-csi-proxy-send-05 On Sep 14, 2010, at 7:33 PM, Murphy, Sandra wrote: > Hopefully readable. As it is sent from a smartphone. >=20 > Roque and I have communicated about timing of my rereview. He says I = might as well wait for the wg to decide. I am interested, iirc, in what = actions or messages require what certs >=20 >=20 > Sandy >=20 > -----Original Message---. Looking forward to (having time to) = reviewing the new draft. >=20 > -- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Tue 9/14/2010 11:12 AM > To: marcelo bagnulo braun > Cc: Roque Gagliano; draft-ietf-csi-send-cert@tools.ietf.org; = secdir@ietf.org; Murphy, Sandra; Garc=EDa; = draft-ietf-csi-proxy-send.all@tools.ietf.org; "Alberto "@core3.amsl.com; = Ralph Droms; csi-chairs@tools.ietf.org; IESG IESG; Russ Housley > Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 >=20 > marcelo bagnulo braun wrote: > > > > > > El 13/09/10 16:29, Roque Gagliano escribi=F3: > >> Hi Ralph, > >> > >> I can answer for the draft-ietf-csi-send-cert document. The new > >> revision addressed all the DISCUSS positions for that document. > >> > >> As I mentioned in a previous email, we came back to the WG to ask = one > >> change that is been requested by one of the authors of the > >> draft-ietf-csi-proxy-send document. The change consist of adding a = new > >> EKU. > >> > >> I think is best to wait for the WG opinion on this issue because if > >> this additional EKU is needed, it makes sense to have it in this = same > >> document. > >> > > Right, the problem is that the WG is slient, so we probably need to > > solve this in some other way i.e. propose something to the WG and = see if > > anybody objects. > > > > The new EKU is the proposed way to deal with one comment from = Sandy's > > review of the proxy send document. It seems we could live without, = but > > it would be a somehow inferior solution. I would suggest that unless > > getting a new EKU is a lot of work, we go ahead with that. >=20 > Getting an EKU is pretty easy. Ask Russ Housley > (cced) for one. He controls assigning the OID > out of the PKIX arc. Obvioulsy, you'll need to add some text in the > document to explain its use. >=20 > spt >=20 > > would that make sense? > > > > Regards, marcelo > > > > > >> Regards, > >> Roque. > >> > >> = --------------------------------------------------------------------------= -------------------------------------------------------------------- > >> > >> Roque > >> Gagliano = =20 > >> Cisco Systems International S=E0rl =20 > >> Software Engineer Mailstop > >> ROL01/2/ > >> Corporate Development Technology Group Avenue = des > >> Uttins 5 > >> 1180 Rolle > >> rogaglia@cisco.com = Switzerland > >> Phone: +41 21 823 2805 =20 > >> > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > >> On Sep 13, 2010, at 4:21 PM, Ralph Droms wrote: > >> > >>> Can you clarify the status of draft-ietf-csi-send-cert and > >>> draft-ietf-csi-proxy-send? Does the new rev of > >>> draft-ietf-csi-send-cert address the DISCUSS positions on both = docs? > >>> > >>> - Ralph > >>> > >>> On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano wrote: > >>> > >>>> Hi Sandra, > >>>> > >>>> I issued a new version of the draft draft-ietf-csi-send-cert = documents. > >>>> > >>>> I believe the new version addresses all the concerns expressed in > >>>> this mail exchange. > >>>> > >>>> Regards, > >>>> > >>>> Roque > >>>> > >>>> > >>>> > >>>> > >>>> On Jul 6, 2010, at 5:32 PM, Alberto Garc=EDa wrote: > >>>> > >>>>> Hi, > >>>>> The text of this email has been extracted from a thorough review = of > >>>>> draft-ietf-csi-proxy-send being made by Sandra Murphy. > >>>>> The reason why the email has been separated is to include the > >>>>> authors of draft-ietf-csi-send-cert in the discussion of this = part > >>>>> of the text, since I think some of the issues raised by Sandra > >>>>> affect this document. > >>>>> > >>>>> I include my comments inline. > >>>>> > >>>>> | -----Mensaje original----- > >>>>> | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > >>>>> | Enviado el: viernes, 02 de julio de 2010 2:31 > >>>>> | Para: iesg@ietf.org; secdir@ietf.org; > >>>>> draft-ietf-csi-proxy-send.all@tools.ietf.org > >>>>> | Asunto: secdir review of draft-ietf-csi-proxy-send-04 > >>>>> | > >>>>> | This is a review of draft draft-ietf-csi-proxy-send-04.txt. > >>>>> | > >>>>> | 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 provides new Neighbor Discovery options that = will > >>>>> secure > >>>>> | proxied Neighbor Discovery messages. It is an update to: > >>>>> | > >>>>> | RFC4861: Neighbor Discovery in IPv6 > >>>>> | RFC4389: Neighbor Discovery Proxies (ND Proxy) > >>>>> | RFC3971: Send Neighbor Discovery (SEND) > >>>>> | > >>>>> | This draft relies on draft draft-ietf-csi-send-cert-04.txt. > >>>>> | > >>>>> | The need for new mechanisms for security for proxied messages = is > >>>>> explained > >>>>> | in draft-ietf-csi-sndp-prob-04.txt. > >>>>> | > >>>>> | I've read all of these, but it is pretty new to me, so I = could > >>>>> have missed > >>>>> | something. > >>>>> | > >>>>> | The Neighbor Discovery protocol communicates link-level > >>>>> addresses in the > >>>>> | protocol messages. The ND Proxy extension would make changes = to > >>>>> those > >>>>> | fields. SEND, which secures the base ND protocol, relies on = the > >>>>> sender of > >>>>> | a message computing a signature associated with the source IP > >>>>> address of > >>>>> | the message. Any ND Proxy changes to messages would = invalidate the > >>>>> | signature and the ND Proxy itself could not generate a new > >>>>> signature > >>>>> | (since it would not have the private key associated with the > >>>>> source IP > >>>>> | address). This draft introduces a Proxy Signature (PS) = option > >>>>> to secure > >>>>> | the proxied messages. > >>>>> | > >>>>> | RFC3971, the base SEND spec, defines a new Router = Authorization > >>>>> | Certificate profile, dependent on RFC3779, which authorizes = the > >>>>> router to > >>>>> | act as a router and act for certain prefixes. Message > >>>>> authorization in > >>>>> | SEND of some ND messages checks the prefixes listed in the > >>>>> certificate > >>>>> | against the prefixes mentioned in those messages. There is = no > >>>>> explicit > >>>>> | representation in the certificate of the authority to act as = a > >>>>> router. > >>>>> | Possession of the certificate in SEND serves as implicit > >>>>> authorization to > >>>>> | act as a router, as that was the only authorization defined. > >>>>> | > >>>>> | With the introduction of proxies, there was a need to > >>>>> distinguish the > >>>>> | various roles that a node might have in the network. No = longer is > >>>>> | possession of a certificate adequate authorization. The = draft > >>>>> | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field = to > >>>>> distinguish > >>>>> | three different roles: router, proxy and owner. That draft > >>>>> notes that > >>>>> | multiple key purposes are possible. I believe that it is = also > >>>>> possible to > >>>>> | have single roles - so a node could be a proxy but not a = router. > >>>>> > >>>>> Yes, of course single roles are supported. > >>>>> > >>>>> | With the extensions of the csi-send-cert draft, possession of = a > >>>>> | certificate is no longer proof of any particular = authorization.=20 > >>>>> It seem > >>>>> | clear to me that the authorization validation described in > >>>>> RFC3971 is no > >>>>> | longer sufficient. I believe that a discussion is needed of > >>>>> what messages > >>>>> | require or allow each particular key purpose authorization.=20= > >>>>> Issuing an > >>>>> | RA, for example, seems likely to require the "router" value = of > >>>>> the key > >>>>> | purpose field, if the new certificate format was used for > >>>>> authorization. > >>>>> | Issuing an NA may require the "owner" value of the key = purpose > >>>>> field, if > >>>>> | the new certificate format was used for authorization rather > >>>>> than a CGA. > >>>>> | I do not know if that discussion would be more appropriate = here > >>>>> or in the > >>>>> | csi-send-cert draft, or another draft entirely that updates = RFC3971 > >>>>> | directly. > >>>>> | > >>>>> | If a SPND proxy was using SEND to communicate with other = nodes that > >>>>> | understood SPND, would it be OK to use a new format cert = (with the > >>>>> | "router" KeyPurposeId) as a router certificate for the SEND = RSA > >>>>> Signature > >>>>> | Options? > >>>>> | > >>>>> I see. I agree that this needs more precision. > >>>>> > >>>>> In draft-ietf-csi-send-cert-05, section 7 (it is the same text = as > >>>>> in cert-04) it discusses the messages that are authorized by = each > >>>>> KeyPurposeId > >>>>> - "router authorization value indicates that the > >>>>> certificate has been issued for allowing the router to = advertise > >>>>> prefix(es)" > >>>>> (I understand that implicitly states that it authorizes the > >>>>> generation of RA messages. It is not crystal clear for me if it > >>>>> authorizes NA for routers, although if I had to take this text > >>>>> literally, I would suppose routers would need an 'owner' > >>>>> authorization if this PKI model substitutes RFC3971 CGA > >>>>> authorization, considering that the prefix for NA would be = narrowed > >>>>> in general to one address, while the RA authorization is = prefix-wide) > >>>>> - "proxy authorization value indicates that the > >>>>> certificate has been issued for allowing the proxy to perform > >>>>> proxying of neighbor discovery messages for the prefix(es) = that are > >>>>> mentioned using the X.509 extensions for IP addresses" > >>>>> (I understand it now implicitly states it authorizes for ANY > >>>>> neighbor discovery message. By the way, this is the assumption > >>>>> underlying in general draft-ietf-csi-proxy-send-04: in the > >>>>> application scenarios, some require RA proxying, which is = assumed > >>>>> to be performed by means of the proxy cert) > >>>>> - "owner authorization [...]For an > >>>>> address in such certificate the host can assign the address, = send/ > >>>>> receive traffic from this address, and can respond to NSes = about > >>>>> that > >>>>> address" > >>>>> (this is the clearest of all statements - although I think = issuing > >>>>> secured NS and RS should also be considered) > >>>>> > >>>>> So, as defined now in draft-ietf-csi-proxy-send-04, proxy > >>>>> certificates provide authorization for securing *any* ND = message. > >>>>> Considering the application scenarios, some require proxying RA > >>>>> (PMIPv6 and RFC4389), and the MIPv6 scenario just require NS/NA > >>>>> proxying. > >>>>> > >>>>> In summary so far, there is some specification of the = authorization > >>>>> in draft-csi-send-cert, which I think it would be nice that it > >>>>> could be refined, and if so, my opinion is that the refinement = of > >>>>> which ND message is authorized by each KeyPurposeId should be in > >>>>> that document. > >>>>> However, continuing with this issue, I must say that the way the > >>>>> 'proxy authorization' is defined, and the relationship with the > >>>>> other cases, is not satisfactory for me. > >>>>> I think the use of 'owner' should be restricted for hosts that > >>>>> really own the address (therefore, a substitution of the CGA > >>>>> mechanism) - as opposed to proxies. > >>>>> For the 'proxy authorization', I think it could be refined into > >>>>> something like "proxy host" authorization, and "proxy router" > >>>>> authorization. > >>>>> 'Proxy host' would authorize for proxying NA, NS and RS, and = "proxy > >>>>> router" authorization would authorize RA and Redirect. This = would > >>>>> provide a finer grain which I think would be desirable (for > >>>>> example, MIPv6 does not need protecting neither RA nor = redirect). > >>>>> I think this would work (if so, it should be changed in > >>>>> draft-csi-send-cert). > >>>>> > >>>>> What do you think? (both authors of draft-csi-send-cert, Sandra, > >>>>> etc.). > >>>>> > >>>>> Regards, > >>>>> Alberto > >>>>> > >>>>> > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > >=20 >=20 --Apple-Mail-280-1051710693 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Sandra,

Both document have now been updated = to include the new EKU. I believe that you can now re-visit your = review.

Regards,
Roque

Ref: 


On Sep 14, 2010, at 7:33 PM, Murphy, Sandra = wrote:

Hopefully = readable. As it is sent from a smartphone.

Roque and I have communicated about timing of my rereview.  He says = I might as well wait for the wg to decide.  I am interested, iirc, = in what actions or messages require what certs


Sandy

-----Original Message---.  Looking forward to (having time to) = reviewing the new draft.

--
From: Sean Turner [mailto:turners@ieca.com]
Sent: Tue 9/14/2010 11:12 AM
To: marcelo bagnulo braun
Cc: Roque Gagliano; draft-ietf-csi-sen= d-cert@tools.ietf.org; secdir@ietf.org; Murphy, Sandra; = Garc=EDa; draft-ietf-cs= i-proxy-send.all@tools.ietf.org; "Alberto "@core3.amsl.com; Ralph = Droms; csi-chairs@tools.ietf.org; = IESG IESG; Russ Housley
Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04

marcelo bagnulo braun wrote:
>
>
> El 13/09/10 16:29, Roque Gagliano escribi=F3:
>> Hi Ralph,
>>
>> I can answer for the draft-ietf-csi-send-cert document. The = new
>> revision addressed all the DISCUSS positions for that = document.
>>
>> As I mentioned in a previous email, we came back to the WG to = ask one
>> change that is been requested by one of the authors of the
>> draft-ietf-csi-proxy-send document. The change consist of = adding a new
>> EKU.
>>
>> I think is best to wait for the WG opinion on this issue = because if
>> this additional EKU is needed, it makes sense to have it in = this same
>> document.
>>
> Right, the problem is that the WG is slient, so we probably need = to
> solve this in some other way i.e. propose something to the WG and = see if
> anybody objects.
>
> The new EKU is the proposed way to deal with one comment from = Sandy's
> review of the proxy send document. It seems we could live without, = but
> it would be a somehow inferior solution. I would suggest that = unless
> getting a new EKU is a lot of work, we go ahead with that.

Getting an EKU is pretty easy.  Ask Russ Housley
<housley@vigilsec.com> = (cced) for one.  He controls assigning the OID
out of the PKIX arc.  Obvioulsy, you'll need to add some text in = the
document to explain its use.

spt

> would that make sense?
>
> Regards, marcelo
>
>
>> Regards,
>> Roque.
>>
>> = --------------------------------------------------------------------------= --------------------------------------------------------------------
>>
>> Roque
>> = Gagliano           =             &n= bsp;           &nbs= p;            =             &n= bsp; 
>> Cisco Systems International S=E0rl  
>> Software = Engineer           =             &n= bsp;           &nbs= p;    Mailstop
>> ROL01/2/
>> Corporate Development  Technology = Group           &nb= sp;        Avenue des
>> Uttins 5
= >>           =             &n= bsp;           &nbs= p;            =          1180 Rolle
>> rogaglia@cisco.com   = ;            &= nbsp;           &nb= sp;            = Switzerland
>> Phone: +41 21 823 = 2805           &nbs= p;            =           
>>
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>
>> On Sep 13, 2010, at 4:21 PM, Ralph Droms wrote:
>>
>>> Can you clarify the status of draft-ietf-csi-send-cert = and
>>> draft-ietf-csi-proxy-send?  Does the new rev of
>>> draft-ietf-csi-send-cert address the DISCUSS positions on = both docs?
>>>
>>> - Ralph
>>>
>>> On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano = wrote:
>>>
>>>> Hi Sandra,
>>>>
>>>> I issued a new version of the draft = draft-ietf-csi-send-cert documents.
>>>>
>>>> I believe the new version addresses all the concerns = expressed in
>>>> this mail exchange.
>>>>
>>>> Regards,
>>>>
>>>> Roque
>>>>
>>>>
>>>>
>>>>
>>>> On Jul 6, 2010, at 5:32 PM, Alberto Garc=EDa wrote:
>>>>
>>>>> Hi,
>>>>> The text of this email has been extracted from a = thorough review of
>>>>> draft-ietf-csi-proxy-send being made by Sandra = Murphy.
>>>>> The reason why the email has been separated is to = include the
>>>>> authors of draft-ietf-csi-send-cert in the = discussion of this part
>>>>> of the text, since I think some of the issues = raised by Sandra
>>>>> affect this document.
>>>>>
>>>>> I include my comments inline.
>>>>>
>>>>> |  -----Mensaje original-----
>>>>> |  De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com]
>>>>> |  Enviado el: viernes, 02 de julio de 2010 = 2:31
>>>>> |  Para: iesg@ietf.org; secdir@ietf.org;
>>>>> draft-ietf-cs= i-proxy-send.all@tools.ietf.org
>>>>> |  Asunto: secdir review of = draft-ietf-csi-proxy-send-04
>>>>> |
>>>>> |  This is a review of draft = draft-ietf-csi-proxy-send-04.txt.
>>>>> |
>>>>> |  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 provides new Neighbor = Discovery options that will
>>>>> secure
>>>>> |  proxied Neighbor Discovery messages.  = It is an update to:
>>>>> |
>>>>> |  RFC4861: Neighbor Discovery in IPv6
>>>>> |  RFC4389: Neighbor Discovery Proxies (ND = Proxy)
>>>>> |  RFC3971: Send Neighbor Discovery (SEND)
>>>>> |
>>>>> |  This draft relies on draft = draft-ietf-csi-send-cert-04.txt.
>>>>> |
>>>>> |  The need for new mechanisms for security = for proxied messages is
>>>>> explained
>>>>> |  in draft-ietf-csi-sndp-prob-04.txt.
>>>>> |
>>>>> |  I've read all of these, but it is pretty = new to me, so I could
>>>>> have missed
>>>>> |  something.
>>>>> |
>>>>> |  The Neighbor Discovery protocol = communicates link-level
>>>>> addresses in the
>>>>> |  protocol messages.  The ND Proxy = extension would make changes to
>>>>> those
>>>>> |  fields.  SEND, which secures the base = ND protocol, relies on the
>>>>> sender of
>>>>> |  a message computing a signature associated = with the source IP
>>>>> address of
>>>>> |  the message.  Any ND Proxy changes to = messages would invalidate the
>>>>> |  signature and the ND Proxy itself could not = generate a new
>>>>> signature
>>>>> |  (since it would not have the private key = associated with the
>>>>> source IP
>>>>> |  address).  This draft introduces a = Proxy Signature (PS) option
>>>>> to secure
>>>>> |  the proxied messages.
>>>>> |
>>>>> |  RFC3971, the base SEND spec, defines a new = Router Authorization
>>>>> |  Certificate profile, dependent on RFC3779, = which authorizes the
>>>>> router to
>>>>> |  act as a router and act for certain = prefixes.  Message
>>>>> authorization in
>>>>> |  SEND of some ND messages checks the = prefixes listed in the
>>>>> certificate
>>>>> |  against the prefixes mentioned in those = messages.  There is no
>>>>> explicit
>>>>> |  representation in the certificate of the = authority to act as a
>>>>> router.
>>>>> |  Possession of the certificate in SEND = serves as implicit
>>>>> authorization to
>>>>> |  act as a router, as that was the only = authorization defined.
>>>>> |
>>>>> |  With the introduction of proxies, there was = a need to
>>>>> distinguish the
>>>>> |  various roles that a node might have in the = network.  No longer is
>>>>> |  possession of a certificate adequate = authorization.  The draft
>>>>> |  draft-ietf-csi-send-cert-04.txt uses the = KeyPurposeId field to
>>>>> distinguish
>>>>> |  three different roles: router, proxy and = owner.  That draft
>>>>> notes that
>>>>> |  multiple key purposes are possible.  I = believe that it is also
>>>>> possible to
>>>>> |  have single roles - so a node could be a = proxy but not a router.
>>>>>
>>>>> Yes, of course single roles are supported.
>>>>>
>>>>> |  With the extensions of the csi-send-cert = draft, possession of a
>>>>> |  certificate is no longer proof of any = particular authorization. 
>>>>> It seem
>>>>> |  clear to me that the authorization = validation described in
>>>>> RFC3971 is no
>>>>> |  longer sufficient.  I believe that a = discussion is needed of
>>>>> what messages
>>>>> |  require or allow each particular key = purpose authorization. 
>>>>> Issuing an
>>>>> |  RA, for example, seems likely to require = the "router" value of
>>>>> the key
>>>>> |  purpose field, if the new certificate = format was used for
>>>>> authorization.
>>>>> |  Issuing an NA may require the "owner" value = of the key purpose
>>>>> field, if
>>>>> |  the new certificate format was used for = authorization rather
>>>>> than a CGA.
>>>>> |  I do not know if that discussion would be = more appropriate here
>>>>> or in the
>>>>> |  csi-send-cert draft, or another draft = entirely that updates RFC3971
>>>>> |  directly.
>>>>> |
>>>>> |  If a SPND proxy was using SEND to = communicate with other nodes that
>>>>> |  understood SPND, would it be OK to use a = new format cert (with the
>>>>> |  "router" KeyPurposeId) as a router = certificate for the SEND RSA
>>>>> Signature
>>>>> |  Options?
>>>>> |
>>>>> I see. I agree that this needs more precision.
>>>>>
>>>>> In draft-ietf-csi-send-cert-05, section 7 (it is = the same text as
>>>>> in cert-04) it discusses the messages that are = authorized by each
>>>>> KeyPurposeId
>>>>> - "router authorization value indicates that = the
>>>>>    certificate has been issued for = allowing the router to advertise
>>>>>    prefix(es)"
>>>>> (I understand that implicitly states that it = authorizes the
>>>>> generation of RA messages. It is not crystal clear = for me if it
>>>>> authorizes NA for routers, although if I had to = take this text
>>>>> literally, I would suppose routers would need an = 'owner'
>>>>> authorization if this PKI model substitutes RFC3971 = CGA
>>>>> authorization, considering that the prefix for NA = would be narrowed
>>>>> in general to one address, while the RA = authorization is prefix-wide)
>>>>> - "proxy authorization value indicates that the
>>>>>    certificate has been issued for = allowing the proxy to perform
>>>>>    proxying of neighbor discovery = messages for the prefix(es) that are
>>>>>    mentioned using the X.509 = extensions for IP addresses"
>>>>> (I understand it now implicitly states it = authorizes for ANY
>>>>> neighbor discovery message. By the way, this is the = assumption
>>>>> underlying in general draft-ietf-csi-proxy-send-04: = in the
>>>>> application scenarios, some require RA proxying, = which is assumed
>>>>> to be performed by means of the proxy cert)
>>>>> - "owner authorization [...]For an
>>>>>    address in such certificate the = host can assign the address, send/
>>>>>    receive traffic from this = address, and can respond to NSes about
>>>>> that
>>>>>    address"
>>>>> (this is the clearest of all statements - although = I think issuing
>>>>> secured NS and RS should also be considered)
>>>>>
>>>>> So, as defined now in draft-ietf-csi-proxy-send-04, = proxy
>>>>> certificates provide authorization for securing = *any* ND message.
>>>>> Considering the application scenarios, some require = proxying RA
>>>>> (PMIPv6 and RFC4389), and the MIPv6 scenario just = require NS/NA
>>>>> proxying.
>>>>>
>>>>> In summary so far, there is some specification of = the authorization
>>>>> in draft-csi-send-cert, which I think it would be = nice that it
>>>>> could be refined, and if so, my opinion is that the = refinement of
>>>>> which ND message is authorized by each KeyPurposeId = should be in
>>>>> that document.
>>>>> However, continuing with this issue, I must say = that the way the
>>>>> 'proxy authorization' is defined, and the = relationship with the
>>>>> other cases, is not satisfactory for me.
>>>>> I think the use of 'owner' should be restricted for = hosts that
>>>>> really own the address (therefore, a substitution = of the CGA
>>>>> mechanism) - as opposed to proxies.
>>>>> For the 'proxy authorization', I think it could be = refined into
>>>>> something like "proxy host" authorization, and = "proxy router"
>>>>> authorization.
>>>>> 'Proxy host' would authorize for proxying NA, NS = and RS, and "proxy
>>>>> router" authorization would authorize RA and = Redirect. This would
>>>>> provide a finer grain which I think would be = desirable (for
>>>>> example, MIPv6 does not need protecting neither RA = nor redirect).
>>>>> I think this would work (if so, it should be = changed in
>>>>> draft-csi-send-cert).
>>>>>
>>>>> What do you think? (both authors of = draft-csi-send-cert, Sandra,
>>>>> etc.).
>>>>>
>>>>> Regards,
>>>>> Alberto
>>>>>
>>>>>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org= /mailman/listinfo/secdir
>


= --Apple-Mail-280-1051710693-- From bruno.decraene@orange-ftgroup.com Thu Oct 7 09:35:34 2010 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 547B73A709E; Thu, 7 Oct 2010 09:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.244, 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 UbxTN1IPrHrJ; Thu, 7 Oct 2010 09:35:33 -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 154C73A706B; Thu, 7 Oct 2010 09:35:33 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D3674FC400A; Thu, 7 Oct 2010 18:36:33 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C7A43FC4008; Thu, 7 Oct 2010 18:36:33 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 18:36:31 +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: Thu, 7 Oct 2010 18:36:36 +0200 Message-ID: In-Reply-To: <20101007140434.2BA3C22829@thrintun.hactrn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-requirements-04 Thread-Index: ActmKLSnhbG2SLOdTK2g22OuzegQDQAFCGCg References: <20101007140434.2BA3C22829@thrintun.hactrn.net> From: To: X-OriginalArrivalTime: 07 Oct 2010 16:36:31.0785 (UTC) FILETIME=[CC5C9990:01CB663D] X-Mailman-Approved-At: Sun, 10 Oct 2010 08:25:45 -0700 Cc: draft-ietf-grow-bgp-graceful-shutdown-requirements.all@tools.ietf.org, zubair.ahmad@orange-ftgroup.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown-requirements-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: Thu, 07 Oct 2010 16:35:34 -0000 Rob, Thanks for your review of the document and your comments. I share your analysis. More inline. Regards, Bruno > -----Original Message----- > From: Rob Austein [mailto:sra@hactrn.net] > Sent: Thursday, October 07, 2010 4:05 PM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-grow-bgp-graceful-shutdown- > requirements.all@tools.ietf.org > Subject: [secdir] Review of draft-ietf-grow-bgp-graceful-shutdown- > requirements-04 >=20 > 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. >=20 > This draft discusses requirements for a proposed BGP extension to > allow graceful transition between redundant sessions during planned > maintenance windows. Unexpected failures are out of scope, the point > of the exercise is just to minimize avoidable traffic loss. While > the draft does not say so in so many words, a high-level description > of the desired mechanism might be the ability to give a neighbor some > advance notice of a planned change along with a hint of what the > normal BGP data will look like after that change, so that the neighbor > can prepare for the change. >=20 > As far as I can tell, the required mechanism is likely to be harmless, > assuming it can be kept simple: as described, the protocol extension > would be a conversation between adjacent routers, either of which > could bring down the session or inject garbage into the session > anyway, so the probability that the extension would introduce a new > attack vector seems low. In theory an evil neighbor might do > something nasty by providing misleading advance information, but > again, said neighbor could do the same thing now and have it take > effect immediately, so there's no obvious gain here for an attacker. >=20 > The security considerations section is weak, although as this is a > requirements document it is not entirely unreasonable to postpone real > security considerations until the discussion of solutions. A > paragraph (like the preceding one in this review) giving a brief > explanation of why this kind of mechanism is likely to be harmless > would be nice, but given the lateness of this review (mea culpa) I > will leave it up to the IESG to decide whether to ask for this. I can propose to update the security section with the following: "7. Security Considerations At the requirements level, this graceful shutdown mechanism is expected to not affect the security of the BGP protocol, especially if it can be kept simple. No new sessions are required and the additional ability to signal the graceful shutdown is not expected to bring additional attack vector as BGP neighbours already have the ability to send incorrect or misleading information or even shut down the session. Security considerations MUST be addressed by the proposed solutions. In particular they SHOULD address the issues of bogus g-shut messages and how they would affect the network(s), as well as the impact of hiding a g-shut message so that g-shut is not performed. The solution SHOULD NOT increase the ability for one AS to selectively influence routing decision in the peer AS (inbound Traffic Engineering) outside the case of the BGP session shutdown. Otherwise, the peer AS SHOULD have means to detect such behavior." If this is fine for you and the IESG, I can commit the change in the document. Otherwise, comments are welcomed. > I have no serious security concerns regarding this document. From shawn.emery@oracle.com Sun Oct 10 23:37:38 2010 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 2DFE03A68CC; Sun, 10 Oct 2010 23:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 6VAc84SAcAY3; Sun, 10 Oct 2010 23:37:34 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E512E3A6767; Sun, 10 Oct 2010 23:37:33 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9B6cSm2001543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Oct 2010 06:38:33 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9B1vmLf030800; Mon, 11 Oct 2010 06:38:27 GMT Received: from abhmt005.oracle.com by acsmt353.oracle.com with ESMTP id 679033411286779083; Sun, 10 Oct 2010 23:38:03 -0700 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 10 Oct 2010 23:38:03 -0700 Message-ID: <4CB2B0C4.9080000@oracle.com> Date: Mon, 11 Oct 2010 00:37:56 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.8) Gecko/20100913 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-arkko-townsley-coexistence.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-arkko-townsley-coexistence-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: Mon, 11 Oct 2010 06:37:38 -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 information draft that provides guidance for effectively managing IPv4/IPv6 addresses by address and protocol translation mechanisms. The security considerations section does exist and defers to wing-nat-pt-replacement-comparison for some of the solutions. wing-nat-pt-replacement-comparison discusses possible DoS and spoofing attacks when sharing an IPv4 amongst multiple subscribers. Though it would be nice if either this draft or the one referenced would prescribe techniques to mitigate such attacks. General comments: None. Editorial comments: s/reader to be consider/reader to consider/ This sentence should be restructured for readability purposes: For deployments where the GW is owned and operated by the customer, this becomes operational overhead for the Internet Service Provider (ISP) that it will no longer be able to rely on the customer and the seller of the GW device for. s/of NAT444 need/of NAT444 needs/ s/tunnel could created/tunnel could be created/ Shawn. -- From kivinen@iki.fi Tue Oct 12 05:36:03 2010 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 8FEAD3A6931; Tue, 12 Oct 2010 05:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, 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 VYKD5OxJDkzT; Tue, 12 Oct 2010 05:36:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 57B3A3A67D3; Tue, 12 Oct 2010 05:36:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o9CCbBEZ007361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2010 15:37:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o9CCbBRZ004044; Tue, 12 Oct 2010 15:37:11 +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: <19636.22135.112570.232329@fireball.kivinen.iki.fi> Date: Tue, 12 Oct 2010 15:37:11 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 12 min Cc: draft-ietf-netlmm-lma-discovery.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-netlmm-lma-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, 12 Oct 2010 12:36:03 -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 several different ways how Mobile Access Gateway (MAG) can dynamically discover a Local Mobility Anchor (LMA) for Mobile Node (MN) and recommends the AAA based discovery solutions. The security considerations section warns about the risks about using DNS to obtaining the IP address of the mobility agent, but explains that as MAG and LMA needs to authenticate each other (using IPsec) before PMIPv6 signaling messages are exchanged. The security considerations section seems to be adequate. I have no other comments for this draft. -- kivinen@iki.fi From ted.ietf@gmail.com Thu Oct 14 10:20:35 2010 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 58E253A6BDF; Thu, 14 Oct 2010 10:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, 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 nQWKaFifyeJa; Thu, 14 Oct 2010 10:20:00 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id A45B93A6B6A; Thu, 14 Oct 2010 10:18:28 -0700 (PDT) Received: by qyk36 with SMTP id 36so5999838qyk.10 for ; Thu, 14 Oct 2010 10:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0y9nxu+mWnJX+0iN8N7oOpykxD6YFl3pUZ2rFk9UP7k=; b=CpoIkHVM97h2uuXk06aFDXdoDxdtDtl3Yhxso3EG9u9cKfs5kZtvVN23HMOgKZr40O 13eNmRWdGBD/fvSw5n93jL7bhS4GHqkpYIWmjE6VKaohODOZT6kaD0Q7Z8zuV+IuMj// jGxKoO2xRKpkiCMQLg0Ql7Wow6O9ch/GlUNXw= 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; b=ufNvFjxO7xACvE7UO191K1PtnvnGZi+0kl5MlGMWogCAy8UnZVE7jutE/pCMU/KrVv 2+7+67tByfmbm4TNpJG3gJSkZFymMU+AcWJHgfqL4ZYKW4UX1tdHzpKSkjkcJzlTivmy oGNXngtJRwS/xwAIbyeF1c9Dbk45NYvoPDPyg= MIME-Version: 1.0 Received: by 10.229.75.3 with SMTP id w3mr6031017qcj.296.1287076787682; Thu, 14 Oct 2010 10:19:47 -0700 (PDT) Received: by 10.229.213.69 with HTTP; Thu, 14 Oct 2010 10:19:40 -0700 (PDT) In-Reply-To: <4CAAD4B0.2080807@gmail.com> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> Date: Thu, 14 Oct 2010 10:19:40 -0700 Message-ID: From: Ted Hardie To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , The IETF , "secdir@ietf.org" , "ben@estacado.net" , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" , Christer Holmberg Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch 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, 14 Oct 2010 17:20:35 -0000 I have reviewed the updated draft, and I believe it to be much clearer in intent and in which modifications to the underlying matching semantics are present. If it were to progress in its current form, I would not have any technical objections. While it is still somewhat confusing to have a URI comparison method defined but not used, it is at least clear what the method is and what is used instead in this. On the general clarity, I also have to say that I believe that the document tipped over the "diff" line somewhere. That is, as a set of edits it is now sufficiently complex that it would almost certainly be better to apply the edits and re-spin the whole document rather than provide a set of textual diffs in the current format. If the ADs and WG chairs feel that there is no energy to tackle such a major editorial change, however, I certainly understand. It is possible to build up the correct state with the two documents; it is just more difficult. regards, Ted Hardie From ted.ietf@gmail.com Thu Oct 14 10:21:04 2010 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 A79C83A693A; Thu, 14 Oct 2010 10:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, 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 8NVL2AH1UKee; Thu, 14 Oct 2010 10:21:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5D52F3A6BB5; Thu, 14 Oct 2010 10:18:39 -0700 (PDT) Received: by iwn10 with SMTP id 10so9800692iwn.31 for ; Thu, 14 Oct 2010 10:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0y9nxu+mWnJX+0iN8N7oOpykxD6YFl3pUZ2rFk9UP7k=; b=f3hPEmkS68CE0/AVsAxxVnNVpFwez3mTE+T5amosNdza588b5aKR9Qqy1tue5GBWY3 3AsRANHJHhPBNZ2uxsDc5dRydxkdEwhure+bT/WtWKuktg6qHRV8e0HsGrCnIGhS8trA 88JoP5dduUhdVIobFSzOEapOMBy+ESaD8B9i8= 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; b=cf6+HIAUXggH1fXbrKSGgUr3MxbMmPVYGf361NQYydU2kpao5EYuMS36FL6U41OmTI r/KnvTPXjutAkxc2Hg/P0uslbQA1D3yhy6zmooqdDQXFZmY6/jwUaG+A3sZlAMSSgQTc AR9oG6iodk9REivLpdI3WdziPOKgGQuyiSqZg= MIME-Version: 1.0 Received: by 10.231.152.78 with SMTP id f14mr8716435ibw.60.1287076798506; Thu, 14 Oct 2010 10:19:58 -0700 (PDT) Received: by 10.231.207.15 with HTTP; Thu, 14 Oct 2010 10:19:57 -0700 (PDT) In-Reply-To: <4CAAD4B0.2080807@gmail.com> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> Date: Thu, 14 Oct 2010 10:19:57 -0700 Message-ID: From: Ted Hardie To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , The IETF , "secdir@ietf.org" , "ben@estacado.net" , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" , Christer Holmberg Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch 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, 14 Oct 2010 17:21:04 -0000 I have reviewed the updated draft, and I believe it to be much clearer in intent and in which modifications to the underlying matching semantics are present. If it were to progress in its current form, I would not have any technical objections. While it is still somewhat confusing to have a URI comparison method defined but not used, it is at least clear what the method is and what is used instead in this. On the general clarity, I also have to say that I believe that the document tipped over the "diff" line somewhere. That is, as a set of edits it is now sufficiently complex that it would almost certainly be better to apply the edits and re-spin the whole document rather than provide a set of textual diffs in the current format. If the ADs and WG chairs feel that there is no energy to tackle such a major editorial change, however, I certainly understand. It is possible to build up the correct state with the two documents; it is just more difficult. regards, Ted Hardie From ted.ietf@gmail.com Thu Oct 14 10:44:53 2010 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 5C71E3A63EB; Thu, 14 Oct 2010 10:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, 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 MNACpuVrDnvA; Thu, 14 Oct 2010 10:44:52 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 123BB3A69B5; Thu, 14 Oct 2010 10:44:51 -0700 (PDT) Received: by ywa6 with SMTP id 6so3043657ywa.31 for ; Thu, 14 Oct 2010 10:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q5lViDNEvlCGJXYz0CPEKzGWLfRBNcPnLYk3SsAEri0=; b=uNBnDSyUsWWFbjtgSFJzMsOWWVyl0b3TWJcY0QX8uUrDI81uY06q/zc9oLGPIo+sf4 S1Nef1tNrOLKWDJs5AyHTgJNasEY9bdx9MvXOMnu507pseG163bZzwIt1aFBvWZyC3cy 8XEWcQJt0TvwyPYiQOWcgb+Jc5DqxHuaYqdb8= 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=ImgOw24d7HJYA9tE954g9Qj6WAG4pQ8+hLUF5fX6qGR9X+mdYSDL71cP0BNZ7hjdVH warwWMHLDHBGlGvjiDmp7Ipdk4TvY+a2d/vPvDpnxQwvMUIhZe01WcofK+4GxYkAQ0Jb WC8IXgvHp8VUawKO3vNvg9zyUJk6G77i3Pzqw= MIME-Version: 1.0 Received: by 10.42.214.10 with SMTP id gy10mr6038945icb.370.1287078371085; Thu, 14 Oct 2010 10:46:11 -0700 (PDT) Received: by 10.231.207.15 with HTTP; Thu, 14 Oct 2010 10:46:10 -0700 (PDT) In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> Date: Thu, 14 Oct 2010 10:46:10 -0700 Message-ID: From: Ted Hardie To: Ben Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , The IETF , "secdir@ietf.org" , Gonzalo Camarillo , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" , Christer Holmberg Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch 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, 14 Oct 2010 17:44:53 -0000 Hi Ben, On Thu, Oct 14, 2010 at 10:40 AM, Ben Campbell wrote: > On Oct 14, 2010, at 12:19 PM, Ted Hardie wrote: > >> On the general clarity, I also have to say that I believe that the docum= ent >> tipped over the "diff" line somewhere. =A0That is, as a set of edits it = is now >> sufficiently complex that it would almost certainly be better to apply >> the edits and re-spin the whole document rather than provide a set of >> textual diffs in the current format. =A0If the ADs and WG chairs feel th= at there >> is no energy to tackle such a major editorial change, however, I certain= ly >> understand. =A0It is possible to build up the correct state with the two >> documents; >> it is just more difficult. > > Hi Ted, > > Do I understand correctly that you mean a respin of RFC 4975? > > Thanks! Yes, I do. But I understand if that is not practical at this point in time= . regards, Ted > > Ben. From fluffy@cisco.com Thu Oct 14 13:29:14 2010 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 30E683A6956; Thu, 14 Oct 2010 13:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.222 X-Spam-Level: X-Spam-Status: No, score=-110.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, 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 MuondCo2SJgC; Thu, 14 Oct 2010 13:29:11 -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 72FA63A6A0A; Thu, 14 Oct 2010 13:29:09 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGMFt0yrR7Hu/2dsb2JhbAChInGlJp0BgnSCVASEU4VzgwOILg X-IronPort-AV: E=Sophos;i="4.57,332,1283731200"; d="scan'208";a="604150553" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2010 20:27:56 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9EKRqum015267; Thu, 14 Oct 2010 20:27:53 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <4CAAD4B0.2080807@gmail.com> Date: Thu, 14 Oct 2010 14:27:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1081) Cc: Ted Hardie , The IETF , secdir@ietf.org, draft-ietf-simple-msrp-sessmatch@tools.ietf.org, IESG IESG , Christer Holmberg , simple@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch 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, 14 Oct 2010 20:29:14 -0000 The new draft is clearer but I still don't think it addresses my = concerns. I would say at this point they could be summarized as=20 1) The draft is very hard to review without doing the diffs to 4975. To = try and help instead of just complain, I'm willing to go back patch = these changes into the last XML for 4975 and provide a draft that we can = actually read to see what this all means. I can't do that till after the = -01 deadline.=20 2) As far as I can tell, this does change the security of 4975 in a = pretty significant way in that this allows a MITM to masquerade with the = wrong to and from path that may be in the cert. It is not clear how it = work when the end points are not using self signed certs and changes the = preferred deployment mode from using certs rooted in a trust anchor to = self signed. All this seems to significantly weaken the security of 4975 = which concerns me and I have not seen relevant discussion of all this. I = am open to the idea that it does not making this much worse than they = currently are in 4975 and that it is a reasonable trade off but I'd like = to see concrete discussion of the issues and tradeoffs. How bad is it? = how much worse is it? People says it is no worse but I and several = others remain unconvinced that it is the same as 4975. I'd rather see a = very explicitly discussion with people like the security reviewer about = how much this changes things and if it is acceptable. It's not easy to = sort this all out - it actually might be acceptable - I'm just not = convinced yet and the "there is no problem because there is not change" = form of argument is not convincing me - clearly there is a a change and = at causal glance the point of that change seems to be to insert a MITM.=20= 3) The backwards comparability issue seems huge. Some people have said = an endpoint using this draft will not talk with one that only does 4975. = Yet if this draft if published as an RFC would basically depreciate the = 4975 and replace it with a the result of applying this diff to 4795. So = if one person implements the pre update version, and another person the = post - it's not clear to me how we migrate from old to new on the = existing deployments. A flag day is obviously not going to work. The = more I look at this, the more I think this draft needs to be recast as = a backwards compatible extension to 4975 and not a draft that update = 4975. When I look at how this changes 4975 it seems to mostly relax the = existing security but not disallow things that used to work so I think = it should be possible to do this. On a side note, I phoned a few people = who I know that have MSRP implementation and none of them had any plans = to implement this and were surprised to hear there was a draft that = would update in 4975 with a change like this. To me this combined with = the no backwards compatibility issue argues strongly for figuring out = how to make this an extension instead of a change to MSRP.=20 4) When I search the email lists, I find more more people who see = significant problems with this than I find people that seem to think it = is OK. I don't think it has consensus -I think it just has people who = stopped care. The changes that needed to happen in IETF LC to fix this = draft so it had any chance of working at all more or less convinced me = the WG did not read this draft. The ietf@ietf.org list is not an ideal = location for discussion that rewrites pretty much all of the normative = text of this draft (which is what is happening here).=20 Cullen On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote: > Hi, >=20 > Christer has submitted a new revision of this draft: >=20 > https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ >=20 > Those of you who sent IETF LC comments on this draft, could you please > have a look at the new version and let Christer know if he has = addressed > your concerns? >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 31/08/2010 8:39 PM, Christer Holmberg wrote: >> Hi, >>=20 >> The purpose of this e-mail is to address the secdir comments given by = Richard >> Barnes and Ted Hardie. Due to summer vacations, standardization = meetings >> etc it took a while to put the e-mail together, and we appologise for = that. >>=20 >> GENERAL >> =3D=3D=3D=3D=3D=3D=3D >>=20 >> First, the draft does NOT propose any changes to the TLS = authentication >> procedures =96 that will be clarified. The changes are only related = to the >> procedure for matching an incoming MSRP message to an MSRP session = that >> has been negotiated using SDP =96 once any TLS authentication = procedure has >> already taken place. >>=20 >> So, in case of TLS and name based authentication, if an SBC/ALG = modifies >> the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is the = current >> behavior, and sessmatch doesn=92t change that. >>=20 >> We understand that this fact needs to be clearly indicated in the = draft. >>=20 >> Basically sessmatch allows so that, when using peer to peer MSRP, SIP = SBCs >> and SIP aware firewalls can be in the SIP signaling path without = acting as >> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP = relays >> the SBC/ALG needs to act as MSRP B2BUA, as today. >>=20 >> Sessmatch aims to extend the usability of MSRP peer to peer = communication to >> scenarios where simple ALGs/SBCs are used, and at least in our = experience >> customer interest for standard MSRP has grown (from more or less = zero) >> dramatically due to sessmatch. And, OMA, which previously used a = *non-standard* >> version of MSRP (with no interoperability with standard MSRP), has = also agreed >> to switch to sessmatch (even if it required a number of changes in = their >> specifications). >>=20 >> Second, the intention of sessmatch is not to modify the MSRP URI = matching rules, >> but rather to not use MSRP URI matching for session matching. >>=20 >> Please also note that when we talk about SBCs/ALGs, we refer to = entities that >> normally do NOT have the capability to act as MSRP B2BUAs. >>=20 >> We will comment the individual comments based on the assumptions = above. >>=20 >>=20 >> Comments from Richard >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>> 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. >>>=20 >>> This document changes the URI matching algorithm used in MSRP. MSRP = sessions >>> are typically initiated using SDP bodies in SIP. These SDP >>> bodies contain MSRP URIs that the peers use to contact each other. >>> When one peer receives a request to initiate a session, he verifies = that the >>> URI being requested is one that he initiated in SDP, thereby using = the URI as a >>> shared secret to authenticate that the originator of the session = actually >>> received the SDP body in question. >>>=20 >>> According to the current SDP specification, this comparison is = performed over >>> the whole URI; this document restricts the comparison to the = "session-id" >>> component, omitting the host, port, and transport components. The = goal of the >>> document is to facilitate a certain class of man-in-the-middle = attack, namely >>> to allow a signaling intermediary to insert a media intermediary. = The >>> restriction on the URI comparison is needed in order for the media = intermediary >>> not to have to modify URIs in MSRP packets to reflect the = modifications to URIs >>> in SDP bodies performed to redirect traffic through the media = intermediary. >>=20 >> When an MSRP UA receives an MSRP packet it performs msrp session = matching in order >> to verify that the msrp packet belongs to an existing SDP negotiated = msrp session >> at the UA. RFC4975 prescribes that URI matching should be used for = session matching. >> We argue that the namespace scoping of the session-id values that use = of URI matching >> brings is unnecessary. The 80-bit randomness of the session-id and = the fact that it >> was the UA itself that decided on the session-id value and can ensure = that it is >> unique within the UA makes the session-id sufficiently unique for = session matching. >> Sessmatch is not changing the MSRP URI matching algorithm, it is = changing the session >> matching algorithm not to use MSRP URI matching. >>=20 >>> I have a few significant reservations about this document: >>>=20 >>> 1) This extension makes it more difficult for MSRP entities to = secure their >>> communications against attackers in the signaling path. The current = model >>> provides a basic integrity protection, in that signaling = intermediaries cannot >>> redirect traffic to an arbitrary third party; they must at least = advise the >>> third party about how to modify MSRP packets. The proposed = modification would >>> remove even this cost. >>=20 >> If we do not introduce the sessmatch change then the only alternative = for MSRP >> connections to be able to be set up when SBCs or SIP aware firewalls = are in the >> SIP signaling path is for these to introduce MSRP B2BUA support. This = is probably >> not feasible for most SBCs and SIP aware firewalls, and if it = actually were >> feasible then it would mean as big a security problem, or even = bigger, than >> sessmatch. The choice is thus to not use MSRP at all in presence of = such devices >> or to introduce sessmatch. Not to fix this probably would mean that = use of MSRP >> will be marginalized. >>=20 >>> 2) Moreover, it raises the cost of providing integrity protection to = messages, >>> since Alice must now employ both integrity and confidentiality = protections on >>> an end-to-end basis; if her messages are only integrity-protected, = then a proxy >>> can remove the integrity protection and redirect traffic without it = being >>> observable to Alice. >>>=20 >>> The document needs to clarify what the impacts are for = authentication in secure >>> modes of MSRP. In particular: >>> -- The distinction between "self-signed" and "public" certificates = is >>> inappropriate. The proper distinction is between the name-based = authentication >>> in Section 14.2 of RFC 4975 and the fingerprint-based authentication = in Section >>> 14.4. >>=20 >> We cannot find the terminology =93name-based=94 authentication in RFC = 4975. The RFC talks >> about TLS authentication using either certificates from well-known = certificate >> authorities, or using self-signed certificates together with = certificate fingerprints. >>=20 >> Having said that, however, we DO agree that the terminology you = suggest is more >> appropriate than what we have used and we will introduce this = terminology and explain >> it in the Convention section of the sessmatch draft. >>=20 >>> -- In either case, changing the host name need not result in an = authentication >>> failure, since the media intermediary can simply authenticate as = itself to both >>> endpoints, having changed the respective MSRP URIs appropriately. >>=20 >> A media intermediary can only do this if it is an MSRP B2BUA, and = sessmatch was >> introduced just to avoid most SBCs and ALGs having to implement an = MSRP B2BUA in order >> to allow standard MSRP deployment. >>=20 >>> -- There is currently no requirement that an endpoint identity in = the To-Path >>> URI matches the endpoint identity authenticated at the TLS layer, = because these >>> two are required to be the same. This document changes that = assumption, and >>> should note that these two identities can differ. >>=20 >> We will explicitly mention this. >>=20 >>> The document also precludes any name-based multiplexing, where a = single MSRP >>> process (single IP address and port) directs requests to different = virtual >>> recipients based on the domain name in the To-Path header. (In = analogy to >>> Host-based multiplexing in HTTP, which is very widely deployed.) = Since with >>> this extension, the domain in the To- Path is completely = unpredictable from the >>> recipient's perspective, it is useless to the recipient. >>=20 >> That is correct, but there should be no problem for a single MSRP = process (single >> IP address and port) to direct requests to different virtual = recipients - based >> on the session-id instead. It is only needed for the different = virtual recipients >> to inform the receiver process on which session-ids that are = currently negotiated >> instead of informing it on which domain name the virtual recipient = shall be >> associated with. >>=20 >>> The document has no backward-compatibility. MSRP implementations = that do not >>> support this extension will not be able to receive MSRP sessions = from >>> implementations that do. In that regard, this document seems more = like a new >>> version of MSRP rather than an update. >>=20 >> It is not true that there is no backwards compatibility. If there are = no >> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem = for MSRP >> implementations that do not support the sessmatch extension to = receive MSRP >> sessions from implementations that do. >>=20 >> MSRP implementations that do not support the sessmatch extension are = however not >> able to establish MSRP end to end conversations if there are = ALGs/SBCs in the >> session path (unless these implement MSRP B2BUA) and sessmatch does = not change this >> fact =96 it will not work disregarding if the other endpoint supports = sessmatch or not. >>=20 >>>>> I also note that the security considerations, in addition to = having >>>>> some fairly disingenuous language about the impact of this change, >>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>> would have on them. >>>>=20 >>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly >>>> understood since MSRPS URIs are not mentioned in the draft. >>>>=20 >>>> However, we could explicitly make it clear by modifying the first >>>> sentences of section 5: >>>>=20 >>>> "The change of session matching procedure does not impact the >>>> format of MSRP URIs, disregarding if the "msrp" scheme or the = "msrps" scheme >>>> is used. However, MSRP endpoints can only check that the session-id = part of >>>> the MSRP URI..." >>>=20 >>> The conflict here is that with MRSPS authentication, the name in the >>> certificate is checked against the domain name in the URI, which was = OK when >>> the URI in the message was required to be the same. By allowing the = domain >>> name in the message to change, this draft removes man-in-the-middle = protection >>> from MSRPS. >>>=20 >>> The document notes that a SIP MitM can already direct the user to = another >>> destination. However, if the peers use MSRPS with the current = authentication >>> scheme, the MitM will not be able to be a part of the resulting = MSRPS session, >>> since he can't authenticate as one of the endpoints. If only the = session ID is >>> used in comparisons, the MitM can patch himself in by changing the = domain in >>> the MSRPS URI. (Which actually seems to be the intended use case for = this >draft.) >>>=20 >>> So the current document does introduce a new MitM vulnerability to = MSRPS. >>=20 >> Sessmatch does not change the fact that name based TLS authentication = for MSRPS >> will fail if an SBC or ALG has modified the hostname value in the = MSRP URI in the >> SDP a=3Dpath attribute without also acting as MSRP B2BUA. >>=20 >>=20 >> Comments from Ted >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>> I join Richard in believing that this document makes changes beyond = that which >>> could be understood as "updating" the MSRP URI scheme processing. >>>=20 >>> ... >>>=20 >>> I also note that the security considerations, in addition to having = some fairly >>> disingenuous language about the impact of this change, seems to fail = to mention >>> MSRPS URIs and what, if any, impact this would have on them. >>=20 >> We will clarify what impacts there are. >>=20 >> ------- >>=20 >>>>> To highlight one particular aspect, RFC 4975 does not require >>>>> session-ids to be present, a fact noted both in the ABNF and in = this >>>>> text: >>>>>=20 >>>>> 4. The session-id part is compared as case sensitive. A URI = without >>>>> a session-id part is never equivalent to one that includes one. >>>>>=20 >>>>> A matching scheme which relies on a URI section which is not >>>>> guaranteed to be present has some interesting problems ahead of = it. If >>>>> this effectively makes their use mandatory, that requires a change = to >>>>> the fundamental ABNF and text. >>>>=20 >>>> An MSRP URI in an SDP offer or answer for an MSRP session MUST = include a >>>> session-id part, so I believe the comment is >>>> based on incorrect assumptions. >>>=20 >>> This is not indicated in the URI matching section >>=20 >> We will clarify that sessmatch conformant UAs do not use MSRP URI = matching in >> order to perform MSRP session matching. >>=20 >>>> Section 6 of RFC 4975 says: >>>>=20 >>>> "The session-id part identifies a particular session of the >>>> participant. The absence of the session-id >>>> part indicates a reference to an MSRP host device, but does not = refer to a >>>> particular session at that device." >>>>=20 >>>=20 >>> The full section from which that quote is taken is: >>>=20 >>> The MSRP URI authority field identifies a participant in a = particular >>> MSRP session. If the authority field contains a numeric IP = address, >>> it MUST also contain a port. The session-id part identifies a >>> particular session of the participant. The absence of the = session-id >>> part indicates a reference to an MSRP host device, but does not = refer >>> to a particular session at that device. A particular value of >>> session-id is only meaningful in the context of the associated >>> authority; thus, the authority component can be thought of as >>> identifying the "authority" governing a namespace for the = session-id. >>>=20 >>> This proposal changes the concept of a namespace authority present = in the URI >>> matching section of RFC 4975. I am sorry if my wry reference to this = in my >>> previous message was hard to follow; I should have known better. >>>=20 >>> To be more plain, this proposal fundamentally changes the matching = semantics of >>> the URI set out in RFC 4975, by requiring a match on only a portion = of the URI. >>> At a bare minimum, this would require noting a normative update to = section 6 >>> and 6.1 of RFC 4975, which this draft does not do. In reality, this = is >>> unlikely to be sufficient, as URI matching semantics do not = generally have the >>> concept of ignoring the authority in providing a match (at least in = my reading >>> of the RFC 3986 "ladder of comparison" text). That means you'd have = to special >>> case the MSRP matching semantics, rather than have the URI be parsed = and >>> compared using a standard library. >>=20 >> Sessmatch removes the URI matching as a means to do MSRP session = matching, and >> replaces it with a pure session-id matching. There is no need to = create a new >> URI scheme that does not re-use the authority component. We believe = the minimum >> 80-bit randomness of the session-id, together with the fact that the = UA itself >> generates the session-id it matches on, to be enough for the = session-id to be >> unique in the scope of the sessions that are active at the UA. >>=20 >> Also, the security of the matching is not particularly decreased, = since it is >> relatively easy to find out the authority name anyway. >>=20 >>>>> I also note that the security considerations, in addition to = having >>>>> some fairly disingenuous language about the impact of this change, >>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>> would have on them. >>>>=20 >>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly understood >>>> since MSRPS URIs are not mentioned in the draft. >>>>=20 >>>> However, we could explicitly make it clear by modifying the first = sentences of >>>> section 5: >>>>=20 >>>> "The change of session matching procedure does not impact the = format of MSRP >>>> URIs, disregarding if the "msrp" scheme or the "msrps" scheme is = used. >>>> However, MSRP endpoints can only check that the session-id part of = the MSRP >>>> URI..." >>>>=20 >>> This doesn't seem to me to actually work, based on Richard's = comments, unless >>> what you mean to say is "if MSRPS is in use, nothing in this draft = can be >>> used". That gives you different matching semantics for MSRPS = (authority must >>> be present and must be matched using TLS semantics) vs MSRP (only = session-id is >>> checked) which is at the very least a violation of the principle of = least >>> surprise (no other foo over TLS protocol works that way that I know = of ). >>=20 >> Session matching is done when receiving MSRP packets on an already = established TCP >> or TCP/TLS connection, and there will not be any different session = matching procedure >> depending on if the connection uses TLS or plain TCP. >>=20 >> Regards, >>=20 >> Christer >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From new-work-bounces@ietf.org Thu Oct 14 10:04:13 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8738C3A6B94; Thu, 14 Oct 2010 10:04:13 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6AB983A6B49; Thu, 14 Oct 2010 10:04:10 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20101014170411.6AB983A6B49@core3.amsl.com> Date: Thu, 14 Oct 2010 10:04:11 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 15 Oct 2010 06:06:11 -0700 Subject: [secdir] [new-work] WG Review: Recharter of NETCONF Data Modeling Language (netmod) 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, 14 Oct 2010 17:04:13 -0000 A modified charter has been submitted for the NETCONF Data Modeling Language (netmod) 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 Thursday, October 21, 2010. NETCONF Data Modeling Language (netmod) ----------------------------- Last Modified: 2010-10-12 Current Status: Active Working Group Chairs: David Partain David Kessens Area Director: Dan Romascanu Mailing List Address: netmod@ietf.org To Subscribe: netmod-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netmod/ Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group will initially work on the following items: 1. Core system data model 2. Core interface data model 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate active editorial participation from routing experts and review at WGLC by the Routing Area working group. 4. SMIv2 translation to YANG for read-only operational data and notifications. Guidance will be provided on how to reference existing data structures in SMIv2 from YANG. The NETMOD Working Group will not work on another version of YANG. All new charter items must be fully interoperable with implementations of RFC 4741bis and/or RFC 6020. It will also not serve as a review team for YANG modules developed by other working groups. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones: Oct 2010 Submission of individual draft(s) of System data model draft Oct 2010 Submission of individual draft(s) of Interface data model Oct 2010 Submission of individual draft(s) of Routing data model Oct 2010 Submission of individual draft(s) of SMIv2 translation to YANG Dec 2010 Submit first working group draft of System data model draft Dec 2010 Submit first working group draft of Interface data model Dec 2010 Submit first working group draft of Routing data model Dec 2010 Submit first working group draft of SMIv2 translation to YANG Apr 2011 Submit SMIv2 to YANG translation to the IESG (proposed standard) Apr 2011 Submit System data model to the IESG (proposed standard) Aug 2011 Submit Interface data model to the IESG (proposed standard) Aug 2011 Submit Routing data model to the IESG (proposed standard) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From ben@estacado.net Thu Oct 14 10:40:15 2010 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 5661D3A63EB; Thu, 14 Oct 2010 10:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 UNmxq342Qm9Y; Thu, 14 Oct 2010 10:40:10 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id B50643A6B71; Thu, 14 Oct 2010 10:40:05 -0700 (PDT) Received: from [10.0.1.15] (adsl-68-94-22-118.dsl.rcsntx.swbell.net [68.94.22.118]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o9EHegxL021882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Oct 2010 12:40:47 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Thu, 14 Oct 2010 12:40:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> To: Ted Hardie X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 15 Oct 2010 06:06:11 -0700 Cc: Cullen Jennings , The IETF , "secdir@ietf.org" , Gonzalo Camarillo , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" , Christer Holmberg Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch 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, 14 Oct 2010 17:40:15 -0000 On Oct 14, 2010, at 12:19 PM, Ted Hardie wrote: > On the general clarity, I also have to say that I believe that the = document > tipped over the "diff" line somewhere. That is, as a set of edits it = is now > sufficiently complex that it would almost certainly be better to apply > the edits and re-spin the whole document rather than provide a set of > textual diffs in the current format. If the ADs and WG chairs feel = that there > is no energy to tackle such a major editorial change, however, I = certainly > understand. It is possible to build up the correct state with the two > documents; > it is just more difficult. Hi Ted, Do I understand correctly that you mean a respin of RFC 4975? Thanks! Ben.= From ag@ag-projects.com Thu Oct 14 15:26:10 2010 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 31C2C3A6C36; Thu, 14 Oct 2010 15:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=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 uNGntzjMIeo0; Thu, 14 Oct 2010 15:26:08 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by core3.amsl.com (Postfix) with ESMTP id 6D86B3A6C39; Thu, 14 Oct 2010 15:26:06 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 5E74BB01C6; Fri, 15 Oct 2010 00:27:24 +0200 (CEST) Received: from [10.10.11.43] (armoursquare.rice.iit.edu [64.131.110.238]) by mail.sipthor.net (Postfix) with ESMTPSA id 48790B01BA; Fri, 15 Oct 2010 00:27:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Adrian Georgescu In-Reply-To: <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com> Date: Thu, 14 Oct 2010 17:26:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <572332FE-BFD1-41B0-AE9E-8ECB96D2FB05@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 15 Oct 2010 06:06:11 -0700 Cc: Ted Hardie , The IETF , secdir@ietf.org, Gonzalo Camarillo , draft-ietf-simple-msrp-sessmatch@tools.ietf.org, IESG IESG , simple@ietf.org Subject: Re: [secdir] [Simple] secdir review of draft-ietf-simple-msrp-sessmatch 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, 14 Oct 2010 22:26:10 -0000 My two cents. Having implemented both models in Blink client (Blink is a = free download if someone cares and wants to experiment with both MSRP = models), I can comment that I do not like the acm model. The relay model = is simply better, cleaner and more secure. Adrian On Oct 14, 2010, at 3:27 PM, Cullen Jennings wrote: >=20 > The new draft is clearer but I still don't think it addresses my = concerns. I would say at this point they could be summarized as=20 >=20 > 1) The draft is very hard to review without doing the diffs to 4975. = To try and help instead of just complain, I'm willing to go back patch = these changes into the last XML for 4975 and provide a draft that we can = actually read to see what this all means. I can't do that till after the = -01 deadline.=20 >=20 > 2) As far as I can tell, this does change the security of 4975 in a = pretty significant way in that this allows a MITM to masquerade with the = wrong to and from path that may be in the cert. It is not clear how it = work when the end points are not using self signed certs and changes the = preferred deployment mode from using certs rooted in a trust anchor to = self signed. All this seems to significantly weaken the security of 4975 = which concerns me and I have not seen relevant discussion of all this. I = am open to the idea that it does not making this much worse than they = currently are in 4975 and that it is a reasonable trade off but I'd like = to see concrete discussion of the issues and tradeoffs. How bad is it? = how much worse is it? People says it is no worse but I and several = others remain unconvinced that it is the same as 4975. I'd rather see a = very explicitly discussion with people like the security reviewer about = how much this changes things and if it is acceptable. It's not easy to = sort this all out - it actually might be acceptable - I'm just not = convinced yet and the "there is no problem because there is not change" = form of argument is not convincing me - clearly there is a a change and = at causal glance the point of that change seems to be to insert a MITM.=20= >=20 > 3) The backwards comparability issue seems huge. Some people have said = an endpoint using this draft will not talk with one that only does 4975. = Yet if this draft if published as an RFC would basically depreciate the = 4975 and replace it with a the result of applying this diff to 4795. So = if one person implements the pre update version, and another person the = post - it's not clear to me how we migrate from old to new on the = existing deployments. A flag day is obviously not going to work. The = more I look at this, the more I think this draft needs to be recast as = a backwards compatible extension to 4975 and not a draft that update = 4975. When I look at how this changes 4975 it seems to mostly relax the = existing security but not disallow things that used to work so I think = it should be possible to do this. On a side note, I phoned a few people = who I know that have MSRP implementation and none of them had any plans = to implement this and were surprised to hear there was a draft that = would update in 4975 with a change like this. To me this combined with = the no backwards compatibility issue argues strongly for figuring out = how to make this an extension instead of a change to MSRP.=20 >=20 > 4) When I search the email lists, I find more more people who see = significant problems with this than I find people that seem to think it = is OK. I don't think it has consensus -I think it just has people who = stopped care. The changes that needed to happen in IETF LC to fix this = draft so it had any chance of working at all more or less convinced me = the WG did not read this draft. The ietf@ietf.org list is not an ideal = location for discussion that rewrites pretty much all of the normative = text of this draft (which is what is happening here).=20 >=20 > Cullen >=20 >=20 >=20 > On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote: >=20 >> Hi, >>=20 >> Christer has submitted a new revision of this draft: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ >>=20 >> Those of you who sent IETF LC comments on this draft, could you = please >> have a look at the new version and let Christer know if he has = addressed >> your concerns? >>=20 >> Thanks, >>=20 >> Gonzalo >>=20 >>=20 >> On 31/08/2010 8:39 PM, Christer Holmberg wrote: >>> Hi, >>>=20 >>> The purpose of this e-mail is to address the secdir comments given = by Richard >>> Barnes and Ted Hardie. Due to summer vacations, standardization = meetings >>> etc it took a while to put the e-mail together, and we appologise = for that. >>>=20 >>> GENERAL >>> =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> First, the draft does NOT propose any changes to the TLS = authentication >>> procedures =96 that will be clarified. The changes are only related = to the >>> procedure for matching an incoming MSRP message to an MSRP session = that >>> has been negotiated using SDP =96 once any TLS authentication = procedure has >>> already taken place. >>>=20 >>> So, in case of TLS and name based authentication, if an SBC/ALG = modifies >>> the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is the = current >>> behavior, and sessmatch doesn=92t change that. >>>=20 >>> We understand that this fact needs to be clearly indicated in the = draft. >>>=20 >>> Basically sessmatch allows so that, when using peer to peer MSRP, = SIP SBCs >>> and SIP aware firewalls can be in the SIP signaling path without = acting as >>> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP = relays >>> the SBC/ALG needs to act as MSRP B2BUA, as today. >>>=20 >>> Sessmatch aims to extend the usability of MSRP peer to peer = communication to >>> scenarios where simple ALGs/SBCs are used, and at least in our = experience >>> customer interest for standard MSRP has grown (from more or less = zero) >>> dramatically due to sessmatch. And, OMA, which previously used a = *non-standard* >>> version of MSRP (with no interoperability with standard MSRP), has = also agreed >>> to switch to sessmatch (even if it required a number of changes in = their >>> specifications). >>>=20 >>> Second, the intention of sessmatch is not to modify the MSRP URI = matching rules, >>> but rather to not use MSRP URI matching for session matching. >>>=20 >>> Please also note that when we talk about SBCs/ALGs, we refer to = entities that >>> normally do NOT have the capability to act as MSRP B2BUAs. >>>=20 >>> We will comment the individual comments based on the assumptions = above. >>>=20 >>>=20 >>> Comments from Richard >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>>> 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. >>>>=20 >>>> This document changes the URI matching algorithm used in MSRP. = MSRP sessions >>>> are typically initiated using SDP bodies in SIP. These SDP >>>> bodies contain MSRP URIs that the peers use to contact each other. >>>> When one peer receives a request to initiate a session, he verifies = that the >>>> URI being requested is one that he initiated in SDP, thereby using = the URI as a >>>> shared secret to authenticate that the originator of the session = actually >>>> received the SDP body in question. >>>>=20 >>>> According to the current SDP specification, this comparison is = performed over >>>> the whole URI; this document restricts the comparison to the = "session-id" >>>> component, omitting the host, port, and transport components. The = goal of the >>>> document is to facilitate a certain class of man-in-the-middle = attack, namely >>>> to allow a signaling intermediary to insert a media intermediary. = The >>>> restriction on the URI comparison is needed in order for the media = intermediary >>>> not to have to modify URIs in MSRP packets to reflect the = modifications to URIs >>>> in SDP bodies performed to redirect traffic through the media = intermediary. >>>=20 >>> When an MSRP UA receives an MSRP packet it performs msrp session = matching in order >>> to verify that the msrp packet belongs to an existing SDP negotiated = msrp session >>> at the UA. RFC4975 prescribes that URI matching should be used for = session matching. >>> We argue that the namespace scoping of the session-id values that = use of URI matching >>> brings is unnecessary. The 80-bit randomness of the session-id and = the fact that it >>> was the UA itself that decided on the session-id value and can = ensure that it is >>> unique within the UA makes the session-id sufficiently unique for = session matching. >>> Sessmatch is not changing the MSRP URI matching algorithm, it is = changing the session >>> matching algorithm not to use MSRP URI matching. >>>=20 >>>> I have a few significant reservations about this document: >>>>=20 >>>> 1) This extension makes it more difficult for MSRP entities to = secure their >>>> communications against attackers in the signaling path. The = current model >>>> provides a basic integrity protection, in that signaling = intermediaries cannot >>>> redirect traffic to an arbitrary third party; they must at least = advise the >>>> third party about how to modify MSRP packets. The proposed = modification would >>>> remove even this cost. >>>=20 >>> If we do not introduce the sessmatch change then the only = alternative for MSRP >>> connections to be able to be set up when SBCs or SIP aware firewalls = are in the >>> SIP signaling path is for these to introduce MSRP B2BUA support. = This is probably >>> not feasible for most SBCs and SIP aware firewalls, and if it = actually were >>> feasible then it would mean as big a security problem, or even = bigger, than >>> sessmatch. The choice is thus to not use MSRP at all in presence of = such devices >>> or to introduce sessmatch. Not to fix this probably would mean that = use of MSRP >>> will be marginalized. >>>=20 >>>> 2) Moreover, it raises the cost of providing integrity protection = to messages, >>>> since Alice must now employ both integrity and confidentiality = protections on >>>> an end-to-end basis; if her messages are only integrity-protected, = then a proxy >>>> can remove the integrity protection and redirect traffic without it = being >>>> observable to Alice. >>>>=20 >>>> The document needs to clarify what the impacts are for = authentication in secure >>>> modes of MSRP. In particular: >>>> -- The distinction between "self-signed" and "public" certificates = is >>>> inappropriate. The proper distinction is between the name-based = authentication >>>> in Section 14.2 of RFC 4975 and the fingerprint-based = authentication in Section >>>> 14.4. >>>=20 >>> We cannot find the terminology =93name-based=94 authentication in = RFC 4975. The RFC talks >>> about TLS authentication using either certificates from well-known = certificate >>> authorities, or using self-signed certificates together with = certificate fingerprints. >>>=20 >>> Having said that, however, we DO agree that the terminology you = suggest is more >>> appropriate than what we have used and we will introduce this = terminology and explain >>> it in the Convention section of the sessmatch draft. >>>=20 >>>> -- In either case, changing the host name need not result in an = authentication >>>> failure, since the media intermediary can simply authenticate as = itself to both >>>> endpoints, having changed the respective MSRP URIs appropriately. >>>=20 >>> A media intermediary can only do this if it is an MSRP B2BUA, and = sessmatch was >>> introduced just to avoid most SBCs and ALGs having to implement an = MSRP B2BUA in order >>> to allow standard MSRP deployment. >>>=20 >>>> -- There is currently no requirement that an endpoint identity in = the To-Path >>>> URI matches the endpoint identity authenticated at the TLS layer, = because these >>>> two are required to be the same. This document changes that = assumption, and >>>> should note that these two identities can differ. >>>=20 >>> We will explicitly mention this. >>>=20 >>>> The document also precludes any name-based multiplexing, where a = single MSRP >>>> process (single IP address and port) directs requests to different = virtual >>>> recipients based on the domain name in the To-Path header. (In = analogy to >>>> Host-based multiplexing in HTTP, which is very widely deployed.) = Since with >>>> this extension, the domain in the To- Path is completely = unpredictable from the >>>> recipient's perspective, it is useless to the recipient. >>>=20 >>> That is correct, but there should be no problem for a single MSRP = process (single >>> IP address and port) to direct requests to different virtual = recipients - based >>> on the session-id instead. It is only needed for the different = virtual recipients >>> to inform the receiver process on which session-ids that are = currently negotiated >>> instead of informing it on which domain name the virtual recipient = shall be >>> associated with. >>>=20 >>>> The document has no backward-compatibility. MSRP implementations = that do not >>>> support this extension will not be able to receive MSRP sessions = from >>>> implementations that do. In that regard, this document seems more = like a new >>>> version of MSRP rather than an update. >>>=20 >>> It is not true that there is no backwards compatibility. If there = are no >>> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no = problem for MSRP >>> implementations that do not support the sessmatch extension to = receive MSRP >>> sessions from implementations that do. >>>=20 >>> MSRP implementations that do not support the sessmatch extension are = however not >>> able to establish MSRP end to end conversations if there are = ALGs/SBCs in the >>> session path (unless these implement MSRP B2BUA) and sessmatch does = not change this >>> fact =96 it will not work disregarding if the other endpoint = supports sessmatch or not. >>>=20 >>>>>> I also note that the security considerations, in addition to = having >>>>>> some fairly disingenuous language about the impact of this = change, >>>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>>> would have on them. >>>>>=20 >>>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly >>>>> understood since MSRPS URIs are not mentioned in the draft. >>>>>=20 >>>>> However, we could explicitly make it clear by modifying the first >>>>> sentences of section 5: >>>>>=20 >>>>> "The change of session matching procedure does not impact the >>>>> format of MSRP URIs, disregarding if the "msrp" scheme or the = "msrps" scheme >>>>> is used. However, MSRP endpoints can only check that the = session-id part of >>>>> the MSRP URI..." >>>>=20 >>>> The conflict here is that with MRSPS authentication, the name in = the >>>> certificate is checked against the domain name in the URI, which = was OK when >>>> the URI in the message was required to be the same. By allowing the = domain >>>> name in the message to change, this draft removes man-in-the-middle = protection >>>> from MSRPS. >>>>=20 >>>> The document notes that a SIP MitM can already direct the user to = another >>>> destination. However, if the peers use MSRPS with the current = authentication >>>> scheme, the MitM will not be able to be a part of the resulting = MSRPS session, >>>> since he can't authenticate as one of the endpoints. If only the = session ID is >>>> used in comparisons, the MitM can patch himself in by changing the = domain in >>>> the MSRPS URI. (Which actually seems to be the intended use case = for this >draft.) >>>>=20 >>>> So the current document does introduce a new MitM vulnerability to = MSRPS. >>>=20 >>> Sessmatch does not change the fact that name based TLS = authentication for MSRPS >>> will fail if an SBC or ALG has modified the hostname value in the = MSRP URI in the >>> SDP a=3Dpath attribute without also acting as MSRP B2BUA. >>>=20 >>>=20 >>> Comments from Ted >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>>> I join Richard in believing that this document makes changes beyond = that which >>>> could be understood as "updating" the MSRP URI scheme processing. >>>>=20 >>>> ... >>>>=20 >>>> I also note that the security considerations, in addition to having = some fairly >>>> disingenuous language about the impact of this change, seems to = fail to mention >>>> MSRPS URIs and what, if any, impact this would have on them. >>>=20 >>> We will clarify what impacts there are. >>>=20 >>> ------- >>>=20 >>>>>> To highlight one particular aspect, RFC 4975 does not require >>>>>> session-ids to be present, a fact noted both in the ABNF and in = this >>>>>> text: >>>>>>=20 >>>>>> 4. The session-id part is compared as case sensitive. A URI = without >>>>>> a session-id part is never equivalent to one that includes one. >>>>>>=20 >>>>>> A matching scheme which relies on a URI section which is not >>>>>> guaranteed to be present has some interesting problems ahead of = it. If >>>>>> this effectively makes their use mandatory, that requires a = change to >>>>>> the fundamental ABNF and text. >>>>>=20 >>>>> An MSRP URI in an SDP offer or answer for an MSRP session MUST = include a >>>>> session-id part, so I believe the comment is >>>>> based on incorrect assumptions. >>>>=20 >>>> This is not indicated in the URI matching section >>>=20 >>> We will clarify that sessmatch conformant UAs do not use MSRP URI = matching in >>> order to perform MSRP session matching. >>>=20 >>>>> Section 6 of RFC 4975 says: >>>>>=20 >>>>> "The session-id part identifies a particular session of the >>>>> participant. The absence of the session-id >>>>> part indicates a reference to an MSRP host device, but does not = refer to a >>>>> particular session at that device." >>>>>=20 >>>>=20 >>>> The full section from which that quote is taken is: >>>>=20 >>>> The MSRP URI authority field identifies a participant in a = particular >>>> MSRP session. If the authority field contains a numeric IP = address, >>>> it MUST also contain a port. The session-id part identifies a >>>> particular session of the participant. The absence of the = session-id >>>> part indicates a reference to an MSRP host device, but does not = refer >>>> to a particular session at that device. A particular value of >>>> session-id is only meaningful in the context of the associated >>>> authority; thus, the authority component can be thought of as >>>> identifying the "authority" governing a namespace for the = session-id. >>>>=20 >>>> This proposal changes the concept of a namespace authority present = in the URI >>>> matching section of RFC 4975. I am sorry if my wry reference to = this in my >>>> previous message was hard to follow; I should have known better. >>>>=20 >>>> To be more plain, this proposal fundamentally changes the matching = semantics of >>>> the URI set out in RFC 4975, by requiring a match on only a portion = of the URI. >>>> At a bare minimum, this would require noting a normative update to = section 6 >>>> and 6.1 of RFC 4975, which this draft does not do. In reality, = this is >>>> unlikely to be sufficient, as URI matching semantics do not = generally have the >>>> concept of ignoring the authority in providing a match (at least in = my reading >>>> of the RFC 3986 "ladder of comparison" text). That means you'd = have to special >>>> case the MSRP matching semantics, rather than have the URI be = parsed and >>>> compared using a standard library. >>>=20 >>> Sessmatch removes the URI matching as a means to do MSRP session = matching, and >>> replaces it with a pure session-id matching. There is no need to = create a new >>> URI scheme that does not re-use the authority component. We believe = the minimum >>> 80-bit randomness of the session-id, together with the fact that the = UA itself >>> generates the session-id it matches on, to be enough for the = session-id to be >>> unique in the scope of the sessions that are active at the UA. >>>=20 >>> Also, the security of the matching is not particularly decreased, = since it is >>> relatively easy to find out the authority name anyway. >>>=20 >>>>>> I also note that the security considerations, in addition to = having >>>>>> some fairly disingenuous language about the impact of this = change, >>>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>>> would have on them. >>>>>=20 >>>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly understood >>>>> since MSRPS URIs are not mentioned in the draft. >>>>>=20 >>>>> However, we could explicitly make it clear by modifying the first = sentences of >>>>> section 5: >>>>>=20 >>>>> "The change of session matching procedure does not impact the = format of MSRP >>>>> URIs, disregarding if the "msrp" scheme or the "msrps" scheme is = used. >>>>> However, MSRP endpoints can only check that the session-id part of = the MSRP >>>>> URI..." >>>>>=20 >>>> This doesn't seem to me to actually work, based on Richard's = comments, unless >>>> what you mean to say is "if MSRPS is in use, nothing in this draft = can be >>>> used". That gives you different matching semantics for MSRPS = (authority must >>>> be present and must be matched using TLS semantics) vs MSRP (only = session-id is >>>> checked) which is at the very least a violation of the principle of = least >>>> surprise (no other foo over TLS protocol works that way that I know = of ). >>>=20 >>> Session matching is done when receiving MSRP packets on an already = established TCP >>> or TCP/TLS connection, and there will not be any different session = matching procedure >>> depending on if the connection uses TLS or plain TCP. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ben@estacado.net Thu Oct 14 15:58:48 2010 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 0D3F13A6A8B; Thu, 14 Oct 2010 15:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_14=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 78TtU-v+CTo8; Thu, 14 Oct 2010 15:58:45 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 811BE3A67E2; Thu, 14 Oct 2010 15:58:43 -0700 (PDT) Received: from [10.0.1.15] (adsl-68-94-34-176.dsl.rcsntx.swbell.net [68.94.34.176]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o9EMws80061048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Oct 2010 17:58:59 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <572332FE-BFD1-41B0-AE9E-8ECB96D2FB05@ag-projects.com> Date: Thu, 14 Oct 2010 17:58:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com> <572332FE-BFD1-41B0-AE9E-8ECB96D2FB05@ag-projects.com> To: Adrian Georgescu X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 15 Oct 2010 06:06:11 -0700 Cc: Cullen Jennings , Ted Hardie , The IETF , Gonzalo Camarillo , secdir@ietf.org, draft-ietf-simple-msrp-sessmatch@tools.ietf.org, IESG IESG , simple@ietf.org Subject: Re: [secdir] [Simple] secdir review of draft-ietf-simple-msrp-sessmatch 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, 14 Oct 2010 22:58:48 -0000 Hi Adrian, Are you referring to the COMEDIA support in msrp-acm, the session = matching change in msrp-sessmatch, or both? Thanks! Ben. On Oct 14, 2010, at 5:26 PM, Adrian Georgescu wrote: > My two cents. Having implemented both models in Blink client (Blink is = a free download if someone cares and wants to experiment with both MSRP = models), I can comment that I do not like the acm model. The relay model = is simply better, cleaner and more secure. >=20 > Adrian >=20 >=20 > On Oct 14, 2010, at 3:27 PM, Cullen Jennings wrote: >=20 >>=20 >> The new draft is clearer but I still don't think it addresses my = concerns. I would say at this point they could be summarized as=20 >>=20 >> 1) The draft is very hard to review without doing the diffs to 4975. = To try and help instead of just complain, I'm willing to go back patch = these changes into the last XML for 4975 and provide a draft that we can = actually read to see what this all means. I can't do that till after the = -01 deadline.=20 >>=20 >> 2) As far as I can tell, this does change the security of 4975 in a = pretty significant way in that this allows a MITM to masquerade with the = wrong to and from path that may be in the cert. It is not clear how it = work when the end points are not using self signed certs and changes the = preferred deployment mode from using certs rooted in a trust anchor to = self signed. All this seems to significantly weaken the security of 4975 = which concerns me and I have not seen relevant discussion of all this. I = am open to the idea that it does not making this much worse than they = currently are in 4975 and that it is a reasonable trade off but I'd like = to see concrete discussion of the issues and tradeoffs. How bad is it? = how much worse is it? People says it is no worse but I and several = others remain unconvinced that it is the same as 4975. I'd rather see a = very explicitly discussion with people like the security reviewer about = how much this changes things and if it is acceptable. It's not easy to = sort this all out - it actually might be acceptable - I'm just not = convinced yet and the "there is no problem because there is not change" = form of argument is not convincing me - clearly there is a a change and = at causal glance the point of that change seems to be to insert a MITM.=20= >>=20 >> 3) The backwards comparability issue seems huge. Some people have = said an endpoint using this draft will not talk with one that only does = 4975. Yet if this draft if published as an RFC would basically = depreciate the 4975 and replace it with a the result of applying this = diff to 4795. So if one person implements the pre update version, and = another person the post - it's not clear to me how we migrate from old = to new on the existing deployments. A flag day is obviously not going to = work. The more I look at this, the more I think this draft needs to be = recast as a backwards compatible extension to 4975 and not a draft that = update 4975. When I look at how this changes 4975 it seems to mostly = relax the existing security but not disallow things that used to work so = I think it should be possible to do this. On a side note, I phoned a few = people who I know that have MSRP implementation and none of them had any = plans to implement this and were surprised to hear there was a draft = that would update in 4975 with a change like this. To me this combined = with the no backwards compatibility issue argues strongly for figuring = out how to make this an extension instead of a change to MSRP.=20 >>=20 >> 4) When I search the email lists, I find more more people who see = significant problems with this than I find people that seem to think it = is OK. I don't think it has consensus -I think it just has people who = stopped care. The changes that needed to happen in IETF LC to fix this = draft so it had any chance of working at all more or less convinced me = the WG did not read this draft. The ietf@ietf.org list is not an ideal = location for discussion that rewrites pretty much all of the normative = text of this draft (which is what is happening here).=20 >>=20 >> Cullen >>=20 >>=20 >>=20 >> On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote: >>=20 >>> Hi, >>>=20 >>> Christer has submitted a new revision of this draft: >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ >>>=20 >>> Those of you who sent IETF LC comments on this draft, could you = please >>> have a look at the new version and let Christer know if he has = addressed >>> your concerns? >>>=20 >>> Thanks, >>>=20 >>> Gonzalo >>>=20 >>>=20 >>> On 31/08/2010 8:39 PM, Christer Holmberg wrote: >>>> Hi, >>>>=20 >>>> The purpose of this e-mail is to address the secdir comments given = by Richard >>>> Barnes and Ted Hardie. Due to summer vacations, standardization = meetings >>>> etc it took a while to put the e-mail together, and we appologise = for that. >>>>=20 >>>> GENERAL >>>> =3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> First, the draft does NOT propose any changes to the TLS = authentication >>>> procedures =96 that will be clarified. The changes are only related = to the >>>> procedure for matching an incoming MSRP message to an MSRP session = that >>>> has been negotiated using SDP =96 once any TLS authentication = procedure has >>>> already taken place. >>>>=20 >>>> So, in case of TLS and name based authentication, if an SBC/ALG = modifies >>>> the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is = the current >>>> behavior, and sessmatch doesn=92t change that. >>>>=20 >>>> We understand that this fact needs to be clearly indicated in the = draft. >>>>=20 >>>> Basically sessmatch allows so that, when using peer to peer MSRP, = SIP SBCs >>>> and SIP aware firewalls can be in the SIP signaling path without = acting as >>>> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with = MSRP relays >>>> the SBC/ALG needs to act as MSRP B2BUA, as today. >>>>=20 >>>> Sessmatch aims to extend the usability of MSRP peer to peer = communication to >>>> scenarios where simple ALGs/SBCs are used, and at least in our = experience >>>> customer interest for standard MSRP has grown (from more or less = zero) >>>> dramatically due to sessmatch. And, OMA, which previously used a = *non-standard* >>>> version of MSRP (with no interoperability with standard MSRP), has = also agreed >>>> to switch to sessmatch (even if it required a number of changes in = their >>>> specifications). >>>>=20 >>>> Second, the intention of sessmatch is not to modify the MSRP URI = matching rules, >>>> but rather to not use MSRP URI matching for session matching. >>>>=20 >>>> Please also note that when we talk about SBCs/ALGs, we refer to = entities that >>>> normally do NOT have the capability to act as MSRP B2BUAs. >>>>=20 >>>> We will comment the individual comments based on the assumptions = above. >>>>=20 >>>>=20 >>>> Comments from Richard >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>>> 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. >>>>>=20 >>>>> This document changes the URI matching algorithm used in MSRP. = MSRP sessions >>>>> are typically initiated using SDP bodies in SIP. These SDP >>>>> bodies contain MSRP URIs that the peers use to contact each other. >>>>> When one peer receives a request to initiate a session, he = verifies that the >>>>> URI being requested is one that he initiated in SDP, thereby using = the URI as a >>>>> shared secret to authenticate that the originator of the session = actually >>>>> received the SDP body in question. >>>>>=20 >>>>> According to the current SDP specification, this comparison is = performed over >>>>> the whole URI; this document restricts the comparison to the = "session-id" >>>>> component, omitting the host, port, and transport components. The = goal of the >>>>> document is to facilitate a certain class of man-in-the-middle = attack, namely >>>>> to allow a signaling intermediary to insert a media intermediary. = The >>>>> restriction on the URI comparison is needed in order for the media = intermediary >>>>> not to have to modify URIs in MSRP packets to reflect the = modifications to URIs >>>>> in SDP bodies performed to redirect traffic through the media = intermediary. >>>>=20 >>>> When an MSRP UA receives an MSRP packet it performs msrp session = matching in order >>>> to verify that the msrp packet belongs to an existing SDP = negotiated msrp session >>>> at the UA. RFC4975 prescribes that URI matching should be used for = session matching. >>>> We argue that the namespace scoping of the session-id values that = use of URI matching >>>> brings is unnecessary. The 80-bit randomness of the session-id and = the fact that it >>>> was the UA itself that decided on the session-id value and can = ensure that it is >>>> unique within the UA makes the session-id sufficiently unique for = session matching. >>>> Sessmatch is not changing the MSRP URI matching algorithm, it is = changing the session >>>> matching algorithm not to use MSRP URI matching. >>>>=20 >>>>> I have a few significant reservations about this document: >>>>>=20 >>>>> 1) This extension makes it more difficult for MSRP entities to = secure their >>>>> communications against attackers in the signaling path. The = current model >>>>> provides a basic integrity protection, in that signaling = intermediaries cannot >>>>> redirect traffic to an arbitrary third party; they must at least = advise the >>>>> third party about how to modify MSRP packets. The proposed = modification would >>>>> remove even this cost. >>>>=20 >>>> If we do not introduce the sessmatch change then the only = alternative for MSRP >>>> connections to be able to be set up when SBCs or SIP aware = firewalls are in the >>>> SIP signaling path is for these to introduce MSRP B2BUA support. = This is probably >>>> not feasible for most SBCs and SIP aware firewalls, and if it = actually were >>>> feasible then it would mean as big a security problem, or even = bigger, than >>>> sessmatch. The choice is thus to not use MSRP at all in presence of = such devices >>>> or to introduce sessmatch. Not to fix this probably would mean that = use of MSRP >>>> will be marginalized. >>>>=20 >>>>> 2) Moreover, it raises the cost of providing integrity protection = to messages, >>>>> since Alice must now employ both integrity and confidentiality = protections on >>>>> an end-to-end basis; if her messages are only integrity-protected, = then a proxy >>>>> can remove the integrity protection and redirect traffic without = it being >>>>> observable to Alice. >>>>>=20 >>>>> The document needs to clarify what the impacts are for = authentication in secure >>>>> modes of MSRP. In particular: >>>>> -- The distinction between "self-signed" and "public" certificates = is >>>>> inappropriate. The proper distinction is between the name-based = authentication >>>>> in Section 14.2 of RFC 4975 and the fingerprint-based = authentication in Section >>>>> 14.4. >>>>=20 >>>> We cannot find the terminology =93name-based=94 authentication in = RFC 4975. The RFC talks >>>> about TLS authentication using either certificates from well-known = certificate >>>> authorities, or using self-signed certificates together with = certificate fingerprints. >>>>=20 >>>> Having said that, however, we DO agree that the terminology you = suggest is more >>>> appropriate than what we have used and we will introduce this = terminology and explain >>>> it in the Convention section of the sessmatch draft. >>>>=20 >>>>> -- In either case, changing the host name need not result in an = authentication >>>>> failure, since the media intermediary can simply authenticate as = itself to both >>>>> endpoints, having changed the respective MSRP URIs appropriately. >>>>=20 >>>> A media intermediary can only do this if it is an MSRP B2BUA, and = sessmatch was >>>> introduced just to avoid most SBCs and ALGs having to implement an = MSRP B2BUA in order >>>> to allow standard MSRP deployment. >>>>=20 >>>>> -- There is currently no requirement that an endpoint identity in = the To-Path >>>>> URI matches the endpoint identity authenticated at the TLS layer, = because these >>>>> two are required to be the same. This document changes that = assumption, and >>>>> should note that these two identities can differ. >>>>=20 >>>> We will explicitly mention this. >>>>=20 >>>>> The document also precludes any name-based multiplexing, where a = single MSRP >>>>> process (single IP address and port) directs requests to different = virtual >>>>> recipients based on the domain name in the To-Path header. (In = analogy to >>>>> Host-based multiplexing in HTTP, which is very widely deployed.) = Since with >>>>> this extension, the domain in the To- Path is completely = unpredictable from the >>>>> recipient's perspective, it is useless to the recipient. >>>>=20 >>>> That is correct, but there should be no problem for a single MSRP = process (single >>>> IP address and port) to direct requests to different virtual = recipients - based >>>> on the session-id instead. It is only needed for the different = virtual recipients >>>> to inform the receiver process on which session-ids that are = currently negotiated >>>> instead of informing it on which domain name the virtual recipient = shall be >>>> associated with. >>>>=20 >>>>> The document has no backward-compatibility. MSRP implementations = that do not >>>>> support this extension will not be able to receive MSRP sessions = from >>>>> implementations that do. In that regard, this document seems more = like a new >>>>> version of MSRP rather than an update. >>>>=20 >>>> It is not true that there is no backwards compatibility. If there = are no >>>> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no = problem for MSRP >>>> implementations that do not support the sessmatch extension to = receive MSRP >>>> sessions from implementations that do. >>>>=20 >>>> MSRP implementations that do not support the sessmatch extension = are however not >>>> able to establish MSRP end to end conversations if there are = ALGs/SBCs in the >>>> session path (unless these implement MSRP B2BUA) and sessmatch does = not change this >>>> fact =96 it will not work disregarding if the other endpoint = supports sessmatch or not. >>>>=20 >>>>>>> I also note that the security considerations, in addition to = having >>>>>>> some fairly disingenuous language about the impact of this = change, >>>>>>> seems to fail to mention MSRPS URIs and what, if any, impact = this >>>>>>> would have on them. >>>>>>=20 >>>>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly >>>>>> understood since MSRPS URIs are not mentioned in the draft. >>>>>>=20 >>>>>> However, we could explicitly make it clear by modifying the first >>>>>> sentences of section 5: >>>>>>=20 >>>>>> "The change of session matching procedure does not impact the >>>>>> format of MSRP URIs, disregarding if the "msrp" scheme or the = "msrps" scheme >>>>>> is used. However, MSRP endpoints can only check that the = session-id part of >>>>>> the MSRP URI..." >>>>>=20 >>>>> The conflict here is that with MRSPS authentication, the name in = the >>>>> certificate is checked against the domain name in the URI, which = was OK when >>>>> the URI in the message was required to be the same. By allowing = the domain >>>>> name in the message to change, this draft removes = man-in-the-middle protection >>>>> from MSRPS. >>>>>=20 >>>>> The document notes that a SIP MitM can already direct the user to = another >>>>> destination. However, if the peers use MSRPS with the current = authentication >>>>> scheme, the MitM will not be able to be a part of the resulting = MSRPS session, >>>>> since he can't authenticate as one of the endpoints. If only the = session ID is >>>>> used in comparisons, the MitM can patch himself in by changing the = domain in >>>>> the MSRPS URI. (Which actually seems to be the intended use case = for this >draft.) >>>>>=20 >>>>> So the current document does introduce a new MitM vulnerability to = MSRPS. >>>>=20 >>>> Sessmatch does not change the fact that name based TLS = authentication for MSRPS >>>> will fail if an SBC or ALG has modified the hostname value in the = MSRP URI in the >>>> SDP a=3Dpath attribute without also acting as MSRP B2BUA. >>>>=20 >>>>=20 >>>> Comments from Ted >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>>> I join Richard in believing that this document makes changes = beyond that which >>>>> could be understood as "updating" the MSRP URI scheme processing. >>>>>=20 >>>>> ... >>>>>=20 >>>>> I also note that the security considerations, in addition to = having some fairly >>>>> disingenuous language about the impact of this change, seems to = fail to mention >>>>> MSRPS URIs and what, if any, impact this would have on them. >>>>=20 >>>> We will clarify what impacts there are. >>>>=20 >>>> ------- >>>>=20 >>>>>>> To highlight one particular aspect, RFC 4975 does not require >>>>>>> session-ids to be present, a fact noted both in the ABNF and in = this >>>>>>> text: >>>>>>>=20 >>>>>>> 4. The session-id part is compared as case sensitive. A URI = without >>>>>>> a session-id part is never equivalent to one that includes one. >>>>>>>=20 >>>>>>> A matching scheme which relies on a URI section which is not >>>>>>> guaranteed to be present has some interesting problems ahead of = it. If >>>>>>> this effectively makes their use mandatory, that requires a = change to >>>>>>> the fundamental ABNF and text. >>>>>>=20 >>>>>> An MSRP URI in an SDP offer or answer for an MSRP session MUST = include a >>>>>> session-id part, so I believe the comment is >>>>>> based on incorrect assumptions. >>>>>=20 >>>>> This is not indicated in the URI matching section >>>>=20 >>>> We will clarify that sessmatch conformant UAs do not use MSRP URI = matching in >>>> order to perform MSRP session matching. >>>>=20 >>>>>> Section 6 of RFC 4975 says: >>>>>>=20 >>>>>> "The session-id part identifies a particular session of the >>>>>> participant. The absence of the session-id >>>>>> part indicates a reference to an MSRP host device, but does not = refer to a >>>>>> particular session at that device." >>>>>>=20 >>>>>=20 >>>>> The full section from which that quote is taken is: >>>>>=20 >>>>> The MSRP URI authority field identifies a participant in a = particular >>>>> MSRP session. If the authority field contains a numeric IP = address, >>>>> it MUST also contain a port. The session-id part identifies a >>>>> particular session of the participant. The absence of the = session-id >>>>> part indicates a reference to an MSRP host device, but does not = refer >>>>> to a particular session at that device. A particular value of >>>>> session-id is only meaningful in the context of the associated >>>>> authority; thus, the authority component can be thought of as >>>>> identifying the "authority" governing a namespace for the = session-id. >>>>>=20 >>>>> This proposal changes the concept of a namespace authority present = in the URI >>>>> matching section of RFC 4975. I am sorry if my wry reference to = this in my >>>>> previous message was hard to follow; I should have known better. >>>>>=20 >>>>> To be more plain, this proposal fundamentally changes the matching = semantics of >>>>> the URI set out in RFC 4975, by requiring a match on only a = portion of the URI. >>>>> At a bare minimum, this would require noting a normative update to = section 6 >>>>> and 6.1 of RFC 4975, which this draft does not do. In reality, = this is >>>>> unlikely to be sufficient, as URI matching semantics do not = generally have the >>>>> concept of ignoring the authority in providing a match (at least = in my reading >>>>> of the RFC 3986 "ladder of comparison" text). That means you'd = have to special >>>>> case the MSRP matching semantics, rather than have the URI be = parsed and >>>>> compared using a standard library. >>>>=20 >>>> Sessmatch removes the URI matching as a means to do MSRP session = matching, and >>>> replaces it with a pure session-id matching. There is no need to = create a new >>>> URI scheme that does not re-use the authority component. We believe = the minimum >>>> 80-bit randomness of the session-id, together with the fact that = the UA itself >>>> generates the session-id it matches on, to be enough for the = session-id to be >>>> unique in the scope of the sessions that are active at the UA. >>>>=20 >>>> Also, the security of the matching is not particularly decreased, = since it is >>>> relatively easy to find out the authority name anyway. >>>>=20 >>>>>>> I also note that the security considerations, in addition to = having >>>>>>> some fairly disingenuous language about the impact of this = change, >>>>>>> seems to fail to mention MSRPS URIs and what, if any, impact = this >>>>>>> would have on them. >>>>>>=20 >>>>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly understood >>>>>> since MSRPS URIs are not mentioned in the draft. >>>>>>=20 >>>>>> However, we could explicitly make it clear by modifying the first = sentences of >>>>>> section 5: >>>>>>=20 >>>>>> "The change of session matching procedure does not impact the = format of MSRP >>>>>> URIs, disregarding if the "msrp" scheme or the "msrps" scheme is = used. >>>>>> However, MSRP endpoints can only check that the session-id part = of the MSRP >>>>>> URI..." >>>>>>=20 >>>>> This doesn't seem to me to actually work, based on Richard's = comments, unless >>>>> what you mean to say is "if MSRPS is in use, nothing in this draft = can be >>>>> used". That gives you different matching semantics for MSRPS = (authority must >>>>> be present and must be matched using TLS semantics) vs MSRP (only = session-id is >>>>> checked) which is at the very least a violation of the principle = of least >>>>> surprise (no other foo over TLS protocol works that way that I = know of ). >>>>=20 >>>> Session matching is done when receiving MSRP packets on an already = established TCP >>>> or TCP/TLS connection, and there will not be any different session = matching procedure >>>> depending on if the connection uses TLS or plain TCP. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ag@ag-projects.com Thu Oct 14 18:05:20 2010 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 B1F193A67E6; Thu, 14 Oct 2010 18:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, 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 kZDNUAQBClGc; Thu, 14 Oct 2010 18:05:18 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by core3.amsl.com (Postfix) with ESMTP id E2D3D3A686B; Thu, 14 Oct 2010 18:05:17 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9703BB01C2; Fri, 15 Oct 2010 03:06:36 +0200 (CEST) Received: from [95.99.162.23] (unknown [95.99.162.23]) by mail.sipthor.net (Postfix) with ESMTPSA id BD9F3B0192; Fri, 15 Oct 2010 03:06:26 +0200 (CEST) References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com> <572332FE-BFD1-41B0-AE9E-8ECB96D2FB05@ag-projects.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <985B1081-CE9D-4AE6-9B7F-BDBB03693006@ag-projects.com> X-Mailer: iPhone Mail (8B117) From: Adrian Georgescu Date: Thu, 14 Oct 2010 20:05:47 -0500 To: Ben Campbell X-Mailman-Approved-At: Fri, 15 Oct 2010 06:06:11 -0700 Cc: Cullen Jennings , Ted Hardie , The IETF , "secdir@ietf.org" , Gonzalo Camarillo , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , IESG IESG , "simple@ietf.org" Subject: Re: [secdir] [Simple] secdir review of draft-ietf-simple-msrp-sessmatch 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, 15 Oct 2010 01:05:20 -0000 Both of them -- Adrian On Oct 14, 2010, at 17:58, Ben Campbell wrote: > Hi Adrian, >=20 > Are you referring to the COMEDIA support in msrp-acm, the session matching= change in msrp-sessmatch, or both? >=20 > Thanks! >=20 > Ben. >=20 > On Oct 14, 2010, at 5:26 PM, Adrian Georgescu wrote: >=20 >> My two cents. Having implemented both models in Blink client (Blink is a f= ree download if someone cares and wants to experiment with both MSRP models)= , I can comment that I do not like the acm model. The relay model is simply b= etter, cleaner and more secure. >>=20 >> Adrian >>=20 >>=20 >> On Oct 14, 2010, at 3:27 PM, Cullen Jennings wrote: >>=20 >>>=20 >>> The new draft is clearer but I still don't think it addresses my concern= s. I would say at this point they could be summarized as=20 >>>=20 >>> 1) The draft is very hard to review without doing the diffs to 4975. To t= ry and help instead of just complain, I'm willing to go back patch these cha= nges into the last XML for 4975 and provide a draft that we can actually rea= d to see what this all means. I can't do that till after the -01 deadline.=20= >>>=20 >>> 2) As far as I can tell, this does change the security of 4975 in a pret= ty significant way in that this allows a MITM to masquerade with the wrong t= o and from path that may be in the cert. It is not clear how it work when th= e end points are not using self signed certs and changes the preferred deplo= yment mode from using certs rooted in a trust anchor to self signed. All thi= s seems to significantly weaken the security of 4975 which concerns me and I= have not seen relevant discussion of all this. I am open to the idea that i= t does not making this much worse than they currently are in 4975 and that i= t is a reasonable trade off but I'd like to see concrete discussion of the i= ssues and tradeoffs. How bad is it? how much worse is it? People says it is n= o worse but I and several others remain unconvinced that it is the same as 4= 975. I'd rather see a very explicitly discussion with people like the securi= ty reviewer about how much this changes things and if it is acceptable. It's= not easy to sort this all out - it actually might be acceptable - I'm just n= ot convinced yet and the "there is no problem because there is not change" f= orm of argument is not convincing me - clearly there is a a change and at ca= usal glance the point of that change seems to be to insert a MITM.=20 >>>=20 >>> 3) The backwards comparability issue seems huge. Some people have said a= n endpoint using this draft will not talk with one that only does 4975. Yet i= f this draft if published as an RFC would basically depreciate the 4975 and r= eplace it with a the result of applying this diff to 4795. So if one person i= mplements the pre update version, and another person the post - it's not cle= ar to me how we migrate from old to new on the existing deployments. A flag d= ay is obviously not going to work. The more I look at this, the more I think= this draft needs to be recast as a backwards compatible extension to 4975 a= nd not a draft that update 4975. When I look at how this changes 4975 it see= ms to mostly relax the existing security but not disallow things that used t= o work so I think it should be possible to do this. On a side note, I phoned= a few people who I know that have MSRP implementation and none of them had a= ny plans to implement this and were surprised to hear there was a draft that= would update in 4975 with a change like this. To me this combined with the n= o backwards compatibility issue argues strongly for figuring out how to make= this an extension instead of a change to MSRP.=20 >>>=20 >>> 4) When I search the email lists, I find more more people who see signif= icant problems with this than I find people that seem to think it is OK. I d= on't think it has consensus -I think it just has people who stopped care. T= he changes that needed to happen in IETF LC to fix this draft so it had any c= hance of working at all more or less convinced me the WG did not read this d= raft. The ietf@ietf.org list is not an ideal location for discussion that re= writes pretty much all of the normative text of this draft (which is what is= happening here).=20 >>>=20 >>> Cullen >>>=20 >>>=20 >>>=20 >>> On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote: >>>=20 >>>> Hi, >>>>=20 >>>> Christer has submitted a new revision of this draft: >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ >>>>=20 >>>> Those of you who sent IETF LC comments on this draft, could you please >>>> have a look at the new version and let Christer know if he has addresse= d >>>> your concerns? >>>>=20 >>>> Thanks, >>>>=20 >>>> Gonzalo >>>>=20 >>>>=20 >>>> On 31/08/2010 8:39 PM, Christer Holmberg wrote: >>>>> Hi, >>>>>=20 >>>>> The purpose of this e-mail is to address the secdir comments given by R= ichard >>>>> Barnes and Ted Hardie. Due to summer vacations, standardization meetin= gs >>>>> etc it took a while to put the e-mail together, and we appologise for t= hat. >>>>>=20 >>>>> GENERAL >>>>> =3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> First, the draft does NOT propose any changes to the TLS authenticatio= n >>>>> procedures =E2=80=93 that will be clarified. The changes are only rela= ted to the >>>>> procedure for matching an incoming MSRP message to an MSRP session tha= t >>>>> has been negotiated using SDP =E2=80=93 once any TLS authentication pr= ocedure has >>>>> already taken place. >>>>>=20 >>>>> So, in case of TLS and name based authentication, if an SBC/ALG modifi= es >>>>> the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is the c= urrent >>>>> behavior, and sessmatch doesn=E2=80=99t change that. >>>>>=20 >>>>> We understand that this fact needs to be clearly indicated in the draf= t. >>>>>=20 >>>>> Basically sessmatch allows so that, when using peer to peer MSRP, SIP S= BCs >>>>> and SIP aware firewalls can be in the SIP signaling path without actin= g as >>>>> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP r= elays >>>>> the SBC/ALG needs to act as MSRP B2BUA, as today. >>>>>=20 >>>>> Sessmatch aims to extend the usability of MSRP peer to peer communicat= ion to >>>>> scenarios where simple ALGs/SBCs are used, and at least in our experie= nce >>>>> customer interest for standard MSRP has grown (from more or less zero)= >>>>> dramatically due to sessmatch. And, OMA, which previously used a *non-= standard* >>>>> version of MSRP (with no interoperability with standard MSRP), has als= o agreed >>>>> to switch to sessmatch (even if it required a number of changes in the= ir >>>>> specifications). >>>>>=20 >>>>> Second, the intention of sessmatch is not to modify the MSRP URI match= ing rules, >>>>> but rather to not use MSRP URI matching for session matching. >>>>>=20 >>>>> Please also note that when we talk about SBCs/ALGs, we refer to entiti= es that >>>>> normally do NOT have the capability to act as MSRP B2BUAs. >>>>>=20 >>>>> We will comment the individual comments based on the assumptions above= . >>>>>=20 >>>>>=20 >>>>> Comments from Richard >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>>> I have reviewed this document as part of the security directorate's o= ngoing >>>>>> effort to review all IETF documents being processed by the IESG. Thes= e >>>>>> comments were written primarily for the benefit of the security area d= irectors. >>>>>> Document editors and WG chairs should treat these comments just like a= ny other >>>>>> last call comments. >>>>>>=20 >>>>>> This document changes the URI matching algorithm used in MSRP. MSRP s= essions >>>>>> are typically initiated using SDP bodies in SIP. These SDP >>>>>> bodies contain MSRP URIs that the peers use to contact each other. >>>>>> When one peer receives a request to initiate a session, he verifies t= hat the >>>>>> URI being requested is one that he initiated in SDP, thereby using th= e URI as a >>>>>> shared secret to authenticate that the originator of the session actu= ally >>>>>> received the SDP body in question. >>>>>>=20 >>>>>> According to the current SDP specification, this comparison is perfor= med over >>>>>> the whole URI; this document restricts the comparison to the "session= -id" >>>>>> component, omitting the host, port, and transport components. The go= al of the >>>>>> document is to facilitate a certain class of man-in-the-middle attack= , namely >>>>>> to allow a signaling intermediary to insert a media intermediary. Th= e >>>>>> restriction on the URI comparison is needed in order for the media in= termediary >>>>>> not to have to modify URIs in MSRP packets to reflect the modificatio= ns to URIs >>>>>> in SDP bodies performed to redirect traffic through the media interme= diary. >>>>>=20 >>>>> When an MSRP UA receives an MSRP packet it performs msrp session match= ing in order >>>>> to verify that the msrp packet belongs to an existing SDP negotiated m= srp session >>>>> at the UA. RFC4975 prescribes that URI matching should be used for ses= sion matching. >>>>> We argue that the namespace scoping of the session-id values that use o= f URI matching >>>>> brings is unnecessary. The 80-bit randomness of the session-id and the= fact that it >>>>> was the UA itself that decided on the session-id value and can ensure t= hat it is >>>>> unique within the UA makes the session-id sufficiently unique for sess= ion matching. >>>>> Sessmatch is not changing the MSRP URI matching algorithm, it is chang= ing the session >>>>> matching algorithm not to use MSRP URI matching. >>>>>=20 >>>>>> I have a few significant reservations about this document: >>>>>>=20 >>>>>> 1) This extension makes it more difficult for MSRP entities to secure= their >>>>>> communications against attackers in the signaling path. The current m= odel >>>>>> provides a basic integrity protection, in that signaling intermediari= es cannot >>>>>> redirect traffic to an arbitrary third party; they must at least advi= se the >>>>>> third party about how to modify MSRP packets. The proposed modificati= on would >>>>>> remove even this cost. >>>>>=20 >>>>> If we do not introduce the sessmatch change then the only alternative f= or MSRP >>>>> connections to be able to be set up when SBCs or SIP aware firewalls a= re in the >>>>> SIP signaling path is for these to introduce MSRP B2BUA support. This i= s probably >>>>> not feasible for most SBCs and SIP aware firewalls, and if it actually= were >>>>> feasible then it would mean as big a security problem, or even bigger,= than >>>>> sessmatch. The choice is thus to not use MSRP at all in presence of su= ch devices >>>>> or to introduce sessmatch. Not to fix this probably would mean that us= e of MSRP >>>>> will be marginalized. >>>>>=20 >>>>>> 2) Moreover, it raises the cost of providing integrity protection to m= essages, >>>>>> since Alice must now employ both integrity and confidentiality protec= tions on >>>>>> an end-to-end basis; if her messages are only integrity-protected, th= en a proxy >>>>>> can remove the integrity protection and redirect traffic without it b= eing >>>>>> observable to Alice. >>>>>>=20 >>>>>> The document needs to clarify what the impacts are for authentication= in secure >>>>>> modes of MSRP. In particular: >>>>>> -- The distinction between "self-signed" and "public" certificates is= >>>>>> inappropriate. The proper distinction is between the name-based auth= entication >>>>>> in Section 14.2 of RFC 4975 and the fingerprint-based authentication i= n Section >>>>>> 14.4. >>>>>=20 >>>>> We cannot find the terminology =E2=80=9Cname-based=E2=80=9D authentica= tion in RFC 4975. The RFC talks >>>>> about TLS authentication using either certificates from well-known cer= tificate >>>>> authorities, or using self-signed certificates together with certifica= te fingerprints. >>>>>=20 >>>>> Having said that, however, we DO agree that the terminology you sugges= t is more >>>>> appropriate than what we have used and we will introduce this terminol= ogy and explain >>>>> it in the Convention section of the sessmatch draft. >>>>>=20 >>>>>> -- In either case, changing the host name need not result in an authe= ntication >>>>>> failure, since the media intermediary can simply authenticate as itse= lf to both >>>>>> endpoints, having changed the respective MSRP URIs appropriately. >>>>>=20 >>>>> A media intermediary can only do this if it is an MSRP B2BUA, and sess= match was >>>>> introduced just to avoid most SBCs and ALGs having to implement an MSR= P B2BUA in order >>>>> to allow standard MSRP deployment. >>>>>=20 >>>>>> -- There is currently no requirement that an endpoint identity in the= To-Path >>>>>> URI matches the endpoint identity authenticated at the TLS layer, bec= ause these >>>>>> two are required to be the same. This document changes that assumpti= on, and >>>>>> should note that these two identities can differ. >>>>>=20 >>>>> We will explicitly mention this. >>>>>=20 >>>>>> The document also precludes any name-based multiplexing, where a sing= le MSRP >>>>>> process (single IP address and port) directs requests to different vi= rtual >>>>>> recipients based on the domain name in the To-Path header. (In analog= y to >>>>>> Host-based multiplexing in HTTP, which is very widely deployed.) Sinc= e with >>>>>> this extension, the domain in the To- Path is completely unpredictabl= e from the >>>>>> recipient's perspective, it is useless to the recipient. >>>>>=20 >>>>> That is correct, but there should be no problem for a single MSRP proc= ess (single >>>>> IP address and port) to direct requests to different virtual recipient= s - based >>>>> on the session-id instead. It is only needed for the different virtual= recipients >>>>> to inform the receiver process on which session-ids that are currently= negotiated >>>>> instead of informing it on which domain name the virtual recipient sha= ll be >>>>> associated with. >>>>>=20 >>>>>> The document has no backward-compatibility. MSRP implementations that= do not >>>>>> support this extension will not be able to receive MSRP sessions from= >>>>>> implementations that do. In that regard, this document seems more lik= e a new >>>>>> version of MSRP rather than an update. >>>>>=20 >>>>> It is not true that there is no backwards compatibility. If there are n= o >>>>> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem f= or MSRP >>>>> implementations that do not support the sessmatch extension to receive= MSRP >>>>> sessions from implementations that do. >>>>>=20 >>>>> MSRP implementations that do not support the sessmatch extension are h= owever not >>>>> able to establish MSRP end to end conversations if there are ALGs/SBCs= in the >>>>> session path (unless these implement MSRP B2BUA) and sessmatch does no= t change this >>>>> fact =E2=80=93 it will not work disregarding if the other endpoint sup= ports sessmatch or not. >>>>>=20 >>>>>>>> I also note that the security considerations, in addition to having= >>>>>>>> some fairly disingenuous language about the impact of this change, >>>>>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>>>>> would have on them. >>>>>>>=20 >>>>>>> There are no impacts to MSRPS URIs. I assumed it would be implicitly= >>>>>>> understood since MSRPS URIs are not mentioned in the draft. >>>>>>>=20 >>>>>>> However, we could explicitly make it clear by modifying the first >>>>>>> sentences of section 5: >>>>>>>=20 >>>>>>> "The change of session matching procedure does not impact the >>>>>>> format of MSRP URIs, disregarding if the "msrp" scheme or the "msrps= " scheme >>>>>>> is used. However, MSRP endpoints can only check that the session-id p= art of >>>>>>> the MSRP URI..." >>>>>>=20 >>>>>> The conflict here is that with MRSPS authentication, the name in the >>>>>> certificate is checked against the domain name in the URI, which was O= K when >>>>>> the URI in the message was required to be the same. By allowing the d= omain >>>>>> name in the message to change, this draft removes man-in-the-middle p= rotection >>>>>> from MSRPS. >>>>>>=20 >>>>>> The document notes that a SIP MitM can already direct the user to ano= ther >>>>>> destination. However, if the peers use MSRPS with the current authen= tication >>>>>> scheme, the MitM will not be able to be a part of the resulting MSRPS= session, >>>>>> since he can't authenticate as one of the endpoints. If only the sess= ion ID is >>>>>> used in comparisons, the MitM can patch himself in by changing the do= main in >>>>>> the MSRPS URI. (Which actually seems to be the intended use case for t= his >draft.) >>>>>>=20 >>>>>> So the current document does introduce a new MitM vulnerability to MS= RPS. >>>>>=20 >>>>> Sessmatch does not change the fact that name based TLS authentication f= or MSRPS >>>>> will fail if an SBC or ALG has modified the hostname value in the MSRP= URI in the >>>>> SDP a=3Dpath attribute without also acting as MSRP B2BUA. >>>>>=20 >>>>>=20 >>>>> Comments from Ted >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>>> I join Richard in believing that this document makes changes beyond t= hat which >>>>>> could be understood as "updating" the MSRP URI scheme processing. >>>>>>=20 >>>>>> ... >>>>>>=20 >>>>>> I also note that the security considerations, in addition to having s= ome fairly >>>>>> disingenuous language about the impact of this change, seems to fail t= o mention >>>>>> MSRPS URIs and what, if any, impact this would have on them. >>>>>=20 >>>>> We will clarify what impacts there are. >>>>>=20 >>>>> ------- >>>>>=20 >>>>>>>> To highlight one particular aspect, RFC 4975 does not require >>>>>>>> session-ids to be present, a fact noted both in the ABNF and in thi= s >>>>>>>> text: >>>>>>>>=20 >>>>>>>> 4. The session-id part is compared as case sensitive. A URI withou= t >>>>>>>> a session-id part is never equivalent to one that includes one. >>>>>>>>=20 >>>>>>>> A matching scheme which relies on a URI section which is not >>>>>>>> guaranteed to be present has some interesting problems ahead of it.= If >>>>>>>> this effectively makes their use mandatory, that requires a change t= o >>>>>>>> the fundamental ABNF and text. >>>>>>>=20 >>>>>>> An MSRP URI in an SDP offer or answer for an MSRP session MUST inclu= de a >>>>>>> session-id part, so I believe the comment is >>>>>>> based on incorrect assumptions. >>>>>>=20 >>>>>> This is not indicated in the URI matching section >>>>>=20 >>>>> We will clarify that sessmatch conformant UAs do not use MSRP URI matc= hing in >>>>> order to perform MSRP session matching. >>>>>=20 >>>>>>> Section 6 of RFC 4975 says: >>>>>>>=20 >>>>>>> "The session-id part identifies a particular session of the >>>>>>> participant. The absence of the session-id >>>>>>> part indicates a reference to an MSRP host device, but does not refe= r to a >>>>>>> particular session at that device." >>>>>>>=20 >>>>>>=20 >>>>>> The full section from which that quote is taken is: >>>>>>=20 >>>>>> The MSRP URI authority field identifies a participant in a particular= >>>>>> MSRP session. If the authority field contains a numeric IP address, >>>>>> it MUST also contain a port. The session-id part identifies a >>>>>> particular session of the participant. The absence of the session-id= >>>>>> part indicates a reference to an MSRP host device, but does not refer= >>>>>> to a particular session at that device. A particular value of >>>>>> session-id is only meaningful in the context of the associated >>>>>> authority; thus, the authority component can be thought of as >>>>>> identifying the "authority" governing a namespace for the session-id.= >>>>>>=20 >>>>>> This proposal changes the concept of a namespace authority present in= the URI >>>>>> matching section of RFC 4975. I am sorry if my wry reference to this i= n my >>>>>> previous message was hard to follow; I should have known better. >>>>>>=20 >>>>>> To be more plain, this proposal fundamentally changes the matching se= mantics of >>>>>> the URI set out in RFC 4975, by requiring a match on only a portion o= f the URI. >>>>>> At a bare minimum, this would require noting a normative update to se= ction 6 >>>>>> and 6.1 of RFC 4975, which this draft does not do. In reality, this i= s >>>>>> unlikely to be sufficient, as URI matching semantics do not generally= have the >>>>>> concept of ignoring the authority in providing a match (at least in m= y reading >>>>>> of the RFC 3986 "ladder of comparison" text). That means you'd have t= o special >>>>>> case the MSRP matching semantics, rather than have the URI be parsed a= nd >>>>>> compared using a standard library. >>>>>=20 >>>>> Sessmatch removes the URI matching as a means to do MSRP session match= ing, and >>>>> replaces it with a pure session-id matching. There is no need to creat= e a new >>>>> URI scheme that does not re-use the authority component. We believe th= e minimum >>>>> 80-bit randomness of the session-id, together with the fact that the U= A itself >>>>> generates the session-id it matches on, to be enough for the session-i= d to be >>>>> unique in the scope of the sessions that are active at the UA. >>>>>=20 >>>>> Also, the security of the matching is not particularly decreased, sinc= e it is >>>>> relatively easy to find out the authority name anyway. >>>>>=20 >>>>>>>> I also note that the security considerations, in addition to having= >>>>>>>> some fairly disingenuous language about the impact of this change, >>>>>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>>>>> would have on them. >>>>>>>=20 >>>>>>> There are no impacts to MSRPS URIs. I assumed it would be implicitly= understood >>>>>>> since MSRPS URIs are not mentioned in the draft. >>>>>>>=20 >>>>>>> However, we could explicitly make it clear by modifying the first se= ntences of >>>>>>> section 5: >>>>>>>=20 >>>>>>> "The change of session matching procedure does not impact the format= of MSRP >>>>>>> URIs, disregarding if the "msrp" scheme or the "msrps" scheme is use= d. >>>>>>> However, MSRP endpoints can only check that the session-id part of t= he MSRP >>>>>>> URI..." >>>>>>>=20 >>>>>> This doesn't seem to me to actually work, based on Richard's comments= , unless >>>>>> what you mean to say is "if MSRPS is in use, nothing in this draft ca= n be >>>>>> used". That gives you different matching semantics for MSRPS (authori= ty must >>>>>> be present and must be matched using TLS semantics) vs MSRP (only ses= sion-id is >>>>>> checked) which is at the very least a violation of the principle of l= east >>>>>> surprise (no other foo over TLS protocol works that way that I know o= f ). >>>>>=20 >>>>> Session matching is done when receiving MSRP packets on an already est= ablished TCP >>>>> or TCP/TLS connection, and there will not be any different session mat= ching procedure >>>>> depending on if the connection uses TLS or plain TCP. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From gcamaril@gmail.com Fri Oct 15 03:07:13 2010 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 9DBB93A68A8; Fri, 15 Oct 2010 03:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.744 X-Spam-Level: X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNwnzvQL7w8C; Fri, 15 Oct 2010 03:07:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DA5B93A68AE; Fri, 15 Oct 2010 03:07:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7b26ae00000638e-e9-4cb8280e7641 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 11.0A.25486.E0828BC4; Fri, 15 Oct 2010 12:08:14 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Oct 2010 12:07:38 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Oct 2010 12:07:36 +0200 Message-ID: <4CB827E8.9040400@gmail.com> Date: Fri, 15 Oct 2010 13:07:36 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Cullen Jennings References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com> In-Reply-To: <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Oct 2010 10:07:37.0444 (UTC) FILETIME=[CB50BA40:01CB6C50] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Fri, 15 Oct 2010 06:06:11 -0700 Cc: Ted Hardie , The IETF , "secdir@ietf.org" , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , IESG IESG , Christer Holmberg , "simple@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch 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, 15 Oct 2010 10:07:13 -0000 Hi, I am going to send this draft back to the SIMPLE WG so that they discuss these issues. Once the WG reaches (rough) consensus on what to do, I will be issuing a second IETF LC so that everybody is on the same page. Cheers, Gonzalo On 14/10/2010 11:27 PM, Cullen Jennings wrote: > > The new draft is clearer but I still don't think it addresses my concerns. I would say at this point they could be summarized as > > 1) The draft is very hard to review without doing the diffs to 4975. To try and help instead of just complain, I'm willing to go back patch these changes into the last XML for 4975 and provide a draft that we can actually read to see what this all means. I can't do that till after the -01 deadline. > > 2) As far as I can tell, this does change the security of 4975 in a pretty significant way in that this allows a MITM to masquerade with the wrong to and from path that may be in the cert. It is not clear how it work when the end points are not using self signed certs and changes the preferred deployment mode from using certs rooted in a trust anchor to self signed. All this seems to significantly weaken the security of 4975 which concerns me and I have not seen relevant discussion of all this. I am open to the idea that it does not making this much worse than they currently are in 4975 and that it is a reasonable trade off but I'd like to see concrete discussion of the issues and tradeoffs. How bad is it? how much worse is it? People says it is no worse but I and several others remain unconvinced that it is the same as 4975. I'd rather see a very explicitly discussion with people like the security reviewer about how much this changes things and if it is acceptable. It's n ot easy to sort this all out - it actually might be acceptable - I'm just not convinced yet and the "there is no problem because there is not change" form of argument is not convincing me - clearly there is a a change and at causal glance the point of that change seems to be to insert a MITM. > > 3) The backwards comparability issue seems huge. Some people have said an endpoint using this draft will not talk with one that only does 4975. Yet if this draft if published as an RFC would basically depreciate the 4975 and replace it with a the result of applying this diff to 4795. So if one person implements the pre update version, and another person the post - it's not clear to me how we migrate from old to new on the existing deployments. A flag day is obviously not going to work. The more I look at this, the more I think this draft needs to be recast as a backwards compatible extension to 4975 and not a draft that update 4975. When I look at how this changes 4975 it seems to mostly relax the existing security but not disallow things that used to work so I think it should be possible to do this. On a side note, I phoned a few people who I know that have MSRP implementation and none of them had any plans to implement this and were surprised to hear there was a draft t hat would update in 4975 with a change like this. To me this combined with the no backwards compatibility issue argues strongly for figuring out how to make this an extension instead of a change to MSRP. > > 4) When I search the email lists, I find more more people who see significant problems with this than I find people that seem to think it is OK. I don't think it has consensus -I think it just has people who stopped care. The changes that needed to happen in IETF LC to fix this draft so it had any chance of working at all more or less convinced me the WG did not read this draft. The ietf@ietf.org list is not an ideal location for discussion that rewrites pretty much all of the normative text of this draft (which is what is happening here). > > Cullen > > > > On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> Christer has submitted a new revision of this draft: >> >> https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ >> >> Those of you who sent IETF LC comments on this draft, could you please >> have a look at the new version and let Christer know if he has addressed >> your concerns? >> >> Thanks, >> >> Gonzalo >> >> >> On 31/08/2010 8:39 PM, Christer Holmberg wrote: >>> Hi, >>> >>> The purpose of this e-mail is to address the secdir comments given by Richard >>> Barnes and Ted Hardie. Due to summer vacations, standardization meetings >>> etc it took a while to put the e-mail together, and we appologise for that. >>> >>> GENERAL >>> ======= >>> >>> First, the draft does NOT propose any changes to the TLS authentication >>> procedures – that will be clarified. The changes are only related to the >>> procedure for matching an incoming MSRP message to an MSRP session that >>> has been negotiated using SDP – once any TLS authentication procedure has >>> already taken place. >>> >>> So, in case of TLS and name based authentication, if an SBC/ALG modifies >>> the a=path MSRP URI, the TLS authentication WILL fail. That is the current >>> behavior, and sessmatch doesn’t change that. >>> >>> We understand that this fact needs to be clearly indicated in the draft. >>> >>> Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs >>> and SIP aware firewalls can be in the SIP signaling path without acting as >>> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays >>> the SBC/ALG needs to act as MSRP B2BUA, as today. >>> >>> Sessmatch aims to extend the usability of MSRP peer to peer communication to >>> scenarios where simple ALGs/SBCs are used, and at least in our experience >>> customer interest for standard MSRP has grown (from more or less zero) >>> dramatically due to sessmatch. And, OMA, which previously used a *non-standard* >>> version of MSRP (with no interoperability with standard MSRP), has also agreed >>> to switch to sessmatch (even if it required a number of changes in their >>> specifications). >>> >>> Second, the intention of sessmatch is not to modify the MSRP URI matching rules, >>> but rather to not use MSRP URI matching for session matching. >>> >>> Please also note that when we talk about SBCs/ALGs, we refer to entities that >>> normally do NOT have the capability to act as MSRP B2BUAs. >>> >>> We will comment the individual comments based on the assumptions above. >>> >>> >>> Comments from Richard >>> ===================== >>> >>>> 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 changes the URI matching algorithm used in MSRP. MSRP sessions >>>> are typically initiated using SDP bodies in SIP. These SDP >>>> bodies contain MSRP URIs that the peers use to contact each other. >>>> When one peer receives a request to initiate a session, he verifies that the >>>> URI being requested is one that he initiated in SDP, thereby using the URI as a >>>> shared secret to authenticate that the originator of the session actually >>>> received the SDP body in question. >>>> >>>> According to the current SDP specification, this comparison is performed over >>>> the whole URI; this document restricts the comparison to the "session-id" >>>> component, omitting the host, port, and transport components. The goal of the >>>> document is to facilitate a certain class of man-in-the-middle attack, namely >>>> to allow a signaling intermediary to insert a media intermediary. The >>>> restriction on the URI comparison is needed in order for the media intermediary >>>> not to have to modify URIs in MSRP packets to reflect the modifications to URIs >>>> in SDP bodies performed to redirect traffic through the media intermediary. >>> >>> When an MSRP UA receives an MSRP packet it performs msrp session matching in order >>> to verify that the msrp packet belongs to an existing SDP negotiated msrp session >>> at the UA. RFC4975 prescribes that URI matching should be used for session matching. >>> We argue that the namespace scoping of the session-id values that use of URI matching >>> brings is unnecessary. The 80-bit randomness of the session-id and the fact that it >>> was the UA itself that decided on the session-id value and can ensure that it is >>> unique within the UA makes the session-id sufficiently unique for session matching. >>> Sessmatch is not changing the MSRP URI matching algorithm, it is changing the session >>> matching algorithm not to use MSRP URI matching. >>> >>>> I have a few significant reservations about this document: >>>> >>>> 1) This extension makes it more difficult for MSRP entities to secure their >>>> communications against attackers in the signaling path. The current model >>>> provides a basic integrity protection, in that signaling intermediaries cannot >>>> redirect traffic to an arbitrary third party; they must at least advise the >>>> third party about how to modify MSRP packets. The proposed modification would >>>> remove even this cost. >>> >>> If we do not introduce the sessmatch change then the only alternative for MSRP >>> connections to be able to be set up when SBCs or SIP aware firewalls are in the >>> SIP signaling path is for these to introduce MSRP B2BUA support. This is probably >>> not feasible for most SBCs and SIP aware firewalls, and if it actually were >>> feasible then it would mean as big a security problem, or even bigger, than >>> sessmatch. The choice is thus to not use MSRP at all in presence of such devices >>> or to introduce sessmatch. Not to fix this probably would mean that use of MSRP >>> will be marginalized. >>> >>>> 2) Moreover, it raises the cost of providing integrity protection to messages, >>>> since Alice must now employ both integrity and confidentiality protections on >>>> an end-to-end basis; if her messages are only integrity-protected, then a proxy >>>> can remove the integrity protection and redirect traffic without it being >>>> observable to Alice. >>>> >>>> The document needs to clarify what the impacts are for authentication in secure >>>> modes of MSRP. In particular: >>>> -- The distinction between "self-signed" and "public" certificates is >>>> inappropriate. The proper distinction is between the name-based authentication >>>> in Section 14.2 of RFC 4975 and the fingerprint-based authentication in Section >>>> 14.4. >>> >>> We cannot find the terminology “name-based” authentication in RFC 4975. The RFC talks >>> about TLS authentication using either certificates from well-known certificate >>> authorities, or using self-signed certificates together with certificate fingerprints. >>> >>> Having said that, however, we DO agree that the terminology you suggest is more >>> appropriate than what we have used and we will introduce this terminology and explain >>> it in the Convention section of the sessmatch draft. >>> >>>> -- In either case, changing the host name need not result in an authentication >>>> failure, since the media intermediary can simply authenticate as itself to both >>>> endpoints, having changed the respective MSRP URIs appropriately. >>> >>> A media intermediary can only do this if it is an MSRP B2BUA, and sessmatch was >>> introduced just to avoid most SBCs and ALGs having to implement an MSRP B2BUA in order >>> to allow standard MSRP deployment. >>> >>>> -- There is currently no requirement that an endpoint identity in the To-Path >>>> URI matches the endpoint identity authenticated at the TLS layer, because these >>>> two are required to be the same. This document changes that assumption, and >>>> should note that these two identities can differ. >>> >>> We will explicitly mention this. >>> >>>> The document also precludes any name-based multiplexing, where a single MSRP >>>> process (single IP address and port) directs requests to different virtual >>>> recipients based on the domain name in the To-Path header. (In analogy to >>>> Host-based multiplexing in HTTP, which is very widely deployed.) Since with >>>> this extension, the domain in the To- Path is completely unpredictable from the >>>> recipient's perspective, it is useless to the recipient. >>> >>> That is correct, but there should be no problem for a single MSRP process (single >>> IP address and port) to direct requests to different virtual recipients - based >>> on the session-id instead. It is only needed for the different virtual recipients >>> to inform the receiver process on which session-ids that are currently negotiated >>> instead of informing it on which domain name the virtual recipient shall be >>> associated with. >>> >>>> The document has no backward-compatibility. MSRP implementations that do not >>>> support this extension will not be able to receive MSRP sessions from >>>> implementations that do. In that regard, this document seems more like a new >>>> version of MSRP rather than an update. >>> >>> It is not true that there is no backwards compatibility. If there are no >>> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem for MSRP >>> implementations that do not support the sessmatch extension to receive MSRP >>> sessions from implementations that do. >>> >>> MSRP implementations that do not support the sessmatch extension are however not >>> able to establish MSRP end to end conversations if there are ALGs/SBCs in the >>> session path (unless these implement MSRP B2BUA) and sessmatch does not change this >>> fact – it will not work disregarding if the other endpoint supports sessmatch or not. >>> >>>>>> I also note that the security considerations, in addition to having >>>>>> some fairly disingenuous language about the impact of this change, >>>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>>> would have on them. >>>>> >>>>> There are no impacts to MSRPS URIs. I assumed it would be implicitly >>>>> understood since MSRPS URIs are not mentioned in the draft. >>>>> >>>>> However, we could explicitly make it clear by modifying the first >>>>> sentences of section 5: >>>>> >>>>> "The change of session matching procedure does not impact the >>>>> format of MSRP URIs, disregarding if the "msrp" scheme or the "msrps" scheme >>>>> is used. However, MSRP endpoints can only check that the session-id part of >>>>> the MSRP URI..." >>>> >>>> The conflict here is that with MRSPS authentication, the name in the >>>> certificate is checked against the domain name in the URI, which was OK when >>>> the URI in the message was required to be the same. By allowing the domain >>>> name in the message to change, this draft removes man-in-the-middle protection >>>> from MSRPS. >>>> >>>> The document notes that a SIP MitM can already direct the user to another >>>> destination. However, if the peers use MSRPS with the current authentication >>>> scheme, the MitM will not be able to be a part of the resulting MSRPS session, >>>> since he can't authenticate as one of the endpoints. If only the session ID is >>>> used in comparisons, the MitM can patch himself in by changing the domain in >>>> the MSRPS URI. (Which actually seems to be the intended use case for this >draft.) >>>> >>>> So the current document does introduce a new MitM vulnerability to MSRPS. >>> >>> Sessmatch does not change the fact that name based TLS authentication for MSRPS >>> will fail if an SBC or ALG has modified the hostname value in the MSRP URI in the >>> SDP a=path attribute without also acting as MSRP B2BUA. >>> >>> >>> Comments from Ted >>> ================= >>> >>>> I join Richard in believing that this document makes changes beyond that which >>>> could be understood as "updating" the MSRP URI scheme processing. >>>> >>>> ... >>>> >>>> I also note that the security considerations, in addition to having some fairly >>>> disingenuous language about the impact of this change, seems to fail to mention >>>> MSRPS URIs and what, if any, impact this would have on them. >>> >>> We will clarify what impacts there are. >>> >>> ------- >>> >>>>>> To highlight one particular aspect, RFC 4975 does not require >>>>>> session-ids to be present, a fact noted both in the ABNF and in this >>>>>> text: >>>>>> >>>>>> 4. The session-id part is compared as case sensitive. A URI without >>>>>> a session-id part is never equivalent to one that includes one. >>>>>> >>>>>> A matching scheme which relies on a URI section which is not >>>>>> guaranteed to be present has some interesting problems ahead of it. If >>>>>> this effectively makes their use mandatory, that requires a change to >>>>>> the fundamental ABNF and text. >>>>> >>>>> An MSRP URI in an SDP offer or answer for an MSRP session MUST include a >>>>> session-id part, so I believe the comment is >>>>> based on incorrect assumptions. >>>> >>>> This is not indicated in the URI matching section >>> >>> We will clarify that sessmatch conformant UAs do not use MSRP URI matching in >>> order to perform MSRP session matching. >>> >>>>> Section 6 of RFC 4975 says: >>>>> >>>>> "The session-id part identifies a particular session of the >>>>> participant. The absence of the session-id >>>>> part indicates a reference to an MSRP host device, but does not refer to a >>>>> particular session at that device." >>>>> >>>> >>>> The full section from which that quote is taken is: >>>> >>>> The MSRP URI authority field identifies a participant in a particular >>>> MSRP session. If the authority field contains a numeric IP address, >>>> it MUST also contain a port. The session-id part identifies a >>>> particular session of the participant. The absence of the session-id >>>> part indicates a reference to an MSRP host device, but does not refer >>>> to a particular session at that device. A particular value of >>>> session-id is only meaningful in the context of the associated >>>> authority; thus, the authority component can be thought of as >>>> identifying the "authority" governing a namespace for the session-id. >>>> >>>> This proposal changes the concept of a namespace authority present in the URI >>>> matching section of RFC 4975. I am sorry if my wry reference to this in my >>>> previous message was hard to follow; I should have known better. >>>> >>>> To be more plain, this proposal fundamentally changes the matching semantics of >>>> the URI set out in RFC 4975, by requiring a match on only a portion of the URI. >>>> At a bare minimum, this would require noting a normative update to section 6 >>>> and 6.1 of RFC 4975, which this draft does not do. In reality, this is >>>> unlikely to be sufficient, as URI matching semantics do not generally have the >>>> concept of ignoring the authority in providing a match (at least in my reading >>>> of the RFC 3986 "ladder of comparison" text). That means you'd have to special >>>> case the MSRP matching semantics, rather than have the URI be parsed and >>>> compared using a standard library. >>> >>> Sessmatch removes the URI matching as a means to do MSRP session matching, and >>> replaces it with a pure session-id matching. There is no need to create a new >>> URI scheme that does not re-use the authority component. We believe the minimum >>> 80-bit randomness of the session-id, together with the fact that the UA itself >>> generates the session-id it matches on, to be enough for the session-id to be >>> unique in the scope of the sessions that are active at the UA. >>> >>> Also, the security of the matching is not particularly decreased, since it is >>> relatively easy to find out the authority name anyway. >>> >>>>>> I also note that the security considerations, in addition to having >>>>>> some fairly disingenuous language about the impact of this change, >>>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>>> would have on them. >>>>> >>>>> There are no impacts to MSRPS URIs. I assumed it would be implicitly understood >>>>> since MSRPS URIs are not mentioned in the draft. >>>>> >>>>> However, we could explicitly make it clear by modifying the first sentences of >>>>> section 5: >>>>> >>>>> "The change of session matching procedure does not impact the format of MSRP >>>>> URIs, disregarding if the "msrp" scheme or the "msrps" scheme is used. >>>>> However, MSRP endpoints can only check that the session-id part of the MSRP >>>>> URI..." >>>>> >>>> This doesn't seem to me to actually work, based on Richard's comments, unless >>>> what you mean to say is "if MSRPS is in use, nothing in this draft can be >>>> used". That gives you different matching semantics for MSRPS (authority must >>>> be present and must be matched using TLS semantics) vs MSRP (only session-id is >>>> checked) which is at the very least a violation of the principle of least >>>> surprise (no other foo over TLS protocol works that way that I know of ). >>> >>> Session matching is done when receiving MSRP packets on an already established TCP >>> or TCP/TLS connection, and there will not be any different session matching procedure >>> depending on if the connection uses TLS or plain TCP. >>> >>> Regards, >>> >>> Christer >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > From weiler+secdir@watson.org Fri Oct 15 07:47:35 2010 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 353B03A6C81 for ; Fri, 15 Oct 2010 07:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 KMsRGHTeY2pC for ; Fri, 15 Oct 2010 07:47:34 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 0835A3A6C9D for ; Fri, 15 Oct 2010 07:47:02 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o9FEmNIP061317 for ; Fri, 15 Oct 2010 10:48:23 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o9FEmNfY061314 for ; Fri, 15 Oct 2010 10:48:23 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 15 Oct 2010 10:48:23 -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.2.3 (fledge.watson.org [127.0.0.1]); Fri, 15 Oct 2010 10:48:24 -0400 (EDT) Subject: [secdir] Assignments 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, 15 Oct 2010 14:47:35 -0000 Every doc on next week's IESG telechat agenda has already been reviewed. Good job. Four new last call assignments are included below. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Kathleen Moriarty is next in the rotation. Last calls and special requests: Reviewer LC end Draft Richard Barnes 2010-10-21 draft-ietf-xmpp-3920bis-17 Richard Barnes 2010-10-21 draft-ietf-xmpp-3921bis-15 Richard Barnes 2010-10-21 draft-ietf-xmpp-address-05 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Jeffrey Hutzelman 2010-10-13 draft-ietf-mpls-ldp-upstream-08 Charlie Kaufman 2010-10-12 draft-ietf-storm-ifcpmib-05 Scott Kelly 2010-10-21 draft-ietf-avt-rtp-h264-rcdo-07 Stephen Kent 2010-10-21 draft-ietf-sipcore-reinvite-06 Julien Laganier 2010-10-22 draft-ietf-avt-rtp-svc-23 Barry Leiba 2010-10-25 draft-ietf-dime-rfc3588bis-25 Chris Lonvick 2010-10-25 draft-ietf-geopriv-rfc3825bis-12 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-11-15 draft-igoe-secsh-x509v3-06 Catherine Meadows 2010-11-09 draft-turner-md2-to-historic-05 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-3920bis-17 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-3921bis-15 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-address-05 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-03 Glen Zorn 2010-09-16 draft-ietf-l3vpn-mvpn-spmsi-joins-01 From catherine.meadows@nrl.navy.mil Sat Oct 16 11:35:28 2010 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 4B7C43A6AC1; Sat, 16 Oct 2010 11:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 J9kj7nS9FqB6; Sat, 16 Oct 2010 11:35:26 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id E52333A6A28; Sat, 16 Oct 2010 11:35:21 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id o9GIad1l006995; Sat, 16 Oct 2010 14:36:40 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id o9GIaZUp020612; Sat, 16 Oct 2010 14:36:35 -0400 (EDT) Received: (from [IPv6:::1] [10.0.0.13]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010101614363404303 ; Sat, 16 Oct 2010 14:36:34 -0400 From: Catherine Meadows Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 16 Oct 2010 14:36:34 -0400 Message-Id: <864DCF6A-A192-41F6-9A46-04D6AC64DC06@nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: draft-turner-md2-to-historic.all@tools.ietf.org Subject: [secdir] Secdir review of draft-turner-md2-to-historic-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: Sat, 16 Oct 2010 18:35:28 -0000 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 treat=20 these comments just like any other last call comments. This document recommends that the MD2 hash algorithm be moved to = historic status and gives the rationale for doing this. The reasons are mainly security-related, = given that the algorithm has been shown not to be collision-free and is vulnerable to pre-image = attacks. Performance is also an issue. The impact is minimal, given that support for MD2 in the = standards that refer to it is either optional or discouraged. I have no problems with the decision or rationale. I agree, as I am = sure that everyone else does, the MD2 should be retired. =20 I do have one minor recommendation though about the rationale: in = section 2 (the Rationale section), you say that MD2 has been shown to not be collision-free and is = vulnerable to pre-image attacks. The Rationale appears to give both these concerns equal value. But in Section 6 = (Security Considerations), you say that the most successful collision attacks against MD2 are not = significantly better than the birthday attack, and the real security problems with MD2 have to do with its = vulnerability to pre-image attacks. It seems to me that this reasoning should be reflected in the Rationale. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil From alexey.melnikov@isode.com Sun Oct 17 23:51:47 2010 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 32CD23A6CA7; Sun, 17 Oct 2010 23:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.111 X-Spam-Level: X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=-1.731, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 H4a5qDoKHzWU; Sun, 17 Oct 2010 23:51:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 161103A6C86; Sun, 17 Oct 2010 23:51:46 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.33]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 18 Oct 2010 07:53:11 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CBA95C6.9060305@isode.com> Date: Sun, 17 Oct 2010 07:20:54 +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: Phillip Hallam-Baker References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kurt.Zeilenga@Isode.COM, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR Review of draft-zeilenga-ldap-dontusecopy-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, 18 Oct 2010 06:51:47 -0000 Phillip Hallam-Baker 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 describes what is essentially a 'send original, not > cached flag' for LDAP. > > Only security issue I can see here is that the following does not give > the purpose very clearly. > >4. Security Considerations > > This control is intended to be provided where providing service using > copied information might lead to unexpected application behavior. > Designers of directory applications should consider where it is > appropriate for clients to provide this control. Designers should > consider whether use of copied information, in particular security and > policy information, may result insecure behavior. > > > I would suggest the following instead > >4. Security Considerations > > This control is intended to be provided where providing service using > copied information might lead to unexpected application behavior. > > Use of the Don't Use Copy control may permit an attacker to perform > or amplify a Denial of Service attack by causing additional server > resources to be employed. > > LDAP is frequently used for storage and distribution of security > sensitive information, including access control and security policy > information. Failure to use the Don't Use Copy control may thus > permit an attacker to gain unauthorized access by allowing reliance > on stale data. > > The meaning is unchanged, but the additional context might help the > reader. I like your text better, as it is much more explicit about threats. From turners@ieca.com Mon Oct 18 12:01:46 2010 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 09EBF3A6E33 for ; Mon, 18 Oct 2010 12:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 xPF8GY1tTtpz for ; Mon, 18 Oct 2010 12:01:45 -0700 (PDT) Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id ADE4C3A6BBC for ; Mon, 18 Oct 2010 12:01:31 -0700 (PDT) Received: (qmail 57821 invoked from network); 18 Oct 2010 19:02:58 -0000 Received: from thunderfish.local (turners@96.231.118.186 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 18 Oct 2010 12:02:57 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: qDP4mGsVM1kGJuYDVYgVAqOZw_5rb0zFQmFBBVHc1llKLlr c1w0vb76lpAAg7c6ZTwxnqJJD1pFfvUQIko0fbTJMbeMAHpF2df3LjsQb.GD vkF8g8D0WbSI1ysD_fs0XiaMhVyvlG0ogIsA6KePvmOlYQtQcxmKiF8q7u3z ir6XG2J6CBGspaIdbVe9iuR7Hl7oMcKzKktbK0yzSiaPyXQJA3HNfv1ICP0P WPoAFmC.K1qUJ2BIo44RxOpTSzYs6zyTV70lEx1LBu6ECFuyRFA.1PuuO17q tbIGyiWdmImKJftvCDZ4d8.oZBTRI7ShIrgV6giVJs7so4RuO.87b2Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CBC99E0.2080204@ieca.com> Date: Mon, 18 Oct 2010 15:02:56 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Catherine Meadows References: <864DCF6A-A192-41F6-9A46-04D6AC64DC06@nrl.navy.mil> In-Reply-To: <864DCF6A-A192-41F6-9A46-04D6AC64DC06@nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-turner-md2-to-historic.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-turner-md2-to-historic-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, 18 Oct 2010 19:01:46 -0000 Catherine, Thanks for your review. How about I make the following two changes: 1) In Section 1, add something to provide a better characterization of the collision-resistance: OLD: Since its publication, MD2 has been shown to not be collision-free [ROCH1995][KNMA2005][ROCH1997] and shown to have successful pre-image attacks [KNMA2005][MULL2004][KMM2010]. NEW: Since its publication, MD2 has been shown to not be collision-free [ROCH1995][KNMA2005][ROCH1997], albeit successful pre-image attacks for properly implement MD2 are not that damaging. MD2 has also been shown to have successful pre-image and second-preimage attacks [KNMA2005[MULL2004][KMM2010]. 2) In section 6, align the last sentence of the second paragraph and the 1st sentence of paragraph 3: OLD: .., which is not significantly better than the birthday attack. Even though collision attacks on MD2 are not more powerful than the birthday attack, MD2 was found not to be one-way... NEW: .., which is not significantly better than the birthday attack. Even though collision attacks on MD2 are not significantly more powerful than the birthday attack, MD2 was found not to be one-way... spt On 10/16/10 2:36 PM, Catherine Meadows 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 recommends that the MD2 hash algorithm be moved to historic status and gives > the rationale for doing this. The reasons are mainly security-related, given that the algorithm > has been shown not to be collision-free and is vulnerable to pre-image attacks. Performance is also an > issue. The impact is minimal, given that support for MD2 in the standards that refer to it is either optional or > discouraged. > > I have no problems with the decision or rationale. I agree, as I am sure that everyone else does, the MD2 > should be retired. > > I do have one minor recommendation though about the rationale: in section 2 (the Rationale section), > you say that MD2 has been shown to not be collision-free and is vulnerable to pre-image attacks. The Rationale > appears to give both these concerns equal value. But in Section 6 (Security Considerations), you say > that the most successful collision attacks against MD2 are not significantly better than the birthday attack, > and the real security problems with MD2 have to do with its vulnerability to pre-image attacks. It seems to me that > this reasoning should be reflected in the Rationale. > > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From catherine.meadows@nrl.navy.mil Mon Oct 18 12:09:45 2010 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 CE2CF3A6D0B; Mon, 18 Oct 2010 12:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.836, 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 h6E3s65oUls0; Mon, 18 Oct 2010 12:09:44 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 4C78C3A6B8F; Mon, 18 Oct 2010 12:09:43 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id o9IJBCrb006829; Mon, 18 Oct 2010 15:11:12 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id o9IJB5iB010158; Mon, 18 Oct 2010 15:11:10 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010101815110906141 ; Mon, 18 Oct 2010 15:11:09 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-5--115476741 From: Catherine Meadows In-Reply-To: <4CBC99E0.2080204@ieca.com> Date: Mon, 18 Oct 2010 15:16:08 -0400 Message-Id: <9D18C25E-888A-4807-A983-D0BC208224EB@nrl.navy.mil> References: <864DCF6A-A192-41F6-9A46-04D6AC64DC06@nrl.navy.mil> <4CBC99E0.2080204@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1081) Cc: draft-turner-md2-to-historic.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-turner-md2-to-historic-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, 18 Oct 2010 19:09:46 -0000 --Apple-Mail-5--115476741 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sean, Yes, this looks much better, although I think that for Since its publication, MD2 has been shown to not be collision-free [ROCH1995][KNMA2005][ROCH1997], albeit successful pre-image attacks for properly implement MD2 are not that damaging.=20 what you really meant to say was Since its publication, MD2 has been shown to not be collision-free [ROCH1995][KNMA2005][ROCH1997], albeit successful collision attacks for properly implemented MD2 are not that damaging.=20 Is that correct? Cathy On Oct 18, 2010, at 3:02 PM, Sean Turner wrote: > Catherine, >=20 > Thanks for your review. >=20 > How about I make the following two changes: >=20 > 1) In Section 1, add something to provide a better characterization of = the collision-resistance: >=20 > OLD: >=20 > Since its publication, MD2 has been shown to not be collision-free > [ROCH1995][KNMA2005][ROCH1997] and shown to have successful > pre-image attacks [KNMA2005][MULL2004][KMM2010]. >=20 > NEW: >=20 > Since its publication, MD2 has been shown to not be collision-free > [ROCH1995][KNMA2005][ROCH1997], albeit successful pre-image attacks > for properly implement MD2 are not that damaging. MD2 has also been > shown to have successful pre-image and second-preimage attacks > [KNMA2005[MULL2004][KMM2010]. >=20 > 2) In section 6, align the last sentence of the second paragraph and = the 1st sentence of paragraph 3: >=20 > OLD: >=20 > .., which is not significantly better than the birthday attack. >=20 > Even though collision attacks on MD2 are not more powerful than > the birthday attack, MD2 was found not to be one-way... >=20 > NEW: >=20 > .., which is not significantly better than the birthday attack. >=20 > Even though collision attacks on MD2 are not significantly more > powerful than the birthday attack, MD2 was found not to be > one-way... >=20 > spt >=20 > On 10/16/10 2:36 PM, Catherine Meadows 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. >>=20 >>=20 >> This document recommends that the MD2 hash algorithm be moved to = historic status and gives >> the rationale for doing this. The reasons are mainly = security-related, given that the algorithm >> has been shown not to be collision-free and is vulnerable to = pre-image attacks. Performance is also an >> issue. The impact is minimal, given that support for MD2 in the = standards that refer to it is either optional or >> discouraged. >>=20 >> I have no problems with the decision or rationale. I agree, as I am = sure that everyone else does, the MD2 >> should be retired. >>=20 >> I do have one minor recommendation though about the rationale: in = section 2 (the Rationale section), >> you say that MD2 has been shown to not be collision-free and is = vulnerable to pre-image attacks. The Rationale >> appears to give both these concerns equal value. But in Section 6 = (Security Considerations), you say >> that the most successful collision attacks against MD2 are not = significantly better than the birthday attack, >> and the real security problems with MD2 have to do with its = vulnerability to pre-image attacks. It seems to me that >> this reasoning should be reflected in the Rationale. >>=20 >>=20 >> Catherine Meadows >> Naval Research Laboratory >> Code 5543 >> 4555 Overlook Ave., S.W. >> Washington DC, 20375 >> phone: 202-767-3490 >> fax: 202-404-7942 >> email: catherine.meadows@nrl.navy.mil >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >>=20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-5--115476741 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Catherine,

Thanks for your review.

How = about I make the following two changes:

1) In Section 1, add = something to provide a better characterization of the = collision-resistance:

OLD:

Since its publication, MD2 has = been shown to not be collision-free
[ROCH1995][KNMA2005][ROCH1997] = and shown to have successful
pre-image attacks = [KNMA2005][MULL2004][KMM2010].

NEW:

Since its = publication, MD2 has been shown to not be collision-free
= [ROCH1995][KNMA2005][ROCH1997], albeit successful pre-image attacks
= for properly implement MD2 are not that damaging. MD2 has also been
= shown to have successful pre-image and second-preimage attacks
= [KNMA2005[MULL2004][KMM2010].

2) In section 6, align the last = sentence of the second paragraph and the 1st sentence of paragraph = 3:

OLD:

.., which is not significantly better than the = birthday attack.

Even though collision attacks on MD2 are not = more powerful than
the  birthday attack, MD2 was found not to = be one-way...

NEW:

.., which is not significantly better = than the birthday attack.

Even though collision attacks on MD2 = are not significantly more
powerful than the birthday attack, MD2 = was found not to be
one-way...

spt

On 10/16/10 2:36 = PM, Catherine Meadows 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 = recommends that the MD2 hash algorithm be moved to historic status and = gives
the rationale for doing = this.  The reasons are mainly security-related, given that the = algorithm
has been shown not = to be collision-free and is vulnerable to pre-image attacks. =  Performance is also an
issue.  The impact is minimal, given that support for = MD2 in the standards that refer to it is either optional = or
discouraged.

I have no = problems with the decision or rationale.  I agree, as I am sure = that everyone else does, the MD2
should be retired.

I do have one = minor recommendation though about the rationale: in section 2 (the = Rationale section),
you say = that MD2 has been shown to not be collision-free and is vulnerable to = pre-image attacks.  The Rationale
appears to give both these concerns equal value. But in = Section 6 (Security Considerations), you say
that the most successful collision attacks against MD2 are = not significantly better than the birthday = attack,
and the real security = problems with MD2 have to do with its vulnerability to pre-image = attacks.  It seems to me that
this reasoning should be reflected in the = Rationale.


Catherine = Meadows
Naval Research = Laboratory
Code = 5543
4555 Overlook Ave., = S.W.
Washington DC, = 20375
phone: = 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

_______________________________________________
secdir mailing = list
secdir@ietf.org
https://www.ietf.org= /mailman/listinfo/secdir


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail-5--115476741-- From turners@ieca.com Mon Oct 18 12:25:26 2010 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 D33A23A6E57 for ; Mon, 18 Oct 2010 12:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 v6MFYgP93eiw for ; Mon, 18 Oct 2010 12:25:26 -0700 (PDT) Received: from smtp113.biz.mail.mud.yahoo.com (smtp113.biz.mail.mud.yahoo.com [209.191.68.78]) by core3.amsl.com (Postfix) with SMTP id 9ABAF3A6E51 for ; Mon, 18 Oct 2010 12:25:26 -0700 (PDT) Received: (qmail 88913 invoked from network); 18 Oct 2010 19:26:47 -0000 Received: from thunderfish.local (turners@96.231.118.186 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 18 Oct 2010 12:26:46 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: GIO9YDQVM1m6Bu2Solm9p2T.7D9JJBXuuVSlPgqIyAqU.US LFkW1g76yUvk__ujLcJ0VMe6ZOqcxPiDJpnGKv0TycbjhbvTsQM.CqIx6.Cj EVCdcZSTRH1RHa_J4J_Q7iey_zenm28irokN9rh1ZXiFL7QjZcCaRcjLASfX 94K3Q.wEVQD_MqbElf6kbFbA48CUNEvpd7psdiUGRCLx.8mGCm.jbKebD_AD eeuNrgCOzZXpRanbXsNpXBNJ_5wlZSCCoXeBb2tdmzUPVkl0Nrzurz7rK7OT fqECMeUboYMzznE811buX7RMaPvJTvdM4WqeTsQ3RgRfJlecvpNj65A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CBC9F75.3030407@ieca.com> Date: Mon, 18 Oct 2010 15:26:45 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Catherine Meadows References: <864DCF6A-A192-41F6-9A46-04D6AC64DC06@nrl.navy.mil> <4CBC99E0.2080204@ieca.com> <9D18C25E-888A-4807-A983-D0BC208224EB@nrl.navy.mil> In-Reply-To: <9D18C25E-888A-4807-A983-D0BC208224EB@nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, draft-turner-md2-to-historic.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-turner-md2-to-historic-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, 18 Oct 2010 19:25:26 -0000 drat - yes the albeit phrase should be about the collision attacks not the pre-image attacks. spt On 10/18/10 3:16 PM, Catherine Meadows wrote: > Sean, > > Yes, this looks much better, although I think that for > > Since its publication, MD2 has been shown to not be collision-free > [ROCH1995][KNMA2005][ROCH1997], albeit successful pre-image attacks > for properly implement MD2 are not that damaging. > > what you really meant to say was > > Since its publication, MD2 has been shown to not be collision-free > [ROCH1995][KNMA2005][ROCH1997], albeit successful collision attacks > for properly implemented MD2 are not that damaging. > > Is that correct? > > Cathy > > On Oct 18, 2010, at 3:02 PM, Sean Turner wrote: > >> Catherine, >> >> Thanks for your review. >> >> How about I make the following two changes: >> >> 1) In Section 1, add something to provide a better characterization >> of the collision-resistance: >> >> OLD: >> >> Since its publication, MD2 has been shown to not be collision-free >> [ROCH1995][KNMA2005][ROCH1997] and shown to have successful >> pre-image attacks [KNMA2005][MULL2004][KMM2010]. >> >> NEW: >> >> Since its publication, MD2 has been shown to not be collision-free >> [ROCH1995][KNMA2005][ROCH1997], albeit successful pre-image attacks >> for properly implement MD2 are not that damaging. MD2 has also been >> shown to have successful pre-image and second-preimage attacks >> [KNMA2005[MULL2004][KMM2010]. >> >> 2) In section 6, align the last sentence of the second paragraph and >> the 1st sentence of paragraph 3: >> >> OLD: >> >> .., which is not significantly better than the birthday attack. >> >> Even though collision attacks on MD2 are not more powerful than >> the birthday attack, MD2 was found not to be one-way... >> >> NEW: >> >> .., which is not significantly better than the birthday attack. >> >> Even though collision attacks on MD2 are not significantly more >> powerful than the birthday attack, MD2 was found not to be >> one-way... >> >> spt >> >> On 10/16/10 2:36 PM, Catherine Meadows 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 recommends that the MD2 hash algorithm be moved to >>> historic status and gives >>> the rationale for doing this. The reasons are mainly >>> security-related, given that the algorithm >>> has been shown not to be collision-free and is vulnerable to >>> pre-image attacks. Performance is also an >>> issue. The impact is minimal, given that support for MD2 in the >>> standards that refer to it is either optional or >>> discouraged. >>> >>> I have no problems with the decision or rationale. I agree, as I am >>> sure that everyone else does, the MD2 >>> should be retired. >>> >>> I do have one minor recommendation though about the rationale: in >>> section 2 (the Rationale section), >>> you say that MD2 has been shown to not be collision-free and is >>> vulnerable to pre-image attacks. The Rationale >>> appears to give both these concerns equal value. But in Section 6 >>> (Security Considerations), you say >>> that the most successful collision attacks against MD2 are not >>> significantly better than the birthday attack, >>> and the real security problems with MD2 have to do with its >>> vulnerability to pre-image attacks. It seems to me that >>> this reasoning should be reflected in the Rationale. >>> >>> >>> Catherine Meadows >>> Naval Research Laboratory >>> Code 5543 >>> 4555 Overlook Ave., S.W. >>> Washington DC, 20375 >>> phone: 202-767-3490 >>> fax: 202-404-7942 >>> email: catherine.meadows@nrl.navy.mil >>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > From ben@estacado.net Tue Oct 19 16:04:47 2010 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 64A473A685B; Tue, 19 Oct 2010 16:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, J_CHICKENPOX_14=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 OkTOabbAMMdq; Tue, 19 Oct 2010 16:04:45 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 9D3723A6804; Tue, 19 Oct 2010 16:04:43 -0700 (PDT) Received: from [10.0.1.19] (adsl-68-94-28-42.dsl.rcsntx.swbell.net [68.94.28.42]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o9JN5MfW019940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Oct 2010 18:05:29 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: <4CB827E8.9040400@gmail.com> Date: Tue, 19 Oct 2010 18:05:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2358A806-E09D-43D6-A5CF-6A7AB3FA6AE6@estacado.net> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> <4CAAD4B0.2080807@gmail.com> <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com> <4CB827E8.9040400@gmail.com> To: Simple WG X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Wed, 20 Oct 2010 07:45:06 -0700 Cc: Cullen Jennings , Ted Hardie , The IETF , secdir@ietf.org, Gonzalo Camarillo , draft-ietf-simple-msrp-sessmatch@tools.ietf.org, IESG IESG Subject: Re: [secdir] [Simple] secdir review of draft-ietf-simple-msrp-sessmatch 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, 19 Oct 2010 23:04:47 -0000 [As SIMPLE co-chair] draft-ietf-simple-msrp-sessmatch has some significant additions from the = version for which we originally requested publication. I implore = everyone who cares one way or another about this draft to re-review it = as soon as they are able. Thanks! Ben. On Oct 15, 2010, at 5:07 AM, Gonzalo Camarillo wrote: > Hi, >=20 > I am going to send this draft back to the SIMPLE WG so that they = discuss > these issues. Once the WG reaches (rough) consensus on what to do, I > will be issuing a second IETF LC so that everybody is on the same = page. >=20 > Cheers, >=20 > Gonzalo >=20 > On 14/10/2010 11:27 PM, Cullen Jennings wrote: >>=20 >> The new draft is clearer but I still don't think it addresses my = concerns. I would say at this point they could be summarized as >>=20 >> 1) The draft is very hard to review without doing the diffs to 4975. = To try and help instead of just complain, I'm willing to go back patch = these changes into the last XML for 4975 and provide a draft that we can = actually read to see what this all means. I can't do that till after the = -01 deadline. >>=20 >> 2) As far as I can tell, this does change the security of 4975 in a = pretty significant way in that this allows a MITM to masquerade with the = wrong to and from path that may be in the cert. It is not clear how it = work when the end points are not using self signed certs and changes the = preferred deployment mode from using certs rooted in a trust anchor to = self signed. All this seems to significantly weaken the security of 4975 = which concerns me and I have not seen relevant discussion of all this. I = am open to the idea that it does not making this much worse than they = currently are in 4975 and that it is a reasonable trade off but I'd like = to see concrete discussion of the issues and tradeoffs. How bad is it? = how much worse is it? People says it is no worse but I and several = others remain unconvinced that it is the same as 4975. I'd rather see a = very explicitly discussion with people like the security reviewer about = how much this changes things and if it is acceptable. It's n > ot easy to sort this all out - it actually might be acceptable - I'm = just not convinced yet and the "there is no problem because there is not = change" form of argument is not convincing me - clearly there is a a = change and at causal glance the point of that change seems to be to = insert a MITM. >>=20 >> 3) The backwards comparability issue seems huge. Some people have = said an endpoint using this draft will not talk with one that only does = 4975. Yet if this draft if published as an RFC would basically = depreciate the 4975 and replace it with a the result of applying this = diff to 4795. So if one person implements the pre update version, and = another person the post - it's not clear to me how we migrate from old = to new on the existing deployments. A flag day is obviously not going to = work. The more I look at this, the more I think this draft needs to be = recast as a backwards compatible extension to 4975 and not a draft that = update 4975. When I look at how this changes 4975 it seems to mostly = relax the existing security but not disallow things that used to work so = I think it should be possible to do this. On a side note, I phoned a few = people who I know that have MSRP implementation and none of them had any = plans to implement this and were surprised to hear there was a draft t > hat would update in 4975 with a change like this. To me this combined = with the no backwards compatibility issue argues strongly for figuring = out how to make this an extension instead of a change to MSRP. >>=20 >> 4) When I search the email lists, I find more more people who see = significant problems with this than I find people that seem to think it = is OK. I don't think it has consensus -I think it just has people who = stopped care. The changes that needed to happen in IETF LC to fix this = draft so it had any chance of working at all more or less convinced me = the WG did not read this draft. The ietf@ietf.org list is not an ideal = location for discussion that rewrites pretty much all of the normative = text of this draft (which is what is happening here). >>=20 >> Cullen >>=20 >>=20 >>=20 >> On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote: >>=20 >>> Hi, >>>=20 >>> Christer has submitted a new revision of this draft: >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ >>>=20 >>> Those of you who sent IETF LC comments on this draft, could you = please >>> have a look at the new version and let Christer know if he has = addressed >>> your concerns? >>>=20 >>> Thanks, >>>=20 >>> Gonzalo >>>=20 >>>=20 >>> On 31/08/2010 8:39 PM, Christer Holmberg wrote: >>>> Hi, >>>>=20 >>>> The purpose of this e-mail is to address the secdir comments given = by Richard >>>> Barnes and Ted Hardie. Due to summer vacations, standardization = meetings >>>> etc it took a while to put the e-mail together, and we appologise = for that. >>>>=20 >>>> GENERAL >>>> =3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> First, the draft does NOT propose any changes to the TLS = authentication >>>> procedures =96 that will be clarified. The changes are only related = to the >>>> procedure for matching an incoming MSRP message to an MSRP session = that >>>> has been negotiated using SDP =96 once any TLS authentication = procedure has >>>> already taken place. >>>>=20 >>>> So, in case of TLS and name based authentication, if an SBC/ALG = modifies >>>> the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is = the current >>>> behavior, and sessmatch doesn=92t change that. >>>>=20 >>>> We understand that this fact needs to be clearly indicated in the = draft. >>>>=20 >>>> Basically sessmatch allows so that, when using peer to peer MSRP, = SIP SBCs >>>> and SIP aware firewalls can be in the SIP signaling path without = acting as >>>> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with = MSRP relays >>>> the SBC/ALG needs to act as MSRP B2BUA, as today. >>>>=20 >>>> Sessmatch aims to extend the usability of MSRP peer to peer = communication to >>>> scenarios where simple ALGs/SBCs are used, and at least in our = experience >>>> customer interest for standard MSRP has grown (from more or less = zero) >>>> dramatically due to sessmatch. And, OMA, which previously used a = *non-standard* >>>> version of MSRP (with no interoperability with standard MSRP), has = also agreed >>>> to switch to sessmatch (even if it required a number of changes in = their >>>> specifications). >>>>=20 >>>> Second, the intention of sessmatch is not to modify the MSRP URI = matching rules, >>>> but rather to not use MSRP URI matching for session matching. >>>>=20 >>>> Please also note that when we talk about SBCs/ALGs, we refer to = entities that >>>> normally do NOT have the capability to act as MSRP B2BUAs. >>>>=20 >>>> We will comment the individual comments based on the assumptions = above. >>>>=20 >>>>=20 >>>> Comments from Richard >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>>> 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. >>>>>=20 >>>>> This document changes the URI matching algorithm used in MSRP. = MSRP sessions >>>>> are typically initiated using SDP bodies in SIP. These SDP >>>>> bodies contain MSRP URIs that the peers use to contact each other. >>>>> When one peer receives a request to initiate a session, he = verifies that the >>>>> URI being requested is one that he initiated in SDP, thereby using = the URI as a >>>>> shared secret to authenticate that the originator of the session = actually >>>>> received the SDP body in question. >>>>>=20 >>>>> According to the current SDP specification, this comparison is = performed over >>>>> the whole URI; this document restricts the comparison to the = "session-id" >>>>> component, omitting the host, port, and transport components. The = goal of the >>>>> document is to facilitate a certain class of man-in-the-middle = attack, namely >>>>> to allow a signaling intermediary to insert a media intermediary. = The >>>>> restriction on the URI comparison is needed in order for the media = intermediary >>>>> not to have to modify URIs in MSRP packets to reflect the = modifications to URIs >>>>> in SDP bodies performed to redirect traffic through the media = intermediary. >>>>=20 >>>> When an MSRP UA receives an MSRP packet it performs msrp session = matching in order >>>> to verify that the msrp packet belongs to an existing SDP = negotiated msrp session >>>> at the UA. RFC4975 prescribes that URI matching should be used for = session matching. >>>> We argue that the namespace scoping of the session-id values that = use of URI matching >>>> brings is unnecessary. The 80-bit randomness of the session-id and = the fact that it >>>> was the UA itself that decided on the session-id value and can = ensure that it is >>>> unique within the UA makes the session-id sufficiently unique for = session matching. >>>> Sessmatch is not changing the MSRP URI matching algorithm, it is = changing the session >>>> matching algorithm not to use MSRP URI matching. >>>>=20 >>>>> I have a few significant reservations about this document: >>>>>=20 >>>>> 1) This extension makes it more difficult for MSRP entities to = secure their >>>>> communications against attackers in the signaling path. The = current model >>>>> provides a basic integrity protection, in that signaling = intermediaries cannot >>>>> redirect traffic to an arbitrary third party; they must at least = advise the >>>>> third party about how to modify MSRP packets. The proposed = modification would >>>>> remove even this cost. >>>>=20 >>>> If we do not introduce the sessmatch change then the only = alternative for MSRP >>>> connections to be able to be set up when SBCs or SIP aware = firewalls are in the >>>> SIP signaling path is for these to introduce MSRP B2BUA support. = This is probably >>>> not feasible for most SBCs and SIP aware firewalls, and if it = actually were >>>> feasible then it would mean as big a security problem, or even = bigger, than >>>> sessmatch. The choice is thus to not use MSRP at all in presence of = such devices >>>> or to introduce sessmatch. Not to fix this probably would mean that = use of MSRP >>>> will be marginalized. >>>>=20 >>>>> 2) Moreover, it raises the cost of providing integrity protection = to messages, >>>>> since Alice must now employ both integrity and confidentiality = protections on >>>>> an end-to-end basis; if her messages are only integrity-protected, = then a proxy >>>>> can remove the integrity protection and redirect traffic without = it being >>>>> observable to Alice. >>>>>=20 >>>>> The document needs to clarify what the impacts are for = authentication in secure >>>>> modes of MSRP. In particular: >>>>> -- The distinction between "self-signed" and "public" certificates = is >>>>> inappropriate. The proper distinction is between the name-based = authentication >>>>> in Section 14.2 of RFC 4975 and the fingerprint-based = authentication in Section >>>>> 14.4. >>>>=20 >>>> We cannot find the terminology =93name-based=94 authentication in = RFC 4975. The RFC talks >>>> about TLS authentication using either certificates from well-known = certificate >>>> authorities, or using self-signed certificates together with = certificate fingerprints. >>>>=20 >>>> Having said that, however, we DO agree that the terminology you = suggest is more >>>> appropriate than what we have used and we will introduce this = terminology and explain >>>> it in the Convention section of the sessmatch draft. >>>>=20 >>>>> -- In either case, changing the host name need not result in an = authentication >>>>> failure, since the media intermediary can simply authenticate as = itself to both >>>>> endpoints, having changed the respective MSRP URIs appropriately. >>>>=20 >>>> A media intermediary can only do this if it is an MSRP B2BUA, and = sessmatch was >>>> introduced just to avoid most SBCs and ALGs having to implement an = MSRP B2BUA in order >>>> to allow standard MSRP deployment. >>>>=20 >>>>> -- There is currently no requirement that an endpoint identity in = the To-Path >>>>> URI matches the endpoint identity authenticated at the TLS layer, = because these >>>>> two are required to be the same. This document changes that = assumption, and >>>>> should note that these two identities can differ. >>>>=20 >>>> We will explicitly mention this. >>>>=20 >>>>> The document also precludes any name-based multiplexing, where a = single MSRP >>>>> process (single IP address and port) directs requests to different = virtual >>>>> recipients based on the domain name in the To-Path header. (In = analogy to >>>>> Host-based multiplexing in HTTP, which is very widely deployed.) = Since with >>>>> this extension, the domain in the To- Path is completely = unpredictable from the >>>>> recipient's perspective, it is useless to the recipient. >>>>=20 >>>> That is correct, but there should be no problem for a single MSRP = process (single >>>> IP address and port) to direct requests to different virtual = recipients - based >>>> on the session-id instead. It is only needed for the different = virtual recipients >>>> to inform the receiver process on which session-ids that are = currently negotiated >>>> instead of informing it on which domain name the virtual recipient = shall be >>>> associated with. >>>>=20 >>>>> The document has no backward-compatibility. MSRP implementations = that do not >>>>> support this extension will not be able to receive MSRP sessions = from >>>>> implementations that do. In that regard, this document seems more = like a new >>>>> version of MSRP rather than an update. >>>>=20 >>>> It is not true that there is no backwards compatibility. If there = are no >>>> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no = problem for MSRP >>>> implementations that do not support the sessmatch extension to = receive MSRP >>>> sessions from implementations that do. >>>>=20 >>>> MSRP implementations that do not support the sessmatch extension = are however not >>>> able to establish MSRP end to end conversations if there are = ALGs/SBCs in the >>>> session path (unless these implement MSRP B2BUA) and sessmatch does = not change this >>>> fact =96 it will not work disregarding if the other endpoint = supports sessmatch or not. >>>>=20 >>>>>>> I also note that the security considerations, in addition to = having >>>>>>> some fairly disingenuous language about the impact of this = change, >>>>>>> seems to fail to mention MSRPS URIs and what, if any, impact = this >>>>>>> would have on them. >>>>>>=20 >>>>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly >>>>>> understood since MSRPS URIs are not mentioned in the draft. >>>>>>=20 >>>>>> However, we could explicitly make it clear by modifying the first >>>>>> sentences of section 5: >>>>>>=20 >>>>>> "The change of session matching procedure does not impact the >>>>>> format of MSRP URIs, disregarding if the "msrp" scheme or the = "msrps" scheme >>>>>> is used. However, MSRP endpoints can only check that the = session-id part of >>>>>> the MSRP URI..." >>>>>=20 >>>>> The conflict here is that with MRSPS authentication, the name in = the >>>>> certificate is checked against the domain name in the URI, which = was OK when >>>>> the URI in the message was required to be the same. By allowing = the domain >>>>> name in the message to change, this draft removes = man-in-the-middle protection >>>>> from MSRPS. >>>>>=20 >>>>> The document notes that a SIP MitM can already direct the user to = another >>>>> destination. However, if the peers use MSRPS with the current = authentication >>>>> scheme, the MitM will not be able to be a part of the resulting = MSRPS session, >>>>> since he can't authenticate as one of the endpoints. If only the = session ID is >>>>> used in comparisons, the MitM can patch himself in by changing the = domain in >>>>> the MSRPS URI. (Which actually seems to be the intended use case = for this >draft.) >>>>>=20 >>>>> So the current document does introduce a new MitM vulnerability to = MSRPS. >>>>=20 >>>> Sessmatch does not change the fact that name based TLS = authentication for MSRPS >>>> will fail if an SBC or ALG has modified the hostname value in the = MSRP URI in the >>>> SDP a=3Dpath attribute without also acting as MSRP B2BUA. >>>>=20 >>>>=20 >>>> Comments from Ted >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>>> I join Richard in believing that this document makes changes = beyond that which >>>>> could be understood as "updating" the MSRP URI scheme processing. >>>>>=20 >>>>> ... >>>>>=20 >>>>> I also note that the security considerations, in addition to = having some fairly >>>>> disingenuous language about the impact of this change, seems to = fail to mention >>>>> MSRPS URIs and what, if any, impact this would have on them. >>>>=20 >>>> We will clarify what impacts there are. >>>>=20 >>>> ------- >>>>=20 >>>>>>> To highlight one particular aspect, RFC 4975 does not require >>>>>>> session-ids to be present, a fact noted both in the ABNF and in = this >>>>>>> text: >>>>>>>=20 >>>>>>> 4. The session-id part is compared as case sensitive. A URI = without >>>>>>> a session-id part is never equivalent to one that includes one. >>>>>>>=20 >>>>>>> A matching scheme which relies on a URI section which is not >>>>>>> guaranteed to be present has some interesting problems ahead of = it. If >>>>>>> this effectively makes their use mandatory, that requires a = change to >>>>>>> the fundamental ABNF and text. >>>>>>=20 >>>>>> An MSRP URI in an SDP offer or answer for an MSRP session MUST = include a >>>>>> session-id part, so I believe the comment is >>>>>> based on incorrect assumptions. >>>>>=20 >>>>> This is not indicated in the URI matching section >>>>=20 >>>> We will clarify that sessmatch conformant UAs do not use MSRP URI = matching in >>>> order to perform MSRP session matching. >>>>=20 >>>>>> Section 6 of RFC 4975 says: >>>>>>=20 >>>>>> "The session-id part identifies a particular session of the >>>>>> participant. The absence of the session-id >>>>>> part indicates a reference to an MSRP host device, but does not = refer to a >>>>>> particular session at that device." >>>>>>=20 >>>>>=20 >>>>> The full section from which that quote is taken is: >>>>>=20 >>>>> The MSRP URI authority field identifies a participant in a = particular >>>>> MSRP session. If the authority field contains a numeric IP = address, >>>>> it MUST also contain a port. The session-id part identifies a >>>>> particular session of the participant. The absence of the = session-id >>>>> part indicates a reference to an MSRP host device, but does not = refer >>>>> to a particular session at that device. A particular value of >>>>> session-id is only meaningful in the context of the associated >>>>> authority; thus, the authority component can be thought of as >>>>> identifying the "authority" governing a namespace for the = session-id. >>>>>=20 >>>>> This proposal changes the concept of a namespace authority present = in the URI >>>>> matching section of RFC 4975. I am sorry if my wry reference to = this in my >>>>> previous message was hard to follow; I should have known better. >>>>>=20 >>>>> To be more plain, this proposal fundamentally changes the matching = semantics of >>>>> the URI set out in RFC 4975, by requiring a match on only a = portion of the URI. >>>>> At a bare minimum, this would require noting a normative update to = section 6 >>>>> and 6.1 of RFC 4975, which this draft does not do. In reality, = this is >>>>> unlikely to be sufficient, as URI matching semantics do not = generally have the >>>>> concept of ignoring the authority in providing a match (at least = in my reading >>>>> of the RFC 3986 "ladder of comparison" text). That means you'd = have to special >>>>> case the MSRP matching semantics, rather than have the URI be = parsed and >>>>> compared using a standard library. >>>>=20 >>>> Sessmatch removes the URI matching as a means to do MSRP session = matching, and >>>> replaces it with a pure session-id matching. There is no need to = create a new >>>> URI scheme that does not re-use the authority component. We believe = the minimum >>>> 80-bit randomness of the session-id, together with the fact that = the UA itself >>>> generates the session-id it matches on, to be enough for the = session-id to be >>>> unique in the scope of the sessions that are active at the UA. >>>>=20 >>>> Also, the security of the matching is not particularly decreased, = since it is >>>> relatively easy to find out the authority name anyway. >>>>=20 >>>>>>> I also note that the security considerations, in addition to = having >>>>>>> some fairly disingenuous language about the impact of this = change, >>>>>>> seems to fail to mention MSRPS URIs and what, if any, impact = this >>>>>>> would have on them. >>>>>>=20 >>>>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly understood >>>>>> since MSRPS URIs are not mentioned in the draft. >>>>>>=20 >>>>>> However, we could explicitly make it clear by modifying the first = sentences of >>>>>> section 5: >>>>>>=20 >>>>>> "The change of session matching procedure does not impact the = format of MSRP >>>>>> URIs, disregarding if the "msrp" scheme or the "msrps" scheme is = used. >>>>>> However, MSRP endpoints can only check that the session-id part = of the MSRP >>>>>> URI..." >>>>>>=20 >>>>> This doesn't seem to me to actually work, based on Richard's = comments, unless >>>>> what you mean to say is "if MSRPS is in use, nothing in this draft = can be >>>>> used". That gives you different matching semantics for MSRPS = (authority must >>>>> be present and must be matched using TLS semantics) vs MSRP (only = session-id is >>>>> checked) which is at the very least a violation of the principle = of least >>>>> surprise (no other foo over TLS protocol works that way that I = know of ). >>>>=20 >>>> Session matching is done when receiving MSRP packets on an already = established TCP >>>> or TCP/TLS connection, and there will not be any different session = matching procedure >>>> depending on if the connection uses TLS or plain TCP. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>=20 >>=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From abegen@cisco.com Tue Oct 19 08:17:16 2010 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 029B03A688D; Tue, 19 Oct 2010 08:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 Hi55WqM5vEyl; Tue, 19 Oct 2010 08:17:13 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DF2383A6870; Tue, 19 Oct 2010 08:17:12 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP5TvUyrR7Hu/2dsb2JhbAChZ3GjL5xfhUoEhFWJAA X-IronPort-AV: E=Sophos;i="4.57,350,1283731200"; d="scan'208";a="203142312" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 19 Oct 2010 15:18:41 +0000 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.14.3) with ESMTP id o9JFIfI2019855; Tue, 19 Oct 2010 15:18:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Oct 2010 08:18:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Oct 2010 08:18:40 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D758A5D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4CAA07C8.4030806@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15 Thread-Index: Actj5XZ6siccECGjQDmrr42uZdjsgwLSyiBg References: <4CAA07C8.4030806@cs.tcd.ie> From: "Ali C. Begen (abegen)" To: "Stephen Farrell" , , X-OriginalArrivalTime: 19 Oct 2010 15:18:41.0561 (UTC) FILETIME=[E9A5F890:01CB6FA0] X-Mailman-Approved-At: Wed, 20 Oct 2010 07:45:29 -0700 Cc: avt-chairs@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15 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, 19 Oct 2010 15:17:16 -0000 Sorry for not responding to this email earlier. I thought I did. Thanks = to Robert for reminding me. All,=20 We tried to address all the issues mentioned below in the latest = version. I will respond line by line below. > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, October 04, 2010 12:59 PM > To: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org; = sec-ads@ietf.org > Cc: secdir@ietf.org; avt-chairs@ietf.org > Subject: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15 >=20 >=20 > #include >=20 > This document defines a way for multicast receivers (e.g. IPTV = clients) > to rapidly acquire the reference information required to make sense of > the session data. Reference information is usually only sent > periodically within the session, so this document defines how to setup > a new unicast session with a server that transmits the reference > information to the client on request so as a result the client doesn't > have to wait so long. >=20 > Overall, I'm a bit concerned that this might create new DoS exploit > potential, but I could be wrong (don't know enough about multicast) = and > I see there has been a separate thread on ietf-discuss that had some > mention of that. (I've not read that thread in detail.) If an off-path > attacker could insert RAMS-* messages with values that are likely > to result in things happening then that, I think, would be quite bad, > but I'm not quite sure. Yes, things may go wrong if an attacker sends RAMS control messages on = behalf of others or an attacker modifies others' messages. We ack this = problem and provide some solutions to deal with it. =20 > Detailed security-related issues/questions: >=20 > - How does the client know that it has the right FT/BRS? (Does it > always get that from SDP?) What would happen if it has a bogus FT/BRS? > (Is that likely?) The SDP should be only accepted from reliable sources. So, = authentication and integrity checks are recommended. This applies to any = application using SDP. =20 > - P17 says that the BRS may reject the RAMS-R request. Are there > security reasons that might cause rejection? If so, what? Not really. The rejection reasons are mostly related to the ones already = listed in section 7.3.1. =20 > - P18 says that the BRS can replace the SSRC from the RAMS-R with > something else. Wouldn't that allow a bad BRS to redirect an RTP_Rx to > some dodgy stream, instead of the one requested? Should the RTP_Rx > react to that somehow? We need to have this since the SSRC that is known by the RTP_Rx may have = changed and it has to trust to the server for the most up-to-date SSRC. = Note that here we assume the server side (BRS) is not compromised. If it = is, it does not matter. It can send junk data w/o changing the SSRC. =20 > - How are updated RAMS-R and RAMS-I related to originals? Is there a > way to insert these (maybe from off-path?) If there is, could a fake > RAMS-I mount a DoS on the RTP-Rx? (E.g. by supplying crap = information.) First of all, supporting the updated messages is an optional feature, = which is highly discouraged anyway (due to various other reasons). In = case, an implementation supports it, the security considerations are not = much different. Section 10 makes some proposals to deal with this (e.g., = source address validation, SRTP, policing, etc.). =20 > - Could I send a fake RTCP BYE pretending to be from some RTP_Rx in > order to DoS that client? You can but you need to know the CNAME (which is possible). However, if = RTCP messages are authenticated and source address is validated, you = will fail. =20 > - Could I send a RAMS-R requesting a very high bitrate for a burst as > a way to DoS someone local to the (claimed) source of the RAMS-R? (The > max is 2^64 I guess) Yeah, we added a text for it. The server should pay attention to what = the client mentioned in that field. In any case, that is an upper limit = and the server can transmit at much slower pace if it wants to. =20 > - p31: the Min RAMS buffer fill requirement seems to allow RTP-Rx to > request almost 50 days (2^32ms) of content in the unicast burst. That > seems too much, from the p-o-v of potential DoS exploits. Maybe say > that the BRS SHOULD impose some limit as part of DoS mitigation? Yes, we added text about this as well. The server can naturally reject = the decision anyway if it computes that the client is better off by = joining the mcast immediately (rather than first receiving the burst and = then joining). The client then can join and build up a buffer as long as = it wants to. =20 > - p35: the earliest join time is also a 32 bit millisecond counter. > Should the RTP_Rx also have some kind of sanity check if asked to wait > days? Same comment wrt burst duration. Yes, see the new text in section 10. >=20 > - p42: Saying "adequate" security measures are "RECOMMENDED" to = protect > SDP description, without saying what they might be, is very vague. > What's an implementer supposed to do? This really depends on how SDP is distributed. It could be HTTP(S), RTSP = or something else.=20 =20 > - p43 mentions SRTP as a SHOULD. How widely is that deployed and does > it make sense for this use-case? I think that should be clear. (If = SRTP > isn't really used, or if its not going to be used here, then its not a > real countermeasure.) Well, in managed networks such as IPTV networks, servers and clients are = known by the system admin, configured properly, etc. so one may not need = to implement SRTP. In non-managed environments, SRTP is a good tool and = if they want protection, they better use it.=20 =20 > - p43 says RAMS itself brings no new attacks, but surely it does = create > some new off-path DoS potential, if messages could be guessed? And we tried to explain these *new* attacks in Section 10. =20 > - p43: what does "consider the security of such SRTP key sharing = mean?" > I think this spec should say. We revised that part. See the new text to see whether it works. =20 > Nits/Non-security things: >=20 > - p8: CNAME is used without being defined. Done. =20 > - p15: AVPF is used before being defined/expanded. Done. =20 > - p18: Saying "If the RTP_Rx will issue a ..." seems confusing. Would > that be clear to an implementer? In other words ought the spec say > SHOULD somewhere here? (In which case, it'd also presumably say when > its ok not to follow the SHOULD.) Rephrased this part. =20 > - p19: This says that if the BRS has given a 504 etc. reject, then the > RTP_Rx MUST NOT retry. Does that mean just for this stream or for any > stream? Its not clear to me if the "MUST NOT" is scoped to one = "channel > change" button press, or many, and if many, how that'd ever be reset, > though that might be my ignorance of the use-case and multicast in > general:-) The response codes have their own scopes. A client may not be authorized = for any RAMS operation, or maybe RAMS is not enabled only for that = stream. We explicitly say this now in the text. =20 > - p20 says the BRS "can" use the updated RAMS-R - that's not 2119 > language, so I assume you mean "MAY" and the intent is to allow > implementers to handle updated RAMS-R in whatever way suits best, = given > their internal state when the update arrives? For some reason, we did not wanna use 2119 language here (I don't recall = it now). But, the idea is that it is really up to the server whether to = use the updated request or ignore it. =20 > - p21 says "there is no need" to send RAMS-T for rejected stuff. = Maybe > that'd be better as a MUST NOT or SHOULD NOT? Why do we need to say any 2119 language here. The server is not = expecting a RAMS-T for them, but the client could still send one. =20 > - p21: the mix of SHALL and MUST looks odd, I at least, would prefer > just MUSTs. Fixed. =20 > - p21, typo s/and started/and has started/ Fixed. =20 > - p21, OSN-minus-one as a signal for the BRS to stop - can that OSN > wrap around? Sure it does since it is an RTP seqnum and all rtp seqnum rules apply to = it as well. =20 > - p34: what are "the regular wrapping rules" for MSN and how does > that work with an 8 bit field that is only zero when a new RAMS-R is > received? Wrapping rules are known in general I think since nobody has asked = before what they were :) and MSN is usually 0, but if it keeps = increasing, after it has reached the max value, it will naturally wrap = around (which is very unlikely to happen). =20 > - p38: saying support for rfc5576 "can also be needed" seems vague. > Better to specifically say when its needed. Expanded the text to say when it would be needed. Thanks much for the careful review. -acbegen =20 > Regards, > Stephen. >=20 From kent@bbn.com Wed Oct 20 19:16:17 2010 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 CA2483A68E3 for ; Wed, 20 Oct 2010 19:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, 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 t9CPab3kB1+P for ; Wed, 20 Oct 2010 19:16:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 416DE3A6925 for ; Wed, 20 Oct 2010 19:16:13 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36733 helo=[10.84.131.15]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P8kiv-000JYC-Rj; Wed, 20 Oct 2010 22:17:47 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 20 Oct 2010 22:17:29 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: gao.yang2@zte.com.cn, pkyzivat@cisco.com, Christer.Holmberg@ericsson.com, Gonzalo.Camarillo@ericsson.com, tim.polk@nist.gov, rjsparks@nostrum.com Subject: [secdir] review of draft-ietf-sipcore-reinvite-06.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, 21 Oct 2010 02:16:17 -0000 I 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 (draft-ietf-sipcore-reinvite-06.txt) provides clarification on how to process a re-invite in SIP. The notion of a re-invite is defined in RFC 3261 (SIP). This document was created to clarify the description provided in 3261, based on feedback from implementers. It includes a number of examples designed to clarify. It is fair to say that this document not only offers clarifications, but also makes some changes to SIP handling of re-INVITEs. For example, the document notes that "Section 4.3 specifies new rules for the handling of target-refresh requests." The document makes reference to "properly" authenticated requests in a couple of places (4.4 & 4.6), but provides no indication of what constitutes proper authentication. I think it would be appropriate to include references to whatever SIP security mechanisms are currently recommended for message/session authentication (as opposed to what 3261 said 8 years ago). The document has a trivial Security Considerations section: This document does not introduce any new security issue. It just clarifies how certain transactions should be handled in SIP. Security issues related to re-INVITEs and UPDATE requests are discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311]. I checked 3261 and I agree that this document provides a decent review of security for SIP in general, but it makes no specific mention of UPDATE or (re)INVITE messages and attendant security concerns. RFC 3311 has an almost trivial Security Considerations section, but at least it does specifically refer to UPDATE and (re-)Invite messages, briefly, and the need for authentication. I think it would be appropriate to add a discussion of how these clarifications operate in various SIP security contexts, e.g., use of TLS for point-to-point SIP security or use of S/MIME for end-to-end SIP security. A statement that the security offered for SIP when the initial call setup was processed cannot be undermined by a later re-INVITE or UPDATE would be reassuring (if accompanied by a rationale for that statement :). From julienl@qualcomm.com Fri Oct 22 14:12:29 2010 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 354C63A6965; Fri, 22 Oct 2010 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 jKFBH+DjeKW8; Fri, 22 Oct 2010 14:12:27 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2E7533A696E; Fri, 22 Oct 2010 14:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287782046; x=1319318046; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"secdir@ietf.org"=20,=20"iesg@iet f.org"=20|CC:=20"draft-ietf-avt-rtp-svc.al l@tools.ietf.org"=0D=0A=09|Date:=20Fri,=2022=20Oct=202010=2014:13:58=20 -0700|Subject:=20SECDIR=20Review=20of=20draft-ietf-avt-rt p-svc-23|Thread-Topic:=20SECDIR=20Review=20of=20draft-iet f-avt-rtp-svc-23|Thread-Index:=20ActyLgqaVpvgawTXTK6RBNcE 7V2G0A=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=sBxl/vt5WRkMyhIFbE2t6QwdlMEavL0AMlsrKoqE44w=; b=mUYc5ss1B3OSYKrlqNekY+Ys//Rp55OqbG10PDubECJCQs5OpcVNxet7 vq4Fqz4Jf7ZEcYeHka5ngW3616dYUxLMqKRdBNZA4s1WE26rBIRvaKo8P sEmwzbwa/ryvRXfayRmJdSDlYqHD8dogaJrBhxFn+eIzrkjFk1T/Ymb9g 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6144"; a="58898238" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 22 Oct 2010 14:14:05 -0700 X-IronPort-AV: E=Sophos;i="4.58,224,1286175600"; d="scan'208";a="26168856" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 22 Oct 2010 14:14:05 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 22 Oct 2010 14:14:05 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 22 Oct 2010 14:14:05 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Fri, 22 Oct 2010 14:14:04 -0700 From: "Laganier, Julien" To: "secdir@ietf.org" , "iesg@ietf.org" Date: Fri, 22 Oct 2010 14:13:58 -0700 Thread-Topic: SECDIR Review of draft-ietf-avt-rtp-svc-23 Thread-Index: ActyLgqaVpvgawTXTK6RBNcE7V2G0A== Message-ID: 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 Cc: "draft-ietf-avt-rtp-svc.all@tools.ietf.org" Subject: [secdir] SECDIR Review of draft-ietf-avt-rtp-svc-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: Fri, 22 Oct 2010 21:12:29 -0000 I reviewed this document as part of the security directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comment= s were written primarily for the benefit of the security area directors. D= ocument editors and WG chairs should treat these comments just like any oth= er last call comments. This document describes an RTP payload format for Scalable Video Coding tha= t is applicable to applications such as video streaming. Disclaimer: I am not familiar with RTP applications, and even less with vid= eo coding. However, it appears that the security considerations MAY need mo= re work: > 8. Security Considerations > > Section 9 of [I-D.ietf-avt-rtp-rfc3984bis] applies. Additionally, > the following applies. Suggest rewording: "The security considerations of the RTP Payload Format f= or H.264 Video specification [I-D.ietf-avt-rtp-rfc3984bis] applies." Also, the reference is not listed in the {Normative, Informative} Reference= Section. > Decoders MUST exercise caution with respect to the handling of > reserved NAL unit types and reserved SEI messages, particularly if > they contain active elements, and MUST restrict their domain of > applicability to the presentation containing the stream. The safest > way is to simply discard these NAL units and SEI messages. Maybe this is due to my ignorance about coding but I find this underspecifi= ed, notably given the presence of the MUST key word. How about spelling exa= ctly what a decoder MUST do, as opposed to say "exercise caution". E.g., "D= ecoders MUST discard NAL units and SEI messages.", and then explain why, or= point to [I-D.ietf-avt-rtp-rfc3984bis] if there's a good explanation there= . > When integrity protection is applied, care MUST be taken that the > stream being transported may be scalable; hence a receiver may be > able to access only part of the entire stream. Hmm. If integrity protection is applied to the RTP packet, and not to the v= ideo content being encoded in a scalable manner, there shouldn't be a probl= em, right? So maybe you need to qualify the object to which integrity prote= ction is applied in the statement above. Is it the RTP packet, or the strea= m? > Informative note: Other security aspects, including > confidentiality, authentication, and denial-of-service threat, > for SVC are similar as H.264/AVC, as discussed in Section 9 of > [I-D.ietf-avt-rtp-rfc3984bis]. This seems redundant with the first paragraph of the Security Consideration= s that already stated that Section 9 of [I-D.ietf-avt-rtp-rfc3984bis] appli= es. HTH, --julien From weiler+secdir@watson.org Sun Oct 24 16:26:32 2010 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 09EB63A691F for ; Sun, 24 Oct 2010 16:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 urEVATRF6gBh for ; Sun, 24 Oct 2010 16:26:31 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id E2A1B3A6918 for ; Sun, 24 Oct 2010 16:26:30 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o9ONSDhw045306 for ; Sun, 24 Oct 2010 19:28:13 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o9ONSDHT045303 for ; Sun, 24 Oct 2010 19:28:13 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 24 Oct 2010 19:28: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.2.3 (fledge.watson.org [127.0.0.1]); Sun, 24 Oct 2010 19:28:13 -0400 (EDT) Subject: [secdir] Assignments 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: Sun, 24 Oct 2010 23:26:32 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Radia Perlman is next in the rotation. For telechat 2010-10-28 Reviewer LC end Draft Stephen Farrell TR2010-09-28 draft-ietf-avt-rapid-acquisition-for-rtp-16 Sandy Murphy T - draft-irtf-rrg-recommendation-14 Glen Zorn T 2010-09-16 draft-ietf-l3vpn-mvpn-spmsi-joins-01 Last calls and special requests: Reviewer LC end Draft Richard Barnes 2010-10-21 draft-ietf-xmpp-3920bis-17 Richard Barnes 2010-10-21 draft-ietf-xmpp-3921bis-15 Richard Barnes 2010-10-21 draft-ietf-xmpp-address-05 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Jeffrey Hutzelman 2010-10-13 draft-ietf-mpls-ldp-upstream-08 Charlie Kaufman 2010-10-12 draft-ietf-storm-ifcpmib-05 Scott Kelly 2010-10-21 draft-ietf-avt-rtp-h264-rcdo-07 Barry Leiba 2010-10-25 draft-ietf-dime-rfc3588bis-25 Chris Lonvick 2010-10-25 draft-ietf-geopriv-rfc3825bis-12 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-11-15 draft-igoe-secsh-x509v3-06 Kathleen Moriarty 2010-11-03 draft-ietf-ipfix-anon-05 Russ Mundy 2010-11-10 draft-ietf-emu-eaptunnel-req-08 Magnus Nystrom 2010-11-05 draft-ietf-dnsop-name-server-management-reqs-04 Hilarie Orman 2010-11-03 draft-ietf-sipcore-event-rate-control-05 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-3920bis-17 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-3921bis-15 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-address-05 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-03 From charliek@microsoft.com Sun Oct 24 20:08:00 2010 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 8E7C43A6939; Sun, 24 Oct 2010 20:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BfK8FvXiy40E; Sun, 24 Oct 2010 20:07:59 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A517C3A6359; Sun, 24 Oct 2010 20:07:59 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 24 Oct 2010 20:09:36 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.144]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi id 14.01.0255.003; Sun, 24 Oct 2010 20:09:34 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-storm-ifcpmib.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-storm-ifcpmib-05.txt Thread-Index: Actz8JowYxQlgwZRR/S79JDTHWqysQ== Date: Mon, 25 Oct 2010 03:09:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-storm-ifcpmib-05.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, 25 Oct 2010 03:08:00 -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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Writing, interpreting, and reviewing MIB documents is to some degree a spec= ialized art, and I can't claim to give this a thorough technical review. Th= e Security Considerations section of most MIB documents is usually pro form= a and not very interesting. This one, however, is exceptional and perhaps s= hould be taken as a model for the Security Considerations sections of other= MIB documents. It describes how security sensitive the various values that= can be accessed through the MIB are, both with respect to reading them and= with respect to updating them. While what fields are going to be sensitive= in what way is often going to be scenario dependent, indications of which = fields might be sensitive and why (particularly in cases where the explanat= ion is not obvious) would make a helpful commentary. This document does not say much about the relative sensitivity of various f= ields (I'm assuming because in this case there isn't much to say). I found no problems with this document. --Charlie From stephen.farrell@cs.tcd.ie Mon Oct 25 06:46:34 2010 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 973F93A683F; Mon, 25 Oct 2010 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ldOmPAUFprv7; Mon, 25 Oct 2010 06:46:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 1449A3A681B; Mon, 25 Oct 2010 06:46:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A41D53E409E; Mon, 25 Oct 2010 14:48:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1288014488; bh=z8IYLVXo7GjQOb UTHQCjcm2ni99H/uvdF1RbsGKKrzU=; b=BubDLHrSAo87M73BA2Zjj7gWDFeH69 n5R9OTrst1gsa3Ks8GGuSe5pflRb1+wknG8Uy0WnHlRQWPh7D0lDcACMLwf5MdFp sS97K6MNI2osdy0bewpzNyED6j/vsSJWZyepFyBIHFxlLLQy0t/4mcClNTE7eQ5H meghiGUv79Zu1KXZhREQIXvCSczNpbePOm3HLRgXCU9PLZQFRh6JPqT2snVNG3K8 UXmpkVDIPQy5x3ObZinGgHdr1NifoCPcD4C218opHPX9SGEoQ00AIdBMOu2HEbvG J9tsgBIhwr/qMEt05L+cMKOQSwQPKI7if8Xz9iCpFSNl0euyjVDPQIsQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iNucjfsyLiGv; Mon, 25 Oct 2010 14:48:08 +0100 (IST) Received: from [192.168.46.103] (ip-193-142-112-98.inqbator.poznan.pl [193.142.112.98]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4B3713E407C; Mon, 25 Oct 2010 14:46:58 +0100 (IST) Message-ID: <4CC58A1C.5020704@cs.tcd.ie> Date: Mon, 25 Oct 2010 14:46:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4CAA07C8.4030806@cs.tcd.ie> <04CAD96D4C5A3D48B1919248A8FE0D540D758A5D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D758A5D@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org, sec-ads@ietf.org, avt-chairs@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16 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, 25 Oct 2010 13:46:34 -0000 Hi Ali, On 19/10/10 16:18, Ali C. Begen (abegen) wrote: > Sorry for not responding to this email earlier. Me too:-) draft-ietf-avt-rapid-acquisition-for-rtp-16 seems to me to do a good job of addressing my comments on -15, except, perhaps, for two. The first is that this protocol is vulnerable to off-path DoS attacks unless SRTP is used, and even where SRTP is used, additional (though minor) constraints on how it is used are required to prevent authorized receivers messing with one another. The -16 version is clear enough (I think) about this, so my only remaining question is whether or not SRTP, with the additional constraints specified, is likely to be deployed or not. I have no idea myself, but if its unlikely to really be deployed, then the vulnerability could probably easily be exploited which would be bad and would lead me at least to wonder whether it would be wiser to try to design this so that it is less vulnerable to off-path attacks. (Assuming that such a solution exists of course.) The second one relates to the additional SRTP constraints. The new text says that the BRS needs to keep a list of receiver certs (which seems unlikely) or else must ensure that all receivers are certified by some "trusted" CA. I don't think that really works - if the problem is that authorized receivers could DoS one another then I don't see how this fixes that. Or am I missing something? S. PS: The text quoted is from the response to my review of -15, I guess it makes life easier to change the subject line to -16 for this re-review but I might be wrong. If so, sorry;-) > I thought I did. Thanks to Robert for reminding me. > > All, > > We tried to address all the issues mentioned below in the latest version. I will respond line by line below. > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Monday, October 04, 2010 12:59 PM >> To: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org; sec-ads@ietf.org >> Cc: secdir@ietf.org; avt-chairs@ietf.org >> Subject: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15 >> >> >> #include >> >> This document defines a way for multicast receivers (e.g. IPTV clients) >> to rapidly acquire the reference information required to make sense of >> the session data. Reference information is usually only sent >> periodically within the session, so this document defines how to setup >> a new unicast session with a server that transmits the reference >> information to the client on request so as a result the client doesn't >> have to wait so long. >> >> Overall, I'm a bit concerned that this might create new DoS exploit >> potential, but I could be wrong (don't know enough about multicast) and >> I see there has been a separate thread on ietf-discuss that had some >> mention of that. (I've not read that thread in detail.) If an off-path >> attacker could insert RAMS-* messages with values that are likely >> to result in things happening then that, I think, would be quite bad, >> but I'm not quite sure. > > Yes, things may go wrong if an attacker sends RAMS control messages on behalf of others or an attacker modifies others' messages. We ack this problem and provide some solutions to deal with it. > >> Detailed security-related issues/questions: >> >> - How does the client know that it has the right FT/BRS? (Does it >> always get that from SDP?) What would happen if it has a bogus FT/BRS? >> (Is that likely?) > > The SDP should be only accepted from reliable sources. So, authentication and integrity checks are recommended. This applies to any application using SDP. > >> - P17 says that the BRS may reject the RAMS-R request. Are there >> security reasons that might cause rejection? If so, what? > > Not really. The rejection reasons are mostly related to the ones already listed in section 7.3.1. > >> - P18 says that the BRS can replace the SSRC from the RAMS-R with >> something else. Wouldn't that allow a bad BRS to redirect an RTP_Rx to >> some dodgy stream, instead of the one requested? Should the RTP_Rx >> react to that somehow? > > We need to have this since the SSRC that is known by the RTP_Rx may have changed and it has to trust to the server for the most up-to-date SSRC. Note that here we assume the server side (BRS) is not compromised. If it is, it does not matter. It can send junk data w/o changing the SSRC. > >> - How are updated RAMS-R and RAMS-I related to originals? Is there a >> way to insert these (maybe from off-path?) If there is, could a fake >> RAMS-I mount a DoS on the RTP-Rx? (E.g. by supplying crap information.) > > First of all, supporting the updated messages is an optional feature, which is highly discouraged anyway (due to various other reasons). In case, an implementation supports it, the security considerations are not much different. Section 10 makes some proposals to deal with this (e.g., source address validation, SRTP, policing, etc.). > >> - Could I send a fake RTCP BYE pretending to be from some RTP_Rx in >> order to DoS that client? > > You can but you need to know the CNAME (which is possible). However, if RTCP messages are authenticated and source address is validated, you will fail. > >> - Could I send a RAMS-R requesting a very high bitrate for a burst as >> a way to DoS someone local to the (claimed) source of the RAMS-R? (The >> max is 2^64 I guess) > > Yeah, we added a text for it. The server should pay attention to what the client mentioned in that field. In any case, that is an upper limit and the server can transmit at much slower pace if it wants to. > >> - p31: the Min RAMS buffer fill requirement seems to allow RTP-Rx to >> request almost 50 days (2^32ms) of content in the unicast burst. That >> seems too much, from the p-o-v of potential DoS exploits. Maybe say >> that the BRS SHOULD impose some limit as part of DoS mitigation? > > Yes, we added text about this as well. The server can naturally reject the decision anyway if it computes that the client is better off by joining the mcast immediately (rather than first receiving the burst and then joining). The client then can join and build up a buffer as long as it wants to. > >> - p35: the earliest join time is also a 32 bit millisecond counter. >> Should the RTP_Rx also have some kind of sanity check if asked to wait >> days? Same comment wrt burst duration. > > Yes, see the new text in section 10. > >> >> - p42: Saying "adequate" security measures are "RECOMMENDED" to protect >> SDP description, without saying what they might be, is very vague. >> What's an implementer supposed to do? > > This really depends on how SDP is distributed. It could be HTTP(S), RTSP or something else. > >> - p43 mentions SRTP as a SHOULD. How widely is that deployed and does >> it make sense for this use-case? I think that should be clear. (If SRTP >> isn't really used, or if its not going to be used here, then its not a >> real countermeasure.) > > Well, in managed networks such as IPTV networks, servers and clients are known by the system admin, configured properly, etc. so one may not need to implement SRTP. In non-managed environments, SRTP is a good tool and if they want protection, they better use it. > >> - p43 says RAMS itself brings no new attacks, but surely it does create >> some new off-path DoS potential, if messages could be guessed? > > And we tried to explain these *new* attacks in Section 10. > >> - p43: what does "consider the security of such SRTP key sharing mean?" >> I think this spec should say. > > We revised that part. See the new text to see whether it works. > >> Nits/Non-security things: >> >> - p8: CNAME is used without being defined. > > Done. > >> - p15: AVPF is used before being defined/expanded. > > Done. > >> - p18: Saying "If the RTP_Rx will issue a ..." seems confusing. Would >> that be clear to an implementer? In other words ought the spec say >> SHOULD somewhere here? (In which case, it'd also presumably say when >> its ok not to follow the SHOULD.) > > Rephrased this part. > >> - p19: This says that if the BRS has given a 504 etc. reject, then the >> RTP_Rx MUST NOT retry. Does that mean just for this stream or for any >> stream? Its not clear to me if the "MUST NOT" is scoped to one "channel >> change" button press, or many, and if many, how that'd ever be reset, >> though that might be my ignorance of the use-case and multicast in >> general:-) > > The response codes have their own scopes. A client may not be authorized for any RAMS operation, or maybe RAMS is not enabled only for that stream. We explicitly say this now in the text. > >> - p20 says the BRS "can" use the updated RAMS-R - that's not 2119 >> language, so I assume you mean "MAY" and the intent is to allow >> implementers to handle updated RAMS-R in whatever way suits best, given >> their internal state when the update arrives? > > For some reason, we did not wanna use 2119 language here (I don't recall it now). But, the idea is that it is really up to the server whether to use the updated request or ignore it. > >> - p21 says "there is no need" to send RAMS-T for rejected stuff. Maybe >> that'd be better as a MUST NOT or SHOULD NOT? > > Why do we need to say any 2119 language here. The server is not expecting a RAMS-T for them, but the client could still send one. > >> - p21: the mix of SHALL and MUST looks odd, I at least, would prefer >> just MUSTs. > > Fixed. > >> - p21, typo s/and started/and has started/ > > Fixed. > >> - p21, OSN-minus-one as a signal for the BRS to stop - can that OSN >> wrap around? > > Sure it does since it is an RTP seqnum and all rtp seqnum rules apply to it as well. > >> - p34: what are "the regular wrapping rules" for MSN and how does >> that work with an 8 bit field that is only zero when a new RAMS-R is >> received? > > Wrapping rules are known in general I think since nobody has asked before what they were :) and MSN is usually 0, but if it keeps increasing, after it has reached the max value, it will naturally wrap around (which is very unlikely to happen). > >> - p38: saying support for rfc5576 "can also be needed" seems vague. >> Better to specifically say when its needed. > > Expanded the text to say when it would be needed. > > Thanks much for the careful review. > > -acbegen > >> Regards, >> Stephen. >> > > From stephen.farrell@cs.tcd.ie Mon Oct 25 07:51:50 2010 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 0E84E3A6A4A; Mon, 25 Oct 2010 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 kHYykSfzMxxA; Mon, 25 Oct 2010 07:51:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 2D98A3A6A5B; Mon, 25 Oct 2010 07:51:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0BF9A3E409E; Mon, 25 Oct 2010 15:53:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1288018410; bh=5teaBQ9WDg1Zky XIOtpZawGlxDo5BZ3tBI5HQZzsczs=; b=QWxeSOdLgo6R+/8Wzeri0hf+vTMMRp jR0yj7Q7BXLbK3CkUQr/1I+U7xoZJLSyWL17GDGvZRAFNY2LdZFiXVQ8uUlgIkTt xAvbh17rN69k88Jwp9c4IgwxL24hyNsdBLF7Dq1/b+5ynwsDsDVrRHpbqdpgDhgc zcxasW5ZdvvX/1GGklxUyctlphiy2fa8EKGio73L84Rqa17RBb5bX+UlU70lUjVE mbMRoREAmL9zj990XgO9TtzuNO9UFpfDj6vfgoBXVfO2Snv9c75xXcOJmCY+mLkO HBgoAFRlriR4s1SkxkAgvF2f+J+c9UsuBCaaH9Rr/htClyhKylqM0Yyw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cO-s+Oi6OR1C; Mon, 25 Oct 2010 15:53:30 +0100 (IST) Received: from [192.168.46.103] (ip-193-142-112-98.inqbator.poznan.pl [193.142.112.98]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3E95D3E409B; Mon, 25 Oct 2010 15:53:29 +0100 (IST) Message-ID: <4CC599E7.2010703@cs.tcd.ie> Date: Mon, 25 Oct 2010 15:53:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4CAA07C8.4030806@cs.tcd.ie> <04CAD96D4C5A3D48B1919248A8FE0D540D758A5D@xmb-sjc-215.amer.cisco.com> <4CC58A1C.5020704@cs.tcd.ie> <04CAD96D4C5A3D48B1919248A8FE0D540D81691E@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D81691E@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org, sec-ads@ietf.org, avt-chairs@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16 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, 25 Oct 2010 14:51:50 -0000 On 25/10/10 15:04, Ali C. Begen (abegen) wrote: > Hi Stephen, > > This time, hopefully a quick answer. Let's keep it up while we can:-) >> The first is that this protocol is vulnerable to off-path DoS attacks >> unless SRTP is used, and even where SRTP is used, additional (though >> minor) constraints on how it is used are required to prevent >> authorized receivers messing with one another. > > First of all, while RAMS could be favored more by the attackers due to the damage it can make, the same set of problems exist in any scenario where a feedback target (receiving feedback from multicast receivers) is supposed to act on them (doing retransmissions, or asking the actual media source to slow down, speed up, etc.). Fair enough. I've no idea if this application is more likely to be used as a potential DoS vector, compared to others with the same issues. > If we really need further explanation about SRTP, I will get together with my SRTP-savvy friends and work on this. Don't think that's needed myself, its more whether or not SRTP is a real solution that'll be used, and as I say, I've no idea about that. >> The -16 version is clear enough (I think) about this, so my only >> remaining question is whether or not SRTP, with the additional >> constraints specified, is likely to be deployed or not. > > Well, I think we are only responsible to mention the problems and possible solutions. We cannot force vendors to implement everything from A to Z. The first deployment that RAMS has is the IPTV networks (for fast channel change). In such environments, the networks are managed and clients are deployed by the operator anyway. So, many of these concerns are not even relevant. I'd imagine they would not care much about SRTP. > > In other areas, SRTP could be needed, but will it be always used? It is not up to me. Sure. But I guess there are other situations where RFCs say e.g. "use s/mime" but we know that people just don't do that. >> I have no idea myself, but if its unlikely to really be deployed, >> then the vulnerability could probably easily be exploited which >> would be bad and would lead me at least to wonder whether it would >> be wiser to try to design this so that it is less vulnerable to >> off-path attacks. (Assuming that such a solution exists of course.) > > I would not say it is very unlikely as SRTP exists today in many VoIP applications. So, the code is available. It is not rocket science, either. So, there is hope ;) Right. And I assume that the AVT WG and the IESG might know if that hope is likely to be realised. To be clear, I'm not asking for a change to -16 here, I'm really asking if -16's use of SRTP is likely to happen or not, and if not, (which you guys may know), then whether that's considered ok or not. >> The second one relates to the additional SRTP constraints. The new >> text says that the BRS needs to keep a list of receiver certs (which >> seems unlikely) or else must ensure that all receivers are certified >> by some "trusted" CA. I don't think that really works - if the >> problem is that authorized receivers could DoS one another then I >> don't see how this fixes that. Or am I missing something? > > Hit by your friends? E.g., the wife's set-top can attack the husband's set-top if her channel changes are getting slower. That is a tough problem to fix, though ;) Well, hit by anyone else who can change a channel using that BRS, which presumably is more than just my friends. > I think this can be only solved if each unicast session is associated with the initial requestor's cert. So, only the messages with the right cert can cause changes in that session. Would that solve the problem? I guess so, though that then depends on each receiver having a key pair and cert, which is probably a deployment headache. Is there no other way that this protocol could be hardened against off-path DoS attempts? E.g. if messages contained a nonce that had to be present in each subsequent message if it was present in the first? Maybe the WG considered that and rejected it, I don't know. Cheers, S. > > -acbegen > >> S. >> >> PS: The text quoted is from the response to my review of -15, I >> guess it makes life easier to change the subject line to -16 for >> this re-review but I might be wrong. If so, sorry;-) > > From rbarnes@bbn.com Mon Oct 25 19:06:34 2010 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 E8E353A67D6; Mon, 25 Oct 2010 19:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5iyipUrJajo; Mon, 25 Oct 2010 19:06:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id ACEFA3A68A8; Mon, 25 Oct 2010 19:06:33 -0700 (PDT) Received: from [128.89.253.84] (port=50299 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PAYxX-0003Nx-5w; Mon, 25 Oct 2010 22:08:19 -0400 Message-ID: <4CC63810.2030809@bbn.com> Date: Mon, 25 Oct 2010 22:08:16 -0400 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-xmpp-address@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [secdir] SECDIR review of draft-ietf-xmpp-address-05.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, 26 Oct 2010 02:06:35 -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 data structure for addressing XMPP resources. As such, it has the potential to create authentication issues, in particular related to spoofing and mimicry of addresses. The document does a good job of describing these risks and available mitigations, but could use a little bit of clarification on a few points. Detailed comments follow. --Richard Major issues: General: It's not clear to me from the text in this document JIDs differ from XMPP URIs. My naïve assumption would be that an XMPP URI would simply be a JID with the scheme "xmpp:" prepended, but the last paragraph of Section 2.1 made me uncertain about this. (I have not checked RFC 5122 to verify whether this is the case syntactically.) Since many client applications will have to convert from XMPP URIs to JIDs -- and because this is a security-sensitive operation -- it seems like it would be helpful for this document to specify conversions between XMPP URIs and JIDs, even if only by reference to RFC 5122. S4.3: It seems like there should be some discussion here about how entities that create JIDs can help mitigate issues of confusability. For example, the existence of confusable characters in the domainpart is mitigated by proper registry policies (which I presume could be incorporated by reference to some IDNA documents). Localparts and resourceparts are not constrained to be domain names, but they are controlled or at least approved by a server, so the server can apply similar policies to these parts. S4.4.1 P2: The observation that only part of an identifier can be authenticated is a good one to make, but there's one subtlety: The remote server is actually authoritative for the localpart and resourcepart of the JID, so the fact that the remote domain has assigned a particular 'from' address effectively authenticates those fields when the domain is authenticated. It might help to note that end-to-end authentication of XMPP stanzas could help mitigate this risk, since it would require the rogue server to generate false credentials in addition to modifying 'from' addresses. Minor issues: S2.2 P2: For clarity, I would change the "SHOULD be an FQDN, can be an IP address or unqualified host name" to "MUST be an FQDN, IPv4 address literal, IPv6 address literal, or unqualified host name". If the intention here is that unqualified host names should have the same syntax as FQDNs, then that should be stated. S2.2 P3: Not clear why this is a "Note:" paragraph, especially since it has "MUST" requirements in it. From rbarnes@bbn.com Mon Oct 25 19:06:36 2010 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 817143A6C1B; Mon, 25 Oct 2010 19:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eh3z7mIY0Fj; Mon, 25 Oct 2010 19:06:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 831D13A67D6; Mon, 25 Oct 2010 19:06:35 -0700 (PDT) Received: from [128.89.253.84] (port=50300 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PAYxZ-0003O1-Cs; Mon, 25 Oct 2010 22:08:21 -0400 Message-ID: <4CC63813.5070101@bbn.com> Date: Mon, 25 Oct 2010 22:08:19 -0400 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-xmpp-3921bis@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-ietf-xmpp-3921bis-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: Tue, 26 Oct 2010 02:06: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 document describes an instant-messaging and presence system based on the core system of exchanging XML stanzas described in RFC 3920 and draft-ietf-xmpp-3920bis. As the document rightly notes, the underlying transport protocol addresses most of the security considerations for this document, and that document seems to have a thorough discussion of security considerations (although I have not done a thorough review). In general, I think that the security considerations in this document adequately describe the additional risks posed by the instant-messaging- and presence-specific parts of the protocol (beyond those of the base protocol), and corresponding mitigations. One thing that might merit clarification: The overriding application-layer security concern here is the proper routing of presence and instant messaging stanzas through the XMPP system. (Underlying communications security concerns are addressed by the core spec.) For the most part, these concerns with requirements on servers to act in certain ways on behalf of the user. It could be helpful to the reader to re-state some of the communications patterns from Section 13.1 of draft-ietf-xmpp-3920bis and comment on the particular roles that the entities play in the context of instant messaging and presence (e.g., routing unicast stanzas, fan-out of broadcast presence messages). --Richard From turners@ieca.com Tue Oct 26 07:14:21 2010 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 162B13A6844 for ; Tue, 26 Oct 2010 07:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 uaXTDoG7ZwTl for ; Tue, 26 Oct 2010 07:14:19 -0700 (PDT) Received: from nm19-vm0.bullet.mail.ne1.yahoo.com (nm19-vm0.bullet.mail.ne1.yahoo.com [98.138.91.59]) by core3.amsl.com (Postfix) with SMTP id 965563A681D for ; Tue, 26 Oct 2010 07:14:19 -0700 (PDT) Received: from [98.138.90.53] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 26 Oct 2010 14:16:04 -0000 Received: from [98.138.89.249] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 26 Oct 2010 14:16:04 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 26 Oct 2010 14:16:03 -0000 X-Yahoo-Newman-Id: 228954.53168.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 61624 invoked from network); 26 Oct 2010 14:16:02 -0000 Received: from thunderfish.local (turners@96.241.1.46 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 26 Oct 2010 07:16:02 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: XzFjxFEVM1nfBjTZ.nuIcK1x5uZ5y79pXBc.kd66ZOKSR9w vxG8j40yF1XFb8Y.OiCGI4hfLSZJRQFWUX8oklaNSXpJQytSjVQGtD8vDhom GZ_S9B8P2b4rtUe1YR7P5x.NHuuUjguJKlPTbLL55wbVRm2l.o2y9zKadeOD 8jAzHHLtlvmYbleGzSx4_Ac5QdOPHl2SJzbwP0dGij5e8L_DZta8t2KmRKUG QLf.5mtiEWq_7cgxIc584HMf102T.Ev_0CH.4YpWv90_5bR91jnLyPpg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CC6E2A2.9000309@ieca.com> Date: Tue, 26 Oct 2010 10:16:02 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Security Directorate lunch in IETF79 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, 26 Oct 2010 14:14:21 -0000 As usual, we're planning to have the Security Directorate lunch on Tuesday. The room is still TBD. If there's anything special you'd like to discuss, please drop an email to Tim or me. Best regards, Tim & Sean From phoffman@imc.org Tue Oct 26 08:04:32 2010 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 D3E613A680A for ; Tue, 26 Oct 2010 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] 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 XWurQjYcAt8j for ; Tue, 26 Oct 2010 08:04:32 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1BD8E3A6936 for ; Tue, 26 Oct 2010 08:04:32 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9QF6GYC080573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Oct 2010 08:06:17 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CC6E2A2.9000309@ieca.com> References: <4CC6E2A2.9000309@ieca.com> Date: Tue, 26 Oct 2010 08:06:15 -0700 To: Sean Turner , secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] Security Directorate lunch in IETF79 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, 26 Oct 2010 15:04:32 -0000 At 10:16 AM -0400 10/26/10, Sean Turner wrote: >As usual, we're planning to have the Security Directorate lunch on Tuesday. The room is still TBD. > >If there's anything special you'd like to discuss, please drop an email to Tim or me. What will the lunch scene for the meeting be? We have heard nothing from the Beijing hosts about where to-go food can be found in the hotel or short walking distance. From turners@ieca.com Tue Oct 26 08:14:39 2010 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 1CA113A6882 for ; Tue, 26 Oct 2010 08:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 HyFR9phfRxVs for ; Tue, 26 Oct 2010 08:14:36 -0700 (PDT) Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by core3.amsl.com (Postfix) with SMTP id DF2E53A67F2 for ; Tue, 26 Oct 2010 08:14:35 -0700 (PDT) Received: from [98.139.91.67] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 26 Oct 2010 15:16:21 -0000 Received: from [98.139.91.10] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 26 Oct 2010 15:16:21 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 26 Oct 2010 15:16:21 -0000 X-Yahoo-Newman-Id: 139502.29386.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 42242 invoked from network); 26 Oct 2010 15:16:21 -0000 Received: from thunderfish.local (turners@96.241.1.46 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 26 Oct 2010 08:16:20 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: uxa6j2cVM1mGn6xq4JExS8I7L9LE4F8WgPhjCdmukC5jsE9 qvhwU6GEFxsmup2l3h6oxt3RRWhRDedvC9eVKdmf2yrOkOWM.5hZzaiJjoKt wA_X40Mm6cMrJ3QOq865DcLUkuKiVrrXACGhsSz5B54dnx_O.U.vkw6c.DGS xSYDKOgvBfmGD9SoRcVv3XzgUbo62wWbUweqSl77t8yRKuDDv.bvmAI9gPKB AbMfvs9VwyvzXOIt4GpPmXPBQB5qkjdsfX9sC8oNCGsYx8VeBKchXqfxuBqN p1sbhFh1V55.zqI5Hq8vGkDzzgWo.2q3.wJ2WmHG7ng-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CC6F0C3.6040308@ieca.com> Date: Tue, 26 Oct 2010 11:16:19 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Paul Hoffman References: <4CC6E2A2.9000309@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] Security Directorate lunch in IETF79 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, 26 Oct 2010 15:14:39 -0000 On 10/26/10 11:06 AM, Paul Hoffman wrote: > At 10:16 AM -0400 10/26/10, Sean Turner wrote: >> As usual, we're planning to have the Security Directorate lunch on Tuesday. The room is still TBD. >> >> If there's anything special you'd like to discuss, please drop an email to Tim or me. > > What will the lunch scene for the meeting be? We have heard nothing from the Beijing hosts about where to-go food can be found in the hotel or short walking distance. I actually don't know anything about the lunch scene. I thought Tina's draft https://datatracker.ietf.org/doc/draft-tsou-ietf79-discover-china/ had some information in about restaurants nearby. I'm hoping they'll have something special setup for the crowds, but at least the hotel has a place that might be quick (the say grab a sandwich to go): http://www.shangri-la.com/en/property/beijing/shangrila/dining/restaurant/thedelicatessen spt From phoffman@imc.org Tue Oct 26 08:29:04 2010 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 777563A6818 for ; Tue, 26 Oct 2010 08:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 1dpIxVlabjtk for ; Tue, 26 Oct 2010 08:29:03 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 62D8F3A680A for ; Tue, 26 Oct 2010 08:29:03 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9QFUm10082601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Oct 2010 08:30:49 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CC6F0C3.6040308@ieca.com> References: <4CC6E2A2.9000309@ieca.com> <4CC6F0C3.6040308@ieca.com> Date: Tue, 26 Oct 2010 08:30:47 -0700 To: Sean Turner From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: secdir@ietf.org Subject: Re: [secdir] Security Directorate lunch in IETF79 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, 26 Oct 2010 15:29:04 -0000 At 11:16 AM -0400 10/26/10, Sean Turner wrote: >I actually don't know anything about the lunch scene. I thought Tina's draft https://datatracker.ietf.org/doc/draft-tsou-ietf79-discover-china/ had some information in about restaurants nearby. It lists a small number of restaurants, but both of the "street food" places listed are a taxi ride away. > I'm hoping they'll have something special setup for the crowds, but at least the hotel has a place that might be quick (the say grab a sandwich to go): > >http://www.shangri-la.com/en/property/beijing/shangrila/dining/restaurant/thedelicatessen Yep, so far that is the *only* place that we know of that to-go food is available. I'm hoping that there are street vendors or small to-go places nearby the hotel, but if not, we might be a bit hungry at secdir. From clonvick@cisco.com Tue Oct 26 11:38:55 2010 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 5B9DF3A68FB; Tue, 26 Oct 2010 11:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 r4i041O1tIcr; Tue, 26 Oct 2010 11:38:36 -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 6E0E83A6877; Tue, 26 Oct 2010 11:38:27 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANa9xkyrR7Ht/2dsb2JhbACTWAGNdnGlEJxAhUgEhFc X-IronPort-AV: E=Sophos;i="4.58,242,1286150400"; d="scan'208";a="610037537" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2010 18:40:10 +0000 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 o9QIeAQa001734; Tue, 26 Oct 2010 18:40:10 GMT Date: Tue, 26 Oct 2010 11:40:09 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, rbarnes@bbn.com, draft-ietf-geopriv-rfc3825bis.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-ietf-geopriv-rfc3825bis-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, 26 Oct 2010 18:38:55 -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. Overall, I find the document to be of good quality and can find no security related concerns that have not been addressed. Thanks, Chris From rbarnes@bbn.com Tue Oct 26 14:46:07 2010 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 7D2BF3A696D; Tue, 26 Oct 2010 14:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, 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 7pkPVHBjOs7R; Tue, 26 Oct 2010 14:46:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3A94D3A680B; Tue, 26 Oct 2010 14:46:06 -0700 (PDT) Received: from [192.1.255.215] (port=51411 helo=col-dhcp-192-1-255-215.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PArN4-000LpW-7w; Tue, 26 Oct 2010 17:47:54 -0400 Message-Id: From: "Richard L. Barnes" To: Peter Saint-Andre In-Reply-To: <4CC743EE.6090703@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Oct 2010 17:47:52 -0400 References: <4CC63810.2030809@bbn.com> <4CC743EE.6090703@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: draft-ietf-xmpp-address@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.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, 26 Oct 2010 21:46:07 -0000 > Is this revised text clearer? > > For the purpose of communication over an XMPP network (e.g., in the > 'to' or 'from' address of an XMPP stanza), an entity's address MUST > be represented as a JID, not as a Uniform Resource Identifier [URI] > or Internationalized Resource Identifier [IRI]. An XMPP URI or IRI > [XMPP-URI] is in essence a JID prepended with 'xmpp:', but the > native > addressing format used in XMPP is that of a mere JID without a URI > scheme. ([XMPP-URI] is provided only for identification and > interaction outside the context of XMPP itself, for example when > linking to a JID from a web page.) Yes, that is better, especially with the revision below. > However, we might want to add the following sentence at the end of the > revised paragraph quoted above: > > See [XMPP-URI] for a description of the process for securely > extracting a JID from an XMPP URI or IRI. After taking a better look at RFC 5122, I agree that that sentence is all that's needed. > >> S4.3: >> It seems like there should be some discussion here about how entities >> that create JIDs can help mitigate issues of confusability. For >> example, the existence of confusable characters in the domainpart is >> mitigated by proper registry policies (which I presume could be >> incorporated by reference to some IDNA documents). Localparts and >> resourceparts are not constrained to be domain names, but they are >> controlled or at least approved by a server, so the server can apply >> similar policies to these parts. > > That said, I think draft-ietf-xmpp-address-06 (you reviewed -05) > includes some text that might address your concern, to wit: > > ### > ... > ### > > Does that help? That's exactly what I was looking for! Presumably the same considerations apply to resourceparts, so perhaps just one more sentence establishing that equivalence would be in order. > >> S4.4.1 P2: >> The observation that only part of an identifier can be >> authenticated is >> a good one to make, but there's one subtlety: The remote server is >> actually authoritative for the localpart and resourcepart of the >> JID, so >> the fact that the remote domain has assigned a particular 'from' >> address >> effectively authenticates those fields when the domain is >> authenticated. >> It might help to note that end-to-end authentication of XMPP stanzas >> could help mitigate this risk, since it would require the rogue >> server >> to generate false credentials in addition to modifying 'from' >> addresses. Any thoughts on this issue? >> Minor issues: >> >> S2.2 P2: For clarity, I would change the "SHOULD be an FQDN, can be >> an >> IP address or unqualified host name" to "MUST be an FQDN, IPv4 >> address >> literal, IPv6 address literal, or unqualified host name". If the >> intention here is that unqualified host names should have the same >> syntax as FQDNs, then that should be stated. > > I take it you mean something like the following edited text: > > ### > > The domainpart for every XMPP service MUST be a fully qualified > domain name ("FQDN"; see [DNS]), IPv4 address, IPv6 address, or > unqualifed hostname (i.e., a text label that is resolvable on > a local network). > > Interoperability Note: Domainparts that are IP addresses might > not be accepted by other services for the sake of server-to- > server > communication, and domainparts that are unqualified > hostnames cannot be used on public networks because they are > resolvable only on a local network. > > ### > > Is that what you were looking for? Yes. >> S2.2 P3: Not clear why this is a "Note:" paragraph, especially >> since it >> has "MUST" requirements in it. > > I've removed the "Implementation Note:" string at the beginning of > that > paragraph. Ok. From rbarnes@bbn.com Tue Oct 26 15:11:20 2010 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 1D4613A68FD; Tue, 26 Oct 2010 15:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, 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 rIXr+ODEijlR; Tue, 26 Oct 2010 15:11:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0D5E13A68D2; Tue, 26 Oct 2010 15:11:13 -0700 (PDT) Received: from [192.1.255.215] (port=51620 helo=col-dhcp-192-1-255-215.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PArlN-000MIE-18; Tue, 26 Oct 2010 18:13:01 -0400 Message-Id: From: "Richard L. Barnes" To: Peter Saint-Andre In-Reply-To: <4CC75191.4010106@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Oct 2010 18:12:59 -0400 References: <4CC63810.2030809@bbn.com> <4CC743EE.6090703@stpeter.im> <4CC75191.4010106@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: draft-ietf-xmpp-address@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.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, 26 Oct 2010 22:11:20 -0000 On Oct 26, 2010, at 6:09 PM, Peter Saint-Andre wrote: > On 10/26/10 3:47 PM, Richard L. Barnes wrote: > > > >>>> S4.3: It seems like there should be some discussion here about >>>> how entities that create JIDs can help mitigate issues of >>>> confusability. For example, the existence of confusable >>>> characters in the domainpart is mitigated by proper registry >>>> policies (which I presume could be incorporated by reference to >>>> some IDNA documents). Localparts and resourceparts are not >>>> constrained to be domain names, but they are controlled or at >>>> least approved by a server, so the server can apply similar >>>> policies to these parts. >>> >>> That said, I think draft-ietf-xmpp-address-06 (you reviewed -05) >>> includes some text that might address your concern, to wit: >>> >>> ### ... ### >>> >>> Does that help? >> >> That's exactly what I was looking for! Presumably the same >> considerations apply to resourceparts, so perhaps just one more >> sentence establishing that equivalence would be in order. > > See the antepenultimate sentence of this adjusted paragraph: > > ### > > 1. Because an XMPP service that allows registration of XMPP user > accounts (localparts) plays a role similar to that of a registry > for DNS domain names, such a service SHOULD establish a policy > about the scripts or blocks of characters it will allow in > localparts at the service. Such a policy is likely to be > informed by the languages and scripts that are used to write > registered account names; in particular, to reduce confusion, > the > service MAY forbid registration of XMPP localparts that contain > characters from more than one script and to restrict > registrations to characters drawn from a very small number of > scripts (e.g., scripts that are well-understood by the > administrators of the service). Such policies are also > appropriate for XMPP services that allow temporary or permanent > registration of XMPP resourceparts, e.g., during resource > binding > [XMPP] or upon joining an XMPP-based chat room [XEP-0045]. For > related considerations in the context of domain name > registration, refer to Section 4.3 of [IDNA-PROTO] and Section > 3.2 of [IDNA-RATIONALE]. Note well that methods for enforcing > such restrictions are out of scope for this document. > > ### Perfect. > >>>> S4.4.1 P2: The observation that only part of an identifier can be >>>> authenticated is a good one to make, but there's one subtlety: >>>> The remote server is actually authoritative for the localpart and >>>> resourcepart of the JID, so the fact that the remote domain has >>>> assigned a particular 'from' address effectively authenticates >>>> those fields when the domain is authenticated. It might help to >>>> note that end-to-end authentication of XMPP stanzas could help >>>> mitigate this risk, since it would require the rogue server to >>>> generate false credentials in addition to modifying 'from' >>>> addresses. >> >> Any thoughts on this issue? > > Sorry, I was going to scroll up to that part of the email before > hitting > send. :) > > I suggest the following modified text: > > ### > > Address forging is difficult in XMPP systems, given the requirement > for sending servers to stamp 'from' addresses and for receiving > servers to verify sending domains via server-to-server > authentication > (see [XMPP]). However, address forging is possible if: > > o A poorly implemented server ignores the requirement for stamping > the 'from' address. This would enable any entity that > authenticated with the server to send stanzas from any > localpart@domainpart as long as the domainpart matches the > sending > domain of the server. > > o An actively malicious server generates stanzas on behalf of any > registered account. > > Therefore, an entity outside the security perimeter of a particular > server cannot reliably distinguish between bare JIDs of the form > at that server and thus can authenticate only > the domainpart of such JIDs with any level of assurance. This > specification does not define methods for discovering or > counteracting such poorly implemented or rogue servers. However, > the > end-to-end authentication or signing of XMPP stanzas could help to > mitigate this risk, since it would require the rogue server to > generate false credentials in addition to modifying 'from' > addresses. > > ### > > Hopefully by the time we supersede the address spec, we will have > developed a technology for end-to-end signing and encryption of XMPP > stanzas, which we can reference from the foregoing paragraph. Hope springs eternal :) Revised text is fine. Thanks for responding quickly. --Richard From new-work-bounces@ietf.org Thu Oct 21 14:06:47 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420B13A6870; Thu, 21 Oct 2010 14:06:47 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B1C083A68CE; Thu, 21 Oct 2010 14:06:45 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20101021210645.B1C083A68CE@core3.amsl.com> Date: Thu, 21 Oct 2010 14:06:45 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Benchmarking Methodology (bmwg) 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, 21 Oct 2010 21:06:47 -0000 A modified charter has been submitted for the Benchmarking Methodology (bmwg) 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 Thursday, October 28, 2010. Benchmarking Methodology (bmwg) --------------------------------------------------- Current Status: Active Working Group r4 Last Updated 2010-10-20 Chair: Al Morton Operations and Management Area Directors: Ronald Bonica Dan Romascanu Operations and Management Area Advisor: Ronald Bonica Mailing Lists: Address: bmwg@ietf.org To Subscribe: bmwg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/bmwg/ Description of Working Group: The Benchmarking Methodology Working Group (BMWG) will continue to produce a series of recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. Taking a view of networking divided into planes, the scope of work includes benchmarks for the management, control, and forwarding planes. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. The set of relevant benchmarks will be developed with input from the community of users (e.g, network operators and testing organizations) and from those affected by the benchmarks when they are published (networking and test equipment manufacturers). When possible, the benchmarks and other terminology will be developed jointly with organizations that are willing to share their expertise. Joint review requirements for a specific work area will be included in the detailed description of the task, as listed below. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to the characterization of implementations of various internetworking technologies using controlled stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the capabilities and operation of inter-networking technology implementations. The BMWG will communicate with the operations community through organizations such as NANOG, RIPE, and APRICOT. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * BGP Control-plane Convergence Methodology (Terminology is complete): With relevant performance characteristics identified, BMWG will prepare a Benchmarking Methodology Document with review from the Routing Area (e.g., the IDR working group and/or the RTG-DIR). The Benchmarking Methodology will be Last-Called in all the groups that previously provided input, including another round of network operator input during the last call. * SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. * Flow Export and Collection: Develop terminology and methods to characterize network devices flow monitoring, export, and collection. The goal is a methodology to assess the maximum IP flow rate that a network device can sustain without losing any IP flow information or compromising the accuracy of information exported on the IP flows, and to asses the forwarding plane performance (if the forwarding function is present) in the presence of Flow Monitoring. * Data Center Bridging Devices: Some key concepts from BMWG's past work are not meaningful when testing switches that implement new IEEE specifications in the area of data center bridging. For example, throughput as defined in RFC 1242 cannot be measured when testing devices that implement three new IEEE specifications: priority-based flow control (802.1Qbb); priority groups (802.1Qaz); and congestion notification (802.1Qau). Since devices that implement these new congestion-management specifications should never drop frames, and since the metric of throughput distinguishes between non-zero and zero drop rates, no throughput measurement is possible using the existing methodology. The current emphasis is on the Priority Flow Control aspects of Data Center Bridging, and the work will include an investigation into whether TRILL RBridges require any specific treatment in the methodology. This work will update RFC 2455 and exchange periodic Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. * Content Aware Devices: New classes of network devices that operate above the IP layer of the network stack require a new methodology to perform adequate benchmarking. Existing BMWG RFCs (RFC2647 and RFC3511) provides useful measurement and performance statistics, though they may not reflect the actual performance of the device when deployed in production networks. Operating within the limitations of the charter, namely blackbox characterization in laboratory environments, the BMWG will develop a methodology that more closely relates the performance of these devices to performance in an operational setting. In order to confirm or identify key performance characteristics, BMWG will solicit input from operations groups such as NANOG, RIP and APRICOT. * LDP Dataplane Convergence: In order to identify key LDP convergence performance characteristics, BMWG will solicit input from operations groups such as NANOG, RIP and APRICOT. When relevant performance characteristics have been identified, BMWG will jointly prepare a Benchmarking Terminology Document with the Routing Area (e.g., the MPLS working group and or the RTG-DIR), which would define metrics relevant to LDP convergence. The Benchmark definition document would be Last-Called in all the working groups that produced it, and solicit operator input during the last call. The work will then continue in BMWG to define the test methodology, with input and review from the aforementioned parties. Goals and Milestones Done Expand the current Ethernet switch benchmarking methodology draft to define the metrics and methodologies particular to the general class of connectionless, LAN switches. Done Edit the LAN switch draft to reflect the input from BMWG. Issue a new version of document for comment. If appropriate, ascertain consensus on whether to recommend the draft for consideration as an RFC. Done Take controversial components of multicast draft to mailing list for discussion. Incorporate changes to draft and reissue appropriately. Done Submit workplan for initiating work on Benchmarking Methodology for LAN Switching Devices. Done Submit workplan for continuing work on the Terminology for Cell/Call Benchmarking draft. Done Submit initial draft of Benchmarking Methodology for LAN Switches. Done Submit Terminology for IP Multicast Benchmarking draft for AD Review. Done Submit Benchmarking Terminology for Firewall Performance for AD review Done Progress ATM benchmarking terminology draft to AD review. Done Submit Benchmarking Methodology for LAN Switching Devices draft for AD review. Done Submit first draft of Firewall Benchmarking Methodology. Done First Draft of Terminology for FIB related Router Performance Benchmarking. Done First Draft of Router Benchmarking Framework Done Progress Frame Relay benchmarking terminology draft to AD review. Done Methodology for ATM Benchmarking for AD review. Done Terminology for ATM ABR Benchmarking for AD review. Done Terminology for FIB related Router Performance Benchmarking to AD review. Done Firewall Benchmarking Methodology to AD Review Done First Draft of Methodology for FIB related Router Performance Benchmarking. Done First draft Net Traffic Control Benchmarking Methodology. Done Methodology for IP Multicast Benchmarking to AD Review. Done Resource Reservation Benchmarking Terminology to AD Review Done First I-D on IPsec Device Benchmarking Terminology Done EGP Convergence Benchmarking Terminology to AD Review Done Resource Reservation Benchmarking Methodology to AD Review Done Net Traffic Control Benchmarking Terminology to AD Review Done IGP/Data-Plane Terminology I-D to AD Review Done IGP/Data-Plane Methodology and Considerations I-Ds to AD Review Done Hash and Stuffing I-D to AD Review Done IPv6 Benchmarking Methodology to AD Review Done IPsec Device Benchmarking Terminology to IESG Review Done IPsec Device Benchmarking Methodology to IESG Review Updated Milestones Done Terminology For Protection Benchmarking to AD Review Sep 2010 Networking Device Reset Benchmark (Updates RFC 2544) to IESG Review Dec 2010 Methodology For Protection Benchmarking to IESG Review Jun 2011 Terminology for SIP Device Benchmarking to IESG Review Jun 2011 Methodology for SIP Device Benchmarking to IESG Review Jul 2010 Basic BGP Convergence Benchmarking Methodology to IESG Review. Feb 2011 Methodology for Flow Export and Collection Benchmarking to IESG Review Jun 2011 Methodology for Data Center Bridging Benchmarking to IESG Review Dec 2011 Terminology for Content Aware Device Benchmarking to IESG Review Dec 2011 Methodology for Content Aware Device Benchmarking to IESG Review Dec 2011 Terminology for LDP Convergence Benchmarking to IESG Review Dec 2011 Methodology for LDP Convergence Benchmarking to IESG Review _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From abegen@cisco.com Mon Oct 25 07:02:38 2010 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 BFC793A6A27; Mon, 25 Oct 2010 07:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, 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 YwJSiOL+Pn3p; Mon, 25 Oct 2010 07:02:37 -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 289E13A683F; Mon, 25 Oct 2010 07:02:37 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALcqxUyrR7Hu/2dsb2JhbAChXXGfV5wPhUgEhFSJBQ X-IronPort-AV: E=Sophos;i="4.58,236,1286150400"; d="scan'208";a="609407497" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 25 Oct 2010 14:04:22 +0000 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.14.3) with ESMTP id o9PE4Mwp002403; Mon, 25 Oct 2010 14:04:22 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 07:04:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2010 07:04:41 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D81691E@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4CC58A1C.5020704@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16 Thread-Index: Act0S1C4aWcJ9m28QlS73LG6fWkIAwAAGpPQ References: <4CAA07C8.4030806@cs.tcd.ie> <04CAD96D4C5A3D48B1919248A8FE0D540D758A5D@xmb-sjc-215.amer.cisco.com> <4CC58A1C.5020704@cs.tcd.ie> From: "Ali C. Begen (abegen)" To: "Stephen Farrell" X-OriginalArrivalTime: 25 Oct 2010 14:04:21.0948 (UTC) FILETIME=[85FD87C0:01CB744D] X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Cc: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org, sec-ads@ietf.org, avt-chairs@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16 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, 25 Oct 2010 14:02:39 -0000 Hi Stephen, This time, hopefully a quick answer.=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, October 25, 2010 3:46 PM > To: Ali C. Begen (abegen) > Cc: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org; = sec-ads@ietf.org; secdir@ietf.org; avt-chairs@ietf.org > Subject: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16 >=20 >=20 > Hi Ali, >=20 > On 19/10/10 16:18, Ali C. Begen (abegen) wrote: > > Sorry for not responding to this email earlier. >=20 > Me too:-) >=20 > draft-ietf-avt-rapid-acquisition-for-rtp-16 seems to me to do a good > job of addressing my comments on -15, except, perhaps, for two. Good. =20 > The first is that this protocol is vulnerable to off-path DoS attacks > unless SRTP is used, and even where SRTP is used, additional (though > minor) constraints on how it is used are required to prevent > authorized receivers messing with one another. First of all, while RAMS could be favored more by the attackers due to = the damage it can make, the same set of problems exist in any scenario = where a feedback target (receiving feedback from multicast receivers) is = supposed to act on them (doing retransmissions, or asking the actual = media source to slow down, speed up, etc.). If we really need further explanation about SRTP, I will get together = with my SRTP-savvy friends and work on this. =20 > The -16 version is clear enough (I think) about this, so my only > remaining question is whether or not SRTP, with the additional > constraints specified, is likely to be deployed or not. Well, I think we are only responsible to mention the problems and = possible solutions. We cannot force vendors to implement everything from = A to Z. The first deployment that RAMS has is the IPTV networks (for = fast channel change). In such environments, the networks are managed and = clients are deployed by the operator anyway. So, many of these concerns = are not even relevant. I'd imagine they would not care much about SRTP. In other areas, SRTP could be needed, but will it be always used? It is = not up to me. =20 > I have no idea myself, but if its unlikely to really be deployed, > then the vulnerability could probably easily be exploited which > would be bad and would lead me at least to wonder whether it would > be wiser to try to design this so that it is less vulnerable to > off-path attacks. (Assuming that such a solution exists of course.) I would not say it is very unlikely as SRTP exists today in many VoIP = applications. So, the code is available. It is not rocket science, = either. So, there is hope ;) =20 > The second one relates to the additional SRTP constraints. The new > text says that the BRS needs to keep a list of receiver certs (which > seems unlikely) or else must ensure that all receivers are certified > by some "trusted" CA. I don't think that really works - if the > problem is that authorized receivers could DoS one another then I > don't see how this fixes that. Or am I missing something? Hit by your friends? E.g., the wife's set-top can attack the husband's = set-top if her channel changes are getting slower. That is a tough = problem to fix, though ;) I think this can be only solved if each unicast session is associated = with the initial requestor's cert. So, only the messages with the right = cert can cause changes in that session. Would that solve the problem? -acbegen =20 > S. >=20 > PS: The text quoted is from the response to my review of -15, I > guess it makes life easier to change the subject line to -16 for > this re-review but I might be wrong. If so, sorry;-) From abegen@cisco.com Mon Oct 25 08:12:59 2010 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 A78003A686B; Mon, 25 Oct 2010 08:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, 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 PcYNQ95oJGzH; Mon, 25 Oct 2010 08:12:56 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 90BA93A6A27; Mon, 25 Oct 2010 08:12:56 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANI7xUyrR7H+/2dsb2JhbAChXXGgH5wlhUgEhFSJBQ X-IronPort-AV: E=Sophos;i="4.58,236,1286150400"; d="scan'208";a="206223944" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 25 Oct 2010 15:14:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9PFEfv7024561; Mon, 25 Oct 2010 15:14:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 08:14:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2010 08:15:04 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D816948@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4CC599E7.2010703@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16 Thread-Index: Act0VGWN9CE7A2kMSqegc8VG0BPxkgAAYR9w References: <4CAA07C8.4030806@cs.tcd.ie> <04CAD96D4C5A3D48B1919248A8FE0D540D758A5D@xmb-sjc-215.amer.cisco.com> <4CC58A1C.5020704@cs.tcd.ie> <04CAD96D4C5A3D48B1919248A8FE0D540D81691E@xmb-sjc-215.amer.cisco.com> <4CC599E7.2010703@cs.tcd.ie> From: "Ali C. Begen (abegen)" To: "Stephen Farrell" X-OriginalArrivalTime: 25 Oct 2010 15:14:41.0558 (UTC) FILETIME=[5912EB60:01CB7457] X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Cc: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org, sec-ads@ietf.org, avt-chairs@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16 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, 25 Oct 2010 15:12:59 -0000 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, October 25, 2010 4:53 PM > To: Ali C. Begen (abegen) > Cc: draft-ietf-avt-rapid-acquisition-for-rtp.all@tools.ietf.org; = sec-ads@ietf.org; secdir@ietf.org; avt-chairs@ietf.org > Subject: Re: secdir review of = draft-ietf-avt-rapid-acquisition-for-rtp-16 >=20 >=20 >=20 > On 25/10/10 15:04, Ali C. Begen (abegen) wrote: > > Hi Stephen, > > > > This time, hopefully a quick answer. >=20 > Let's keep it up while we can:-) >=20 > >> The first is that this protocol is vulnerable to off-path DoS = attacks > >> unless SRTP is used, and even where SRTP is used, additional = (though > >> minor) constraints on how it is used are required to prevent > >> authorized receivers messing with one another. > > > > First of all, while RAMS could be favored more by the attackers due = to the damage it can make, the same set of problems > exist in any scenario where a feedback target (receiving feedback from = multicast receivers) is supposed to act on them > (doing retransmissions, or asking the actual media source to slow = down, speed up, etc.). >=20 > Fair enough. I've no idea if this application is more likely > to be used as a potential DoS vector, compared to others with > the same issues. We will see. IPTV is one of the mostly used multicast (SSM) application = out there. So, RAMS will be a good test. =20 > > If we really need further explanation about SRTP, I will get = together with my SRTP-savvy friends and work on this. >=20 > Don't think that's needed myself, its more whether or not > SRTP is a real solution that'll be used, and as I say, I've > no idea about that. >=20 > >> The -16 version is clear enough (I think) about this, so my only > >> remaining question is whether or not SRTP, with the additional > >> constraints specified, is likely to be deployed or not. > > > > Well, I think we are only responsible to mention the problems and = possible solutions. We cannot force vendors to > implement everything from A to Z. The first deployment that RAMS has = is the IPTV networks (for fast channel change). In > such environments, the networks are managed and clients are deployed = by the operator anyway. So, many of these concerns > are not even relevant. I'd imagine they would not care much about = SRTP. > > > > In other areas, SRTP could be needed, but will it be always used? It = is not up to me. >=20 > Sure. But I guess there are other situations where RFCs say > e.g. "use s/mime" but we know that people just don't do that. Indeed. =20 > >> I have no idea myself, but if its unlikely to really be deployed, > >> then the vulnerability could probably easily be exploited which > >> would be bad and would lead me at least to wonder whether it would > >> be wiser to try to design this so that it is less vulnerable to > >> off-path attacks. (Assuming that such a solution exists of course.) > > > > I would not say it is very unlikely as SRTP exists today in many = VoIP applications. So, the code is available. It is not rocket > science, either. So, there is hope ;) >=20 > Right. And I assume that the AVT WG and the IESG might know > if that hope is likely to be realised. >=20 > To be clear, I'm not asking for a change to -16 here, I'm really > asking if -16's use of SRTP is likely to happen or not, and if > not, (which you guys may know), then whether that's considered > ok or not. I don't have a concern at least for the applications we are considering = RAMS for. If IESG will have, then I hope we will figure out something. =20 > >> The second one relates to the additional SRTP constraints. The new > >> text says that the BRS needs to keep a list of receiver certs = (which > >> seems unlikely) or else must ensure that all receivers are = certified > >> by some "trusted" CA. I don't think that really works - if the > >> problem is that authorized receivers could DoS one another then I > >> don't see how this fixes that. Or am I missing something? > > > > Hit by your friends? E.g., the wife's set-top can attack the = husband's set-top if her channel changes are getting slower. That > is a tough problem to fix, though ;) >=20 > Well, hit by anyone else who can change a channel using > that BRS, which presumably is more than just my friends. The example was just funny and I could not resist sending :) =20 > > I think this can be only solved if each unicast session is = associated with the initial requestor's cert. So, only the messages > with the right cert can cause changes in that session. Would that = solve the problem? >=20 > I guess so, though that then depends on each receiver having > a key pair and cert, which is probably a deployment headache. Yes, that would be a concern if the server needs to deal with e.g., 100K = clients. > Is there no other way that this protocol could be hardened > against off-path DoS attempts? E.g. if messages contained a > nonce that had to be present in each subsequent message if > it was present in the first? Maybe the WG considered that > and rejected it, I don't know. Actually, there is a normative reference for RAMS, which is the port = mapping stuff: http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02 https://datatracker.ietf.org/idtracker/draft-begen-avt-token-for-portmapp= ing/ These add a natural protection since they require a cookie or token = validation (which verifies the address (and maybe the port) of the = client). The work is still in progress but eventually, regardless of = which approach is chosen, it will hopefully avoid somebody else using = your cookie/token so in theory they cannot hijack your RAMS session. Cheers, acbegen. From stpeter@stpeter.im Mon Oct 25 21:08:26 2010 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 AA8843A684C; Mon, 25 Oct 2010 21:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 ur5i4Xl4xTBd; Mon, 25 Oct 2010 21:08:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 526F73A683A; Mon, 25 Oct 2010 21:08:25 -0700 (PDT) Received: from squire.local (dsl-179-124.dynamic-dsl.frii.net [216.17.179.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 788FA40D1E; Mon, 25 Oct 2010 22:18:06 -0600 (MDT) Message-ID: <4CC654A1.7020502@stpeter.im> Date: Mon, 25 Oct 2010 22:10:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4CC63813.5070101@bbn.com> In-Reply-To: <4CC63813.5070101@bbn.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010703080903010906020308" X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Cc: draft-ietf-xmpp-3921bis@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-3921bis-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: Tue, 26 Oct 2010 04:08:26 -0000 This is a cryptographically signed message in MIME format. --------------ms010703080903010906020308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the review. One comment inline. On 10/25/10 8:08 PM, Richard L. Barnes 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= =2E > 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. >=20 > This document describes an instant-messaging and presence system based > on the core system of exchanging XML stanzas described in RFC 3920 and > draft-ietf-xmpp-3920bis. As the document rightly notes, the underlying= > transport protocol addresses most of the security considerations for > this document, and that document seems to have a thorough discussion of= > security considerations (although I have not done a thorough review). I= n > general, I think that the security considerations in this document > adequately describe the additional risks posed by the instant-messaging= - > and presence-specific parts of the protocol (beyond those of the base > protocol), and corresponding mitigations. >=20 > One thing that might merit clarification: The overriding > application-layer security concern here is the proper routing of > presence and instant messaging stanzas through the XMPP system. > (Underlying communications security concerns are addressed by the core > spec.) For the most part, these concerns with requirements on servers > to act in certain ways on behalf of the user. It could be helpful to > the reader to re-state some of the communications patterns from Section= > 13.1 of draft-ietf-xmpp-3920bis and comment on the particular roles tha= t > the entities play in the context of instant messaging and presence > (e.g., routing unicast stanzas, fan-out of broadcast presence= > messages). Although in general I'm not a fan of repeating material that is already covered by a referenced specification, I agree that it might be appropriate to provide a reminder about the underlying architecture of XMPP and its implications for the security of various IM-related and presence-related interactions. I'll reply again once I have investigated the best location for such a reminder and have formulated proposed text. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010703080903010906020308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NjA0MTAwOVowIwYJKoZIhvcNAQkEMRYEFFkUnQeOx/en918eeN/JDm/rCCpLMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCiv3T/PU4QLtkeXFsHWempqqpIGk+KwmGI41hs0R0NaeYitSrRM4DxDpZ+ jV59BpH4VpWJExt45VH/AfvR9tHQhdfD+TT9fSjMKEXT9xJ+4Vk1gNU+567vPwKZJTsyq3Gv paPluTuwnxho5S5JgMBnYYe4IsZZ6c+M77gUJYfbpR3SS3i/eVOAQG3G9yH1rkLPumFLdDUJ RIaDTPqCVg83pDkhWY3no0/G/Sn41GtkYLAXZfZNckA8xC+FDGdrPn3NgH7Mrs6UKwm8wBue RSMY+MUsQBaTd620tv/7g6J2mpffkazWCEX9SVxsA1RytHrDGHEjuDC9bTw54ZOyX1M6AAAA AAAA --------------ms010703080903010906020308-- From stpeter@stpeter.im Tue Oct 26 09:58:00 2010 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 40BA93A698F; Tue, 26 Oct 2010 09:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, 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 BPZnqZGn110I; Tue, 26 Oct 2010 09:57:58 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6A8BF3A6939; Tue, 26 Oct 2010 09:57:58 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9CEAE40D1E; Tue, 26 Oct 2010 11:07:43 -0600 (MDT) Message-ID: <4CC708FF.5070801@stpeter.im> Date: Tue, 26 Oct 2010 10:59:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4CC63813.5070101@bbn.com> <4CC654A1.7020502@stpeter.im> In-Reply-To: <4CC654A1.7020502@stpeter.im> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060108050408090502020002" X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Cc: draft-ietf-xmpp-3921bis@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] [xmpp] SECDIR review of draft-ietf-xmpp-3921bis-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: Tue, 26 Oct 2010 16:58:00 -0000 This is a cryptographically signed message in MIME format. --------------ms060108050408090502020002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/25/10 10:10 PM, Peter Saint-Andre wrote: > Thanks for the review. One comment inline. >=20 > On 10/25/10 8:08 PM, Richard L. Barnes wrote: >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IES= G. >> 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 instant-messaging and presence system based= >> on the core system of exchanging XML stanzas described in RFC 3920 and= >> draft-ietf-xmpp-3920bis. As the document rightly notes, the underlyin= g >> transport protocol addresses most of the security considerations for >> this document, and that document seems to have a thorough discussion o= f >> security considerations (although I have not done a thorough review). = In >> general, I think that the security considerations in this document >> adequately describe the additional risks posed by the instant-messagin= g- >> and presence-specific parts of the protocol (beyond those of the base >> protocol), and corresponding mitigations. >> >> One thing that might merit clarification: The overriding >> application-layer security concern here is the proper routing of >> presence and instant messaging stanzas through the XMPP system. >> (Underlying communications security concerns are addressed by the core= >> spec.) For the most part, these concerns with requirements on servers= >> to act in certain ways on behalf of the user. It could be helpful to >> the reader to re-state some of the communications patterns from Sectio= n >> 13.1 of draft-ietf-xmpp-3920bis and comment on the particular roles th= at >> the entities play in the context of instant messaging and presence >> (e.g., routing unicast stanzas, fan-out of broadcast presenc= e >> messages). >=20 > Although in general I'm not a fan of repeating material that is already= > covered by a referenced specification, I agree that it might be > appropriate to provide a reminder about the underlying architecture of > XMPP and its implications for the security of various IM-related and > presence-related interactions. I'll reply again once I have investigate= d > the best location for such a reminder and have formulated proposed text= =2E Does the following text (to be added to the Security Considerations section of 3920bis) address your concern? ### Section 13.1 of [XMPP-CORE] outlines the architectural roles of clients and servers in typical deployments of XMPP, and discusses the security properties associated with those roles. These roles have an impact on the security of instant messages, presence subscriptons, and presence notifications as described in this document. In essence, an XMPP user registers (or has provisioned) an account on an XMPP server and therefore places some level of trust in the server to complete various tasks on the user's behalf, enforce security policies, etc. Thus it is the server's responsibility to: 1. Preferably mandate the use of channel encryption for communication with local clients and remote servers. 2. Authenticate any client that wishes to access the user's account. 3. Process XML stanzas to and from clients that have authenticated as the user (specifically with regard to instant messaging and presence functionality, store the user's roster, process inbound and outbound subscription requests and responses, generate and handle presence probes, broadcast outbound presence notifications, route outbound messages, and deliver inbound messages and presence notifications). As discussed in Sections 13.1 and 13.4 of [XMPP-CORE], even if the server fulfills the foregoing responsibilities, the client does not have any assurance that stanzas it might exchange with other clients (whether on the same server or a remote server) are protected for all hops along the XMPP communication path, or within the server itself. It is the responsibility of the client to use an appropriate technology for encryption and signing of XML stanzas if it wishes to ensure end-to-end confidentiality and integrity of its communications. ### Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060108050408090502020002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NjE2NTk0M1owIwYJKoZIhvcNAQkEMRYEFGTc3RzAPehOx2YMES9FBX8pmT/NMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBV0qRsx8heFdVmnN2FVXaN1E1VRtWEz9JlndxCEwI4I1dQkoeJLpXqGkAP pnIGggJWxBqokH9Q5WOgCuMzq9DTZzUaAHoE14cjI1dF9Igs66kbdu7aXjsOsd0rQL/DR2pa KztPOVjFeRNCkzlszBBhZ78EjH8wYR2rxcN7joqWh2pcu7DJGvE9sE5KHQzVaRQEWcViC4LG V39CGALAWgzAJDYxcwtM088uKJgLl7JgU+SYnJOgryPv0eucDXIDckkIMYgygaeBBb80WC7h e+ziq93czk6hEobTHFSJYLKBq3j1tLE7rZx+INTna2pGXoYpjIC6ekqYZ0Q2k65XsF3dAAAA AAAA --------------ms060108050408090502020002-- From new-work-bounces@ietf.org Tue Oct 26 10:00:14 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DAD3A69C4; Tue, 26 Oct 2010 10:00:14 -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 1B0563A698F; Tue, 26 Oct 2010 10:00:02 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20101026170003.1B0563A698F@core3.amsl.com> Date: Tue, 26 Oct 2010 10:00:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Subject: [secdir] [new-work] WG Review: Keys In DNS (kidns) 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, 26 Oct 2010 17:00:14 -0000 A new IETF working group has been proposed in the Security 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, November 7, 2010 Keys In DNS (kidns) ----------------------- Last modified: 2010-10-25 Current status: Proposed Working Group Chairs: Warren Kumari Ondrej Sury Security Area Directors: Sean Turner Tim Polk Security Area Advisor: Tim Polk Mailing Lists: General Discussion: keyassure@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure Archive: http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html Objective: Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through the DNS and authenticated using DNSSEC to obtain public keys which are associated with a service located at a domain name. Problem Statement: Entities on the Internet are usually identified using domain names and forming a cryptographically secured connection to the entity requires the entity to authenticate its name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. DNSSEC provides a mechanism for a domain operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for domain operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. Possible starting points for these deliverables include draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and draft-josefsson-keyassure-tls. The mechanisms developed by this group will address bindings between domain names and keys, allowing flexibility for all key-transport mechanisms supported by the application protocols addressed (e.g., both self-signed and CA-issued certificates for use in TLS). The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols. Milestones: Dec 2010 First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS Jan 2011 First WG draft of standards-track protocols for using DNS to associate hosts with IPsec Jun 2011 Protocol for using DNS to associate domain names with keys for TLS and DTLS to IESG Aug 2011 Protocols for using DNS to associate domain names with keys for IPsec to IESG Aug 2011 Recharter _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Oct 26 10:15:22 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA963A69E2; Tue, 26 Oct 2010 10:15:22 -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 1387B3A69A6; Tue, 26 Oct 2010 10:15:08 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20101026171509.1387B3A69A6@core3.amsl.com> Date: Tue, 26 Oct 2010 10:15:08 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Multiple Interfaces (mif) 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, 26 Oct 2010 17:15:22 -0000 A modified charter has been submitted for the Multiple Interfaces (mif) 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, November 2, 2010. A diff from the previous charter is available at: http://www.arkko.com/ietf/mif/charterdiff.html Multiple Interfaces (mif) --------------------------------------------- Status: Active Working Group Last updated: 2010-10-22 Chairs: Margaret Wasserman Hui Deng Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when contradictory configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the impacts and effectiveness of these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. After completing some of its initial goals in 2010 the group is also developing three specific extensions: 1) DNS server selection solution: a specification for describing a way for a network to communicate to nodes information required to perform advanced DNS server selection at name resolution request granularity in scenarios involving multiple namespaces. The specification shall describe the information to be delivered for nodes and the protocol to be used for delivery. 2) DHCPv6 routing configuration: DHCPv6 routing configuration: a specification of DHCPv6 options allowing to provision client nodes with small amount of static routing information (e.g. regarding first-hop selection). This is an additional mechanism to the one already defined in RFC 4191 to enable per-host configuration in a managed network environment. The development of dynamic routing capabilities or ability to send more than a few specific routes are explicitly outside the scope of work in this, and require the use of either existing or new routing protocols. 3) MIF API: While no changes are needed for applications to run on multiple interface hosts, a new API could provide additional services to applications running on hosts attached to multiple provisioning domains. For instance, these services could assist advanced applications in having greater control over first-hop, source address and/or DNS selection issues. This API will be defined as an abstract interface specification, i.e., specific details about mapping to operating system primitives or programming language will be left out. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. With the exception of support for additional DHCP options in DHCP servers, group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Future work in this area requires rechartering the working group or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Goals and Milestones Done WG chartered Done Initial draft on problem statement adopted by the WG Done Initial draft on existing practices adopted by the WG Done Initial draft on analysis of existing practices adopted by the WG Done Problem statement draft submitted to the IESG for publication as an Informational RFC Done Existing practices draft submitted to the IESG for publication as an Informational RFC Dec 2010 Initial WG draft on DHCPv6 option for routing configuration Jan 2011 Analysis draft submitted to the IESG for publication as an Informational RFC Jan 2011 Initial WG draft on advanced DNS server selection solution Jan 2011 Initial WG draft on MIF API extension. Jun 2011 Submit DHCPv6 routing configuration option to IESG for publication as a Proposed Standard RFC Nov 2011 Submit advanced DNS server selection solution to IESG for publication as a Proposed Standard RFC Nov 2011 Submit MIF API extension solution to IESG for publication as an Informational RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From stpeter@stpeter.im Tue Oct 26 14:09:27 2010 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 538FD3A68FD; Tue, 26 Oct 2010 14:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, 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 jQPqRYgdfK4O; Tue, 26 Oct 2010 14:09:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 06CA83A6804; Tue, 26 Oct 2010 14:09:25 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 69D2A40D1E; Tue, 26 Oct 2010 15:19:11 -0600 (MDT) Message-ID: <4CC743EE.6090703@stpeter.im> Date: Tue, 26 Oct 2010 15:11:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4CC63810.2030809@bbn.com> In-Reply-To: <4CC63810.2030809@bbn.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000706070402090606080209" X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Cc: draft-ietf-xmpp-address@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.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, 26 Oct 2010 21:09:27 -0000 This is a cryptographically signed message in MIME format. --------------ms000706070402090606080209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Copying xmpp@ietf.org to keep the WG in the loop...] Thanks for the review. Please be aware that you reviewed draft-ietf-xmpp-address-05, but based on further discussion in the XMPP WG we published -06 right before the October 25 cutoff, and I think -06 includes text that might address some of your concerns (details below). A diff is here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-xmpp-address-06.txt On 10/25/10 8:08 PM, Richard L. Barnes 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= =2E > 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. >=20 > This document describes a data structure for addressing XMPP resources.= > As such, it has the potential to create authentication issues, in > particular related to spoofing and mimicry of addresses. The document > does a good job of describing these risks and available mitigations, bu= t > could use a little bit of clarification on a few points. >=20 > Detailed comments follow. >=20 > --Richard >=20 >=20 >=20 >=20 > Major issues: >=20 > General: It's not clear to me from the text in this document JIDs diffe= r > from XMPP URIs. My na=C3=AFve assumption would be that an XMPP URI wou= ld > simply be a JID with the scheme "xmpp:" prepended,=20 Correct. There are complexities involved when the JID contains characters outside the ASCII range, which is why RFC 5122 says to convert the URI to an IRI before extracting the JID. > but the last > paragraph of Section 2.1 made me uncertain about this. (I have not > checked RFC 5122 to verify whether this is the case syntactically.) Is this revised text clearer? For the purpose of communication over an XMPP network (e.g., in the 'to' or 'from' address of an XMPP stanza), an entity's address MUST be represented as a JID, not as a Uniform Resource Identifier [URI] or Internationalized Resource Identifier [IRI]. An XMPP URI or IRI [XMPP-URI] is in essence a JID prepended with 'xmpp:', but the native addressing format used in XMPP is that of a mere JID without a URI scheme. ([XMPP-URI] is provided only for identification and interaction outside the context of XMPP itself, for example when linking to a JID from a web page.) > Since many client applications will have to convert from XMPP URIs to > JIDs -- and because this is a security-sensitive operation -- it seems > like it would be helpful for this document to specify conversions > between XMPP URIs and JIDs, even if only by reference to RFC 5122. I agree that we need to somewhere describe how a JID can be securely extracted from an XMPP URI, and I think RFC 5122 handles that fairly well at the moment. If the matter is not clear in RFC 5122, then it needs to be clarified in 5122bis -- RFC 5122 will be revised anyway once we supersede the address spec you've reviewed, once 3987bis is published, etc. Because this (temporary) address spec mentions XMPP URIs/IRIs only to say that they are explicitly out of scope for XMPP itself and must not be used as the address format for communication over an XMPP network, I think it's not proper to introduce dependencies on RFC 5122 in the core specification. However, we might want to add the following sentence at the end of the revised paragraph quoted above: See [XMPP-URI] for a description of the process for securely extracting a JID from an XMPP URI or IRI. > S4.3: > It seems like there should be some discussion here about how entities > that create JIDs can help mitigate issues of confusability. For > example, the existence of confusable characters in the domainpart is > mitigated by proper registry policies (which I presume could be > incorporated by reference to some IDNA documents). Localparts and > resourceparts are not constrained to be domain names, but they are > controlled or at least approved by a server, so the server can apply > similar policies to these parts. The XMPP community is just beginning to get a handle on these issues. I agree that an XMPP server functions as a registry of sorts: a registry of localparts associated with accounts. See for instance the last paragraph here: http://tools.ietf.org/html/draft-saintandre-xmpp-i18n-02#section-2 Similarly, an XMPP groupchat service functions as kind of registry for temporary resourceparts, and in some cases even permanent resourceparts: http://xmpp.org/extensions/xep-0045.html#register With the understanding that usernames can be provisioned and not registered directly by a user, I'll point out that the "in-band registration" protocol (XEP-0077) traditionally used for registration of an account at an XMPP server has included absolutely no support for registration *policies* (e.g., disallowing symbol characters in the localpart), because the XMPP community was blithely unaware of possible problems with the lack of such policies. This is something that needs to be remedied, but it has not been remedied yet. I'm hoping that work on the successor to the address spec you've reviewed will lead to at least some solutions to these problems, and the individual I-D that I mentioned above is an attempt at starting that conversation. That said, I think draft-ietf-xmpp-address-06 (you reviewed -05) includes some text that might address your concern, to wit: ### Despite the fact that some specific suggestions about identification and handling of confusable characters appear in the Unicode Security Considerations [UNICODE-SEC], it is also true (as noted in [IDNA-DEFS]) that "there are no comprehensive technical solutions to the problems of confusable characters". Mimicked JIDs that involve characters from only one script, or from the script typically employed by a particular user or community of language users, are not easy to combat (e.g., the simple typejacking attack previously described, which relies on a surface similarity between the characters "1" and "l" in some presentations). However, mimicked addresses that involve characters from more than one script, or from a script not typically employed by a particular user or community of language users, can be mitigated somewhat through the application of appropriate registration policies at XMPP services and presentation policies in XMPP client software. Therefore the following policies are encouraged: 1. Because an XMPP service that allows registration of XMPP user accounts (localparts) plays a role similar to that of a registry for DNS domain names, such a service SHOULD establish a policy about the scripts or blocks of characters it will allow in localparts at the service. Such a policy is likely to be informed by the languages and scripts that are used to write registered account names; in particular, to reduce confusion, the service MAY forbid registration of XMPP localparts that contain characters from more than one script and to restrict registrations to characters drawn from a very small number of scripts (e.g., scripts that are well-understood by the administrators of the service). For related considerations in the context of domain name registration, refer to Section 4.3 of [IDNA-PROTO] and Section 3.2 of [IDNA-RATIONALE]. Note well that methods for enforcing such restrictions are out of scope for this document. 2. Because every human user of an XMPP client presumably has a preferred language (or, in some cases, a small set of preferred languages), an XMPP client SHOULD gather that information either explicitly from the user or implicitly via the operating system of the user's device. Furthermore, because most languages are typically represented by a single script (or a small set of scripts) and most scripts are typically contained in one or more blocks of characters, an XMPP client SHOULD warn the user when presenting a JID that mixes characters from more than one script or block, or that uses characters outside the normal range of the user's preferred language(s). This recommendation is not intended to discourage communication across different communities of language users; instead, it recognizes the existence of such communities and encourages due caution when presenting unfamiliar scripts or characters to human users. ### Does that help? > S4.4.1 P2: > The observation that only part of an identifier can be authenticated is= > a good one to make, but there's one subtlety: The remote server is > actually authoritative for the localpart and resourcepart of the JID, s= o > the fact that the remote domain has assigned a particular 'from' addres= s > effectively authenticates those fields when the domain is authenticated= =2E > It might help to note that end-to-end authentication of XMPP stanzas > could help mitigate this risk, since it would require the rogue server > to generate false credentials in addition to modifying 'from' addresses= =2E >=20 >=20 > Minor issues: >=20 > S2.2 P2: For clarity, I would change the "SHOULD be an FQDN, can be an > IP address or unqualified host name" to "MUST be an FQDN, IPv4 address > literal, IPv6 address literal, or unqualified host name". If the > intention here is that unqualified host names should have the same > syntax as FQDNs, then that should be stated. I take it you mean something like the following edited text: ### The domainpart for every XMPP service MUST be a fully qualified domain name ("FQDN"; see [DNS]), IPv4 address, IPv6 address, or unqualifed hostname (i.e., a text label that is resolvable on a local network). Interoperability Note: Domainparts that are IP addresses might not be accepted by other services for the sake of server-to-server communication, and domainparts that are unqualified hostnames cannot be used on public networks because they are resolvable only on a local network. ### Is that what you were looking for? > S2.2 P3: Not clear why this is a "Note:" paragraph, especially since it= > has "MUST" requirements in it. I've removed the "Implementation Note:" string at the beginning of that paragraph. Thanks again for the review. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000706070402090606080209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NjIxMTExMFowIwYJKoZIhvcNAQkEMRYEFFQGBYW57hjq+57s53T1JdFBUUG4MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBR+7kws+tUs+wNxrfCbaYFJ043NPjBJvCzkVMr+iJWLI9kYUSVpDQEpbZZ UomyeHqkFXLVbuPTBCBcUtROYjjIwTJoXVjUg50bPnWwoDY09rAW1+7EjtIE28BPwtNbYBxQ Zo0kBIe2TYJmNSr51UCcAskkIjRgKGnOLN7EC3mT9RjgbmzQaCsTJU6+QOm0lTWCqwzuV5rp UtUaec1Tux4TwCqZYJKW0UnNiJxqW821xzymgj2652ljV6vbu5fvPXyudypiHRJuio6utSo2 A+Wok1d3thIQ4E54KGF0fmgOh7jtk6GMbX5nrVztjJSONFJQpIF3DX5BfDl11YDROFGmAAAA AAAA --------------ms000706070402090606080209-- From stpeter@stpeter.im Tue Oct 26 15:07:37 2010 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 32CF43A6897; Tue, 26 Oct 2010 15:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, 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 KmDNO9cFeCCF; Tue, 26 Oct 2010 15:07:35 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A8A4E3A680B; Tue, 26 Oct 2010 15:07:35 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2021D40D1F; Tue, 26 Oct 2010 16:17:23 -0600 (MDT) Message-ID: <4CC75191.4010106@stpeter.im> Date: Tue, 26 Oct 2010 16:09:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4CC63810.2030809@bbn.com> <4CC743EE.6090703@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040907010308030600020302" X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700 Cc: draft-ietf-xmpp-address@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-address-05.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, 26 Oct 2010 22:07:37 -0000 This is a cryptographically signed message in MIME format. --------------ms040907010308030600020302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/26/10 3:47 PM, Richard L. Barnes wrote: >>> S4.3: It seems like there should be some discussion here about >>> how entities that create JIDs can help mitigate issues of >>> confusability. For example, the existence of confusable >>> characters in the domainpart is mitigated by proper registry >>> policies (which I presume could be incorporated by reference to >>> some IDNA documents). Localparts and resourceparts are not >>> constrained to be domain names, but they are controlled or at >>> least approved by a server, so the server can apply similar >>> policies to these parts. >>=20 >> That said, I think draft-ietf-xmpp-address-06 (you reviewed -05)=20 >> includes some text that might address your concern, to wit: >>=20 >> ### ... ### >>=20 >> Does that help? >=20 > That's exactly what I was looking for! Presumably the same=20 > considerations apply to resourceparts, so perhaps just one more > sentence establishing that equivalence would be in order. See the antepenultimate sentence of this adjusted paragraph: ### 1. Because an XMPP service that allows registration of XMPP user accounts (localparts) plays a role similar to that of a registry for DNS domain names, such a service SHOULD establish a policy about the scripts or blocks of characters it will allow in localparts at the service. Such a policy is likely to be informed by the languages and scripts that are used to write registered account names; in particular, to reduce confusion, the service MAY forbid registration of XMPP localparts that contain characters from more than one script and to restrict registrations to characters drawn from a very small number of scripts (e.g., scripts that are well-understood by the administrators of the service). Such policies are also appropriate for XMPP services that allow temporary or permanent registration of XMPP resourceparts, e.g., during resource binding [XMPP] or upon joining an XMPP-based chat room [XEP-0045]. For related considerations in the context of domain name registration, refer to Section 4.3 of [IDNA-PROTO] and Section 3.2 of [IDNA-RATIONALE]. Note well that methods for enforcing such restrictions are out of scope for this document. ### >>> S4.4.1 P2: The observation that only part of an identifier can be >>> authenticated is a good one to make, but there's one subtlety: >>> The remote server is actually authoritative for the localpart and >>> resourcepart of the JID, so the fact that the remote domain has >>> assigned a particular 'from' address effectively authenticates >>> those fields when the domain is authenticated. It might help to >>> note that end-to-end authentication of XMPP stanzas could help >>> mitigate this risk, since it would require the rogue server to >>> generate false credentials in addition to modifying 'from' >>> addresses. >=20 > Any thoughts on this issue? Sorry, I was going to scroll up to that part of the email before hitting send. :) I suggest the following modified text: ### Address forging is difficult in XMPP systems, given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server-to-server authentication (see [XMPP]). However, address forging is possible if: o A poorly implemented server ignores the requirement for stamping the 'from' address. This would enable any entity that authenticated with the server to send stanzas from any localpart@domainpart as long as the domainpart matches the sending domain of the server. o An actively malicious server generates stanzas on behalf of any registered account. Therefore, an entity outside the security perimeter of a particular server cannot reliably distinguish between bare JIDs of the form at that server and thus can authenticate only the domainpart of such JIDs with any level of assurance. This specification does not define methods for discovering or counteracting such poorly implemented or rogue servers. However, the end-to-end authentication or signing of XMPP stanzas could help to mitigate this risk, since it would require the rogue server to generate false credentials in addition to modifying 'from' addresses. ### Hopefully by the time we supersede the address spec, we will have developed a technology for end-to-end signing and encryption of XMPP stanzas, which we can reference from the foregoing paragraph. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040907010308030600020302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NjIyMDkyMlowIwYJKoZIhvcNAQkEMRYEFEtqQlEIWCryQjciHQRpc0oyU2llMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBE92wibNv3Hkpp6cjycU/28xWotkT9dRKIrX3zxRaaNRqLYWxdbGaMOECJ YCyejYjnmriDF19nnLR64g4V5sWXkznkA//3/5BuABfg2Z9VWzpdEAJeyI6CmL609GG/ZOGw Ph9Ewm5iga12ImeNVJtbU+5DtTxkDWSKvqa3QoLMs2aBtUYcmtyL/MQAi9eiBXpW/YQ2g6Sr 8KuBKUS5dLbtMszCIEgZ7g4aZIZAiW32lGQxQBZyr4IomsZSsmWNjdLVCozVI689amMIa8GL KDLhZ18V5wRXOEC9Bvp+jJ3mabX1C0Ao1ZaHeaoPP1tXG9cCXGKZViiIuUEbdFm5oMwlAAAA AAAA --------------ms040907010308030600020302-- From magnusn@gmail.com Tue Oct 26 20:29:26 2010 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 76C0E3A697F; Tue, 26 Oct 2010 20:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227] 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 fVBdf91XxjG7; Tue, 26 Oct 2010 20:29:22 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6FB2D3A6958; Tue, 26 Oct 2010 20:29:21 -0700 (PDT) Received: by iwn40 with SMTP id 40so263965iwn.31 for ; Tue, 26 Oct 2010 20:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=HnZDH0I4lX8rFwX4b6U6eMCuN4DpXKGyN59Ln6Cpx/E=; b=Mz6QnuXOBIwPmYU3Ih4c98pqIcciCVe65hHWHiUGKFR9vqsMdm6vU2+ZRChXjCFpJi 0AWFKsjOR7hqSMq3dV517A5Rut/8OvIlnAb7dwD8FquBhlaoNL8/mC7HQb0buLZ3Pecy M2/nqiVXDnrV/57EacUUUh/nirNiUeUjdkmMg= 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=Kv1rL+VRF5ywxuEr3F3ruK8y6RdjRhoaeJIL2Fbp3M/8JZZvI6wWKPTkL4VVNyZ/x8 g9zSQKnw29mKq08lQhJFbEUSBwnlP11QF9+Wel2mb8Tl9dfOFr7tv8hQLj8rdyXB1HLf gME28osgDMyMZjaGdVX+HggNv50p14sCRUqZo= MIME-Version: 1.0 Received: by 10.231.182.85 with SMTP id cb21mr1479804ibb.49.1288150270015; Tue, 26 Oct 2010 20:31:10 -0700 (PDT) Received: by 10.231.154.72 with HTTP; Tue, 26 Oct 2010 20:31:09 -0700 (PDT) Date: Tue, 26 Oct 2010 20:31:09 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: secdir@ietf.org, iesg@ietf.org, draft-ietf-dnsop-name-server-management-reqs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] Secdir review of draft-ietf-dnsop-name-server-management-reqs-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: Wed, 27 Oct 2010 03:29: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. =A0These 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 requirements on management solutions for name serve= rs. I find this document easy to read and well organized, but have the following security-related suggestions and questions: - Section 3.2.2: When developing requirements for a new management solution, why not require support for DNSSEC? - Section 4.4: "Fine-grained" is not defined. I believe a management solution for name servers always should provide an authorization solution, and would suggest you change the initial sentence of this requirement to say: "The solution MUST be capable of providing an authorization model for any management protocols it introduces to the completed system." - Section 6 (Security Considerations): The first sentence is essentially a tautology: "Any management protocol that meets the criteria discussed in this document needs to support the criteria discussed in Section 4 [in this document] ..." I suggest striking this sentence as those criteria already are mandated anyway. Alternatively, re-formulate to something like: "Any management protocol for which conformance to this document is claimed needs to fully support the criteria discussed in Section 4 ..." -- Magnus From gonzalo.camarillo@ericsson.com Wed Oct 27 05:19:41 2010 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 458A63A684A for ; Wed, 27 Oct 2010 05:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 dbe3jB41-fTC for ; Wed, 27 Oct 2010 05:19:40 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8B3523A67CF for ; Wed, 27 Oct 2010 05:19:35 -0700 (PDT) X-AuditID: c1b4fb39-b7b54ae000003464-da-4cc81944cac2 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.38.13412.44918CC4; Wed, 27 Oct 2010 14:21:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Oct 2010 14:21:23 +0200 Received: from [131.160.126.178] ([131.160.126.178]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Oct 2010 14:21:23 +0200 Message-ID: <4CC81942.3060502@ericsson.com> Date: Wed, 27 Oct 2010 15:21:22 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2010 12:21:23.0696 (UTC) FILETIME=[784A9700:01CB75D1] X-Brightmail-Tracker: AAAAAA== Cc: "secdir@ietf.org" , "gao.yang2@zte.com.cn" , "pkyzivat@cisco.com" , Christer Holmberg , "tim.polk@nist.gov" , "rjsparks@nostrum.com" Subject: Re: [secdir] review of draft-ietf-sipcore-reinvite-06.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, 27 Oct 2010 12:19:41 -0000 Hi Stephen, thanks for your review. My answers inline: On 21/10/2010 5:17 AM, Stephen Kent wrote: > I 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 (draft-ietf-sipcore-reinvite-06.txt) provides > clarification on how to process a re-invite in SIP. The notion of a > re-invite is defined in RFC 3261 (SIP). This document was created to > clarify the description provided in 3261, based on feedback from > implementers. It includes a number of examples designed to clarify. > It is fair to say that this document not only offers clarifications, > but also makes some changes to SIP handling of re-INVITEs. For > example, the document notes that "Section 4.3 specifies new rules for > the handling of target-refresh requests." > > The document makes reference to "properly" authenticated requests in > a couple of places (4.4 & 4.6), but provides no indication of what > constitutes proper authentication. I think it would be appropriate to > include references to whatever SIP security mechanisms are currently > recommended for message/session authentication (as opposed to what > 3261 said 8 years ago). I suggest adding the following text in both places: "(see Section 26.2 of RFC 3261)". http://tools.ietf.org/html/rfc3261#section-26.2 The way user agents authenticate incoming requests has not changed much since RFC 3261 was published. > The document has a trivial Security Considerations section: > > This document does not introduce any new security issue. It just > clarifies how certain transactions should be handled in SIP. > Security issues related to re-INVITEs and UPDATE requests are > discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311]. > > I checked 3261 and I agree that this document provides a decent > review of security for SIP in general, but it makes no specific > mention of UPDATE or (re)INVITE messages and attendant security > concerns. RFC 3311 has an almost trivial Security Considerations > section, but at least it does specifically refer to UPDATE and > (re-)Invite messages, briefly, and the need for authentication. I > think it would be appropriate to add a discussion of how these > clarifications operate in various SIP security contexts, e.g., use of > TLS for point-to-point SIP security or use of S/MIME for end-to-end > SIP security. A statement that the security offered for SIP when the > initial call setup was processed cannot be undermined by a later > re-INVITE or UPDATE would be reassuring (if accompanied by a > rationale for that statement :). > I suggest adding the following text to the Security Considerations Section. Feel free to edit the text if you wish: "In particular, in order not to reduce the security level for a given session, re-INVITEs and UPDATE requests SHOULD be secured in a similar or stronger manner as the initial INVITE request that created the session. For example, if the initial INVITE request was end-to-end integrity protected or encrypted, subsequent re-INVITEs and UPDATE requests should also be so." A discussion on which security mechanisms should be applied in different contexts in outside the scope of this document, IMHO. SIP has been and is being deployed in so different environments that we would need a whole document (or more likely a set of them) to discuss all relevant issues. Thanks, Gonzalo From Sandra.Murphy@cobham.com Wed Oct 27 10:50:56 2010 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 63B4C3A69C8 for ; Wed, 27 Oct 2010 10:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, 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 JulLT0EHDs5a for ; Wed, 27 Oct 2010 10:50:54 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D671A3A68B1 for ; Wed, 27 Oct 2010 10:50:53 -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 o9RHqgY6014802; Wed, 27 Oct 2010 12:52:42 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o9RHqelM027957; Wed, 27 Oct 2010 12:52:42 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.119]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 13:52:40 -0400 Date: Wed, 27 Oct 2010 13:52:35 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Paul Hoffman In-Reply-To: Message-ID: References: <4CC6E2A2.9000309@ieca.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Oct 2010 17:52:40.0931 (UTC) FILETIME=[C00BF330:01CB75FF] Cc: secdir@ietf.org Subject: Re: [secdir] Security Directorate lunch in IETF79 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, 27 Oct 2010 17:50:56 -0000 On Tue, 26 Oct 2010, Paul Hoffman wrote: > At 10:16 AM -0400 10/26/10, Sean Turner wrote: >> As usual, we're planning to have the Security Directorate lunch on Tuesday. The room is still TBD. >> >> If there's anything special you'd like to discuss, please drop an email to Tim or me. > > What will the lunch scene for the meeting be? We have heard nothing from the Beijing hosts about where to-go food can be found in the hotel or short walking distance. The web site http://www.ietf79.cn/ has a "22 Oct. Updates" link to a list of restaurants in the hotel itself plus info about a "quick buffet working lunch" (100RMB), and a link to a map with other restaurants identified http://www.ietf79.cn/uploadfile/2010/1022/20101022095203464.pdf. Did you mean more than that? --Sandy > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From phoffman@imc.org Wed Oct 27 11:57:46 2010 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 1AB263A686C for ; Wed, 27 Oct 2010 11:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 wQNm8AQnnuwW for ; Wed, 27 Oct 2010 11:57:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9E4963A67F9 for ; Wed, 27 Oct 2010 11:57:44 -0700 (PDT) Received: from [10.20.30.151] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9RIxNNr069266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 11:59:31 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CC6E2A2.9000309@ieca.com> Date: Wed, 27 Oct 2010 11:59:21 -0700 To: Sandra Murphy From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: secdir@ietf.org Subject: Re: [secdir] Security Directorate lunch in IETF79 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, 27 Oct 2010 18:57:46 -0000 At 1:52 PM -0400 10/27/10, Sandra Murphy wrote: >On Tue, 26 Oct 2010, Paul Hoffman wrote: > >>At 10:16 AM -0400 10/26/10, Sean Turner wrote: >>>As usual, we're planning to have the Security Directorate lunch on Tuesday. The room is still TBD. >>> >>>If there's anything special you'd like to discuss, please drop an email to Tim or me. >> >>What will the lunch scene for the meeting be? We have heard nothing from the Beijing hosts about where to-go food can be found in the hotel or short walking distance. > >The web site http://www.ietf79.cn/ has a "22 Oct. Updates" link to a list of restaurants in the hotel itself plus info about a "quick buffet working lunch" (100RMB), and a link to a map with other restaurants identified http://www.ietf79.cn/uploadfile/2010/1022/20101022095203464.pdf. > >Did you mean more than that? No, that's exactly what I wanted. I'm glad to see the host is working on this! It looks like there are plenty of mini-markets nearby for fast food that will be well under 100 RMB ($15). From gwz@net-zen.net Wed Oct 27 20:19:17 2010 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 9D9123A67DF for ; Wed, 27 Oct 2010 20:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, 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 1oAFZ19jYUa9 for ; Wed, 27 Oct 2010 20:19:16 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id D3EE23A67FE for ; Wed, 27 Oct 2010 20:19:15 -0700 (PDT) Received: (qmail 29612 invoked from network); 28 Oct 2010 03:21:06 -0000 Received: from unknown (124.122.134.245) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 28 Oct 2010 03:21:04 -0000 From: "Glen Zorn" To: "'Paul Hoffman'" , "'Sandra Murphy'" References: <4CC6E2A2.9000309@ieca.com> In-Reply-To: Date: Thu, 28 Oct 2010 10:20:34 +0700 Organization: Network Zen Message-ID: <000001cb764f$17c791c0$4756b540$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Act2CRsAryLU0/JrR6iJqlWM9MSzBgARacng Content-Language: en-us Cc: secdir@ietf.org Subject: Re: [secdir] Security Directorate lunch in IETF79 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, 28 Oct 2010 03:19:17 -0000 > At 1:52 PM -0400 10/27/10, Sandra Murphy wrote: > >On Tue, 26 Oct 2010, Paul Hoffman wrote: > > > >>At 10:16 AM -0400 10/26/10, Sean Turner wrote: > >>>As usual, we're planning to have the Security Directorate lunch on > Tuesday. The room is still TBD. > >>> > >>>If there's anything special you'd like to discuss, please drop an > email to Tim or me. > >> > >>What will the lunch scene for the meeting be? We have heard nothing > from the Beijing hosts about where to-go food can be found in the hotel > or short walking distance. > > > >The web site http://www.ietf79.cn/ has a "22 Oct. Updates" link to a > list of restaurants in the hotel itself plus info about a "quick buffet > working lunch" (100RMB), and a link to a map with other restaurants > identified > http://www.ietf79.cn/uploadfile/2010/1022/20101022095203464.pdf. > > > >Did you mean more than that? > > No, that's exactly what I wanted. I'm glad to see the host is working on > this! It looks like there are plenty of mini-markets nearby for fast > food that will be well under 100 RMB ($15). $15??? Wow. How expensive has China become? If you can't eat well for < $5/day in Bangkok you're not trying... > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From yaronf.ietf@gmail.com Thu Oct 28 03:26:36 2010 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 8EB563A6875; Thu, 28 Oct 2010 03:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8fDlKj1Y0MFP; Thu, 28 Oct 2010 03:26:34 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EC1643A67E1; Thu, 28 Oct 2010 03:26:33 -0700 (PDT) Received: by bwz12 with SMTP id 12so1474340bwz.31 for ; Thu, 28 Oct 2010 03:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=U/0HvGfyJAPU5RVY1z0KFi+0FdsGuFsMxdX7DF8vvXs=; b=eWc/2YBXQmcGxWp9Z7irT1YK/9DF1fmKKUoiL2hryLKgUVopXybqJ0jmdjsmpU/PtB 57Ca9Zwwir3kZPdLov3ti0Z7IV+ebh1BbdVUEno3RQiezyKyXpacUJghq3m40aaF3i7q /GapiCXPDm828ZMV5GohsXIbSu9MHhq7V9pp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=VT6a0gfEj+llTV7dhLiGdv4y+vFygKgJmO/sQ/+hXX6Cj3QvnET0HqblrUFXz2FqSs 3Ym7bx9qAv4crN23p0v2en2RGtmvF4X/xjkWZcNp08Ttt0fnBXvXNrwEsnOMMBbp9bj1 WGSw6EfiAwZxlKgt5+9rTxW0LzaIMO1GX7l5Q= Received: by 10.204.120.80 with SMTP id c16mr2020081bkr.162.1288261704809; Thu, 28 Oct 2010 03:28:24 -0700 (PDT) Received: from [192.168.0.102] ([109.253.148.3]) by mx.google.com with ESMTPS id p34sm7851105bkf.15.2010.10.28.03.28.18 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Oct 2010 03:28:23 -0700 (PDT) Message-ID: <4CC9503D.2000809@gmail.com> Date: Thu, 28 Oct 2010 12:28:13 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17 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, 28 Oct 2010 10:26: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. The document updates RFC 3920, which is the definition of the core XMPP real-time messaging protocol. It should be noted the instant messaging and presence are layered on top of this protocol, and specified separately. General The document is initially intimidating, because of its length. But it is extremely well written (for which I would like to thank the editor) and well organized. So overall, a good read. I have not found anything that I consider a glaring security hole. But this is a layered security architecture (application layer == XMPP core == SASL == TLS) which is not easy to do right. Hence the large number of comments and questions below. I also appreciate the open discussion of the existing implementations and their security issues (e.g. "server dialback", shiver). I hope this document results in a security improvement in real deployments. Detailed Comments Note: these comments are based on rev -17 of the draft. This only matters as far as section numbers, with the only security-relevant change in -18 being a useful note on end-to-end protection. - 1.3: Implementation note: I suggest adding something like "Solutions specified in this document offer a significantly better level of security." - 3.3: why do we not recommend to use TLS (stateless) session resumption for reconnection? - 4.2.5 the access control rule at the bottom of this section makes sense. Why why does it explicitly not apply to elements other than XML stanzas? Are there cases where you negotiate TLS with someone other than the server? You can even imagine weird tunneling attacks using this "feature". - 4.2.5: "other than itself" - am I really allowed to send "message" stanzas from one resource of a JID to another resource of the same JID, before feature negotiation and before TLS negotiation? - 4.2.6: why do we even allow non-SASL protected server-to-server communication? - 4.3: How is TLS negotiated for the additional streams? How is it bound to the SASL negotiation that (apparently) only takes place once? - 4.4: this section appears to tie the two streams in the opposite directions together - when you close one you expect the other guy to close the other ASAP. But what is the behavior for "multiple streams over multiple connections" (Sec. 4.3)? - 4.4: what about orderly tear-down of the TLS association ("closure alert")? - 4.8.3.12: does not-authorized only refer to stream-level, rather than stanza-level errors? Are there cases when I am authorized to send some stanza types but not others? - 4.8.3.14 remote-connection-failed has dubious security benefit (why tell the world that your RADIUS server is down), compared to reusing internal-error. - 4.8.3.16: shouldn't we say that "reset" (when the stream is encrypted) also applies to the higher layers, i.e. encryption and authentication should be performed again? - 4.8.3.18: what are the security implications of a "redirect"? Should the client apply the same policy, e.g. for using TLS, as for the original server? Which "to" identity to use? Can redirection occur before the recipient is even authenticated? - 4.9: Don't we resend the "stream" header again after completing the TLS negotiation (Sec. 4.2.3). - 5.3.5: the text mentions that client certificates are "sufficiently rare", which is a pity because they do make sense for server-to-server interaction. So I suggest to promote renegotiation from OPTIONAL to RECOMMENDED. - 5.3.6: extensions may be out of scope. But I think we need to include a few words re: the TLS version, at least to prohibit SSL 3.0. - 5.4.1: don't you have to declare version >= 1.0 if you simply support this draft? Same question in 6.4.1. - 5.4.3.1: why is the initiator required to present a certificate "So that mutual authentication will be possible"? There are many other ways of ensuring mutual auth. I suggest to reword as "mutual certificate authentication". - Global replace TLS "cipher" -> "ciphersuite". - 5.4.3.1, bullet 5: actually, based on the "from" attribute that the receiving entity has just sent. - 5.4.3.3: where do we say that both sides must validate the "to" and "from" identities in view of the identities presented at the TLS layer (if any)? - 6.3.2: do you restart the stream twice, once after TLS and once after SASL?? - 6.3.3: shouldn't we simply "MUST NOT" the PLAIN mechanism? - 6.3.7: and what is the identity used for server-to-server auth? Also, it is very uncommon to consider the password as part of the identity. - 6.4.4: isn't it inconsistent that SASL aborts are converted into XMPP failures, but TLS failures are not? - 7.7.2.2: the preferred option #1, while reasonable in itself, does not allow the client to determine its own policy (whether it wants multiple sessions from multiple devices or not). - 8.1.1.2: any validated domain -> any validated subdomain. - 8.3.1, rule #2: if the error is a result of something gone bad with the addresses, then simply swapping "to" and "from" may not be appropriate, and may even be a security issue. - Same, rule #6, the recipient MUST NOT include the original XML if it's not well formed, right? - 8.3.2: MUST NOT... be presented to the human user - this is impossible to enforce, and most likely will not be followed. Moreover, there's a reason why we include a language tag. I suggest to tone it down a bit. - 8.3.3.11: what are "improper credentials"? It sounds like we are not differentiating the conditions of authentication failure vs. authorization failure. - 8.3.3.14: the "security note" doesn't makes sense to me - no matter what error code is returned, the sender has gained information that we don't want to provide. The note should say something along the lines of: such services must not be available to entities that cannot be trusted with knowing the status of an arbitrary recipient. See also 8.3.3.20. - 8.3.3.15: Are there no security implications to redirection at the stanza level? - 8.3.3.18: The "wait" error type might not be appropriate for some situations, e.g. authentication issues. - 8.3.3.21: do you explain anywhere what is the difference between "prior registration" and "prior subscription"? - 9.1.1, step 7: this is utterly trivial, but please mention that the new "stream" element is sent over TLS. - 9.1.5: as I noted in Sec. 4.4, the TLS connection needs to be closed as well. - 10.2: "try many different resources", I suppose it is typically fewer than 10 per JID, which does not make the attack uninteresting. - 10.4.2: if the protocol supports routing, shouldn't we mention that there are cases where the IQ stanza will be forwarded to another server, not the one mentioned in the "To" header? And what about loop prevention? - 10.5.3.3: this is a strange rule. Does it mean that if I'm using a desktop (/desktop) and a mobile (/mobile), and I'm connected to the desktop, I cannot have messages targeted at my mobile be deferred (and stored somewhere) until I connect from that device? - 13.4: "for the ensuring" -> "for ensuring" (or: to ensure). - 13.4: the security note is confusing, because it is unclear whether it has any normative status. Otherwise, it is almost trivial: of course you can provide these guarantees by different means. - 13.4: the cipher suites are not just "nun-null". They MUST provide both confidentiality and integrity. - 13.6: the out-of-band trust chain rule may be practical for server-to-server connections, but probably not for large client deployments and when certificates are sometimes rolled over. - 13.7: terminology: "mutual authentication" describes authentication with client certs, just as much as it describes the server presenting a cert and the client authenticating with SASL. This also applies to 5.4.3. - 13.7.1.1: The word "issuer" is ambiguous. It usually refers to a person/organization, but here you use it to refer to the certificate itself. How about replacing the heading of the second list by: "the following rules apply to issuer certificates, used to sign XMPP end-entity certificates"? - 13.7.1.1: it's strange to specify the hash algorithm, but not the signature algorithm (RSA-512 anyone?) - 13.7.1.1: what are "access certificates"? Neither 5280 nor Google can help... And how can an issuer cert NOT be marked with the CA bit? - 13.7.1.1: and most important, is the "relying party" (e.g. the client) required to check all these rules and fail validation if any of them is not met? - 13.7.1.2.2: enabling entity -> enabling entities. - 13.7.1.4: "conjuction" misspelled. - 13.7.2: "An implementation MUST enable a human user to view information about the certification path." I'm afraid this is security theater, because 99.5% of your target population cannot understand this information. - 13.7.2.2.1: "MUST either validate" - incomplete sentence (and actually, at a sensitive point in the text). - 13.7.2.2.1, subcase #3: please mention that some servers will simply fail validation at this point, subject to their policy. I.e., some might insist on correct client certs. - 13.7.2.3: "periodically query OCSP" - is there any guidance about the period? Is a recommended period specified in the cert or communicated by the OCSP responder? - 13.7.2: a silly question, but anyway: where do you say that the client's cert is correlated with the client's JID, as it appears in the From line (when setting up the original stream and/or when setting the stream anew after TLS negotiation)? And vice versa, for the server cert and the client's To header. - 13.8: I suggest to add (here or elsewhere): "All password-based mechanisms are susceptible to password guessing attacks, and therefore the authenticator MUST implement common rate-limiting mitigations." - 13.8: "For both confidentiality and authentication with passwords" - here you don't specify a TLS ciphersuite. - 13.8: the note kind of implies that PLAIN is preferable to DIGEST-MD5, which is clearly not the case. - 13.9.4: why is SASL-PLAIN singled out here? Other mechanisms are susceptible to off-line password guessing when used without TLS confidentiality, which is not a trivial attack but still a significant risk. - 13.11: all three examples of "service unavailable" can be ruled out on an operational server. Are there no better examples? - 15: The sasl-whitespace "feature" is not really a feature, because you'd fail any interoperability if you send whitespace during the SASL phase, right? Similarly tls-whitespace. - 15: if we insist on PLAIN, I would expect a security-mti-auth-order feature, where the proposals are ordered right (i.e. with PLAIN at the end). - 15: why is confidentiality-only a MUST? Is it widely deployed? Is it required for backward compatibility? By the way, please expand the acronym MTI somewhere. - 15: and hey, there's no feature defined for TLS+SCRAM+? Isn't this the one we want/expect to be deployed? - 15: stanza-* features - if you have an XML schema, can't you just say that conformance to the schema is REQUIRED and eliminate all this stuff? Given that these are MUSTs, not SHOULDs, a formal specification is so much easier to validate. This does *not* contradict the fact that runtime validation is optional. - 15: I would expect one or a few features around validation of identities at the various layers, since we're spending much of the document on this issue. "tls-certs" is an important piece of that, but not the whole thing. From Sandra.Murphy@cobham.com Thu Oct 28 10:25:40 2010 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 BD85F3A68EB; Thu, 28 Oct 2010 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.093 X-Spam-Level: X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 GRrpp2-homoq; Thu, 28 Oct 2010 10:25:39 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B95BE3A6857; Thu, 28 Oct 2010 10:25:38 -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 o9SHRU5l031690; Thu, 28 Oct 2010 12:27:30 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o9SHRUgD005720; Thu, 28 Oct 2010 12:27:30 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.119]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Oct 2010 13:27:29 -0400 Date: Thu, 28 Oct 2010 13:27:29 -0400 (Eastern Daylight Time) From: Sandra Murphy To: secdir@ietf.org, tony.li@tony.li, iesg@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Oct 2010 17:27:30.0005 (UTC) FILETIME=[65E0B050:01CB76C5] Subject: [secdir] comments on draft-irtf-rrg-recommendation-14 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, 28 Oct 2010 17:25:40 -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 unfortunately was off-net for a few days and got to this assignment rather late. The document is long and covers a broad swath of material and I was not able to cover it deeply. This document is a product of the rrg IRTF working group. It summarizes 15 different proposals for a new routing and addressing architecture for the Internet, with short summaries, critiques and rebuttals for each, and gives a final recommendation to the IETF for future direction. With the breadth of scope of the document, there is no way for me to review each proposal's documents for security considerations. The security considerations of *this* document itself is quite terse: 20. Security Considerations All solutions are required to provide security that is at least as strong as the existing Internet routing and addressing architecture. Given the widely reported weakness of the "existing Internet routing and addressing architecture", this is a low bar indeed. There are attempts in progress to attempt to improve the security of the Internet routing and addressing architecture. I do not know what to suggest if these improvements leave the Internet with stronger security than is provided by these proposals. The summaries of the different proposals devote little attention to the infrastructure security ramifications of the proposal. Given the stated goal, perhaps no attention was necessary. Many of these proposals include an encapsulation system, presenting the expected difficulties with end system authentication, filtering systems at boundaries, etc. Some proposals addressed these concerns. I am not sure if the security considerations section meant that the proposals were required to avoid weakening the end-host security protections already provided (ipsec, NAT, whatever). The rrg wg came to consensus that a fundamental architectural feature is a separation of locator and identifier for any node. Many of the discussed alternatives include a mapping system that produce a locator for a given destination identifier. The mapping system would seem to be a very likely point of vulnerability, permitting traffic redirection for data exposure or blackholing, etc. Many proposals suggest a hierarchic architecture of the mapping system for scaling purposes. I would presume that an authorization scheme for the mapping system would be essential, and that the hierarchy would be an important aspect of that scheme. Of course, I can't tell much at this level of detail about how and if each proposals addresses this. (One of the recommendations suggests communicating mapping info through bgp - I can not say at this point whether the SIDR suggestions for improving bgp security would be applicable.) --Sandy Nits: PMTUD Path Maximum Transmission Unit Discovery: The process or mechanism that determines the largest packet that can be sent between a given source and destination with being either i) fragmented (IPv4 only), or ii) discarded (if not fragmentable) because it is too large to be sent down one link in the path from the source to the destination. It should say "*without* being either", right? A long sentence so I may have lost my place. Several of the comments start using terms that are part of the wg deliberations, I'm sure. But it makes reading the discussions and critiques obtuse. In particular, "Core-Edge Separation" and "Core-Edge Elimination" seems to a well understood concept in the wg. It needs to be defined somewhere. A web search found references in some conference papers and in rrg mailing lists. From stephen.farrell@cs.tcd.ie Thu Oct 28 14:20:46 2010 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 8E1F43A695C; Thu, 28 Oct 2010 14:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 VqWjGmk+6VnU; Thu, 28 Oct 2010 14:20:45 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id CE3E63A6860; Thu, 28 Oct 2010 14:20:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3ECB520E002; Thu, 28 Oct 2010 22:22:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1288300957; bh=G5Hud3yy9V51MO R0NQa9Rk3nqD0ZzcDqrLp3/XLWtmk=; b=3ww4seaiSO7zZmpb/Sv9wGg3r7sDsJ u4zbJZaYyPsWV5zNsCHgBEWLMGMg9a4oaEGOBIeR+OxhLXRbkOSluYTJFLQGWVXy XNNkpfpqJ68ro71DtVjS1SuMvVcSlKT5btc9p5Ut7NN2H1BBQx0MD9GBm766nR1R fpPI86ANJimFyd3PNCnmxarklhG+/D5BRrfYkyEKL5uDrmjH2jkWskSIHQy/Nw/+ 9JvktD/D2bjkHj3vEsPUklBpojpN7PMmZRCFywlxssjdVr8yX15QrViepYj8M5oo Id2mQFFKLrUldj7W7BRP0YS9CUX+yNg01/sNmV+wX2p/LLnU8nRVvNWQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id GlGEmJ6YXI-f; Thu, 28 Oct 2010 22:22:37 +0100 (IST) Received: from [192.168.225.32] (hnc91.internetdsl.tpnet.pl [79.188.80.91]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F35C420E001; Thu, 28 Oct 2010 22:22:33 +0100 (IST) Message-ID: <4CC9E98D.1090804@cs.tcd.ie> Date: Thu, 28 Oct 2010 22:22:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tony.li@tony.li, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] comments on draft-irtf-rrg-recommendation-14 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, 28 Oct 2010 21:20:46 -0000 Not really for Sandy, more for the ADs/Sam W: Why are we doing a secdir review of an IRTF draft? That's not required by any process I know of (speaking as an IRTF RG chair). Unless maybe the RRG asked for it, in which case, ignore this. Otherwise we should try filter the assignments for irtf drafts since this is not the 1st time this has happened. (Last time, I spotted it before someone did a review.) Ta, Stephen. On 28/10/10 18:27, Sandra Murphy 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 unfortunately was off-net for a few days and got to this assignment > rather late. The document is long and covers a broad swath of material > and I was not able to cover it deeply. > > This document is a product of the rrg IRTF working group. It summarizes > 15 different proposals for a new routing and addressing architecture for > the Internet, with short summaries, critiques and rebuttals for each, > and gives a final recommendation to the IETF for future direction. > > With the breadth of scope of the document, there is no way for me to > review each proposal's documents for security considerations. > > The security considerations of *this* document itself is quite terse: > > 20. Security Considerations > > All solutions are required to provide security that is at least as > strong as the existing Internet routing and addressing architecture. > > Given the widely reported weakness of the "existing Internet routing and > addressing architecture", this is a low bar indeed. There are attempts > in progress to attempt to improve the security of the Internet routing > and addressing architecture. I do not know what to suggest if these > improvements leave the Internet with stronger security than is provided > by these proposals. > > The summaries of the different proposals devote little attention to the > infrastructure security ramifications of the proposal. Given the stated > goal, perhaps no attention was necessary. > > Many of these proposals include an encapsulation system, presenting the > expected difficulties with end system authentication, filtering systems > at boundaries, etc. Some proposals addressed these concerns. I am not > sure if the security considerations section meant that the proposals > were required to avoid weakening the end-host security protections > already provided (ipsec, NAT, whatever). > > The rrg wg came to consensus that a fundamental architectural feature is > a separation of locator and identifier for any node. Many of the > discussed alternatives include a mapping system that produce a locator > for a given destination identifier. > > The mapping system would seem to be a very likely point of > vulnerability, permitting traffic redirection for data exposure or > blackholing, etc. Many proposals suggest a hierarchic architecture of > the mapping system for scaling purposes. I would presume that an > authorization scheme for the mapping system would be essential, and that > the hierarchy would be an important aspect of that scheme. Of course, I > can't tell much at this level of detail about how and if each proposals > addresses this. (One of the recommendations suggests communicating > mapping info through bgp - I can not say at this point whether the SIDR > suggestions for improving bgp security would be applicable.) > > --Sandy > > Nits: > > PMTUD Path Maximum Transmission Unit Discovery: The process or > mechanism that determines the largest packet that can be sent > between a given source and destination with being either i) > fragmented (IPv4 only), or ii) discarded (if not fragmentable) > because it is too large to be sent down one link in the path from > the source to the destination. > > It should say "*without* being either", right? A long sentence so I may > have lost my place. > > > Several of the comments start using terms that are part of the wg > deliberations, I'm sure. But it makes reading the discussions and > critiques obtuse. In particular, "Core-Edge Separation" and "Core-Edge > Elimination" seems to a well understood concept in the wg. It needs to > be defined somewhere. A web search found references in some conference > papers and in rrg mailing lists. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From william.polk@nist.gov Thu Oct 28 18:14:14 2010 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 373AF3A69D5; Thu, 28 Oct 2010 18:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 Cj3-IulagHgk; Thu, 28 Oct 2010 18:14:12 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 462E93A67D0; Thu, 28 Oct 2010 18:14:12 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o9T1FrEL004256; Thu, 28 Oct 2010 21:15:53 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 28 Oct 2010 21:15:38 -0400 From: "Polk, William T." To: Stephen Farrell , Sandra Murphy Date: Thu, 28 Oct 2010 21:15:49 -0400 Thread-Topic: [secdir] comments on draft-irtf-rrg-recommendation-14 Thread-Index: Act25k3YCKHusFNxRqWBbdaGr4gz8wAIIRV+ Message-ID: In-Reply-To: <4CC9E98D.1090804@cs.tcd.ie> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8EF98851F4B7wpolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Cc: "tony.li@tony.li" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] comments on draft-irtf-rrg-recommendation-14 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, 29 Oct 2010 01:14:14 -0000 --_000_C8EF98851F4B7wpolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephen, We have not changed the process. There was a tools error - the draft ended= up on the agenda as an informational RFC on the IETF stream. I actually p= ointed this out to the secretariat so that the document was moved to the ri= ght part of the agenda, but I did not notice that this document got assigne= d for a secdir review. Sandy was diligent and did the review before the te= lechat. We need to figure out why the tools error is occurring and get this correct= ed. Adding a manual step for irtf stream filtering would be a real burden = for Sam. Thanks, Tim On 10/28/10 5:22 PM, "Stephen Farrell" wrote: Not really for Sandy, more for the ADs/Sam W: Why are we doing a secdir review of an IRTF draft? That's not required by any process I know of (speaking as an IRTF RG chair). Unless maybe the RRG asked for it, in which case, ignore this. Otherwise we should try filter the assignments for irtf drafts since this is not the 1st time this has happened. (Last time, I spotted it before someone did a review.) Ta, Stephen. On 28/10/10 18:27, Sandra Murphy 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 unfortunately was off-net for a few days and got to this assignment > rather late. The document is long and covers a broad swath of material > and I was not able to cover it deeply. > > This document is a product of the rrg IRTF working group. It summarizes > 15 different proposals for a new routing and addressing architecture for > the Internet, with short summaries, critiques and rebuttals for each, > and gives a final recommendation to the IETF for future direction. > > With the breadth of scope of the document, there is no way for me to > review each proposal's documents for security considerations. > > The security considerations of *this* document itself is quite terse: > > 20. Security Considerations > > All solutions are required to provide security that is at least as > strong as the existing Internet routing and addressing architecture. > > Given the widely reported weakness of the "existing Internet routing and > addressing architecture", this is a low bar indeed. There are attempts > in progress to attempt to improve the security of the Internet routing > and addressing architecture. I do not know what to suggest if these > improvements leave the Internet with stronger security than is provided > by these proposals. > > The summaries of the different proposals devote little attention to the > infrastructure security ramifications of the proposal. Given the stated > goal, perhaps no attention was necessary. > > Many of these proposals include an encapsulation system, presenting the > expected difficulties with end system authentication, filtering systems > at boundaries, etc. Some proposals addressed these concerns. I am not > sure if the security considerations section meant that the proposals > were required to avoid weakening the end-host security protections > already provided (ipsec, NAT, whatever). > > The rrg wg came to consensus that a fundamental architectural feature is > a separation of locator and identifier for any node. Many of the > discussed alternatives include a mapping system that produce a locator > for a given destination identifier. > > The mapping system would seem to be a very likely point of > vulnerability, permitting traffic redirection for data exposure or > blackholing, etc. Many proposals suggest a hierarchic architecture of > the mapping system for scaling purposes. I would presume that an > authorization scheme for the mapping system would be essential, and that > the hierarchy would be an important aspect of that scheme. Of course, I > can't tell much at this level of detail about how and if each proposals > addresses this. (One of the recommendations suggests communicating > mapping info through bgp - I can not say at this point whether the SIDR > suggestions for improving bgp security would be applicable.) > > --Sandy > > Nits: > > PMTUD Path Maximum Transmission Unit Discovery: The process or > mechanism that determines the largest packet that can be sent > between a given source and destination with being either i) > fragmented (IPv4 only), or ii) discarded (if not fragmentable) > because it is too large to be sent down one link in the path from > the source to the destination. > > It should say "*without* being either", right? A long sentence so I may > have lost my place. > > > Several of the comments start using terms that are part of the wg > deliberations, I'm sure. But it makes reading the discussions and > critiques obtuse. In particular, "Core-Edge Separation" and "Core-Edge > Elimination" seems to a well understood concept in the wg. It needs to > be defined somewhere. A web search found references in some conference > papers and in rrg mailing lists. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > --_000_C8EF98851F4B7wpolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [secdir] comments on draft-irtf-rrg-recommendation-14 Stephen,

We have not changed the process.  There was a tools error - the draft = ended up on the agenda as an informational RFC on the IETF stream.  I = actually pointed this out to the secretariat so that the document was moved= to the right part of the agenda, but I did not notice that this document g= ot assigned for a secdir review.  Sandy was diligent and did the revie= w before the telechat.

We need to figure out why the tools error is occurring and get this correct= ed.  Adding a manual step for irtf stream filtering would be a real bu= rden for Sam.

Thanks,

Tim


On 10/28/10 5:22 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:



Not really for Sandy, more for the ADs/Sam W:

Why are we doing a secdir review of an IRTF draft? That's
not required by any process I know of (speaking as an IRTF
RG chair).

Unless maybe the RRG asked for it, in which case, ignore
this.

Otherwise we should try filter the assignments for
irtf drafts since this is not the 1st time this has
happened. (Last time, I spotted it before someone did a
review.)

Ta,
Stephen.

On 28/10/10 18:27, Sandra Murphy wrote:
>
> I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IES= G.
> These comments were written primarily for the benefit of the security<= BR> > area directors.  Document editors and WG chairs should treat thes= e
> comments just like any other last call comments.
>
> I unfortunately was off-net for a few days and got to this assignment<= BR> > rather late.  The document is long and covers a broad swath of ma= terial
> and I was not able to cover it deeply.
>
> This document is a product of the rrg IRTF working group.  It sum= marizes
> 15 different proposals for a new routing and addressing architecture f= or
> the Internet, with short summaries, critiques and rebuttals for each,<= BR> > and gives a final recommendation to the IETF for future direction.
>
> With the breadth of scope of the document, there is no way for me to > review each proposal's documents for security considerations.
>
> The security considerations of *this* document itself is quite terse:<= BR> >
> 20. Security Considerations
>
>    All solutions are required to provide security that = is at least as
>    strong as the existing Internet routing and addressi= ng architecture.
>
> Given the widely reported weakness of the "existing Internet rout= ing and
> addressing architecture", this is a low bar indeed.  There a= re attempts
> in progress to attempt to improve the security of the Internet routing=
> and addressing architecture.  I do not know what to suggest if th= ese
> improvements leave the Internet with stronger security than is provide= d
> by these proposals.
>
> The summaries of the different proposals devote little attention to th= e
> infrastructure security ramifications of the proposal.  Given the= stated
> goal, perhaps no attention was necessary.
>
> Many of these proposals include an encapsulation system, presenting th= e
> expected difficulties with end system authentication, filtering system= s
> at boundaries, etc.  Some proposals addressed these concerns. &nb= sp;I am not
> sure if the security considerations section meant that the proposals > were required to avoid weakening the end-host security protections
> already provided (ipsec, NAT, whatever).
>
> The rrg wg came to consensus that a fundamental architectural feature = is
> a separation of locator and identifier for any node.  Many of the=
> discussed alternatives include a mapping system that produce a locator=
> for a given destination identifier.
>
> The mapping system would seem to be a very likely point of
> vulnerability, permitting traffic redirection for data exposure or
> blackholing, etc. Many proposals suggest a hierarchic architecture of<= BR> > the mapping system for scaling purposes.  I would presume that an=
> authorization scheme for the mapping system would be essential, and th= at
> the hierarchy would be an important aspect of that scheme.  Of co= urse, I
> can't tell much at this level of detail about how and if each proposal= s
> addresses this.  (One of the recommendations suggests communicati= ng
> mapping info through bgp - I can not say at this point whether the SID= R
> suggestions for improving bgp security would be applicable.)
>
> --Sandy
>
> Nits:
>
>    PMTUD  Path Maximum Transmission Unit Discovery= : The process or
>       mechanism that determines the larg= est packet that can be sent
>       between a given source and destina= tion with being either i)
>       fragmented (IPv4 only), or ii) dis= carded (if not fragmentable)
>       because it is too large to be sent= down one link in the path from
>       the source to the destination.
>
> It should say "*without* being either", right?  A long = sentence so I may
> have lost my place.
>
>
> Several of the comments start using terms that are part of the wg
> deliberations, I'm sure.  But it makes reading the discussions an= d
> critiques obtuse.  In particular, "Core-Edge Separation"= ; and "Core-Edge
> Elimination" seems to a well understood concept in the wg.  = It needs to
> be defined somewhere.  A web search found references in some conf= erence
> papers and in rrg mailing lists.
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.i= etf.org/mailman/listinfo/secdir
>

--_000_C8EF98851F4B7wpolknistgov_-- From yaronf.ietf@gmail.com Fri Oct 29 00:45:08 2010 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 138773A6A20; Fri, 29 Oct 2010 00:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak33X1kCx+ha; Fri, 29 Oct 2010 00:45:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7E1613A6A1E; Fri, 29 Oct 2010 00:45:05 -0700 (PDT) Received: by wyb28 with SMTP id 28so2782627wyb.31 for ; Fri, 29 Oct 2010 00:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ee5A7RDh3NHt5FjaofZVxZjZkFZYf/NmYr/d4TO/1nU=; b=GxxTwiDNF4DqcyEiLIOeUDR0rxk0GwJ8CGp0OeuoP4Kp194QDbc7nkeXF7kLqBYTaa 5eEfVJb3SEUebQFQKMZivZ8lEBPta+TK8uEIYKDkwLzg1JhE2saUVLioqfXwTqzGb7lP mxdrm9eVPbL93PekSewdJCGZ1N2JLAHEuhvlM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KncPMx/DiRqC91q/9R0XRv3tR/60Rw+GtM/ZLZcf3k8Xcw8QO1XS//LU/tJi2DQEr8 Su0tUxptgBmKPFQCzYdRChyzrDVIFXqpQJMtbYgQ7LTiDcL5NRdQoSVtT5lDc5SF/Zzu M7hNttTZQz1gOJH65oo6C+W6xjXdZxl2/wXKk= Received: by 10.227.127.79 with SMTP id f15mr3482005wbs.93.1288338418841; Fri, 29 Oct 2010 00:46:58 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-22-84.red.bezeqint.net [79.179.22.84]) by mx.google.com with ESMTPS id a17sm1776806wbe.12.2010.10.29.00.46.55 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 00:46:56 -0700 (PDT) Message-ID: <4CCA7BED.1020907@gmail.com> Date: Fri, 29 Oct 2010 09:46:53 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <4CC9503D.2000809@gmail.com> <4CCA470B.20601@stpeter.im> In-Reply-To: <4CCA470B.20601@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17 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, 29 Oct 2010 07:45:08 -0000 Hi Peter, On 10/29/2010 06:01 AM, Peter Saint-Andre wrote: > Thanks for your careful and thorough review. To maintain forward > momentum, this is Part 1 of my reply, up through the end of Section 4. I > shall endeavor to reply regarding the remainder of your review in the > next 24-48 hours. > Thanks a lot for using my comments and misunderstandings to improve the document. I have removed pieces of this mail where I fully accept your response/changes. >> - 4.3: How is TLS negotiated for the additional streams? > > Each stream is separately secured. > >> How is it bound >> to the SASL negotiation that (apparently) only takes place once? > > It isn't, because each stream is separately secured (preferably by means > of TLS + SASL). > > I propose that we clarify these matters by modifying the following > paragraphs from Section 4.3 ("Directionality"): > > ### > > 4.3. Directionality > > An XML stream is always unidirectional, by which is meant that XML > stanzas can be sent in only one direction over the stream (either > from the initiating entity to the receiving entity or from the > receiving entity to the initiating entity). > > Depending on the type of session that has been negotiated and the > nature of the entities involved, the entities might use: > > o Two streams over a single TCP connection, where the security > context negotiated for the first stream is applied to the second > stream. This is typical for client-to-server sessions, and a > server MUST allow a client to use the same TCP connection for both > streams. > > o Two streams over two TCP connections, where each stream is > separately secured. In this approach, one TCP connection is used > for the stream in which stanzas are sent from the initiating > entity to the receiving entity, and the other TCP connection is > used for the stream in which stanzas are sent from the receiving > entity to the initiating entity. This is typical for server-to- > server sessions. > > o Multiple streams over two or more TCP connections, where each > stream is separately secured. This approach is sometimes used for > server-to-server communication between two large XMPP service > providers; however, this can make it difficult to maintain > coherence of data received over multiple streams in situations > described under Section 10.1, which is why a server MAY return a > stream error to a remote server that attempts to > negotiate more than one stream (as described under > Section 4.8.3.3). > > This concept of directionality applies only to stanzas and explicitly > does not apply to first-level children of the stream root that are > used to bootstrap or manage the stream (e.g., first-level elements > used for TLS negotiation, SASL negotiation, Server Dialback > [XEP-0220], and Stream Management [XEP-0198]). > > The foregoing considerations imply that while completing STARTTLS > negotiation (Section 5) and SASL negotiation (Section 6) two servers > would use one TCP connection, but after the stream negotiation > process is done that original TCP connection would be used only for > the initiating server to send XML stanzas to the receiving server. > In order for the receiving server to send XML stanzas to the > initiating server, the receiving server would need to reverse the > roles and negotiate an XML stream from the receiving server to the > initiating server over a separate TCP connection. > Perhaps add a final sentence: "This separate TCP connection is then secured using a new round of TLS and/or SASL negotiation." > ### > >> - 4.8.3.18: what are the security implications of a "redirect"? > > Of? Seemingly underspecified. :( > >> Should >> the client apply the same policy, e.g. for using TLS, as for the >> original server? > > Yes. > >> Which "to" identity to use? > > The 'to' address of the initial stream header would still be the DNS > domain name of the XMPP service to which the initiating entity is trying > to connect (see also draft-saintandre-tls-server-id-check). > >> Can redirection occur >> before the recipient is even authenticated? > > Yes. > > I propose that we modify the description as follows: > > The server will not provide service to the initiating entity but is > redirecting traffic to another host under the administrative control > of the same service provider. The XML character data of the other-host/> element returned by the server MUST specify the > alternate hostname or IP address at which to connect, which MUST be a > valid domainpart or a domainpart plus port number (separated by the > ':' character in the form "domainpart:port"). If the domainpart is > the same as the source domain, derived domain, or resolved IP address > to which the initiating entity originally connected (differing only > by the port number), then the initiating entity SHOULD simply attempt > to reconnect at that address. Otherwise, the initiating entity MUST > resolve the hostname specified in the element as > described under Section 3.2. > > I also propose that we add the following paragraph to the end of the > section: > > When negotiating a stream with the host to which it has been > redirected, the initiating entity MUST apply the same policies it > would have applied to the original connection attempt (e.g., a policy > requiring TLS), MUST specify the same 'to' address on the initial > stream header, and MUST verify the identity of the new host using the > same reference identifier(s) it would have used for the original > connection attempt (in accordance with [TLS-CERTS]. Even if > receiving entity returns a error before the > confidentiality and integrity of the stream have been established > (thus introducing the possibility of a denial of service attack), the > fact that the initiating entity needs to verify the identity of the > XMPP service based on the same reference identifiers implies that the > initiating entity will not connect to a malicious entity; however, to > reduce the possibility of a denial of service attack, the receiving > entity SHOULD NOT return a error until after the > stream has been protected (e.g., via TLS). > ... and the sending entity SHOULD maintain a running redirect counter, and give up after a certain number of successive redirects. Also, the mitigation you propose in the last sentence only helps if "An entity MAY have a policy where it only accepts elements from authenticated peers. >> - 4.9: Don't we resend the "stream" header again after completing the >> TLS negotiation (Sec. 4.2.3). > > For sure. I propose that we change this: > > [ ... channel encryption ... ] > > [ ... authentication ... ] > > [ ... resource binding ... ] > > to: > > [ ... stream negotiation ... ] > I'm not sure. Since we start the example with two elements, it would make sense to show the additional (4?) elements further down. Although the "simple" examples would no longer fit a page. Maybe add a "really simple" example with no security? > ### END OF PART 1 ### > > > From yaronf.ietf@gmail.com Fri Oct 29 07:24:42 2010 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 390E33A689D; Fri, 29 Oct 2010 07:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1c+VDa1FcLsR; Fri, 29 Oct 2010 07:24:38 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 47DC13A686D; Fri, 29 Oct 2010 07:24:37 -0700 (PDT) Received: by wyb28 with SMTP id 28so3193640wyb.31 for ; Fri, 29 Oct 2010 07:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=OX6xqPlAyy0QXwmSF2cWSKN/ezd2zny2426/I8WFYLM=; b=pcZqI9O8PPykURoLAwqAeCu32iVqgBJo70Jxl1/H/AQSifU5VWW/9+v87G4ybjBOZt xuKS///N+0dewvzffJw8ZWM0SDxayZEpmvr1DIs3jnjSCGQqYejI6ZPrKCO2/tNaenfC cN8JRTj8GCgRM1w8PxQDI3vilMTE+nleqOG+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=E2Irq2sZgWO80y0yqqcS4EZZvdr+T0K4vsWIHWrvRuikku8eMrDBC/xffrn/qDvyxd TTzgIefQpbX+h+vn9OU0VT+/wAnXtAgdB9DQImId51bsXDjOIGwpbcv7jyC3W5Ddgf1k 8qnQv6nRBdsu24Nv3w9YnHzPzfBt1QPX2e6Sw= Received: by 10.227.143.146 with SMTP id v18mr758235wbu.63.1288362391200; Fri, 29 Oct 2010 07:26:31 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-22-84.red.bezeqint.net [79.179.22.84]) by mx.google.com with ESMTPS id a17sm2114235wbe.0.2010.10.29.07.26.25 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 07:26:28 -0700 (PDT) Message-ID: <4CCAD98E.1040300@gmail.com> Date: Fri, 29 Oct 2010 16:26:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Peter Saint-Andre References: <4CC9503D.2000809@gmail.com> <4CCA470B.20601@stpeter.im> <4CCA7BED.1020907@gmail.com> <4CCAD810.4060508@stpeter.im> In-Reply-To: <4CCAD810.4060508@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17 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, 29 Oct 2010 14:24:42 -0000 Hi Peter, I'm fine with your proposals. Thanks, Yaron On 10/29/2010 04:20 PM, Peter Saint-Andre wrote: > Hi Yaron, a few additional comments and text proposals inline. > > On 10/29/10 1:46 AM, Yaron Sheffer wrote: >> Hi Peter, >> >> On 10/29/2010 06:01 AM, Peter Saint-Andre wrote: >>> Thanks for your careful and thorough review. To maintain forward >>> momentum, this is Part 1 of my reply, up through the end of Section 4. I >>> shall endeavor to reply regarding the remainder of your review in the >>> next 24-48 hours. >>> >> Thanks a lot for using my comments and misunderstandings to improve the >> document. >> >> I have removed pieces of this mail where I fully accept your >> response/changes. >> >>>> - 4.3: How is TLS negotiated for the additional streams? >>> >>> Each stream is separately secured. >>> >>>> How is it bound >>>> to the SASL negotiation that (apparently) only takes place once? >>> >>> It isn't, because each stream is separately secured (preferably by means >>> of TLS + SASL). >>> >>> I propose that we clarify these matters by modifying the following >>> paragraphs from Section 4.3 ("Directionality"): >>> >>> ### >>> >>> 4.3. Directionality >>> >>> An XML stream is always unidirectional, by which is meant that XML >>> stanzas can be sent in only one direction over the stream (either >>> from the initiating entity to the receiving entity or from the >>> receiving entity to the initiating entity). >>> >>> Depending on the type of session that has been negotiated and the >>> nature of the entities involved, the entities might use: >>> >>> o Two streams over a single TCP connection, where the security >>> context negotiated for the first stream is applied to the second >>> stream. This is typical for client-to-server sessions, and a >>> server MUST allow a client to use the same TCP connection for both >>> streams. >>> >>> o Two streams over two TCP connections, where each stream is >>> separately secured. In this approach, one TCP connection is used >>> for the stream in which stanzas are sent from the initiating >>> entity to the receiving entity, and the other TCP connection is >>> used for the stream in which stanzas are sent from the receiving >>> entity to the initiating entity. This is typical for server-to- >>> server sessions. >>> >>> o Multiple streams over two or more TCP connections, where each >>> stream is separately secured. This approach is sometimes used for >>> server-to-server communication between two large XMPP service >>> providers; however, this can make it difficult to maintain >>> coherence of data received over multiple streams in situations >>> described under Section 10.1, which is why a server MAY return a >>> stream error to a remote server that attempts to >>> negotiate more than one stream (as described under >>> Section 4.8.3.3). >>> >>> This concept of directionality applies only to stanzas and explicitly >>> does not apply to first-level children of the stream root that are >>> used to bootstrap or manage the stream (e.g., first-level elements >>> used for TLS negotiation, SASL negotiation, Server Dialback >>> [XEP-0220], and Stream Management [XEP-0198]). >>> >>> The foregoing considerations imply that while completing STARTTLS >>> negotiation (Section 5) and SASL negotiation (Section 6) two servers >>> would use one TCP connection, but after the stream negotiation >>> process is done that original TCP connection would be used only for >>> the initiating server to send XML stanzas to the receiving server. >>> In order for the receiving server to send XML stanzas to the >>> initiating server, the receiving server would need to reverse the >>> roles and negotiate an XML stream from the receiving server to the >>> initiating server over a separate TCP connection. >>> >> Perhaps add a final sentence: "This separate TCP connection is then >> secured using a new round of TLS and/or SASL negotiation." > > Yes, that's good. Paragraph updated with your text. > >>> ### >>> >>>> - 4.8.3.18: what are the security implications of a "redirect"? >>> >>> Of? Seemingly underspecified. :( >>> >>>> Should >>>> the client apply the same policy, e.g. for using TLS, as for the >>>> original server? >>> >>> Yes. >>> >>>> Which "to" identity to use? >>> >>> The 'to' address of the initial stream header would still be the DNS >>> domain name of the XMPP service to which the initiating entity is trying >>> to connect (see also draft-saintandre-tls-server-id-check). >>> >>>> Can redirection occur >>>> before the recipient is even authenticated? >>> >>> Yes. >>> >>> I propose that we modify the description as follows: >>> >>> The server will not provide service to the initiating entity but is >>> redirecting traffic to another host under the administrative control >>> of the same service provider. The XML character data of the>> other-host/> element returned by the server MUST specify the >>> alternate hostname or IP address at which to connect, which MUST be a >>> valid domainpart or a domainpart plus port number (separated by the >>> ':' character in the form "domainpart:port"). If the domainpart is >>> the same as the source domain, derived domain, or resolved IP address >>> to which the initiating entity originally connected (differing only >>> by the port number), then the initiating entity SHOULD simply attempt >>> to reconnect at that address. Otherwise, the initiating entity MUST >>> resolve the hostname specified in the element as >>> described under Section 3.2. >>> >>> I also propose that we add the following paragraph to the end of the >>> section: >>> >>> When negotiating a stream with the host to which it has been >>> redirected, the initiating entity MUST apply the same policies it >>> would have applied to the original connection attempt (e.g., a policy >>> requiring TLS), MUST specify the same 'to' address on the initial >>> stream header, and MUST verify the identity of the new host using the >>> same reference identifier(s) it would have used for the original >>> connection attempt (in accordance with [TLS-CERTS]. Even if >>> receiving entity returns a error before the >>> confidentiality and integrity of the stream have been established >>> (thus introducing the possibility of a denial of service attack), the >>> fact that the initiating entity needs to verify the identity of the >>> XMPP service based on the same reference identifiers implies that the >>> initiating entity will not connect to a malicious entity; however, to >>> reduce the possibility of a denial of service attack, the receiving >>> entity SHOULD NOT return a error until after the >>> stream has been protected (e.g., via TLS). >>> >> ... and the sending entity SHOULD maintain a running redirect counter, >> and give up after a certain number of successive redirects. >> >> Also, the mitigation you propose in the last sentence only helps if "An >> entity MAY have a policy where it only accepts elements >> from authenticated peers. > > Thanks. I propose that we change this paragraph to: > > When negotiating a stream with the host to which it has been > redirected, the initiating entity MUST apply the same policies it > would have applied to the original connection attempt (e.g., a policy > requiring TLS), MUST specify the same 'to' address on the initial > stream header, and MUST verify the identity of the new host using the > same reference identifier(s) it would have used for the original > connection attempt (in accordance with [TLS-CERTS]. Even if > receiving entity returns a error before the > confidentiality and integrity of the stream have been established > (thus introducing the possibility of a denial of service attack), the > fact that the initiating entity needs to verify the identity of the > XMPP service based on the same reference identifiers implies that the > initiating entity will not connect to a malicious entity; however, to > reduce the possibility of a denial of service attack, the receiving > entity SHOULD NOT return a error until after the > stream has been protected (e.g., via TLS) and the receiving entity > MAY have a policy of following redirects only if it has authenticated > the receiving entity. In addition, the initiating entity SHOULD give > up after a certain number of successive redirects (e.g., at least 2 > but no more than 5). > >>>> - 4.9: Don't we resend the "stream" header again after completing the >>>> TLS negotiation (Sec. 4.2.3). >>> >>> For sure. I propose that we change this: >>> >>> [ ... channel encryption ... ] >>> >>> [ ... authentication ... ] >>> >>> [ ... resource binding ... ] >>> >>> to: >>> >>> [ ... stream negotiation ... ] >>> >> I'm not sure. Since we start the example with two elements, it >> would make sense to show the additional (4?) elements further >> down. Although the "simple" examples would no longer fit a page. Maybe >> add a "really simple" example with no security? > > These examples are included to provide a high-level illustration of what > a session would look like, so I think eliding the whole stream > negotiation process is fine. However, I think it would be good to add a > forward reference to Section 9 so that the reader knows where to go for > detailed examples. Thus propose modifying the first paragraph of Section > 4.9 as follows: > > This section contains two highly simplified examples of a stream- > based connection between a client and a server; these examples are > included for the purpose of illustrating the concepts introduced thus > far, but the reader needs to be aware that these examples elide many > details (see Section 9 for more complete examples). > > Peter > From stephen.farrell@cs.tcd.ie Fri Oct 29 07:49:19 2010 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 CA9293A6A13; Fri, 29 Oct 2010 07:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 av-tn+ZwQ5QB; Fri, 29 Oct 2010 07:49:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 5608A3A689D; Fri, 29 Oct 2010 07:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 563743E415D; Fri, 29 Oct 2010 15:51:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1288363870; bh=Z0su8k/EN+Bj/F HSD+mrYvCVIgx3+7Xa9DUAQvTu+3Y=; b=Dc0ok9tNDVjfbgkxAU9qw7+tybCq9J 5MO8MAIKtb0lwXn9KSf2an/qkI9QMgC02LY83mz2ryFUeF1m6dMT0RbSbtBcJotO wL9yBubDfLg8lELybyoR3wO9kK4eiYxTS4Nry7d5sm0s0q92eQQ0qJmhxkm5nfuN WNJ2o0wrHtz3H0ZHohQGi3gmhi31rWZwxRsoVjeCKWYVjcGRbdytCYKs+G7P4Pf1 dzopnGShLs6fN4iWICnjDq3k2LFtCPCd3c9XkIKIf5Jsd6/DvbAZbYfGg792Ptsr YPtdkSfbCLJy1QYRZLfhP5P0JvaRgY30uBvuCE17kiZRbpMVDjU9ducg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VXk+HwHjSBgl; Fri, 29 Oct 2010 15:51:10 +0100 (IST) Received: from [10.87.48.4] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 39E0F3E415C; Fri, 29 Oct 2010 15:51:08 +0100 (IST) Message-ID: <4CCADF5A.3060704@cs.tcd.ie> Date: Fri, 29 Oct 2010 15:51:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Polk, William T." References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tony.li@tony.li" , Sandra Murphy , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] comments on draft-irtf-rrg-recommendation-14 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, 29 Oct 2010 14:49:19 -0000 On 29/10/10 02:15, Polk, William T. wrote: > Stephen, > > We have not changed the process. There was a tools error That's grand. I just wanted to call it out, in case. Cheers, S. > - the draft > ended up on the agenda as an informational RFC on the IETF stream. I > actually pointed this out to the secretariat so that the document was > moved to the right part of the agenda, but I did not notice that this > document got assigned for a secdir review. Sandy was diligent and did > the review before the telechat. > > We need to figure out why the tools error is occurring and get this > corrected. Adding a manual step for irtf stream filtering would be a > real burden for Sam. > > Thanks, > > Tim > > > On 10/28/10 5:22 PM, "Stephen Farrell" wrote: > > > > Not really for Sandy, more for the ADs/Sam W: > > Why are we doing a secdir review of an IRTF draft? That's > not required by any process I know of (speaking as an IRTF > RG chair). > > Unless maybe the RRG asked for it, in which case, ignore > this. > > Otherwise we should try filter the assignments for > irtf drafts since this is not the 1st time this has > happened. (Last time, I spotted it before someone did a > review.) > > Ta, > Stephen. > > On 28/10/10 18:27, Sandra Murphy 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 unfortunately was off-net for a few days and got to this assignment > > rather late. The document is long and covers a broad swath of material > > and I was not able to cover it deeply. > > > > This document is a product of the rrg IRTF working group. It > summarizes > > 15 different proposals for a new routing and addressing > architecture for > > the Internet, with short summaries, critiques and rebuttals for each, > > and gives a final recommendation to the IETF for future direction. > > > > With the breadth of scope of the document, there is no way for me to > > review each proposal's documents for security considerations. > > > > The security considerations of *this* document itself is quite terse: > > > > 20. Security Considerations > > > > All solutions are required to provide security that is at least as > > strong as the existing Internet routing and addressing architecture. > > > > Given the widely reported weakness of the "existing Internet > routing and > > addressing architecture", this is a low bar indeed. There are attempts > > in progress to attempt to improve the security of the Internet routing > > and addressing architecture. I do not know what to suggest if these > > improvements leave the Internet with stronger security than is provided > > by these proposals. > > > > The summaries of the different proposals devote little attention to the > > infrastructure security ramifications of the proposal. Given the > stated > > goal, perhaps no attention was necessary. > > > > Many of these proposals include an encapsulation system, presenting the > > expected difficulties with end system authentication, filtering systems > > at boundaries, etc. Some proposals addressed these concerns. I am not > > sure if the security considerations section meant that the proposals > > were required to avoid weakening the end-host security protections > > already provided (ipsec, NAT, whatever). > > > > The rrg wg came to consensus that a fundamental architectural > feature is > > a separation of locator and identifier for any node. Many of the > > discussed alternatives include a mapping system that produce a locator > > for a given destination identifier. > > > > The mapping system would seem to be a very likely point of > > vulnerability, permitting traffic redirection for data exposure or > > blackholing, etc. Many proposals suggest a hierarchic architecture of > > the mapping system for scaling purposes. I would presume that an > > authorization scheme for the mapping system would be essential, and > that > > the hierarchy would be an important aspect of that scheme. Of > course, I > > can't tell much at this level of detail about how and if each proposals > > addresses this. (One of the recommendations suggests communicating > > mapping info through bgp - I can not say at this point whether the SIDR > > suggestions for improving bgp security would be applicable.) > > > > --Sandy > > > > Nits: > > > > PMTUD Path Maximum Transmission Unit Discovery: The process or > > mechanism that determines the largest packet that can be sent > > between a given source and destination with being either i) > > fragmented (IPv4 only), or ii) discarded (if not fragmentable) > > because it is too large to be sent down one link in the path from > > the source to the destination. > > > > It should say "*without* being either", right? A long sentence so > I may > > have lost my place. > > > > > > Several of the comments start using terms that are part of the wg > > deliberations, I'm sure. But it makes reading the discussions and > > critiques obtuse. In particular, "Core-Edge Separation" and "Core-Edge > > Elimination" seems to a well understood concept in the wg. It needs to > > be defined somewhere. A web search found references in some conference > > papers and in rrg mailing lists. > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > > From weiler@watson.org Fri Oct 29 11:31:29 2010 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 7280A3A6A5C; Fri, 29 Oct 2010 11:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, 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 3yHRUXbOiTjt; Fri, 29 Oct 2010 11:31:28 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 6A9783A6A43; Fri, 29 Oct 2010 11:31:28 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o9TIXJhY091006; Fri, 29 Oct 2010 14:33:19 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o9TIXJAa091003; Fri, 29 Oct 2010 14:33:19 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 29 Oct 2010 14:33:19 -0400 (EDT) From: Samuel Weiler To: "Polk, William T." In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-259002857-1288377199=:82317" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 29 Oct 2010 14:33:20 -0400 (EDT) Cc: "secdir@ietf.org" , "tony.li@tony.li" , Sandra Murphy , "iesg@ietf.org" Subject: Re: [secdir] comments on draft-irtf-rrg-recommendation-14 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, 29 Oct 2010 18:31:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-259002857-1288377199=:82317 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT > We need to figure out why the tools error is occurring and get this > corrected.  Adding a manual step for irtf stream filtering would be a real > burden for Sam. It may not be so burdensome -- seeing the doc name helps. :-) In this case, I did a double-take and rechecked the IESG agenda. And, seeing where the doc was, decided to go ahead and send it out. -- Sam --621616949-259002857-1288377199=:82317-- From weiler+secdir@watson.org Fri Oct 29 11:46:46 2010 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 3D93E3A683A for ; Fri, 29 Oct 2010 11:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 N3grhuuoIIet for ; Fri, 29 Oct 2010 11:46:45 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 018B03A6A8E for ; Fri, 29 Oct 2010 11:46:44 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id o9TImdoI092230 for ; Fri, 29 Oct 2010 14:48:39 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id o9TImdFt092227 for ; Fri, 29 Oct 2010 14:48:39 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 29 Oct 2010 14:48:39 -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.2.3 (fledge.watson.org [127.0.0.1]); Fri, 29 Oct 2010 14:48:39 -0400 (EDT) Subject: [secdir] Assignments 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, 29 Oct 2010 18:46:46 -0000 The next telechat is after the Beijing meeting. Given the interest in finishing reviews during IETF last call, I'm going to continue sending assignments on a more-or-less regular basis. There is a secdir lunch scheduled for the Tuesday of the meeting, room still TBD. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sam Weiler is next in the rotation. For telechat 2010-11-18 Reviewer LC end Draft Tobias Gondrom TR2010-09-27 draft-ietf-mpls-ldp-igp-sync-bcast-05 Scott Kelly T 2010-10-21 draft-ietf-avt-rtp-h264-rcdo-07 Joe Salowey T 2010-11-17 draft-ietf-dhc-dhcpv6-ldra-03 For telechat 2010-12-02 Reviewer LC end Draft Donald Eastlake TR2010-11-23 draft-cheshire-dnsext-multicastdns-12 Vincent Roca T 2010-11-22 draft-ietf-mpls-tp-oam-framework-09 Juergen Schoenwaelder T 2010-11-23 draft-cheshire-dnsext-nbp-09 Last calls and special requests: Reviewer LC end Draft Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Jeffrey Hutzelman 2010-10-13 draft-ietf-mpls-ldp-upstream-08 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2010-11-15 draft-igoe-secsh-x509v3-06 Kathleen Moriarty 2010-11-03 draft-ietf-ipfix-anon-05 Russ Mundy 2010-11-10 draft-ietf-emu-eaptunnel-req-08 Magnus Nystrom 2010-11-05 draft-ietf-dnsop-name-server-management-reqs-04 Hilarie Orman 2010-11-03 draft-ietf-sipcore-event-rate-control-05 Radia Perlman 2010-11-18 draft-ietf-martini-gin-10 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Eric Rescorla 2010-11-08 draft-ietf-opsec-ip-security-04 Stefan Santesson 2010-11-09 draft-ietf-sieve-notify-presence-02 Yaron Sheffer 2010-10-21 draft-ietf-xmpp-address-06 Tina TSOU 2010-11-08 draft-ietf-sieve-vacation-seconds-02 Carl Wallace 2010-10-25 draft-ietf-dime-rfc3588bis-25 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-06 From yaronf.ietf@gmail.com Sun Oct 31 08:35:28 2010 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 948833A68DA; Sun, 31 Oct 2010 08:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 31-B+0Q5thTL; Sun, 31 Oct 2010 08:35:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id F11043A6991; Sun, 31 Oct 2010 08:35:24 -0700 (PDT) Received: by mail-ww0-f44.google.com with SMTP id 15so4839471wwe.13 for ; Sun, 31 Oct 2010 08:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DNyil+hh7JpcEt3N5vMOUE8umoZm3sF4TBoVu23ASxM=; b=POzO5z6/u3DQ51u1wCJKG2FWudSju5bQDC5dDG9Ms6105QfXBk06FV7JnqWe22JyBH 9DVRYKkXG3nJeWfLFoMfUeHaK6su0lZIaBSbAbWlKgnlzF8y7mVVscd0+IKsGgcaW4Fe UVHexCJapyT2Bxo7Rl++Pn7NEBvC5cpfJ7Rao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=utq7yGhq7sB4gSw1y0GkwIeKApZu0WKgiJVoEEU10tPX6EaEEdyuL4m/aMBI2ZUCEx s1lL0nJIKJfl0cZD8VD+9vG2AA1iSpFv8+XnEJSRWpAK1OxrywUhQY0klEm6SNja8q8l nMYDYZL5gpNfScuJJ0evAfGXH5C0Cb9Qj4JA8= Received: by 10.227.145.66 with SMTP id c2mr14776671wbv.34.1288539443159; Sun, 31 Oct 2010 08:37:23 -0700 (PDT) Received: from [192.168.2.119] (bzq-79-182-8-5.red.bezeqint.net [79.182.8.5]) by mx.google.com with ESMTPS id ga16sm4250240wbb.7.2010.10.31.08.37.16 (version=SSLv3 cipher=RC4-MD5); Sun, 31 Oct 2010 08:37:21 -0700 (PDT) Message-ID: <4CCD8D2B.50900@gmail.com> Date: Sun, 31 Oct 2010 17:37:15 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <4CC9503D.2000809@gmail.com> <4CCB1334.3030203@stpeter.im> In-Reply-To: <4CCB1334.3030203@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17 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, 31 Oct 2010 15:35:28 -0000 Hi Peter, again, I have removed the points where we are in agreement. Thanks, Yaron On 10/29/2010 08:32 PM, Peter Saint-Andre wrote: > This is Part 2 of my reply, from the start of Section 5 through the end > of Section 9. I should be able to address the remainder (Section 10 > through Section 15) in Part 3. > > On 10/28/10 4:28 AM, Yaron Sheffer wrote: > >> - 5.3.5: the text mentions that client certificates are "sufficiently >> rare", which is a pity because they do make sense for server-to-server >> interaction. So I suggest to promote renegotiation from OPTIONAL to >> RECOMMENDED. > > A bit of background: by client certificates we mean end-user > certificates (XMPP client, not TLS client). PKIX certificates are more > common for XMPP servers, but unfortunately they are still far from > ubiquitous. The XMPP Standards Foundation even ran an intermediate CA > for a few years (under the StartCom root) to help seed the network, > which helped us work out bugs in many codebases but still didn't result > in wide adoption. Many service admins still think that PKI is "too hard" > or "too expensive" (despite the fact that our ICA gave out free > certificates, and StartCom continues to do so). > > The XMPP WG had a discussion about TLS renegotiation, starting here: > > http://www.ietf.org/mail-archive/web/xmpp/current/msg01146.html > > At one point we banned TLS renegotiation entirely, then we weighed the > benefits and the costs (including code complexity) and concluded that it > was appropriate to make support strictly optional in XMPP, given how > rarely it would be needed. Simon Josefsson suggested during the WG > discussion that we document our reasons, which we've done in Section > 5.3.5. If you do not find those reasons compelling, the WG needs to > either explain itself more clearly or realize that it is wrong. :) > I accept your reasoning. And servers in most cases can take the risk of information disclosure and still use mutual cert authentication. >> - 5.3.6: extensions may be out of scope. But I think we need to include >> a few words re: the TLS version, at least to prohibit SSL 3.0. > > In fact, discussions within the XMPP WG are what led to this: > > https://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/ > > However, it seems there is not yet consensus to prohibit SSL 3.0 in the > TLS WG. Are you suggesting that the XMPP WG go where the TLS WG has not > gone? I was assuming that XMPP has less legacy baggage than HTTP (i.e. browsers) and therefore prohibiting SSLv3 would be reasonable. If it isn't, forget it. > >> - 5.4.3.3: where do we say that both sides must validate the "to" and >> "from" identities in view of the identities presented at the TLS layer >> (if any)? > > Section 13.7.2 ("Certificate Validation"). There is a forward reference > in bullet 4 of Section 5.4.3.3: > > 4. The initiating entity MUST validate the certificate to determine > if the TLS negotiation will succeed; see Section 13.7.2 regarding > certificate validation procedures. > > Perhaps it would be easier to read if we switched bullets 4 and 5 in > that section? Yes, it makes sense to switch #4 and #5. BTW, you meant 5.4.3.1. > > Also, the bullet about validation probably also needs to say that if the > initiating entity presents a certificate then the receiving entity needs > to also perform validation. Do you agree? Yes, this is the basic case, of course it should be mentioned. > >> - 7.7.2.2: the preferred option #1, while reasonable in itself, does not >> allow the client to determine its own policy (whether it wants multiple >> sessions from multiple devices or not). > > If the client wants multiple sessions from multiple devices, it can > generate a unique resourcepart for each device or ask the server to do > so on its behalf. > But if the client prefers the old behavior (newest resource wins), it cannot have it. Anyway, I'm sure you have debated this point to death. >> - 8.3.2: MUST NOT... be presented to the human user - this is impossible >> to enforce, and most likely will not be followed. Moreover, there's a >> reason why we include a language tag. I suggest to tone it down a bit. > > I suppose SHOULD NOT is fine. The error message shown to the user is > supposed to be based on the defined condition, not some random text > placed in the element (even if language-tagged). Yes, SHOULD NOT would be BETTER... > >> - 8.3.3.11: what are "improper credentials"? It sounds like we are not >> differentiating the conditions of authentication failure vs. >> authorization failure. > > As an example, if a client attempts to join a password-protected > chatroom without providing a password, the chatroom service will return > a stanza error. It will return the same error if the > client attempts to join a password-protected chatroom but provides the > wrong password. Is there a need to differentiate between these two cases? > What triggered my comment was the name of this element, "not authorized". Both of your examples are (broadly speaking), "not authenticated". What about the same service, where I am duly authenticated as Yaron, but still am not allowed to use the service, e.g. because only users belonging to the all-saints group are allowed to it. This would be a true authorization failure. > >> - 8.3.3.21: do you explain anywhere what is the difference between >> "prior registration" and "prior subscription"? > > That's really an issue for various XMPP applications. One such > application is IM and presence (3920bis), where we have the concept of > subscriptions. Another application in which we have subscriptions is > publish-subscribe. An example > of registration can be found in the multi-user chat extension > or in the older "gateway" > that we used to maintain for connecting to legacy IM services. I don't > see much reason to describe all those differences in 3920bis, but we can > add a sentence or two about it if that would be helpful. > I would appreciate a pointer to benefit the uninitiated.