From mcgrew@cisco.com Fri Apr 1 04:19:02 2011 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 1B48F3A6811 for ; Fri, 1 Apr 2011 04:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.53 X-Spam-Level: X-Spam-Status: No, score=-109.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 sGK+yQlSw35S for ; Fri, 1 Apr 2011 04:19:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 28C1B3A67FA for ; Fri, 1 Apr 2011 04:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1709; q=dns/txt; s=iport; t=1301656841; x=1302866441; h=message-id:from:to:in-reply-to:content-transfer-encoding: mime-version:subject:date:references; bh=BD6R7ZjXJc6m+Woko2pTfjizBj56uLLOWqh6xTPmD6U=; b=SCZMCKqGWDQzQPpefQRgisLPedzVcAYsaQyXZ1osDpK+Y0JVMnIdcmpB lo4IOatYaeovBs+oQg10Up4xtcshjoyzkT9NHdp2YCovYWOCDqiZL/Onc Bo47Ihvg2El5IXIPntqXUl0ln34toWevykKM652M0r5t+7k8sBDiUlpw4 Q=; X-IronPort-AV: E=Sophos;i="4.63,282,1299456000"; d="scan'208";a="287274479" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2011 11:20:40 +0000 Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p31BKcld029681; Fri, 1 Apr 2011 11:20:40 GMT Message-Id: <93D11D9B-299A-490E-A6A7-E78EAE4713F4@cisco.com> From: David McGrew To: Fred Baker , secdir@ietf.org, Tim Polk In-Reply-To: <03BEA4A7-EE27-4961-B23D-9AD276797D09@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 31 Mar 2011 17:33:45 -0700 References: <32850C9F-72A5-4E2A-BF15-FF6A236A6B77@cisco.com> <03BEA4A7-EE27-4961-B23D-9AD276797D09@cisco.com> X-Mailer: Apple Mail (2.936) Subject: Re: [secdir] Fwd: New SG17 proposed work items on IPv6 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 Apr 2011 11:19:02 -0000 "many new functions or requirements of IPv6 [including] mandatory IPsec ... can be abused for compromising computer systems or networks. " IPsec does not belong on that list; it is silly to have it there. Unless a v6 device is configured with keys and IPsec policy, it will behave as if IPsec is not present. IPsec is mandatory to implement, but not mandatory to use, of course. A great many v4 devices have had IPsec for years. And lastly, it defies logic to say that IPsec can be used to compromise a device; DoS is not a compromise. "National Institute of Information and Communications Technology (NICT) has identified more than 60 security threats and vulnerabilities that may be caused by new functions or requirements of IPv6" These threats should be referenced so they can be assessed and dealt with; the most useful place to publish them would be as an internet-draft. David On Mar 30, 2011, at 8:52 PM, Fred Baker wrote: > The attached was passed to me, and I think it is something that > would be good for you to comment on to the IETF community. > > Begin forwarded message: > >> From: Hascall Sharp >> Date: March 31, 2011 5:24:00 AM GMT+02:00 >> To: "Fred Baker (fred)" >> Subject: New SG17 proposed work items on IPv6 >> >> This is probably not high on your list of things you'd like to see, >> but I figured you should be aware of it. >> >> "Technical security guideline on deploying IPv6" >> >> > >> >> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From new-work-bounces@ietf.org Fri Apr 1 09:47:22 2011 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 554D33A688C; Fri, 1 Apr 2011 09:47:22 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A13E3A688C for ; Fri, 1 Apr 2011 09:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 OuCSgIQtwzbB for ; Fri, 1 Apr 2011 09:47:20 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id A85F53A6879 for ; Fri, 1 Apr 2011 09:47:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Q5hWu-00053Q-5l; Fri, 01 Apr 2011 12:49:00 -0400 From: Ian Jacobs Date: Fri, 1 Apr 2011 11:48:59 -0500 To: new-work@ietf.org Message-Id: <504C2D54-B808-4F71-9C91-73CC4A61BFE7@w3.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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: Sun, 03 Apr 2011 15:00:50 -0700 Subject: [secdir] [new-work] Proposed W3C Charters: Government Linked Data; eGovernment Interest Group (until 2011-04-29) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 16:47:22 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the eGovernment Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal [2] includes two draft charters: eGovernment Interest Group http://www.w3.org/egov/IG/charter-2011 Government Linked Data (New!) http://www.w3.org/2011/gld/charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2011-04-29 on the proposed charters. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [3], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Sandro Hawke, Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/egov/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/2011/03/egov-activity-proposal [3] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From charliek@microsoft.com Tue Apr 5 21:14:44 2011 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 7F61C3A6860; Tue, 5 Apr 2011 21:14:44 -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 ipjmvfEiryfb; Tue, 5 Apr 2011 21:14:43 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B9D383A685B; Tue, 5 Apr 2011 21:14:43 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Apr 2011 21:16:27 -0700 Received: from TK5EX14MBXC110.redmond.corp.microsoft.com ([169.254.1.154]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0270.002; Tue, 5 Apr 2011 21:16:27 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-avtcore-ports-for-ucast-mcast-rtp.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 Thread-Index: AcvzxmoOwCr5HXG7TFutkMKEhgYPyg== Date: Wed, 6 Apr 2011 04:16:27 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 04:14:44 -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.=A0 These = comments were written primarily for the benefit of the security area direct= ors.=A0 Document editors and WG chairs should treat these comments just lik= e any other last call comments. This protocol deals with requesting and managing multicast and unicast conn= ection streams, and in particular dealing with the case where they are comi= ng through a NAT. The interesting security threat in this case is one of Do= S through amplification, where the attacker with a small number of packets = can request that a source direct a large number of packets towards the vict= im. Because these streams do not have the sorts of acknowledgements that wo= uld force a TCP stream to back off if the target were unresponsive, the pos= sibility of this sort of attack is particularly dangerous. The RTP and RTCP protocols have no authentication infrastructure that can b= e leveraged. There is a resumption that all information is public and can b= e requested by any destination. (It is possible that one could implement en= cryption at a higher layer such that the data received would not be useful = to someone who doesn't know the key, but any such encryption is beyond the = scope of this protocol). This means that certain security attacks are unavo= idable. In particular, an attacker could potentially exhaust the source or = the network by requesting that data from large numbers of locations simulta= neously. And an attacker that can act as a man-in-the-middle between source= and victim can initiate a flood of data and then get out of the way. This protocol attempts to assure that an attacker that can forge the victim= 's IP address but cannot receive packets addressed to the victim cannot mou= nt an amplification DoS attack. It does that by adding a "token" to various= messages in the protocol. The token is generated by the source when a cont= ext is set up and must be supplied by the receiver in requests to modify th= e data streams. In order to not add state at the source, they recommend tha= t the token be generated as an HMAC-SHA1 of the concatenation of the client= IP address, a client nonce (that is chosen for the session and supplied wi= th each request), and a server timestamp (also chosen per session and suppl= ied to prevent long delayed replay). This closely matches the design of "co= okies" in other protocols. The recommended use of HMAC-SHA1 may be slightly controversial, but its sec= urity is more than adequate for this application, it is a local decision on= the part of the server, and the I-D has excellent text on how and when imp= lementations should migrate to a different algorithm (in particular, refere= ncing HMAC-SHA2-256). There is one aspect of the design that I could not figure out reading the s= pec, and it would seem to relate to a security vulnerability that the spec = therefore does not close. The spec recommends computing the token as a hash= over a number of fields including the source IP address but not the source= port. It appears that this is because the RTP and RTCP protocols use diffe= rent ports and they want to use the same token with both. This introduces a= threat, however, that if a node requests a token, that token will be valid= for all nodes that are NATted behind the same IP address. An attacker in t= he inside of the NATted network could therefore acquire a token, hand it of= f to a co-conspirator outside the NATted network, and that co-conspirator c= ould use it to direct traffic at a different node inside the network. It's = not obvious what could or should be done to mitigate this threat. The spec = allows for - but recommends against - using lots of different ports on the = client side for different purposes, but I couldn't figure out how the clien= t knows how all of those ports will be translated by the NAT. If there were= a separate token per port, this problem could be solved, but I suspect the= re is some reason why that is impractical. --Charlie From weiler+secdir@watson.org Wed Apr 6 06:48:30 2011 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 DED353A6935 for ; Wed, 6 Apr 2011 06:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 zkhs5ne9Enhg for ; Wed, 6 Apr 2011 06:48:29 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A51DE3A67B2 for ; Wed, 6 Apr 2011 06:48:29 -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 p36DoDdb066929 for ; Wed, 6 Apr 2011 09:50: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 p36DoDbG066926 for ; Wed, 6 Apr 2011 09:50:13 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 6 Apr 2011 09:50: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]); Wed, 06 Apr 2011 09:50: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: Wed, 06 Apr 2011 13:48:31 -0000 I didn't send out assignments in the week leading up to the Prague meeting, so some of the new assignments below are close to their last call end dates. My apologies. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Love Hornquist-Astrand is next in the rotation. For telechat 2011-04-14 Reviewer LC end Draft Paul Hoffman T - draft-ietf-mboned-addrarch-07 Love Hornquist-Astrand T 2011-03-16 draft-yevstifeyev-tn3270-uri-18 Russ Mundy T 2011-01-04 draft-cardona-cablelabs-urn-07 Sandy Murphy T 2011-03-23 draft-kanno-tls-camellia-01 Vincent Roca T - draft-ietf-netlmm-pmipv6-mib-05 Joe Salowey T 2011-04-01 draft-housley-rfc5008bis-00 Stefan Santesson T 2011-03-23 draft-ietf-dccp-tfrc-rtt-option-05 Tina TSOU T 2011-03-24 draft-ietf-ledbat-survey-05 Nico Williams T 2011-02-09 draft-ietf-rmt-bb-fec-raptorq-05 For telechat 2011-04-28 Reviewer LC end Draft Dave Cridland T 2011-04-13 draft-ietf-ipsecme-ipsecha-protocol-05 Shawn Emery T 2011-04-18 draft-ietf-sidr-roa-validation-10 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2011-04-27 draft-arkko-mikey-iana-00 Rob Austein 2011-05-03 draft-haleplidis-forces-implementation-experience-02 Richard Barnes 2011-04-23 draft-harkins-ipsecme-spsk-auth-03 Uri Blumenthal 2011-04-18 draft-ietf-idr-bgp-identifier-13 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Alan DeKok 2011-04-15 draft-ietf-kitten-digest-to-historic-03 Donald Eastlake 2011-04-11 draft-ietf-mif-current-practices-09 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-17 Tobias Gondrom 2011-04-20 draft-ietf-siprec-req-09 Phillip Hallam-Baker 2011-04-12 draft-ietf-softwire-dual-stack-lite-07 Steve Hanna 2011-04-23 draft-kuegler-ipsecme-pace-ikev2-06 Dan Harkins 2011-05-03 draft-mavrogiannopoulos-ssl-version3-02 Sam Hartman 2011-04-23 draft-shin-augmented-pake-04 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 David McGrew - draft-ietf-ecrit-framework-12 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Sam Weiler 2011-03-24 draft-ietf-sidr-roa-format-10 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-11 Nico Williams 2011-03-24 draft-ietf-sidr-rpki-manifests-09 Glen Zorn 2011-04-10 draft-ietf-netext-redirect-07 From paul.hoffman@vpnc.org Sun Apr 10 19:25:14 2011 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 E8EAA3A6A43 for ; Sun, 10 Apr 2011 19:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 syvj4w2DoR1D for ; Sun, 10 Apr 2011 19:25:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 0C19A3A6A30 for ; Sun, 10 Apr 2011 19:25:13 -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 p3B2PBF0029860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 10 Apr 2011 19:25:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Apr 2011 19:25:11 -0700 Message-Id: <6264A0DE-742E-424C-93C5-0D3554EB0F7D@vpnc.org> To: secdir Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-mboned-addrarch 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 Apr 2011 02:25:15 -0000 Greetings again. This document is an informational overview of how = multicast addresses are allocated and assigned. It does not recommend = particular allocation and/or assignment strategies; it just lists the = many strategies that exist. As such, it has no particular security = considerations other than possible DoS attacks on some allocation = methods, and the Security Considerations section says so. --Paul Hoffman From vincent.roca@inrialpes.fr Mon Apr 11 06:50:50 2011 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 74D5D3A6B1D; Mon, 11 Apr 2011 06:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.091 X-Spam-Level: X-Spam-Status: No, score=-10.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 lSqljogwkY6w; Mon, 11 Apr 2011 06:50:49 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 1BBED3A6B1C; Mon, 11 Apr 2011 06:50:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,339,1299452400"; d="scan'208";a="80582123" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 11 Apr 2011 15:50:47 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 11 Apr 2011 15:50:47 +0200 Message-Id: To: IESG , secdir@ietf.org, draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-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, 11 Apr 2011 13:50:50 -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. Globally, the "Security Considerations" section is well written and provides details for the associated risks. It clearly RECOMMENDs the use of SNMPv3, which should not come as a surprise given the risks associated to previous versions. This "Security Considerations" section is globally similar to that of RFC4295 (MIPv6 MIB). A few comments: ** What about the completeness of the two lists provided in section 6? For instance the MIB defines the pmip6Capabilities object with attribute MAX-ACCESS read-only (see p. 13). However this object is not listed in the security considerations sections. Is it a mistake? If yes, then does anything miss (I didn't check)? ** Clarification needed: It is said: "Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module." I'm rather surprised that no ACL (or similar) functionality be available. If IPsec is enabled, then hosts are authenticated (using one of several techniques) and it's no longer a big deal to check the authorizations associated to the peer. So that's surprising. BTW, you can maybe remove the redundant "even then," in above sentence. ** Wrong reference: It is said: "It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" Section is not the section of interest as it only focuses on the standardization status. More interesting sections in RFC3410 are: - section 6.3 "SNMPv3 security and administration", and in particular - section 7, in particular section 7.8 "user based security model". NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an issue, now it is. The last sentence of RFC3410/section 7.8 mentions on-going work on using AES in the user-based security model. If this work gave birth to an RFC, that's probably a good document to refer too. ** Obscur: The last sentence of this section: "It is then a customer/operator... them." could easily be improved (split the sentence, please). As such it remains rather obscure. I hope this is useful. Cheers, Vincent From j.schoenwaelder@jacobs-university.de Mon Apr 11 07:06:27 2011 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 29F353A6A18; Mon, 11 Apr 2011 07:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcGBvRVcpvk1; Mon, 11 Apr 2011 07:06:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E3D9028B23E; Mon, 11 Apr 2011 07:06:25 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85BF0C0023; Mon, 11 Apr 2011 16:06:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UP7MfTz+xZlf; Mon, 11 Apr 2011 16:06:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 228EDC0019; Mon, 11 Apr 2011 16:06:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D5C86176140B; Mon, 11 Apr 2011 16:06:19 +0200 (CEST) Date: Mon, 11 Apr 2011 16:06:19 +0200 From: Juergen Schoenwaelder To: Vincent Roca Message-ID: <20110411140619.GA91679@elstar.local> Mail-Followup-To: Vincent Roca , IESG , secdir@ietf.org, draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05 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: Mon, 11 Apr 2011 14:06:27 -0000 On Mon, Apr 11, 2011 at 03:50:47PM +0200, Vincent Roca wrote: > ** Clarification needed: > It is said: > "Even if the network itself is secure (for example by using IPsec), > even then, there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the objects > in this MIB module." > I'm rather surprised that no ACL (or similar) functionality > be available. If IPsec is enabled, then hosts are authenticated > (using one of several techniques) and it's no longer a big deal > to check the authorizations associated to the peer. So that's > surprising. > > BTW, you can maybe remove the redundant "even then," in above > sentence. This is boilerplate text reflecting agreements reached between the SEC ADs and the OPS ADs at that time and used since then (including the somewhat irritating "even then,". > ** Wrong reference: > It is said: > "It is RECOMMENDED that implementers consider the security features as > provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" > Section is not the section of interest as it only focuses > on the standardization status. More interesting sections in RFC3410 > are: > - section 6.3 "SNMPv3 security and administration", and in particular > - section 7, in particular section 7.8 "user based security model". > > NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an > issue, now it is. The last sentence of RFC3410/section 7.8 mentions > on-going work on using AES in the user-based security model. If this > work gave birth to an RFC, that's probably a good document to refer > too. RFC 3826 details how to use AES with SNMPv3. Again, this never made it into the boilerplate. Perhaps some new enthusiastic ADs get engaged to revise the boilerplate? ;-) > ** Obscur: > The last sentence of this section: > "It is then a customer/operator... them." > could easily be improved (split the sentence, please). As such it > remains rather obscure. Again, this is what the boilerplate says. Here is the pointer: http://ops.ietf.org/mib-security.html /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From vincent.roca@inrialpes.fr Mon Apr 11 07:29:45 2011 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 9BDF928C0F5; Mon, 11 Apr 2011 07:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 TP2R023ZxqoZ; Mon, 11 Apr 2011 07:29:43 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 0FC923A6A1A; Mon, 11 Apr 2011 07:29:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,339,1299452400"; d="scan'208";a="80585436" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 11 Apr 2011 16:29:42 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <20110411140619.GA91679@elstar.local> Date: Mon, 11 Apr 2011 16:29:42 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20110411140619.GA91679@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-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, 11 Apr 2011 14:29:45 -0000 Hi Juergen, I was not aware of the existence of this boilerplate. Of course, it changes a lot the situation. Thanks for the pointer. Concerning AES in SNMPv3, I guess that today no SEC AD would object if you add RFC3826 as an additional reference, even if not (yet!) in the official boilerplate ;-) Cheers, Vincent On Apr. 11 2011, 16:06, Juergen Schoenwaelder wrote: > On Mon, Apr 11, 2011 at 03:50:47PM +0200, Vincent Roca wrote: > >> ** Clarification needed: >> It is said: >> "Even if the network itself is secure (for example by using IPsec), >> even then, there is no control as to who on the secure network is >> allowed to access and GET/SET (read/change/create/delete) the objects >> in this MIB module." >> I'm rather surprised that no ACL (or similar) functionality >> be available. If IPsec is enabled, then hosts are authenticated >> (using one of several techniques) and it's no longer a big deal >> to check the authorizations associated to the peer. So that's >> surprising. >> >> BTW, you can maybe remove the redundant "even then," in above >> sentence. > > This is boilerplate text reflecting agreements reached between the SEC > ADs and the OPS ADs at that time and used since then (including the > somewhat irritating "even then,". > >> ** Wrong reference: >> It is said: >> "It is RECOMMENDED that implementers consider the security features as >> provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" >> Section is not the section of interest as it only focuses >> on the standardization status. More interesting sections in RFC3410 >> are: >> - section 6.3 "SNMPv3 security and administration", and in particular >> - section 7, in particular section 7.8 "user based security model". >> >> NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an >> issue, now it is. The last sentence of RFC3410/section 7.8 mentions >> on-going work on using AES in the user-based security model. If this >> work gave birth to an RFC, that's probably a good document to refer >> too. > > RFC 3826 details how to use AES with SNMPv3. Again, this never made it > into the boilerplate. Perhaps some new enthusiastic ADs get engaged to > revise the boilerplate? ;-) > >> ** Obscur: >> The last sentence of this section: >> "It is then a customer/operator... them." >> could easily be improved (split the sentence, please). As such it >> remains rather obscure. > > Again, this is what the boilerplate says. Here is the pointer: > > http://ops.ietf.org/mib-security.html > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From abegen@cisco.com Wed Apr 6 04:20:58 2011 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 A8F7D3A690F; Wed, 6 Apr 2011 04:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 lQtmzh1op6z4; Wed, 6 Apr 2011 04:20:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7515C3A6907; Wed, 6 Apr 2011 04:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=5432; q=dns/txt; s=iport; t=1302088961; x=1303298561; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Bpw9uAeXF1knMWiFbC96iA47CM9wlCEDJOXYj3QfNFc=; b=lQ1gh6K4lBWanK0KwugdfN4la6qGuFBVv3rmYyP4O8vuh1Q0ksl11p8P JLcFNtq4xKx1oKCkNdlQw67HvaMBwMElSYqaSfDfWbG4sXM1oWjOFNv4l yLhWzM9zjLaNiCR6fQjzgiwhsDJHKwMmhpxhzz1IshC7L8i6l5J6sb5I4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAHRMnE2rRDoH/2dsb2JhbACYLY1Ld3iIAZwpnCOFbASFTotX X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208";a="290366585" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2011 11:22:26 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p36BMQut021587; Wed, 6 Apr 2011 11:22:26 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); Wed, 6 Apr 2011 04:22:25 -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: Wed, 6 Apr 2011 04:21:14 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EB56974@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 Thread-Index: AcvzxmoOwCr5HXG7TFutkMKEhgYPygAhEl/g References: From: "Ali C. Begen (abegen)" To: "Charlie Kaufman" , , , X-OriginalArrivalTime: 06 Apr 2011 11:22:25.0956 (UTC) FILETIME=[E8240E40:01CBF44C] X-Mailman-Approved-At: Mon, 11 Apr 2011 08:18:17 -0700 Subject: Re: [secdir] secdir review of draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 11:20:58 -0000 Thanks Charlie. One comment below. > -----Original Message----- > From: Charlie Kaufman [mailto:charliek@microsoft.com] > Sent: Wednesday, April 06, 2011 12:16 AM > To: secdir@ietf.org; iesg@ietf.org; = draft-ietf-avtcore-ports-for-ucast-mcast-rtp.all@tools.ietf.org > Subject: secdir review of = draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 >=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.=A0 These comments were written primarily for = the benefit of the security area directors.=A0 Document > editors and WG chairs should treat these comments just like any other = last call comments. >=20 > This protocol deals with requesting and managing multicast and unicast = connection streams, and in particular dealing with > the case where they are coming through a NAT. The interesting security = threat in this case is one of DoS through > amplification, where the attacker with a small number of packets can = request that a source direct a large number of packets > towards the victim. Because these streams do not have the sorts of = acknowledgements that would force a TCP stream to > back off if the target were unresponsive, the possibility of this sort = of attack is particularly dangerous. >=20 > The RTP and RTCP protocols have no authentication infrastructure that = can be leveraged. There is a resumption that all > information is public and can be requested by any destination. (It is = possible that one could implement encryption at a higher > layer such that the data received would not be useful to someone who = doesn't know the key, but any such encryption is > beyond the scope of this protocol). This means that certain security = attacks are unavoidable. In particular, an attacker could > potentially exhaust the source or the network by requesting that data = from large numbers of locations simultaneously. And > an attacker that can act as a man-in-the-middle between source and = victim can initiate a flood of data and then get out of > the way. >=20 > This protocol attempts to assure that an attacker that can forge the = victim's IP address but cannot receive packets addressed > to the victim cannot mount an amplification DoS attack. It does that = by adding a "token" to various messages in the protocol. > The token is generated by the source when a context is set up and must = be supplied by the receiver in requests to modify the > data streams. In order to not add state at the source, they recommend = that the token be generated as an HMAC-SHA1 of the > concatenation of the client IP address, a client nonce (that is chosen = for the session and supplied with each request), and a > server timestamp (also chosen per session and supplied to prevent long = delayed replay). This closely matches the design of > "cookies" in other protocols. >=20 > The recommended use of HMAC-SHA1 may be slightly controversial, but = its security is more than adequate for this > application, it is a local decision on the part of the server, and the = I-D has excellent text on how and when implementations > should migrate to a different algorithm (in particular, referencing = HMAC-SHA2-256). >=20 > There is one aspect of the design that I could not figure out reading = the spec, and it would seem to relate to a security > vulnerability that the spec therefore does not close. The spec = recommends computing the token as a hash over a number of > fields including the source IP address but not the source port. It = appears that this is because the RTP and RTCP protocols use > different ports and they want to use the same token with both. This = introduces a threat, however, that if a node requests a > token, that token will be valid for all nodes that are NATted behind = the same IP address. An attacker in the inside of the The token depends on other things but they are available next to the = token in the response message. If a client asks for a token, and an = attacker captures that token along with the associated nonce and exp = time, then it can be used in an attack against this client. This is = mentioned in par. 1 of section 9.1.=20 For someone else with a different IP address to start an attack, it = needs to spoof victim's IP address in addition to the token and its = associated info. If spoofing is allowed in the network, you don't need a = token to cause harm. Here we rely on ingress filtering in multicast = networks to minimize this kind of risks.=20 > NATted network could therefore acquire a token, hand it off to a = co-conspirator outside the NATted network, and that co- > conspirator could use it to direct traffic at a different node inside = the network. It's not obvious what could or should be done > to mitigate this threat. The spec allows for - but recommends against = - using lots of different ports on the client side for > different purposes, but I couldn't figure out how the client knows how = all of those ports will be translated by the NAT. If there > were a separate token per port, this problem could be solved, but I = suspect there is some reason why that is impractical. We cannot have a specific token port since there could be several = similar apps running in the same system using this approach. -acbegen >=20 > --Charlie From jsalowey@cisco.com Mon Apr 11 15:14:27 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC521E0669; Mon, 11 Apr 2011 15:14:27 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECp6YbIC4AiZ; Mon, 11 Apr 2011 15:14:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 44B27E0668; Mon, 11 Apr 2011 15:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=562; q=dns/txt; s=iport; t=1302560066; x=1303769666; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=z/Xij4/EssG/7/vhfpzyK0h3KlAfMofggk9vV1ZFNCE=; b=hc/lWnclqDw2JO0IDQ4Dug3qFlFb2SFhG99kR5kwJLmh+tqI1Q9m/niF K3hC142awoE1U0U7VFLYJ5j44CvFINqsWxazEfYkgS4acHsRFIE1LnA/g ibzjr7zVhf+kWJf6fC777SuKn7HDFvjtzaBUzPjAnNsGImikyGb0gYQDo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABdto02tJXG//2dsb2JhbACmH3embpxIhW4EhVuHfYNq X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="427771452" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-1.cisco.com with ESMTP; 11 Apr 2011 21:07:07 +0000 Received: from [10.0.0.9] (rtp-vpn4-1596.cisco.com [10.82.214.60]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3BL75gL017961; Mon, 11 Apr 2011 21:07:06 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 14:08:52 -0700 Message-Id: <54B38DE0-95DA-4949-B19A-3F4964481E49@cisco.com> To: secdir@ietf.org, The IESG , draft-housley-rfc5008bis.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir Review of draft-housley-rfc5008bis-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:14: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. draft-housley-rfc5008bis-00 obsoletes RFC 5008 which defines suite B = algorithms for use in S/MIME. =20 I don't see any issues with the contents of the document or the security = considerations section. =20 From tena@huawei.com Mon Apr 11 15:40:38 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EFF60E0679; Mon, 11 Apr 2011 15:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.392 X-Spam-Level: X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rqKpX1D4B1G; Mon, 11 Apr 2011 15:40:35 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfc.amsl.com (Postfix) with ESMTP id 31342E066B; Mon, 11 Apr 2011 15:40:35 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJI00KX4B1VBK@usaga04-in.huawei.com>; Mon, 11 Apr 2011 16:15:31 -0500 (CDT) Received: from TingZousc1 ([10.193.34.188]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJI00HAUB1SON@usaga04-in.huawei.com>; Mon, 11 Apr 2011 16:15:31 -0500 (CDT) Date: Mon, 11 Apr 2011 14:15:29 -0700 From: Tina Tsou To: secdir@ietf.org Message-id: <000301cbf88d$9728ecf0$c57ac6d0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acv4jZV+9vUR9TciTJaRcQ7H4Fmbhw== Cc: draft-ietf-ledbat-survey@tools.ietf.org, 'IESG' , secdir@ietf.org Subject: [secdir] Review of draft-ietf-ledbat-survey-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:40:39 -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. A few comments: #1 2.1. Accuracy of delay-based congestion predictors P6 "Finally, in the case of fast or short-distance links, the majority of the measured delay can in fact be due to processing in the involved hosts; typically, this processing delay is not of interest, and it can underly fluctuations that are not related to the network at all." Would "underly" be "underlie"? #2 AFAIK, LEDBAT is one of the use-cases for ConEx, because there's no incentive to do LEDBAT while operators count volume, not congestion. PCN for inelastic traffic is nearly completely orthogonal to LEDBAT. But if PCN is used as the active queue mgmt algo for regular elastic traffic, it does have some overlap with LEDBAT, in that it keeps delay very low. But there the similarities end. If this I-D can clarify this relationship a little bit, it would be useful. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From jari.arkko@piuha.net Tue Apr 12 05:09:21 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E2D3E0737; Tue, 12 Apr 2011 05:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E44h0YNZgnqB; Tue, 12 Apr 2011 05:09:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfc.amsl.com (Postfix) with ESMTP id E04E5E0690; Tue, 12 Apr 2011 05:09:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5DB302CC38; Tue, 12 Apr 2011 15:09:18 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6dig48gJXgU; Tue, 12 Apr 2011 15:09:17 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D2FA22CC2F; Tue, 12 Apr 2011 15:09:17 +0300 (EEST) Message-ID: <4DA440ED.8000809@piuha.net> Date: Tue, 12 Apr 2011 15:09:17 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Vincent Roca References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:09:21 -0000 Thanks for your review, Vincent. Authors, any comments? Jari Vincent Roca kirjoitti: > 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. > > > Globally, the "Security Considerations" section is well > written and provides details for the associated risks. > It clearly RECOMMENDs the use of SNMPv3, which should not come > as a surprise given the risks associated to previous versions. > This "Security Considerations" section is globally similar > to that of RFC4295 (MIPv6 MIB). > > A few comments: > > ** What about the completeness of the two lists provided in > section 6? > For instance the MIB defines the pmip6Capabilities object with > attribute MAX-ACCESS read-only (see p. 13). However this object > is not listed in the security considerations sections. Is it > a mistake? If yes, then does anything miss (I didn't check)? > > > ** Clarification needed: > It is said: > "Even if the network itself is secure (for example by using IPsec), > even then, there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the objects > in this MIB module." > I'm rather surprised that no ACL (or similar) functionality > be available. If IPsec is enabled, then hosts are authenticated > (using one of several techniques) and it's no longer a big deal > to check the authorizations associated to the peer. So that's > surprising. > > BTW, you can maybe remove the redundant "even then," in above > sentence. > > > ** Wrong reference: > It is said: > "It is RECOMMENDED that implementers consider the security features as > provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" > Section is not the section of interest as it only focuses > on the standardization status. More interesting sections in RFC3410 > are: > - section 6.3 "SNMPv3 security and administration", and in particular > - section 7, in particular section 7.8 "user based security model". > > NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an > issue, now it is. The last sentence of RFC3410/section 7.8 mentions > on-going work on using AES in the user-based security model. If this > work gave birth to an RFC, that's probably a good document to refer > too. > > > ** Obscur: > The last sentence of this section: > "It is then a customer/operator... them." > could easily be improved (split the sentence, please). As such it > remains rather obscure. > > > I hope this is useful. > Cheers, > > Vincent > > From sgundave@cisco.com Tue Apr 12 07:36:17 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8FB58E07D3; Tue, 12 Apr 2011 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbvnvMWhh5CF; Tue, 12 Apr 2011 07:36:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 77320E07A0; Tue, 12 Apr 2011 07:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3132; q=dns/txt; s=iport; t=1302618976; x=1303828576; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=9x/cYZWiBzfmAAKAyfpG7rJo2zr2aiHbxlmtauW+BMI=; b=aaaIbJ2lI6UIefMzsEtVy5QdIlZYYjwy5H7lvTwUw/ngDey8+qBNQQXY GEQcHOD+STs03JLWXhdwst+6NXE/BjI/LRxFlMiQWALLZL+/N1J5SJl/O 0j98VrSpsPcmf5HooBbGGvkuMMB1JDwqBanI1Gd5rkGLiuHj1smABtL8p g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABpipE2tJV2Z/2dsb2JhbACmK3eIepw+nQOFbgSFW4gHg3U X-IronPort-AV: E=Sophos;i="4.64,195,1301875200"; d="scan'208";a="294568782" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2011 14:36:14 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3CEaDUf002645; Tue, 12 Apr 2011 14:36:14 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 07:36:13 -0700 Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Apr 2011 14:36:13 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 12 Apr 2011 07:36:34 -0700 From: Sri Gundavelli To: Jari Arkko , Vincent Roca Message-ID: Thread-Topic: SecDir review of draft-ietf-netlmm-pmipv6-mib-05 Thread-Index: Acv5HwVlLZzxOvgU6UqBCS/yMQdE0w== In-Reply-To: <4DA440ED.8000809@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Apr 2011 14:36:13.0781 (UTC) FILETIME=[F957D850:01CBF91E] X-Mailman-Approved-At: Tue, 12 Apr 2011 08:06:44 -0700 Cc: draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:36:17 -0000 Hi Jari, We will address these comments. Thanks Vincent for the review. Regards Sri On 4/12/11 5:09 AM, "Jari Arkko" wrote: > Thanks for your review, Vincent. Authors, any comments? > > Jari > > Vincent Roca kirjoitti: >> 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. >> >> >> Globally, the "Security Considerations" section is well >> written and provides details for the associated risks. >> It clearly RECOMMENDs the use of SNMPv3, which should not come >> as a surprise given the risks associated to previous versions. >> This "Security Considerations" section is globally similar >> to that of RFC4295 (MIPv6 MIB). >> >> A few comments: >> >> ** What about the completeness of the two lists provided in >> section 6? >> For instance the MIB defines the pmip6Capabilities object with >> attribute MAX-ACCESS read-only (see p. 13). However this object >> is not listed in the security considerations sections. Is it >> a mistake? If yes, then does anything miss (I didn't check)? >> >> >> ** Clarification needed: >> It is said: >> "Even if the network itself is secure (for example by using IPsec), >> even then, there is no control as to who on the secure network is >> allowed to access and GET/SET (read/change/create/delete) the objects >> in this MIB module." >> I'm rather surprised that no ACL (or similar) functionality >> be available. If IPsec is enabled, then hosts are authenticated >> (using one of several techniques) and it's no longer a big deal >> to check the authorizations associated to the peer. So that's >> surprising. >> >> BTW, you can maybe remove the redundant "even then," in above >> sentence. >> >> >> ** Wrong reference: >> It is said: >> "It is RECOMMENDED that implementers consider the security features as >> provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" >> Section is not the section of interest as it only focuses >> on the standardization status. More interesting sections in RFC3410 >> are: >> - section 6.3 "SNMPv3 security and administration", and in particular >> - section 7, in particular section 7.8 "user based security model". >> >> NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an >> issue, now it is. The last sentence of RFC3410/section 7.8 mentions >> on-going work on using AES in the user-based security model. If this >> work gave birth to an RFC, that's probably a good document to refer >> too. >> >> >> ** Obscur: >> The last sentence of this section: >> "It is then a customer/operator... them." >> could easily be improved (split the sentence, please). As such it >> remains rather obscure. >> >> >> I hope this is useful. >> Cheers, >> >> Vincent >> >> > From Sandra.Murphy@cobham.com Tue Apr 12 09:42:26 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9858FE0835; Tue, 12 Apr 2011 09:42:26 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSRSN9vVd5wl; Tue, 12 Apr 2011 09:42:25 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfc.amsl.com (Postfix) with ESMTP id C3E51E072E; Tue, 12 Apr 2011 09:42:25 -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 p3CGgOuS032685; Tue, 12 Apr 2011 11:42:24 -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 p3CGgO2t023897; Tue, 12 Apr 2011 11:42:25 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([65.38.193.21]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 12:42:24 -0400 Date: Tue, 12 Apr 2011 12:42:24 -0400 (Eastern Daylight Time) From: Sandra Murphy To: secdir@ietf.org, draft-kanno-tls-camellia@tools.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: 12 Apr 2011 16:42:24.0759 (UTC) FILETIME=[99FF6870:01CBF930] Cc: iesg@ietf.org Subject: [secdir] secdir review of draft-kanno-tls-camellia X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 16:42:26 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds new cipher suites to TLS that include the use of the Camilla algorithm. The document follows the format of other documents that have defined cipher suites to TLS. In most cases the text just points to those other documents. It is entirely possible that with sufficient time to study the 9 or 10 references that point to the definition of other cipher suites being cited as models for these cipher suites, I'd be able to view the document as obvious. Unfortunately I had neither the experience nor the time for sufficient study. So I found the text not clear about what other cipher suites were being invoked as models for the suites here. The security consideration section points to the sections in seven other similar documents. I have not been able to review that list of security considerations sections to see that they adequately cover the concers for this algorithm. But as this document is not proposing any novel new combinations of security features and (according to the document, not me) Camilla is very similar to AES, I presume that security considerations are adequately covered. I know of no security concerns specific to Camilla. The language in section 3 (cipher suite definitions) makes frequent mention of the way similar suites are defined elsewhere. As a person who is not au courant on cipher suites, I did not find the language obvious. Advanced Encryption Standard (AES) [20] authenticated encryption with additional data algorithms, AEAD_AES_128_GCM and AEAD_AES_256_GCM are described in RFC5116 [8]. And AES GCM cipher suites for TLS are described in RFC5288 [10]. AES and Camellia share common characteristics including key sizes and block length. CAMELLIA_128_GCM and CAMELLIA_256_GCM are defined according as those of AES. I believe that the authors mean that the definitions of the Cammilla suites are the same as in section 5.1 and 5.2 of 5116 and section 3 of 5288, with appropriate substitution of "Camilla" for "AES", but I am not sure which of the cipher suites in 2.1, 2.2 and 2.3 of this document are included. Particularly as the PSK suites listed in 2.3 would seem to be described in section 3.4 with reference to entirely other documents. Perhaps someone more experienced with cipher suites would think this was obvious, but I could have used a more explicit mapping between the suites defined here and the suites from which the descriptions are being borrowed. Section 3.4 is particularly opaque to my inexperienced eyes as to the mapping between these cipher suites and the similar cipher suites whose descriptiosn are being borrowed: PSK cipher suites for TLS are described in RFC4279 [5], RFC4785 [7], RFC5487 [12], and RFC5489 [13]. That is the complete description of the suites. Which ref applies to which suite in this document? --Sandy From vincent.roca@inrialpes.fr Tue Apr 12 23:51:02 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EC036E070E; Tue, 12 Apr 2011 23:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.049 X-Spam-Level: X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_46=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8yOngtiMQmF; Tue, 12 Apr 2011 23:51:01 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfc.amsl.com (Postfix) with ESMTP id 584D2E070D; Tue, 12 Apr 2011 23:51:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,203,1301868000"; d="scan'208";a="105527269" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 13 Apr 2011 08:50:59 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <4DA545C5.4050708@cysols.com> Date: Wed, 13 Apr 2011 08:50:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: <7197E8D0-E2DB-4148-A915-88E45CFE8797@inrialpes.fr> References: <4DA545C5.4050708@cysols.com> To: "Glenn M. Keeni" X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 06:51:03 -0000 Hi Glenn, >> ** What about the completeness of the two lists provided in >> section 6? >> For instance the MIB defines the pmip6Capabilities object with >> attribute MAX-ACCESS read-only (see p. 13). However this object >> is not listed in the security considerations sections. Is it >> a mistake? If yes, then does anything miss (I didn't check)? > This is not a mistake. Since it is read only, its value cannot > be changed by an attacker. And, revealing the capabilities cannot > be as harmful as other objects e.g. pmip6Status. [ I will agree > that a miscreant may want to physically destroy all objects that > have LMA and or MAG capabilities in order to shutdown a PMIPv6 > network. The pmip6Capabilities object may be misused in that manner. But > that is a generic argument, and holds for ALL the PMIPv6MIB > objects.] So, we have not listed this object as one which is > "particularly sensitive and/or private". > The generic risk aspects are covered in the last paragraph of the > security considerations section [copied from the boilerplate]. > The 2 lists are complete to our knowledge. > Please let us know if there are any risks/vulnerabilities that > are worth mentioning. If there are good reasons not to list this object, I don't have any objection. > The remaining comments relate to the boilerplate which we have > followed to the dot. Yes, this is what Juergen explained. Maybe it's time to update the boilerplate a little bit, but that's a different topic. Cheers, Vincent From shanna@juniper.net Wed Apr 13 16:12:08 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B1E8E07E2; Wed, 13 Apr 2011 16:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4reP3gZHjQF; Wed, 13 Apr 2011 16:12:07 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfc.amsl.com (Postfix) with ESMTP id EE0ECE0697; Wed, 13 Apr 2011 16:12:03 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTaYtwz48Oh501z2Q4iUWGf3UzBJh28x/@postini.com; Wed, 13 Apr 2011 16:12:07 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Apr 2011 16:07:48 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 13 Apr 2011 19:09:43 -0400 From: Stephen Hanna To: "secdir@ietf.org" , "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" Date: Wed, 13 Apr 2011 19:09:42 -0400 Thread-Topic: secdir review of draft-kuegler-ipsecme-pace-ikev2 Thread-Index: Acv6KnQNJjKHUmOhRfWAHDOyjDtUyA== 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: "iesg@ietf.org" Subject: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 23:12:08 -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 defines a password authentication protocol for IKEv2 based on PACE (Password Authenticated Connection Establishment). I am neither a cryptographer nor an expert on IPsec or IKEv2. Given these limitations, I will say that I found the Security Considerations section of the document to be thorough. All of the security issues that I could come up with and more were addressed in a credible manner. Overall, the document is clear and well-written. Personally, I do not have any concerns with this document becoming an RFC. However, it might be wise to wise to have a cryptographer or expert in authentication protocols provide an independent review of the document, if that has not already been done. If it has been done, I have no concerns. Thanks, Steve Hanna From yaronf.ietf@gmail.com Thu Apr 14 00:04:47 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5211FE0675 for ; Thu, 14 Apr 2011 00:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKazqLr+wJQN for ; Thu, 14 Apr 2011 00:04:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 6ADADE065A for ; Thu, 14 Apr 2011 00:04:46 -0700 (PDT) Received: by wyb29 with SMTP id 29so1251700wyb.31 for ; Thu, 14 Apr 2011 00:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z3cYM9S4aGC6jk1gimhRHcSWHyBvKsb0bYmtPhrwMFE=; b=ff+DF41Zfc27AQEhOvU4BVKcrYI5siekjdo6/twn3qluW42y6uG1L+hjtkxWiEtkMf m9q6/C/5IitujErnRog/xHtkmx8uGbRBGO0GCaME06VC3I5HxLWzk5sT9tkVhYWyqjyU n2IrkD2vWXABmnN79rCB0iKgmK+RYGGR9ZmEo= 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=sxBMQ68ccH5vtk+LLWTNybiqy74fgZTS2EiQar6M1BtPBH+gNy5entTSbukaZjDMws UtTMNUzLZ3/zBXUlG+xme8hwOXxtQTFbduRlqYEvIoSAOy00eB5TtCmPKw7kwYqoV+Kw tcYOwAYRuyoWUBsImOUiuRsgMYH53AuzG8Fm0= Received: by 10.227.202.79 with SMTP id fd15mr400262wbb.216.1302764685778; Thu, 14 Apr 2011 00:04:45 -0700 (PDT) Received: from [10.0.0.5] (46-116-74-16.bb.netvision.net.il [46.116.74.16]) by mx.google.com with ESMTPS id h11sm786459wbc.43.2011.04.14.00.04.44 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 00:04:45 -0700 (PDT) Message-ID: <4DA69C8A.7000305@gmail.com> Date: Thu, 14 Apr 2011 10:04:42 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Stephen Hanna References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 07:04:47 -0000 Hi Steve, thanks for your review. This document was published on the ipsecme list. During Last Call we received comments form Dan Harkins, who is certainly "an expert in authentication protocols." The cryptographic part (PACE) has been published in the past, both as an academic paper and as a component of another standard. Both are referenced in the draft. Thanks, Yaron On 04/14/2011 02:09 AM, 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 defines a password authentication protocol for IKEv2 > based on PACE (Password Authenticated Connection Establishment). > > I am neither a cryptographer nor an expert on IPsec or IKEv2. > Given these limitations, I will say that I found the Security > Considerations section of the document to be thorough. All of > the security issues that I could come up with and more were > addressed in a credible manner. Overall, the document is clear > and well-written. Personally, I do not have any concerns with > this document becoming an RFC. However, it might be wise to > wise to have a cryptographer or expert in authentication protocols > provide an independent review of the document, if that has not > already been done. If it has been done, I have no concerns. > > Thanks, > > Steve Hanna > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From weiler+secdir@watson.org Thu Apr 14 08:33:55 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1FE6DE0746 for ; Thu, 14 Apr 2011 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXfvMj9bt4DN for ; Thu, 14 Apr 2011 08:33:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfc.amsl.com (Postfix) with ESMTP id 61E27E073F for ; Thu, 14 Apr 2011 08:33:53 -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 p3EFXquM073097 for ; Thu, 14 Apr 2011 11:33:52 -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 p3EFXqMX073094 for ; Thu, 14 Apr 2011 11:33:52 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 14 Apr 2011 11:33:52 -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]); Thu, 14 Apr 2011 11:33:52 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:33:55 -0000 Several of today's new assignments are for documents on the telechat in two weeks. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Alexey Melnikov is next in the rotation. (Welcome back!) For telechat 2011-04-28 Reviewer LC end Draft Dave Cridland T 2011-04-13 draft-ietf-ipsecme-ipsecha-protocol-05 Shawn Emery T 2011-04-18 draft-ietf-sidr-roa-validation-10 Scott Kelly T 2011-04-25 draft-ietf-dnsop-as112-ops-06 Tero Kivinen T 2011-04-25 draft-ietf-dnsop-as112-under-attack-help-help-05 Julien Laganier T 2011-04-25 draft-ietf-dnsop-default-local-zones-15 Catherine Meadows T 2011-04-20 draft-paxson-tcpm-rfc2988bis-02 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2011-04-27 draft-arkko-mikey-iana-00 Rob Austein 2011-05-03 draft-haleplidis-forces-implementation-experience-02 Richard Barnes 2011-04-23 draft-harkins-ipsecme-spsk-auth-03 Uri Blumenthal 2011-04-18 draft-ietf-idr-bgp-identifier-13 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Alan DeKok 2011-04-15 draft-ietf-kitten-digest-to-historic-03 Donald Eastlake 2011-04-11 draft-ietf-mif-current-practices-09 Shawn Emery 2011-02-21 draft-ietf-ecrit-phonebcp-17 Tobias Gondrom 2011-04-20 draft-ietf-siprec-req-09 Phillip Hallam-Baker 2011-04-12 draft-ietf-softwire-dual-stack-lite-07 Dan Harkins 2011-05-03 draft-mavrogiannopoulos-ssl-version3-03 Sam Hartman 2011-04-23 draft-shin-augmented-pake-04 Love Hornquist-Astrand - draft-daboo-et-al-icalendar-in-xml-08 Jeffrey Hutzelman 2011-04-26 draft-ietf-avtext-multicast-acq-rtcp-xr-04 Charlie Kaufman 2011-04-20 draft-ietf-dime-extended-naptr-06 Stephen Kent 2011-04-20 draft-ietf-ippm-tcp-throughput-tm-12 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Barry Leiba 2011-04-20 draft-ietf-vcarddav-vcardrev-19 Matt Lepinski 2011-04-20 draft-ietf-vcarddav-vcardxml-09 Chris Lonvick 2011-05-04 draft-josefsson-gss-capsulate-04 David McGrew - draft-ietf-ecrit-framework-12 David McGrew 2011-05-09 draft-lear-iana-timezone-database-03 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Sam Weiler 2011-03-24 draft-ietf-sidr-roa-format-10 Nico Williams 2011-03-24 draft-ietf-sidr-rpki-manifests-10 Glen Zorn 2011-04-10 draft-ietf-netext-redirect-07 From nico@cryptonector.com Thu Apr 14 08:39:33 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A2AF5E08B9 for ; Thu, 14 Apr 2011 08:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag3gIKOgb2ER for ; Thu, 14 Apr 2011 08:39:32 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfc.amsl.com (Postfix) with ESMTP id AA8F6E08B1 for ; Thu, 14 Apr 2011 08:39:32 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E239967809B for ; Thu, 14 Apr 2011 08:39:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=LJLW+NsP5CCaR8X4GN7Em KbqZD3cOdbMrI6ZACu+H1peGilyJPZazbzppLDIbIcscjEwpval5Scz2e2TjT+AZ bZbuyW7Teu8Zh4NwDaaAYaeSp6h+im8IS5kTAW0nFbsaWeZ5yZlr4tfhwZ+YyjgT /TFEXM5fJqtR3K3c9FsH8c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=95BwcV46u8R6y8YHWe79 I/sXtWM=; b=YLx+tDusuM8j0WKunj/AtjorSgqqCKkA7BAfS/gTE9tBtyQ7bCQj SwgPK1i/1He+fH2p1CENI9zKmJeff9JUCWuX+S3Ol3vNlMhy9sTTnnGY0B0FX/lZ rTZhHRiVafKTIDzccMjnBMlFlddsg71ygiLTkISyUR+tfn8AxPlVHdg= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id F2BB4678056 for ; Thu, 14 Apr 2011 08:38:33 -0700 (PDT) Received: by vxg33 with SMTP id 33so1744715vxg.31 for ; Thu, 14 Apr 2011 08:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.130 with SMTP id l2mr1378005vdv.14.1302795512720; Thu, 14 Apr 2011 08:38:32 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 08:38:32 -0700 (PDT) In-Reply-To: <4DA69C8A.7000305@gmail.com> References: <4DA69C8A.7000305@gmail.com> Date: Thu, 14 Apr 2011 10:38:32 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:39:33 -0000 [Resend. Forgot to reply-all.] On Thu, Apr 14, 2011 at 2:04 AM, Yaron Sheffer wrote: > This document was published on the ipsecme list. During Last Call we > received comments form Dan Harkins, who is certainly "an expert in > authentication protocols." > > The cryptographic part (PACE) has been published in the past, both as an > academic paper and as a component of another standard. Both are referenced > in the draft. PACE does not use a standard PBKDF. That's not necessarily a problem, of course, but it could be. There's no iteration count, for example, in the SPwd nor KPwd derivations (an iteration count belongs in the SPwd derivation, if anything). Nor is there any password salting(!), nor any discussion regarding the absence of salting. The lack of salting should be considered fatal, IMO. The lack of an iteration count is less significant, but I'd still rather see an iteration count. Note that negotiating a salt and iteration count requires an extra round-trip. And note that iteration count negotiation has security considerations. Of course, PACE is targeting Experimental... do we care about cryptographic issues in Experimental RFCs? I'd say we should, though less so than for Standards Track RFCs since we can only spare so much energy. I'm rather disappointed to see this wheel reinvented. SCRAM (RFC5802) would fit right in instead of PACE, for example, and has the same kinds of properties as PACE, but with a number of advantages over PACE (SCRAM is on the Standards Track, received much more review, uses a PBKDF with salt and iteration count, is implemented, is reusable in many contexts, does channel binding, there's an LDAP schema for storing SCRAM password verifiers, ...). We, secdir, should be encouraging wheel reuse wherever possible over wheel reinvention. Nico -- From paul.hoffman@vpnc.org Thu Apr 14 09:00:52 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 310CCE0783 for ; Thu, 14 Apr 2011 09:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.843 X-Spam-Level: X-Spam-Status: No, score=-101.843 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNTPndX4iUnb for ; Thu, 14 Apr 2011 09:00:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id 683A7E0762 for ; Thu, 14 Apr 2011 09:00:51 -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 p3EG0j11045495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Apr 2011 09:00:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 14 Apr 2011 09:00:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DA69C8A.7000305@gmail.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:00:52 -0000 On Apr 14, 2011, at 8:38 AM, Nico Williams wrote: > Of course, PACE is targeting Experimental... do we care about > cryptographic issues in Experimental RFCs? I'd say we should, though > less so than for Standards Track RFCs since we can only spare so much > energy. If we "care about" such things, they should be discussed on open mailing = lists, particularly if you are criticizing academic publications related = to the document. > I'm rather disappointed to see this wheel reinvented. SCRAM (RFC5802) > would fit right in instead of PACE, for example, and has the same > kinds of properties as PACE, but with a number of advantages over PACE > (SCRAM is on the Standards Track, received much more review, uses a > PBKDF with salt and iteration count, is implemented, is reusable in > many contexts, does channel binding, there's an LDAP schema for > storing SCRAM password verifiers, ...). >=20 > We, secdir, should be encouraging wheel reuse wherever possible over > wheel reinvention. "We" never have encouraged that. Many of "us" are chairs of WGs whose = charters explicitly allow or mandate the opposite of what you are = proposing. If you want a change, it has to come from the ADs, not from = "us". --Paul Hoffman From nico@cryptonector.com Thu Apr 14 09:29:13 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C687DE08ED for ; Thu, 14 Apr 2011 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhURmOYx-GCT for ; Thu, 14 Apr 2011 09:29:13 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfc.amsl.com (Postfix) with ESMTP id C926BE08E6 for ; Thu, 14 Apr 2011 09:29:09 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id D27A0674082 for ; Thu, 14 Apr 2011 09:29:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=qlGKKgFKLI8ss01sWSLi5BH9l/2NS77M8p00Z6hudYV3 n5gc/5qnweOvAmv75sw8hatodxL09UjxQ4R6l8+8apiIFK9nNbCxl/D4kSs6nWBP RkfGKr6ixi9N9ahATpOz36FrRK2Ow3yUONqAkilZFASIbZXr3uiA9AYuYlVZetI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=FxCq3RXSVTGQgJ+FGipgsi+aBw8=; b=Eg4tfkhbirB F9BL3HE32qALMicCzkryzH6x2BHwopsnhsIdDnOwkeoIxxTfq6cj1bv0wmTlrGmu j+to6AOG7uhJPWg1yKXlkq+J2eqJtRHel60oGqoiHn336gVJvHgzVMxwroDbrqwS tM7oUHHcn709jxc4SbilRKyQ96EVJU38= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id AFA9A67407C for ; Thu, 14 Apr 2011 09:29:08 -0700 (PDT) Received: by vws12 with SMTP id 12so1812231vws.31 for ; Thu, 14 Apr 2011 09:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.8 with SMTP id eq8mr1342673vdc.214.1302798547926; Thu, 14 Apr 2011 09:29:07 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 09:29:07 -0700 (PDT) In-Reply-To: References: <4DA69C8A.7000305@gmail.com> Date: Thu, 14 Apr 2011 11:29:07 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:29:13 -0000 On Thu, Apr 14, 2011 at 11:00 AM, Paul Hoffman wrot= e: > On Apr 14, 2011, at 8:38 AM, Nico Williams wrote: >> Of course, PACE is targeting Experimental... do we care about >> cryptographic issues in Experimental RFCs? =C2=A0I'd say we should, thou= gh >> less so than for Standards Track RFCs since we can only spare so much >> energy. > > If we "care about" such things, they should be discussed on open mailing = lists, particularly if you are criticizing academic publications related to= the document. I'm not sure what you mean. I cc'ed all, and reviewers are supposed to cc authors, so the authors should have a copy of my reply. Also, over on the IPsec list we've been discussing password-based mechanisms (though not this one, yet, because I didn't know it was progressing so fast). Since I just became aware of these issues as a result of a secdir posting, that's where I replied. Are you suggesting that secdir reviews should always be cc'ed to the lists where the I-Ds in question were first reviewed? Or that responders to secdir reviews should do so? Did I do something wrong? Really? >> I'm rather disappointed to see this wheel reinvented. =C2=A0SCRAM (RFC58= 02) >> would fit right in instead of PACE, for example, and has the same >> kinds of properties as PACE, but with a number of advantages over PACE >> (SCRAM is on the Standards Track, received much more review, uses a >> PBKDF with salt and iteration count, is implemented, is reusable in >> many contexts, does channel binding, there's an LDAP schema for >> storing SCRAM password verifiers, ...). >> >> We, secdir, should be encouraging wheel reuse wherever possible over >> wheel reinvention. > > "We" never have encouraged that. Many of "us" are chairs of WGs whose cha= rters explicitly allow or mandate the opposite of what you are proposing. I= f you want a change, it has to come from the ADs, not from "us". "We", secdir, are volunteers. This volunteer would rather avoid wheel reinvention, and this volunteer, perhaps naively, had hoped others would agree. Perhaps other volunteers disagree (you do). I explicitly referred to secdir, not WG chairs, not ADs, nor did I refer to actual current practice, but rather stated an opinion of what we ought to do. All that aside, is it really the case that "we" (secdir) don't mind the lack of salting? Really?! In 2011, four decades or so since the invention of salting? Or did you really just mean to criticize me for not cc'ing the IPsec list on my reply? Nico -- From yaronf.ietf@gmail.com Thu Apr 14 09:52:12 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A671E08D2 for ; Thu, 14 Apr 2011 09:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsgewyrV0Qee for ; Thu, 14 Apr 2011 09:52:11 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 02A48E08D5 for ; Thu, 14 Apr 2011 09:52:10 -0700 (PDT) Received: by wwa36 with SMTP id 36so1509517wwa.13 for ; Thu, 14 Apr 2011 09:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zUrt3E/4IcIaHOlPmV2PHUzRCmkoGkp+at9184iHd/g=; b=kbo36N2uX6SzbqGtsNgiLsuRyjcXg+9BM0Kz08Z1dMq+dZq7vB97ZokhotQNBQ6yj9 20qZB3fHhiA6AlyXlotDr8rZnqcPOdaqFAedz+iv9KyPk82PX5ga2Vcb/i5VcRO4+ZOB qQvifO5c19EPk9w2XKJc8jCjv0ggssKEv8pmc= 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=ZX9qHiFbscPpzyO0m/z+wD/5sTNg58tzdCdwF1occTQjwdtMNa5anQXdg9TlsaCOd7 LkEz/09OQegJsT2lSaGdHFbbSXKtQc8furzRKt7U+1OUvigSfgZN9t4QEJNCFe2yBc7x KEem0WN1OH4OejViHkY4ubmswXsyRw3sXvFnM= Received: by 10.216.145.222 with SMTP id p72mr2191320wej.26.1302799883817; Thu, 14 Apr 2011 09:51:23 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-177-21-107.red.bezeqint.net [79.177.21.107]) by mx.google.com with ESMTPS id p5sm1110347wbg.45.2011.04.14.09.51.20 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 09:51:22 -0700 (PDT) Message-ID: <4DA72605.10506@gmail.com> Date: Thu, 14 Apr 2011 19:51:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nico Williams References: <4DA69C8A.7000305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:52:12 -0000 I'm sorry Nico, I simply don't understand where the rant in the second part of your mail is coming from. A few days ago you bombarded the ipsec mailing list with your opinions on authentication infrastructure (some of which I happen to share), without taking the time to figure out the context: the set of drafts that the WG consciously decided NOT to pursue and that finally are able to progress. I'm amazed at the comparison of PACE with SCRAM. In a previous mail you pointed out yourself that SCRAM is vulnerable to on-the-wire dictionary attacks, which PACE is not. The IETF had never managed to standardize any ZKPP methods until just recently (with the exception of TLS-SRP), and finally we're doing something about it, even if on the Experimental track. I believe this counts as a positive contribution to the security of the Internet. I agree that salting the stored password (SPwd) would have improved the security of this protocol (unlike iteration counts). And it can be added with no extra round trips, since it's not "negotiated", just sent by the responder. My coauthor and I need to consider the benefits vs. costs, since the major use case here is not open servers, more often it would be VPN gateways. Thanks, Yaron On 04/14/2011 06:38 PM, Nico Williams wrote: > [Resend. Forgot to reply-all.] > > On Thu, Apr 14, 2011 at 2:04 AM, Yaron Sheffer > wrote: > > This document was published on the ipsecme list. During Last Call we > > received comments form Dan Harkins, who is certainly "an expert in > > authentication protocols." > > > > The cryptographic part (PACE) has been published in the past, both as an > > academic paper and as a component of another standard. Both are > referenced > > in the draft. > > PACE does not use a standard PBKDF. That's not necessarily a problem, > of course, but it could be. There's no iteration count, for example, > in the SPwd nor KPwd derivations (an iteration count belongs in the > SPwd derivation, if anything). Nor is there any password salting(!), > nor any discussion regarding the absence of salting. The lack of > salting should be considered fatal, IMO. The lack of an iteration > count is less significant, but I'd still rather see an iteration > count. Note that negotiating a salt and iteration count requires an > extra round-trip. And note that iteration count negotiation has > security considerations. > > Of course, PACE is targeting Experimental... do we care about > cryptographic issues in Experimental RFCs? I'd say we should, though > less so than for Standards Track RFCs since we can only spare so much > energy. > > I'm rather disappointed to see this wheel reinvented. SCRAM (RFC5802) > would fit right in instead of PACE, for example, and has the same > kinds of properties as PACE, but with a number of advantages over PACE > (SCRAM is on the Standards Track, received much more review, uses a > PBKDF with salt and iteration count, is implemented, is reusable in > many contexts, does channel binding, there's an LDAP schema for > storing SCRAM password verifiers, ...). > > We, secdir, should be encouraging wheel reuse wherever possible over > wheel reinvention. > > Nico > -- From nico@cryptonector.com Thu Apr 14 09:54:22 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8DD1AE0800 for ; Thu, 14 Apr 2011 09:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_11=1, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La4W7TOEt0Nh for ; Thu, 14 Apr 2011 09:54:21 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfc.amsl.com (Postfix) with ESMTP id 87519E078C for ; Thu, 14 Apr 2011 09:54:21 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id A68D5B8058 for ; Thu, 14 Apr 2011 09:54:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=gWQMtzQZWvK7eAD5kWGJeZo9qDRdTt9FDjlHdmdS0W/Z s8oKq7GqzMWvYEOgjbw+UoAwphhEyRZafj3SBSB752LejrARB4IZrejWV6ZglR42 yT5awPUqgejlQie4MYoMVT8R8VxQthF/8NipGYR+kReF+g0kUI7BGujOSeVvNc0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=XcCAj7momQ+W+wtq4JeXamP/hJA=; b=RNkOgva2N3r QP7oJP5VKxgVZD8xFsA/sZ35RJNtVmqftmsjCqCaQOAA6GXXbd9OzJ8f+GrgCY6V C++a/ZwKrtB5xX/BHz1QZeYfAKbA0li88kumOlhmFCRzj5Jiir09Dj64ZcrHfzyi YUHA35pFeyQty9VWGnyxkeO3AueglF1s= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 7331BB8056 for ; Thu, 14 Apr 2011 09:54:20 -0700 (PDT) Received: by vws12 with SMTP id 12so1840139vws.31 for ; Thu, 14 Apr 2011 09:54:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.112.69 with SMTP id io5mr1405656vdb.94.1302800059876; Thu, 14 Apr 2011 09:54:19 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 09:54:19 -0700 (PDT) In-Reply-To: <201104141839.13739.dennis.kuegler@bsi.bund.de> References: <4DA69C8A.7000305@gmail.com> <201104141839.13739.dennis.kuegler@bsi.bund.de> Date: Thu, 14 Apr 2011 11:54:19 -0500 Message-ID: From: Nico Williams To: =?UTF-8?Q?Dennis_K=C3=BCgler?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:54:22 -0000 On Thu, Apr 14, 2011 at 11:39 AM, Dennis K=C3=BCgler wrote: >> PACE does not use a standard PBKDF. =C2=A0That's not necessarily a probl= em, >> of course, but it could be. =C2=A0There's no iteration count, for exampl= e, >> in the SPwd nor KPwd derivations (an iteration count belongs in the >> SPwd derivation, if anything). =C2=A0Nor is there any password salting(!= ), >> nor any discussion regarding the absence of salting. =C2=A0The lack of >> salting should be considered fatal, IMO. =C2=A0The lack of an iteration >> count is less significant, but I'd still rather see an iteration >> count. =C2=A0Note that negotiating a salt and iteration count requires a= n >> extra round-trip. =C2=A0And note that iteration count negotiation has >> security considerations. > > "Standard" PBKDF are used to artifically enhance the entopy of the passwo= rd, > because low-entropy passwords are easy targets for dictionary attacks. PA= CE > is a cryptographic protocol that is designed to (mathematically) withstan= d > (passive) dictionary attacks independent of the strength of the password = and > therefore there is no need for additional countermeasures like salting th= e > password. Salting is still useful regarding password verifier security. Recall that salting was originally invented for that purpose, long before the first challenge/response password protocols were invented. >> Of course, PACE is targeting Experimental... do we care about >> cryptographic issues in Experimental RFCs? =C2=A0I'd say we should, thou= gh >> less so than for Standards Track RFCs since we can only spare so much >> energy. >> >> I'm rather disappointed to see this wheel reinvented. =C2=A0SCRAM (RFC58= 02) >> would fit right in instead of PACE, for example, and has the same >> kinds of properties as PACE, but with a number of advantages over PACE >> (SCRAM is on the Standards Track, received much more review, uses a >> PBKDF with salt and iteration count, is implemented, is reusable in >> many contexts, does channel binding, there's an LDAP schema for >> storing SCRAM password verifiers, ...). > > Actually, the protocols have very different properties. SCRAM (more or le= ss) > requires a public key infrastucture in place, while PACE provides an > authenticated and encrypted channel without any additional security layer= . As far as I can tell PACE provides a secure but not authenticated channel. In Figure 1 I don't see anything that would authenticate the channel other than the shared secret (derived from a password). There is a KE exchange however, which protects PACE against passive attacks, but not against active attacks. Did I miss something else? If not then iteration counts add some value, no? Also, regarding SCRAM, yes, it's intended to be used, ideally, with a secure, authenticated channel and channel binding to that channel. This is not unlike what PACE does, actually, except that PACE builds that channel itself -- but why do that when IKE can already do that anyways? Or, another way to phrase that: you could have done the same thing with SCRAM, something like: I->R: HDR, SAi1, KEi, Ni, R->I: HDR, SAr1, KEr, Nr, I<->R: You get the same properties this way as in PACE, plus salting, plus iteration counts. Plus a Standards Track solution. Plus specification and code reuse. Plus less reviewing to do because the security analysis becomes simpler because the security analysis for SCRAM has been done. >> We, secdir, should be encouraging wheel reuse wherever possible over >> wheel reinvention. > > Once you decide to abandon those simple and insecure password-based > challenge/response protocols, feel free to make use of PACE instead of > reinventing the wheel :-) SCRAM is no less secure than PACE when used as intended: with channel binding to a secure channel, and arguably (that is, I'm arguing this) it's more secure than PACE. Nico -- From paul.hoffman@vpnc.org Thu Apr 14 09:56:54 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D72E3E0836 for ; Thu, 14 Apr 2011 09:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.612 X-Spam-Level: X-Spam-Status: No, score=-101.612 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIL0OfO7+upY for ; Thu, 14 Apr 2011 09:56:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id E5BDAE0800 for ; Thu, 14 Apr 2011 09:56:53 -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 p3EGunwl048387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Apr 2011 09:56:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 14 Apr 2011 09:56:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BC90BF4-8FEB-4986-A0F2-9B3792525EB8@vpnc.org> References: <4DA69C8A.7000305@gmail.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:56:55 -0000 On Apr 14, 2011, at 9:29 AM, Nico Williams wrote: > On Thu, Apr 14, 2011 at 11:00 AM, Paul Hoffman = wrote: >> On Apr 14, 2011, at 8:38 AM, Nico Williams wrote: >>> Of course, PACE is targeting Experimental... do we care about >>> cryptographic issues in Experimental RFCs? I'd say we should, = though >>> less so than for Standards Track RFCs since we can only spare so = much >>> energy. >>=20 >> If we "care about" such things, they should be discussed on open = mailing lists, particularly if you are criticizing academic publications = related to the document. >=20 > I'm not sure what you mean. =20 I mean that the closed secdir mailing list is not an appropriate place = to be discussing proposed problems with crypto protocols if the intended = result is that they protocols will change or that serious design = discussions happen. > I cc'ed all, and reviewers are supposed > to cc authors, so the authors should have a copy of my reply. =20 That is not an open discussion, that forces people who are not on this = mailing list to go through intermediaries. > Also, > over on the IPsec list we've been discussing password-based mechanisms > (though not this one, yet, because I didn't know it was progressing so > fast). Since I just became aware of these issues as a result of a > secdir posting, that's where I replied. No problem there: I was discussing what "we" should do if "we" want = discussions to have results. > Are you suggesting that secdir reviews should always be cc'ed to the > lists where the I-Ds in question were first reviewed? Or that > responders to secdir reviews should do so? Did I do something wrong? > Really? No, no, no, and no. >>> I'm rather disappointed to see this wheel reinvented. SCRAM = (RFC5802) >>> would fit right in instead of PACE, for example, and has the same >>> kinds of properties as PACE, but with a number of advantages over = PACE >>> (SCRAM is on the Standards Track, received much more review, uses a >>> PBKDF with salt and iteration count, is implemented, is reusable in >>> many contexts, does channel binding, there's an LDAP schema for >>> storing SCRAM password verifiers, ...). >>>=20 >>> We, secdir, should be encouraging wheel reuse wherever possible over >>> wheel reinvention. >>=20 >> "We" never have encouraged that. Many of "us" are chairs of WGs whose = charters explicitly allow or mandate the opposite of what you are = proposing. If you want a change, it has to come from the ADs, not from = "us". >=20 > "We", secdir, are volunteers. This volunteer would rather avoid wheel > reinvention, and this volunteer, perhaps naively, had hoped others > would agree. Perhaps other volunteers disagree (you do). I > explicitly referred to secdir, not WG chairs, not ADs, nor did I refer > to actual current practice, but rather stated an opinion of what we > ought to do. Most people on secdir are here because they are chairs of WGs in the = Security Area. Maybe you are thinking of the old secdir model. :-) > All that aside, is it really the case that "we" (secdir) don't mind > the lack of salting? Really?! In 2011, four decades or so since the > invention of salting? =20 I read the paper in the PACE document and thought that it covered the = design well. I even looked for follow-ups to the paper and found none = (although some may have appeared since I looked). Maybe I'm naive, but I = tend to assume that academic review of crypto papers on which there is = also discussion in IETF WGs is sufficient for publishing something as an = Experimental RFC.=20 > Or did you really just mean to criticize me for > not cc'ing the IPsec list on my reply? No. If I meant to do that, I would have. This proposal has already been = discussed in the WG for a bit over a year. --Paul Hoffman From nico@cryptonector.com Thu Apr 14 09:57:51 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AC7C1E08E7 for ; Thu, 14 Apr 2011 09:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsUwq9hugu+G for ; Thu, 14 Apr 2011 09:57:51 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfc.amsl.com (Postfix) with ESMTP id EDD60E0718 for ; Thu, 14 Apr 2011 09:57:50 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 255F22C807A for ; Thu, 14 Apr 2011 09:57:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=d+MN34JYLm8IiX7GXfGmr sjKHonj9uufidjLGdiFr3iinz0FhlyF9jPUpeSs35x+TUzc/EW8fmHCL7YG71j22 mNO9yIIvPqXHag488xBcyD5KwF1VGFSHY1RW6CEjA08hOSyQioK1PDg2YQjoCKG5 NAnInP4XNYiiYsDvFbl0HQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=K4Gnb2jYffrGHBY7K7zq ca7bqIU=; b=h2QwY2kecCk7uE+S9D48T7EMqzaPlN7cdA84vetbOPYAAJrwRR3+ g1ZM+xwRsvMNKfEt738k69WN/A9j/fiPeejbrIq0fxzNDrIXO3T4HT6gmlTT40UO f9gR+QW1ixVz5+vAKJxjXhub64KWMy1BMRyrZxUceSqJJ0JLAIHsz3w= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id EDBC82C806C for ; Thu, 14 Apr 2011 09:57:49 -0700 (PDT) Received: by vws12 with SMTP id 12so1844021vws.31 for ; Thu, 14 Apr 2011 09:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.130 with SMTP id l2mr1500353vdv.14.1302800269317; Thu, 14 Apr 2011 09:57:49 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 09:57:49 -0700 (PDT) In-Reply-To: <4DA72605.10506@gmail.com> References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> Date: Thu, 14 Apr 2011 11:57:49 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:57:51 -0000 On Thu, Apr 14, 2011 at 11:51 AM, Yaron Sheffer wrote: > I'm amazed at the comparison of PACE with SCRAM. In a previous mail you > pointed out yourself that SCRAM is vulnerable to on-the-wire dictionary > attacks, which PACE is not. The IETF had never managed to standardize any > ZKPP methods until just recently (with the exception of TLS-SRP), and > finally we're doing something about it, even if on the Experimental track. I > believe this counts as a positive contribution to the security of the > Internet. This betrays a fundamental misunderstanding of SCRAM and channel binding. SCRAM with channel binding to a secure channel is as secure as PACE, and arguably more so. If you do not understand what I just wrote then you need to read RFCs 5056, 5929, and 5802 -- in that order. > I agree that salting the stored password (SPwd) would have improved the > security of this protocol (unlike iteration counts). And it can be added > with no extra round trips, since it's not "negotiated", just sent by the > responder. My coauthor and I need to consider the benefits vs. costs, since > the major use case here is not open servers, more often it would be VPN > gateways. Salting with a username requires no negotiation, but then you can't rename users without also changing their passwords (a minor issue). Nico -- From nico@cryptonector.com Thu Apr 14 10:06:16 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 693D6E0766 for ; Thu, 14 Apr 2011 10:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lq7kcZbwGJ5 for ; Thu, 14 Apr 2011 10:06:15 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfc.amsl.com (Postfix) with ESMTP id 6985EE0663 for ; Thu, 14 Apr 2011 10:06:15 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 6835843807C for ; Thu, 14 Apr 2011 10:06:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Fz/hIlbkD9eMBsPGf81kRGDJM0LjpMdEDvqQHw3I14NH e3eqOrquLn6dIvfwxMOkpe+1dtkPEx/us5JsCGKNNqAR7rm4O8Fz0wJ8fiCrEUUG wJ0/cVyFs+IK2b+abnRrNHZag/QLfW/6OOUBYG0maTAqpOZLtzVGuGMj5vPLacw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=0CqJs7ID325ZrQhVJGtSgRYgbqE=; b=mgA/0J4NFDr 8c/lLZz2dCPGWWz8Py2Bdd/MtAGTGN5iTFnJZvXxC4Pl/OVpYb2Ab45hiJwlsDut 3V9jkPcPgz2MRrFmic0M9BaXea0q2Zd0suNIKhdRUPNGIER4XnR8jVrWfr6XhVrt Rf6q48TqzaCln5vIbMsvSbAdjYrznHHw= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 350EA43806C for ; Thu, 14 Apr 2011 10:06:14 -0700 (PDT) Received: by vws12 with SMTP id 12so1852983vws.31 for ; Thu, 14 Apr 2011 10:06:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.8 with SMTP id eq8mr1392041vdc.214.1302800773592; Thu, 14 Apr 2011 10:06:13 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 10:06:13 -0700 (PDT) In-Reply-To: <7BC90BF4-8FEB-4986-A0F2-9B3792525EB8@vpnc.org> References: <4DA69C8A.7000305@gmail.com> <7BC90BF4-8FEB-4986-A0F2-9B3792525EB8@vpnc.org> Date: Thu, 14 Apr 2011 12:06:13 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:06:16 -0000 On Thu, Apr 14, 2011 at 11:56 AM, Paul Hoffman wrot= e: > On Apr 14, 2011, at 9:29 AM, Nico Williams wrote: > >> On Thu, Apr 14, 2011 at 11:00 AM, Paul Hoffman w= rote: >>> On Apr 14, 2011, at 8:38 AM, Nico Williams wrote: >>>> Of course, PACE is targeting Experimental... do we care about >>>> cryptographic issues in Experimental RFCs? =C2=A0I'd say we should, th= ough >>>> less so than for Standards Track RFCs since we can only spare so much >>>> energy. >>> >>> If we "care about" such things, they should be discussed on open mailin= g lists, particularly if you are criticizing academic publications related = to the document. >> >> I'm not sure what you mean. > > I mean that the closed secdir mailing list is not an appropriate place to= be discussing proposed problems with crypto protocols if the intended resu= lt is that they protocols will change or that serious design discussions ha= ppen. It is not closed: http://www.ietf.org/mail-archive/web/secdir/current/maillist.html I remember the secdir meeting where opening the archives (though not past archives) was decided :) >>>> I'm rather disappointed to see this wheel reinvented. =C2=A0SCRAM (RFC= 5802) >>>> would fit right in instead of PACE, for example, and has the same >>>> kinds of properties as PACE, but with a number of advantages over PACE >>>> (SCRAM is on the Standards Track, received much more review, uses a >>>> PBKDF with salt and iteration count, is implemented, is reusable in >>>> many contexts, does channel binding, there's an LDAP schema for >>>> storing SCRAM password verifiers, ...). >>>> >>>> We, secdir, should be encouraging wheel reuse wherever possible over >>>> wheel reinvention. >>> >>> "We" never have encouraged that. Many of "us" are chairs of WGs whose c= harters explicitly allow or mandate the opposite of what you are proposing.= If you want a change, it has to come from the ADs, not from "us". >> >> "We", secdir, are volunteers. =C2=A0This volunteer would rather avoid wh= eel >> reinvention, and this volunteer, perhaps naively, had hoped others >> would agree. =C2=A0Perhaps other volunteers disagree (you do). =C2=A0I >> explicitly referred to secdir, not WG chairs, not ADs, nor did I refer >> to actual current practice, but rather stated an opinion of what we >> ought to do. > > Most people on secdir are here because they are chairs of WGs in the Secu= rity Area. Maybe you are thinking of the old secdir model. :-) Perhaps I don't belong here any longer then? And yes, I'm thinking of the old secdir model. When was it abandoned? (We both seem to be out of date then regarding secdir practices!) >> All that aside, is it really the case that "we" (secdir) don't mind >> the lack of salting? =C2=A0Really?! =C2=A0In 2011, four decades or so si= nce the >> invention of salting? > > I read the paper in the PACE document and thought that it covered the des= ign well. I even looked for follow-ups to the paper and found none (althoug= h some may have appeared since I looked). Maybe I'm naive, but I tend to as= sume that academic review of crypto papers on which there is also discussio= n in IETF WGs is sufficient for publishing something as an Experimental RFC= . It may be sufficient, but nothing says that having had WG review no further review is applicable, even for an Experimental RFC (for example, the IESG can always issue a do-not-publish request to the RFC-Editor, even if the I-D in question received WG review and passed WGLC). >> Or did you really just mean to criticize me for >> not cc'ing the IPsec list on my reply? > > > No. If I meant to do that, I would have. This proposal has already been d= iscussed in the WG for a bit over a year. The whole point of secdir review (and IETF review) is to catch things that might not have been caught within a WG. Forgive me for being late to this party, but here I am. Nico -- From dharkins@lounge.org Thu Apr 14 10:21:46 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25166E06A4 for ; Thu, 14 Apr 2011 10:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPFTFsvQS+gb for ; Thu, 14 Apr 2011 10:21:45 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 2CA68E0749 for ; Thu, 14 Apr 2011 10:21:45 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 83D831022404C; Thu, 14 Apr 2011 10:21:44 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 14 Apr 2011 10:21:44 -0700 (PDT) Message-ID: In-Reply-To: References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> Date: Thu, 14 Apr 2011 10:21:44 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:21:46 -0000 Hi Nico, On Thu, April 14, 2011 9:57 am, Nico Williams wrote: > On Thu, Apr 14, 2011 at 11:51 AM, Yaron Sheffer > wrote: >> I'm amazed at the comparison of PACE with SCRAM. In a previous mail you >> pointed out yourself that SCRAM is vulnerable to on-the-wire dictionary >> attacks, which PACE is not. The IETF had never managed to standardize >> any >> ZKPP methods until just recently (with the exception of TLS-SRP), and >> finally we're doing something about it, even if on the Experimental >> track. I >> believe this counts as a positive contribution to the security of the >> Internet. > > This betrays a fundamental misunderstanding of SCRAM and channel binding. > > SCRAM with channel binding to a secure channel is as secure as PACE, > and arguably more so. PACE does not require a secure channel to be passed through. In fact, the way it's used there is no security (yet), it's just an unauthenticated Diffie-Hellman that "protects" the channel that PACE is done through. PACE performs authentication of the IKE SA by doing a ZKPP and adding the authenticated and shared secret result of the ZKPP into the result of the unauthenticated Diffie-Hellman (plus assorted cruft). regards, Dan. From yaronf.ietf@gmail.com Thu Apr 14 10:24:07 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BA763E06A4 for ; Thu, 14 Apr 2011 10:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HJ7XaM1gkxU for ; Thu, 14 Apr 2011 10:24:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 26C38E073F for ; Thu, 14 Apr 2011 10:24:06 -0700 (PDT) Received: by wwa36 with SMTP id 36so1533935wwa.13 for ; Thu, 14 Apr 2011 10:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XFs2CI5AUYfoIFcWYcWQ90MeE5gaP0p2Xb1cS0b5vTY=; b=Q41vbiym7W6NST5E+4qSqGs3uG/EzTlA0EmS6yhibwNg8Yw3w2jz3PrBMw+w9c4PJ0 8y56OSSqaSvBgafw+0fA+20Fij8CrNQuzth4Isj3LYMip0yQfO+r1ChCTog0I6dC2PUU zIXkfb3p8bQZicgnOTNrP5Fxxkiice3KAWGBU= 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=JCwMXL1ta4MdQ3wN2zVwSmZS1fuOoHBE3foFd3l/TP0tk5llcLb8S+rmOpw3BXGMqc fqN4b1L3n3HnrCutoRO4qYcMD4bt9iW1BwRf0l57kIr2jH/lc/k5TyIlH6K/qJ17pqPf BKwPve2WzIiqMs33uZ9qEHN0WAvhECpMJipDs= Received: by 10.227.198.199 with SMTP id ep7mr1087379wbb.40.1302801845397; Thu, 14 Apr 2011 10:24:05 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-177-21-107.red.bezeqint.net [79.177.21.107]) by mx.google.com with ESMTPS id p5sm1126612wbg.62.2011.04.14.10.24.02 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 10:24:04 -0700 (PDT) Message-ID: <4DA72DB0.9060102@gmail.com> Date: Thu, 14 Apr 2011 20:24:00 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nico Williams References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:24:07 -0000 I am unfamiliar with SCRAM, and never claimed otherwise. I just quoted your own analysis during the ipsec ML discussion. *Still* not having read the documents, I'd like to remind you that any auth protocol over IKE is vulnerable to passive attackers until authentication is complete, channel binding or not. We can apply random salt, not just salt with the user name, because the PACE "action" only starts at the *second* exchange of IKEv2. So we can piggyback a salt payload along with the Responder's notification that it supports the protocol. Thanks, Yaron On 04/14/2011 07:57 PM, Nico Williams wrote: > On Thu, Apr 14, 2011 at 11:51 AM, Yaron Sheffer wrote: >> I'm amazed at the comparison of PACE with SCRAM. In a previous mail you >> pointed out yourself that SCRAM is vulnerable to on-the-wire dictionary >> attacks, which PACE is not. The IETF had never managed to standardize any >> ZKPP methods until just recently (with the exception of TLS-SRP), and >> finally we're doing something about it, even if on the Experimental track. I >> believe this counts as a positive contribution to the security of the >> Internet. > > This betrays a fundamental misunderstanding of SCRAM and channel binding. > > SCRAM with channel binding to a secure channel is as secure as PACE, > and arguably more so. > > If you do not understand what I just wrote then you need to read RFCs > 5056, 5929, and 5802 -- in that order. > >> I agree that salting the stored password (SPwd) would have improved the >> security of this protocol (unlike iteration counts). And it can be added >> with no extra round trips, since it's not "negotiated", just sent by the >> responder. My coauthor and I need to consider the benefits vs. costs, since >> the major use case here is not open servers, more often it would be VPN >> gateways. > > Salting with a username requires no negotiation, but then you can't > rename users without also changing their passwords (a minor issue). > > Nico > -- From nico@cryptonector.com Thu Apr 14 10:25:15 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B4ADAE0766 for ; Thu, 14 Apr 2011 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ2GXSYLPPdU for ; Thu, 14 Apr 2011 10:25:15 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfc.amsl.com (Postfix) with ESMTP id 1746DE06A4 for ; Thu, 14 Apr 2011 10:25:15 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 4712121DE82 for ; Thu, 14 Apr 2011 10:25:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Tg4NwjQHbe8PzUg6vN3cV9DwLddRcbnmoVy2zW+3N2gt 2G+ZE+zi8PDCLkwlkilKzJbmeafKorNYkdeRk8f9253sQU7zdDFRtftxCDQZJpCR WHIv9TQucwL+OoqZ1lT0eVsjSmaGOWBoBGt5dcaJFWSW95whFkN2WPynONjTDJs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=iax1JDo0xdmEK4xNBqDWKQjtcuQ=; b=imCgjQQABWV QS4BrCAFKN3jX7xW3Sa6MJ751iP+yVo9kXGR73voJ4axr11sAPMh6UcJWa+jK3ka Ua5dyR7eMRRgw6ECaAPR/mRa5ZhX+NbSpazU36T4LtKuscmE09JV3chAnlRecWua f92ZEjsWMRAwqdNoz9Oml+wHcRGG+V5A= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 0928221DE7E for ; Thu, 14 Apr 2011 10:25:13 -0700 (PDT) Received: by vxg33 with SMTP id 33so1856935vxg.31 for ; Thu, 14 Apr 2011 10:25:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.41 with SMTP id if9mr1472525vdb.54.1302801913406; Thu, 14 Apr 2011 10:25:13 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 10:25:13 -0700 (PDT) In-Reply-To: References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> Date: Thu, 14 Apr 2011 12:25:13 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:25:15 -0000 On Thu, Apr 14, 2011 at 12:21 PM, Dan Harkins wrote: > On Thu, April 14, 2011 9:57 am, Nico Williams wrote: >> This betrays a fundamental misunderstanding of SCRAM and channel binding= . >> >> SCRAM with channel binding to a secure channel is as secure as PACE, >> and arguably more so. > > =C2=A0PACE does not require a secure channel to be passed through. In fac= t, > the way it's used there is no security (yet), it's just an unauthenticate= d > Diffie-Hellman that "protects" the channel that PACE is done through. > PACE performs authentication of the IKE SA by doing a ZKPP and adding the > authenticated and shared secret result of the ZKPP into the result of the > unauthenticated Diffie-Hellman (plus assorted cruft). In RFC5056 terms, your "unauthenticated Diffie-Hellman" exchange is a "chan= nel". There seems to be a terminology disconnect. As a result of this disconnect you and others are discarding the work of others (e.g., SCRAM in this case) without understanding it in the first place. I can't force you to read RFC5056 and become familiar with the notion of channel binding. But I do wish you'd give it a go. Nico -- From nico@cryptonector.com Thu Apr 14 10:32:06 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ADAF7E07C2 for ; Thu, 14 Apr 2011 10:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqAhP8BkzUSF for ; Thu, 14 Apr 2011 10:32:05 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfc.amsl.com (Postfix) with ESMTP id A850BE0768 for ; Thu, 14 Apr 2011 10:32:05 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 331D621DE7D for ; Thu, 14 Apr 2011 10:32:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=txj3KdWn08mSM5tAVXRjJ kPG3RjU+98Z1rzh+f6CsqhCF77SOSEKA3LC9QBuW4va3qQe61UBHRzQLb/WcWTNS MjH1vQkYF7+sGmRhZWDZVOd+mn0KXjGIXa5vUGQTYBpvCfBPIyN/f9YWB9iQCV3f DBFAu91dkrWu16aSVL7bW4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0ZztB1yKEHI6Acd0cs0H buC69GE=; b=S3YcGdO8av3AOQYRP8rSBXeU/7Bv8Bbpuf3WpLOgufvIvt/moWoE BqlluJXorQpdQS91MRIXsSxZCTH0DFVtnuzCUI5APtBo3/M+w9D2hQ+U5A32NVgR crIJ6IMJfvv/LHHpaMBfkpiHolu1qPn4YT4zyI+EoU0OtpcEqMrYH6s= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id E2F6521DE6A for ; Thu, 14 Apr 2011 10:32:04 -0700 (PDT) Received: by vws12 with SMTP id 12so1877564vws.31 for ; Thu, 14 Apr 2011 10:32:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.112.69 with SMTP id io5mr1461361vdb.94.1302802324342; Thu, 14 Apr 2011 10:32:04 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 10:32:04 -0700 (PDT) In-Reply-To: <4DA72DB0.9060102@gmail.com> References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <4DA72DB0.9060102@gmail.com> Date: Thu, 14 Apr 2011 12:32:04 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:32:06 -0000 On Thu, Apr 14, 2011 at 12:24 PM, Yaron Sheffer wrote: > I am unfamiliar with SCRAM, and never claimed otherwise. I just quoted your > own analysis during the ipsec ML discussion. *Still* not having read the > documents, I'd like to remind you that any auth protocol over IKE is > vulnerable to passive attackers until authentication is complete, channel > binding or not. Not if you encrypt the relevant bits with the session key agreed via the KE payloads (which PACE sure does, near as I can tell, since the "ENONCE" is sent protected by the session key: "IKE_PACE: HDR, SK{IDi, [IDr,], SAi2, TSi, TSr, ENONCE, PKEi}"). But the protocol is vulnerable to an active attack. If you authenticate the responder with PKIX first then PACE would not be vulnerable even to an active attack. Certainly an option to be able to authenticate the responder this way would be nice. > We can apply random salt, not just salt with the user name, because the PACE > "action" only starts at the *second* exchange of IKEv2. So we can piggyback > a salt payload along with the Responder's notification that it supports the > protocol. Ah, good point. SCRAM would not allow you to get that one round-trip optimization because it'd be an abstraction violation to run its initial round-trip in parallel with the KE exchange then add in the channel binding in the second round-trip of SCRAM. *This* could be a good reason to not use SCRAM (though I won't concede that just yet), but the points regarding salting and iteration count remain. Nico -- From dharkins@lounge.org Thu Apr 14 10:35:51 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3495AE073F for ; Thu, 14 Apr 2011 10:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1ePmsYQ1PhZ for ; Thu, 14 Apr 2011 10:35:50 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 8A523E06B0 for ; Thu, 14 Apr 2011 10:35:50 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0FD8C1022404C; Thu, 14 Apr 2011 10:35:50 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 14 Apr 2011 10:35:50 -0700 (PDT) Message-ID: <16d9b37f31bdbfc6588d0743515eea5b.squirrel@www.trepanning.net> In-Reply-To: References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> Date: Thu, 14 Apr 2011 10:35:50 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:35:51 -0000 Hi Nico, One other thing... On Thu, April 14, 2011 9:57 am, Nico Williams wrote: > On Thu, Apr 14, 2011 at 11:51 AM, Yaron Sheffer > wrote: >> I agree that salting the stored password (SPwd) would have improved the >> security of this protocol (unlike iteration counts). And it can be added >> with no extra round trips, since it's not "negotiated", just sent by the >> responder. My coauthor and I need to consider the benefits vs. costs, >> since >> the major use case here is not open servers, more often it would be VPN >> gateways. > > Salting with a username requires no negotiation, but then you can't > rename users without also changing their passwords (a minor issue). I'm not sure that salting really buys anything. This is not a client- server protocol; either side can initiate to each other. So both sides need an _identical_ representation of the credential to authenticate with. If there is some agreed-upon salt then the salted password becomes the credential to use. This is no different than just using an unsalted password. The nonces from the IKE exchange are used in PACE to provide additional randomness to its particular use of the password. regards, Dan. From nico@cryptonector.com Thu Apr 14 10:41:59 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A2A62E0716 for ; Thu, 14 Apr 2011 10:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uatwgLW29NT5 for ; Thu, 14 Apr 2011 10:41:59 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfc.amsl.com (Postfix) with ESMTP id E9C84E0690 for ; Thu, 14 Apr 2011 10:41:58 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 5DC48438080 for ; Thu, 14 Apr 2011 10:41:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=GwpWP3M23C6Lw9PLmQiZ4sEtbiZGOx/vsPxMXv9OjE86 /gXFYbpCDc3yUYxRat/FKMnGgda11KJ5ydwr/laQcbCvt9w03gFOW04f1QrE6V75 FTb4ptN/fdKNJBh8Iidi7lvyqJr0pK5mAcJ4W0PIs80fdOlzZ+sV+WQvsOfdd7o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=cEMUUKzXLXY3R6Aqzq0p5/SzvcM=; b=c+vOYD3tQLH zMhfFn629I2d4ZeRVZMCJhwhPjRJz8R85JVcYZMmg66clJ6fcRSF/AUzkAqJmIma qWaAN3L67MbiHACeZ7uMWPbabbrLpRQl+tXu0row8TePHf3RM356qUVvmxQV1+Ii wdhYOSvPjd9bHdKbK62oY/KRTGpmRdGM= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 20A0B43807E for ; Thu, 14 Apr 2011 10:41:57 -0700 (PDT) Received: by vxg33 with SMTP id 33so1872693vxg.31 for ; Thu, 14 Apr 2011 10:41:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.112.69 with SMTP id io5mr1476556vdb.94.1302802917451; Thu, 14 Apr 2011 10:41:57 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 10:41:57 -0700 (PDT) In-Reply-To: <16d9b37f31bdbfc6588d0743515eea5b.squirrel@www.trepanning.net> References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <16d9b37f31bdbfc6588d0743515eea5b.squirrel@www.trepanning.net> Date: Thu, 14 Apr 2011 12:41:57 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:41:59 -0000 On Thu, Apr 14, 2011 at 12:35 PM, Dan Harkins wrote: > =C2=A0I'm not sure that salting really buys anything. This is not a clien= t- > server protocol; either side can initiate to each other. So both sides > need an _identical_ representation of the credential to authenticate with= . > If there is some agreed-upon salt then the salted password becomes > the credential to use. This is no different than just using an unsalted > password. The nonces from the IKE exchange are used in PACE to provide > additional randomness to its particular use of the password. This is important. I hadn't realized that PACE was intended to be initiated in either direction. When one of the peers is a device acting on behalf of a user (who knows just a their username and password) and the other is a system that has access to SPwd (the shared secret derived from the password), then it's important that the peer that sends the ENONCE first be the device where the user is at, else the active attack on PACE gets much simpler (since impersonating the user device is probably simpler than impersonating the other one). Nico -- From dharkins@lounge.org Thu Apr 14 10:47:53 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 409E4E06CD for ; Thu, 14 Apr 2011 10:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiwDb0PzZ68t for ; Thu, 14 Apr 2011 10:47:52 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 3610AE0690 for ; Thu, 14 Apr 2011 10:47:52 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B1D211022404C; Thu, 14 Apr 2011 10:47:51 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 14 Apr 2011 10:47:51 -0700 (PDT) Message-ID: <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> In-Reply-To: References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> Date: Thu, 14 Apr 2011 10:47:51 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:47:53 -0000 Hi Nico, On Thu, April 14, 2011 10:25 am, Nico Williams wrote: > On Thu, Apr 14, 2011 at 12:21 PM, Dan Harkins wrote: >> On Thu, April 14, 2011 9:57 am, Nico Williams wrote: >>> This betrays a fundamental misunderstanding of SCRAM and channel >>> binding. >>> >>> SCRAM with channel binding to a secure channel is as secure as PACE, >>> and arguably more so. >> >>  PACE does not require a secure channel to be passed through. In fact, >> the way it's used there is no security (yet), it's just an >> unauthenticated >> Diffie-Hellman that "protects" the channel that PACE is done through. >> PACE performs authentication of the IKE SA by doing a ZKPP and adding >> the >> authenticated and shared secret result of the ZKPP into the result of >> the >> unauthenticated Diffie-Hellman (plus assorted cruft). > > In RFC5056 terms, your "unauthenticated Diffie-Hellman" exchange is a > "channel". > > There seems to be a terminology disconnect. As a result of this > disconnect you and others are discarding the work of others (e.g., > SCRAM in this case) without understanding it in the first place. I don't think there's a terminology disconnect. Yes, it's a "channel", but the important thing is it's not a "secure channel", which is what you said above. SCRAM is not resistant to off-line dictionary attack, PACE is. So the work of others has not just been ignorantly discarded, it is just not appropriate to use in this particular case. What is needed here is to parlay a low-entropy password into a secure secret without anything else. There is no way to "authenticate the responder with PKIK" (as you implied in another email) because there is nothing else that could be used in accordance with any PKIK RFC. Using SCRAM here would be more secure than the broken PSK mode of IKE(v2) today but would not be resistant to off-line dictionary attack. Don't think of this as a username/password protocol. There is no real "user". There is just a password and the two side have to prove to each other they know it without leaking any information about it to each other or an adversary. SCRAM isn't the right tool for this job. regards, Dan. From nico@cryptonector.com Thu Apr 14 10:59:41 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2FEB6E0765 for ; Thu, 14 Apr 2011 10:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onoctf8wJkN4 for ; Thu, 14 Apr 2011 10:59:40 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfc.amsl.com (Postfix) with ESMTP id 24BA7E065F for ; Thu, 14 Apr 2011 10:59:40 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 8090267407B for ; Thu, 14 Apr 2011 10:59:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=uXVFaDS0v8XGl1lyFEBP5tsXRCNKtFAZwi+HtP2LOgvO DJSdkUfx+YzUsMYP9XR2l427biH070HBRJPLL1xBaJr6WanojKztCk2Yt8gBHo+I bRYq37KTgNnWNn6fYWWz6ki8e/xYXqbvX/MKEs9HL5qB/hubMliDrPX8XGas6cE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=qFcqmKuugEpU+1HADCa6Vdri2V0=; b=NpSXcl9dS8t 2nP4VMDa6U2QROFDPd0/qrVCKGQgHkNduoMLMEb+AtO6y6fwVOg/4OVadYFklGZS CDGLqVa8c5/UMcbImFDWCujoxhzaGq57eInQBImQqakSK2h8shdwBzq4zgqOUObi QqAXOs9OvYtjAxQ8BxgR3TmyFqSm7GKs= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 4DD20674074 for ; Thu, 14 Apr 2011 10:59:39 -0700 (PDT) Received: by vxg33 with SMTP id 33so1889309vxg.31 for ; Thu, 14 Apr 2011 10:59:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.8 with SMTP id eq8mr1473614vdc.214.1302803978724; Thu, 14 Apr 2011 10:59:38 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 10:59:38 -0700 (PDT) In-Reply-To: <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> Date: Thu, 14 Apr 2011 12:59:38 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:59:41 -0000 On Thu, Apr 14, 2011 at 12:47 PM, Dan Harkins wrote: > On Thu, April 14, 2011 10:25 am, Nico Williams wrote: >> In RFC5056 terms, your "unauthenticated Diffie-Hellman" exchange is a >> "channel". >> >> There seems to be a terminology disconnect. =C2=A0As a result of this >> disconnect you and others are discarding the work of others (e.g., >> SCRAM in this case) without understanding it in the first place. > > =C2=A0I don't think there's a terminology disconnect. Yes, it's a "channe= l", > but the important thing is it's not a "secure channel", which is what > you said above. I'm distinguishing secure from authenticated. If the channel can provide confidentiality and integrity protection then it's secure. If it's authenticated that's even better. > =C2=A0SCRAM is not resistant to off-line dictionary attack, PACE is. So > the work of others has not just been ignorantly discarded, it is just > not appropriate to use in this particular case. I don't see how the ENONCE in PACE is resistant to off-line dictionary attacks. What am I missing? I stand by my assertion that SCRAM with channel binding to the KE exchange, and protected by that KE exchange, is protected against passive attacks, and if the channel is authenticated, then it's also protected against active attacks. (Note that I never proposed SCRAM w/o CB, nor would I have.) If I'm right that ENONCE is resistant to off-line dictionary attacks then I stand by my assertion that SCRAM (with CB) is at least as secure as PACE, and arguably more so. > =C2=A0What is needed here is to parlay a low-entropy password into a > secure secret without anything else. There is no way to "authenticate > the responder with PKIK" (as you implied in another email) because > there is nothing else that could be used in accordance with any PKIK RFC. > Using SCRAM here would be more secure than the broken PSK mode of IKE(v2) > today but would not be resistant to off-line dictionary attack. I understand that PKIX credentials will not always be available for either, much less both of the peers (if they are available for both then the only thing the password adds is an additional authentication factor, and is probably an undesirable complication). However, I expect that a certificate will often be available for "servers". As for SCRAM, again, _with_ CB it's no weaker than PACE. > =C2=A0Don't think of this as a username/password protocol. There is no > real "user". There is just a password and the two side have to prove > to each other they know it without leaking any information about it > to each other or an adversary. SCRAM isn't the right tool for this job. If there's no user and the password is randomly generated then I have no concerns whatever. However, everything in the I-D leads me to believe that the password is intended to be memorable to human users. For example, why bother with stringprep if the password is intended to be a randomly generated string? Why bother with Unicode at all in that case? Moreover, the introduction specifically refers to weak shared secrets, which leads me to believe that PACE is specifically intended for user authentication. So which is it? Is PACE just an improved PSK mechanism? Or is PACE a password-based mechanism as we normally think of them (i.e., for human users)? Nico -- From yaronf.ietf@gmail.com Thu Apr 14 11:25:54 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 17995E08B8 for ; Thu, 14 Apr 2011 11:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMqG0g6ey0ny for ; Thu, 14 Apr 2011 11:25:52 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 5C386E084C for ; Thu, 14 Apr 2011 11:25:48 -0700 (PDT) Received: by wyb29 with SMTP id 29so1848290wyb.31 for ; Thu, 14 Apr 2011 11:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iBwzTkRu8/tvhrzsfL9xIMxQNpfO9X86HQHtuaBie2I=; b=mZeQjeaGxFKEliGqkIuVOWjUfuLADrzJdRCLh+ROI+MA4jVyhX/LlUUG6RJq4E8NWd dOiqi54QE6wbU7iC/XBjMnIPsMTWwyhti4KsYfDBBMXJYQ2pT4RoglDdSRTi8fPCxweF fVME8Jomo0lRDEJe54fvd/QKi/IVOKWK5e3Ec= 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=DWe4+N/lA1S4pFMT/f94/wT7WkiShBDq36IPrBPB/OcjBZiEcrHJskOqWsi2mc0+46 gEI/bqnutDy1b7GYXSfFAJU87DcwCTB1eSLufoXzpb/n8MRAJH45RlgZZrS4Nywyc79N nXQEp5C+ZFvmK4BsFWaDuEGyN7RpfSDexn6WQ= Received: by 10.227.177.69 with SMTP id bh5mr173412wbb.155.1302805547650; Thu, 14 Apr 2011 11:25:47 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-177-21-107.red.bezeqint.net [79.177.21.107]) by mx.google.com with ESMTPS id h11sm1155980wbc.60.2011.04.14.11.25.44 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 11:25:47 -0700 (PDT) Message-ID: <4DA73C26.5070407@gmail.com> Date: Thu, 14 Apr 2011 21:25:42 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nico Williams References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:25:54 -0000 Hi Nico, ENONCE in and of itself is not vulnerable to an off-line dictionary attack because the password encrypts a random bit string, and we take care that there is no stray entropy (padding, MAC) that such an attacker could use. As to the bigger question of why the protocol as a whole is not vulnerable to the attack, you will have to follow the proof in the paper (or maybe just ask my coauthor). And regarding the usage scenario: the primary scenario is password-based machine-to-machine authentication. Yes, sysadmins are human (in most cases :-) and they tend to use short passwords for machine auth, much more often than we would have liked. There is a secondary use case that's the usual human-to-server auth, where the peers are too lazy to use EAP. I'm questioning whether this scenario is interesting enough to add a salted "mode" into the protocol. Thanks, Yaron On 04/14/2011 08:59 PM, Nico Williams wrote: > On Thu, Apr 14, 2011 at 12:47 PM, Dan Harkins wrote: >> On Thu, April 14, 2011 10:25 am, Nico Williams wrote: >>> In RFC5056 terms, your "unauthenticated Diffie-Hellman" exchange is a >>> "channel". >>> >>> There seems to be a terminology disconnect. As a result of this >>> disconnect you and others are discarding the work of others (e.g., >>> SCRAM in this case) without understanding it in the first place. >> >> I don't think there's a terminology disconnect. Yes, it's a "channel", >> but the important thing is it's not a "secure channel", which is what >> you said above. > > I'm distinguishing secure from authenticated. If the channel can > provide confidentiality and integrity protection then it's secure. If > it's authenticated that's even better. > >> SCRAM is not resistant to off-line dictionary attack, PACE is. So >> the work of others has not just been ignorantly discarded, it is just >> not appropriate to use in this particular case. > > I don't see how the ENONCE in PACE is resistant to off-line dictionary > attacks. What am I missing? > > I stand by my assertion that SCRAM with channel binding to the KE > exchange, and protected by that KE exchange, is protected against > passive attacks, and if the channel is authenticated, then it's also > protected against active attacks. (Note that I never proposed SCRAM > w/o CB, nor would I have.) > > If I'm right that ENONCE is resistant to off-line dictionary attacks > then I stand by my assertion that SCRAM (with CB) is at least as > secure as PACE, and arguably more so. > >> What is needed here is to parlay a low-entropy password into a >> secure secret without anything else. There is no way to "authenticate >> the responder with PKIK" (as you implied in another email) because >> there is nothing else that could be used in accordance with any PKIK RFC. >> Using SCRAM here would be more secure than the broken PSK mode of IKE(v2) >> today but would not be resistant to off-line dictionary attack. > > I understand that PKIX credentials will not always be available for > either, much less both of the peers (if they are available for both > then the only thing the password adds is an additional authentication > factor, and is probably an undesirable complication). However, I > expect that a certificate will often be available for "servers". As > for SCRAM, again, _with_ CB it's no weaker than PACE. > >> Don't think of this as a username/password protocol. There is no >> real "user". There is just a password and the two side have to prove >> to each other they know it without leaking any information about it >> to each other or an adversary. SCRAM isn't the right tool for this job. > > If there's no user and the password is randomly generated then I have > no concerns whatever. > > However, everything in the I-D leads me to believe that the password > is intended to be memorable to human users. For example, why bother > with stringprep if the password is intended to be a randomly generated > string? Why bother with Unicode at all in that case? Moreover, the > introduction specifically refers to weak shared secrets, which leads > me to believe that PACE is specifically intended for user > authentication. > > So which is it? Is PACE just an improved PSK mechanism? Or is PACE a > password-based mechanism as we normally think of them (i.e., for human > users)? > > Nico > -- From nico@cryptonector.com Thu Apr 14 11:44:11 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0734E080D for ; Thu, 14 Apr 2011 11:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOwY8Bm3WXF9 for ; Thu, 14 Apr 2011 11:44:11 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfc.amsl.com (Postfix) with ESMTP id 2C2DAE084C for ; Thu, 14 Apr 2011 11:44:11 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 3825D438080 for ; Thu, 14 Apr 2011 11:44:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=CUH6V6Vgk3UbrsIVZVK7t 6g4dzHvvvo+WQ7AHGjUFvKVfhxxa96Ckd240r77yDMiUYfUZelcmwx9Mt1O2uloc dIOdvDjmivenfktCRZUyXDB1vUa7yplHkLMU1aB/bovwz1+5rU/BCB8Jfa2sX/WZ hvhsztycOsW9rdFUhnuueU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JsOUtVQp1nPFsYQ/0BEa sDMz/xU=; b=biPyuze9QQZK2WMVeHZNnRp1wDENm5fPozkk3+XnPPfYQ831lOLX xyqJjs3W/47ALctfURCXf4MFMSAGTGcZIMZLLjjk3g/G4KJla2pqvxW3W+V8OL2G xc4VarIFyMbGWKzQK+5MjG1F9fr+Aq54EU/2j7GEODLxWxz4TvMIXmM= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 14BAB43807C for ; Thu, 14 Apr 2011 11:44:10 -0700 (PDT) Received: by vxg33 with SMTP id 33so1934591vxg.31 for ; Thu, 14 Apr 2011 11:44:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.8 with SMTP id eq8mr1543471vdc.214.1302806649302; Thu, 14 Apr 2011 11:44:09 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 11:44:09 -0700 (PDT) In-Reply-To: <4DA73C26.5070407@gmail.com> References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> <4DA73C26.5070407@gmail.com> Date: Thu, 14 Apr 2011 13:44:09 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 18:44:12 -0000 On Thu, Apr 14, 2011 at 1:25 PM, Yaron Sheffer wrote: > ENONCE in and of itself is not vulnerable to an off-line dictionary attack > because the password encrypts a random bit string, and we take care that > there is no stray entropy (padding, MAC) that such an attacker could use. But the ENONCE paired with the AUTH payloads is subject to off-line dictionary attacks (the attacker will have to have impersonated the responder in order to obtain the necessary material). > As to the bigger question of why the protocol as a whole is not vulnerable > to the attack, you will have to follow the proof in the paper (or maybe just > ask my coauthor). It sounds like you're asserting that PACE is a ZKPP. Is that right? > And regarding the usage scenario: the primary scenario is password-based > machine-to-machine authentication. Yes, sysadmins are human (in most cases > :-) and they tend to use short passwords for machine auth, much more often > than we would have liked. You might want to clarify this in the abstract and introduction then. But even so, as long as the passwords are human memorable and the mechanism is not a ZKPP, then my other comments stand. However, if this is really for machine authentication then I'll be happy with text exhorting admins to pick good passwords. > There is a secondary use case that's the usual human-to-server auth, where > the peers are too lazy to use EAP. I'm questioning whether this scenario is > interesting enough to add a salted "mode" into the protocol. Fair enough. From yaronf.ietf@gmail.com Thu Apr 14 12:46:54 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36D29E0712 for ; Thu, 14 Apr 2011 12:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq8f-QeUJa1h for ; Thu, 14 Apr 2011 12:46:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 592A2E0687 for ; Thu, 14 Apr 2011 12:46:53 -0700 (PDT) Received: by wyb29 with SMTP id 29so1909570wyb.31 for ; Thu, 14 Apr 2011 12:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UeahZt0KHePx2uFuQOlyBlQ4rawEPY1/BPZtqJCzxEk=; b=f2Tk/Vs1Hy3qzkc8JVFgaMueJw2aZIyWBRnbPiYqaUCp/YfAQnE+tnuwZu1+pMhJ2a OD+g6ySFJgltRydHL6FrB1qUH/853SqgjHGlAx8s7VXNoRhY7qJSv3mgj9TOa8jGo5HF 1V6vkFnd0CCaHDA5o9KI/drYyGnCMBGF1PUFY= 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=BplY6domssUCDhIb8KZHIsxz78E2T69KoKVhrqnmfpZuLxoI9srwjlfvjsV7N+J6V2 p7Us34aBwdtKy98HkwU5tb4DqHIukoZtPh/0nTjgk4fXo+GsVwSR2MlWmfCcpZICGzMS kuChIdLr5r06vG7rHM0GSWWZLPi2q2u0MJTqA= Received: by 10.227.172.7 with SMTP id j7mr1208252wbz.60.1302810412685; Thu, 14 Apr 2011 12:46:52 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-177-21-107.red.bezeqint.net [79.177.21.107]) by mx.google.com with ESMTPS id bd8sm1194850wbb.31.2011.04.14.12.46.51 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 12:46:52 -0700 (PDT) Message-ID: <4DA74F2A.2060504@gmail.com> Date: Thu, 14 Apr 2011 22:46:50 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nico Williams References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> <4DA73C26.5070407@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 19:46:54 -0000 Yes, PACE is a ZKPP, and the AUTH payloads depend on values that the attacker cannot compute (PACESharedSecret). Again, this assertion is based on the mathematical proof of the protocol. We have tried for many years to educate people to use better passwords. This has not worked. So we'd better assume that passwords are weak by default, and if they're good, all the better. Thanks, Yaron On 04/14/2011 09:44 PM, Nico Williams wrote: > On Thu, Apr 14, 2011 at 1:25 PM, Yaron Sheffer wrote: >> ENONCE in and of itself is not vulnerable to an off-line dictionary attack >> because the password encrypts a random bit string, and we take care that >> there is no stray entropy (padding, MAC) that such an attacker could use. > > But the ENONCE paired with the AUTH payloads is subject to off-line > dictionary attacks (the attacker will have to have impersonated the > responder in order to obtain the necessary material). > >> As to the bigger question of why the protocol as a whole is not vulnerable >> to the attack, you will have to follow the proof in the paper (or maybe just >> ask my coauthor). > > It sounds like you're asserting that PACE is a ZKPP. Is that right? > >> And regarding the usage scenario: the primary scenario is password-based >> machine-to-machine authentication. Yes, sysadmins are human (in most cases >> :-) and they tend to use short passwords for machine auth, much more often >> than we would have liked. > > You might want to clarify this in the abstract and introduction then. > But even so, as long as the passwords are human memorable and the > mechanism is not a ZKPP, then my other comments stand. However, if > this is really for machine authentication then I'll be happy with text > exhorting admins to pick good passwords. > >> There is a secondary use case that's the usual human-to-server auth, where >> the peers are too lazy to use EAP. I'm questioning whether this scenario is >> interesting enough to add a salted "mode" into the protocol. > > Fair enough. From tlyu@mit.edu Thu Apr 14 13:51:33 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CECD3E07CA for ; Thu, 14 Apr 2011 13:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.59 X-Spam-Level: X-Spam-Status: No, score=-100.59 tagged_above=-999 required=5 tests=[AWL=2.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVcRWgQN8Giu for ; Thu, 14 Apr 2011 13:51:33 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfc.amsl.com (Postfix) with ESMTP id 39B15E077E for ; Thu, 14 Apr 2011 13:51:30 -0700 (PDT) X-AuditID: 1209190c-b7b7aae0000047c7-73-4da75e5685d1 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 9D.F5.18375.65E57AD4; Thu, 14 Apr 2011 16:51:34 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p3EKpScx007084; Thu, 14 Apr 2011 16:51:28 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p3EKpNE9013717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Apr 2011 16:51:24 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p3EKpNJp027132; Thu, 14 Apr 2011 16:51:23 -0400 (EDT) To: Yaron Sheffer References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> <4DA73C26.5070407@gmail.com> <4DA74F2A.2060504@gmail.com> From: Tom Yu Date: Thu, 14 Apr 2011 16:51:23 -0400 In-Reply-To: <4DA74F2A.2060504@gmail.com> (Yaron Sheffer's message of "Thu, 14 Apr 2011 22:46:50 +0300") Message-ID: Lines: 8 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT0Q2LW+5r0NsgbdH0rpvF4tS1I2wW HxY+ZLFYdX8GuwOLx8tT5xg9ds66y+6xZMlPJo8vlz+zBbBEcdmkpOZklqUW6dslcGVcnnSM ueAVU8WlQy2MDYzLmboYOTkkBEwkvjYtY4WwxSQu3FvP1sXIxSEksI9RYsaZ7ewQzgZGiadf O5kgnCtMEm/v7IbKdDFKbN60Bcjh4BAR0JSYdtQKJM4scJRR4sS0NWA7hAXcJb5eegc19xaL xMc7zawgDWwC0hJHF5eB1LAIqErsfniSDcTmFMiQaDp6lBnE5hWwkOh4vpMFxOYR4JBYvfsf E0RcUOLkzCdgcWYBLYkb/14yTWAUnIUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJd Q73czBK91JTSTYygoOaU5NnB+Oag0iFGAQ5GJR7eC3LLfYVYE8uKK3MPMUpyMCmJ8t6PBQrx JeWnVGYkFmfEF5XmpBYfYpTgYFYS4e19tcxXiDclsbIqtSgfJiXNwaIkzjtDUt1XSCA9sSQ1 OzW1ILUIJivDwaEkwfsEZKhgUWp6akVaZk4JQpqJgxNkOA/Q8HMgNbzFBYm5xZnpEPlTjIpS 4rzzQRICIImM0jy4XljSecUoDvSKMO9NkCoeYMKC634FNJgJaHC2EtjgkkSElFQD4+QXd6KY ii7xaqiHyDI3q69yvv5+84Msg/sf/yjsly1Y/dVn96W1E74zi3dutW0++e9dckjorXd8fuIc i/oWnD0UPVkjd/ZVg5NqX4oWxWXnzu/Ia32s4Bfjejw/cKc16/PJTyJ2BEktPy6p5rF8Ausv 188nZAvFZrOImUq78T438lyyQN9aTYmlOCPRUIu5qDgRAOraiooVAwAA Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 20:51:34 -0000 Yaron Sheffer writes: > Yes, PACE is a ZKPP, and the AUTH payloads depend on values that the > attacker cannot compute (PACESharedSecret). Again, this assertion is > based on the mathematical proof of the protocol. Given Nico's comments, perhaps the fact that PACE is a ZKPP should be made more obvious earlier in the document. From nico@cryptonector.com Thu Apr 14 13:58:58 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 395E2E0876 for ; Thu, 14 Apr 2011 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6lK-5hwOMQh for ; Thu, 14 Apr 2011 13:58:57 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfc.amsl.com (Postfix) with ESMTP id A438BE085F for ; Thu, 14 Apr 2011 13:58:56 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id F26C535007F for ; Thu, 14 Apr 2011 13:58:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=tvl0p/lTKUabZRX1ym/b6 N5nQv565nB2xHSRCAn2ddDIo/panqjdo835sqQnxxZ6ykcyfiAvLrZwk84qpqaC3 FAPvwindkt3eT6XeKnvhuJLRBhibP3VaHD1sGFMAiJ6+rkrLnZUaHyej0f4xXZmY MvhimNhcxigCQVsXOjLAlQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gRwQ5Fq8PMQ70Y0YyyYU UDdtaGI=; b=MH5ZaZxSrrohGTYwBGFLBYdkSM7Mmo0q3tChHKVGxAD3iYpB7wXX XSicueoNEaEZe3coF3wGK3b95JBR7FRhTnBii8XDwz0Ngf1HSuaODEsuaqXEPWE5 PZDb5XF6wNGMUeX28nEEXxNoLGr1+4BISyEMrpJ6V1HgQ7u3lm2dVXo= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id C2DD3350058 for ; Thu, 14 Apr 2011 13:58:55 -0700 (PDT) Received: by vws12 with SMTP id 12so2070761vws.31 for ; Thu, 14 Apr 2011 13:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.112.69 with SMTP id io5mr1782299vdb.94.1302814735176; Thu, 14 Apr 2011 13:58:55 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 13:58:55 -0700 (PDT) In-Reply-To: References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> <4DA73C26.5070407@gmail.com> <4DA74F2A.2060504@gmail.com> Date: Thu, 14 Apr 2011 15:58:55 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 20:58:58 -0000 On Thu, Apr 14, 2011 at 3:51 PM, Tom Yu wrote: > Yaron Sheffer writes: > >> Yes, PACE is a ZKPP, and the AUTH payloads depend on values that the >> attacker cannot compute (PACESharedSecret). Again, this assertion is >> based on the mathematical proof of the protocol. > > Given Nico's comments, perhaps the fact that PACE is a ZKPP should be > made more obvious earlier in the document. Yes please. I really needed to see figure 1 from the paper. I also needed to read section 4.2 of the I-D. This is a clever ZKPP. Nico -- From nico@cryptonector.com Thu Apr 14 14:13:08 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ED06DE0823 for ; Thu, 14 Apr 2011 14:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-hNkdchcC34 for ; Thu, 14 Apr 2011 14:13:08 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfc.amsl.com (Postfix) with ESMTP id 4C548E07E6 for ; Thu, 14 Apr 2011 14:13:08 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id BBAB9428076 for ; Thu, 14 Apr 2011 14:13:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=K9VBBWwxpzB1Iux8Ez556 cXbZXdqUTBL2qAvONXhcwa7wVPJdxvRK0irO2tfCzUaumWD/mpzzV6q44IoN1peH irLXIBbD7jVgt4IMZBNjl4SedI7PbaIhx72xKWQvVwy/+Oh5WLT0RKKdViTqGtBt Nnm4gV6HDsg/0Cdm+/KoaQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FQ3DN1wcWnSJLbLVLNJs PeKyLTE=; b=tXhDjEkdGyB0FzORokPGyoYpt9X1SQ5agKReiAmw5QWPAoyt5E5O VffDeitkVDaUDIKfhqc49bVcMqavnLbR056t+skexDicmVbKqbREtASq/ALmcvhX HxDw1INYJL7rlKVstxJp3m2+gUCPFKt4q97xC9GTzYXISnPJ2n/zS7c= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 8706142806E for ; Thu, 14 Apr 2011 14:13:07 -0700 (PDT) Received: by vxg33 with SMTP id 33so2063914vxg.31 for ; Thu, 14 Apr 2011 14:13:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with SMTP id el1mr1779811vdb.174.1302815586831; Thu, 14 Apr 2011 14:13:06 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Thu, 14 Apr 2011 14:13:06 -0700 (PDT) In-Reply-To: References: <4DA69C8A.7000305@gmail.com> <4DA72605.10506@gmail.com> <9c05d036d0e99a053cf977d3f2c441db.squirrel@www.trepanning.net> <4DA73C26.5070407@gmail.com> <4DA74F2A.2060504@gmail.com> Date: Thu, 14 Apr 2011 16:13:06 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 21:13:09 -0000 So, I'm embarrassed. Please ignore all my earlier comments on this. Having read the paper, and the sections I'd missed in the I-D, I believe this document is fine. There's no need for salting nor iteration counts in a ZKPP like this (though an augmented version would require salting, and preferably also iteration counts, so as to slow down dictionary attacks on verifiers should the verifiers be lost). Nico -- From gwz@net-zen.net Thu Apr 14 19:10:59 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EB794E0677 for ; Thu, 14 Apr 2011 19:10:59 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DpsuhEIM2ZU for ; Thu, 14 Apr 2011 19:10:59 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) by ietfc.amsl.com (Postfix) with SMTP id DBF19E065C for ; Thu, 14 Apr 2011 19:10:58 -0700 (PDT) Received: (qmail 475 invoked from network); 15 Apr 2011 02:10:58 -0000 Received: from unknown (124.120.179.135) by p3plsmtpa06-04.prod.phx3.secureserver.net (173.201.192.105) with ESMTP; 15 Apr 2011 02:10:57 -0000 Message-ID: <4DA7A92C.4010702@net-zen.net> Date: Fri, 15 Apr 2011 09:10:52 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Hoffman References: <4DA69C8A.7000305@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------040805000305010907000501" Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 02:11:00 -0000 This is a multi-part message in MIME format. --------------040805000305010907000501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/14/2011 11:00 PM, Paul Hoffman wrote: > On Apr 14, 2011, at 8:38 AM, Nico Williams wrote: > >> Of course, PACE is targeting Experimental... do we care about > >> cryptographic issues in Experimental RFCs? I'd say we should, though >> less so than for Standards Track RFCs since we can only spare so much >> energy. > > If we "care about" such things, they should be discussed on open mailing lists, particularly if you are criticizing academic publications related to the document. > >> I'm rather disappointed to see this wheel reinvented. SCRAM (RFC5802) >> would fit right in instead of PACE, for example, and has the same >> kinds of properties as PACE, but with a number of advantages over PACE >> (SCRAM is on the Standards Track, received much more review, uses a >> PBKDF with salt and iteration count, is implemented, is reusable in >> many contexts, does channel binding, there's an LDAP schema for >> storing SCRAM password verifiers, ...). >> >> We, secdir, should be encouraging wheel reuse wherever possible over >> wheel reinvention. Shh! You're questioning what may be the IETF's _real_ primary role: full employment for protocol designers. Case in point: > > "We" never have encouraged that. Many of "us" are chairs of WGs whose charters explicitly allow or mandate the opposite of what you are proposing. If you want a change, it has to come from the ADs, not from "us". Reinventing the wheel 'r' us! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNp6ksAAoJEG4XtfZZU7RfebYH/R5uVr6nhibBuiCAYue3T0XG rn7tpdkNJY25kok4vB7j7oCsJBT3E5j2xD5Rl6+FCRUICaL/UWyKJ1M8SQn5HNc6 rioVATMS9XUmeVBe/8qvYRh7wusxLrEiMTho3Q/MIpLYoAYK24iWSHLNzHxomWEI 2TFGe/padcxXLjs8lYqA4OMJu8jTvR2cPxKYCIKUUKubotyE4UGQmFYgBUxX1E8Y vaz/7GNLBJnls2Dk66+ZN8f1Ey4u3z8lJvRoV3zL3zigdW+gbGPvxPjp5HlRfUZU oFgrP5gtivputHDbnE3uKxTpEteN/rt6DTa4jIRe6WtlPEcD1mu9+JaRAs3I9Jw= =D3GG -----END PGP SIGNATURE----- --------------040805000305010907000501 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------040805000305010907000501-- From barryleiba.mailing.lists@gmail.com Fri Apr 15 06:32:41 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A2825E06A9 for ; Fri, 15 Apr 2011 06:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.647 X-Spam-Level: X-Spam-Status: No, score=-103.647 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wgr3PJi3SMWJ for ; Fri, 15 Apr 2011 06:32:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 2B227E0692 for ; Fri, 15 Apr 2011 06:32:37 -0700 (PDT) Received: by wyb29 with SMTP id 29so2527260wyb.31 for ; Fri, 15 Apr 2011 06:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q3S4Dsrijt/0kGaFxPbvxaKBG6onYXzVzNiWRpN2HpE=; b=QJc8sebhHzKPrUkBgVOHXICf8E+imWr1R8BresbAUwMOeVtcjOsY3/xlcxJFYNeKw8 ipXNeeeEPCWwqZ3FdIoY9jqnnqiVAUqnZzf5GTg3F+5Cup1fuMFsIQ0eQEc3l70z+nEy NiPxph65j4sZ3VuI0Cfd+3nPCA4w68GFHSvBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=idtmJP/2GXM85SLWsytLAadfsz6CM+GVlqe0ix9yzlw9teoOnY5h366xlsWU3Y3fli LRjeuT1P2+Vwu5PZfEYlvk434ZzCvjyapSPeaRsVx/AzteNy6RIQjgnwoUhyMoEhEk89 53ln2vFG+DHFciau8TtOyrNQKXfBCREszxAzg= MIME-Version: 1.0 Received: by 10.227.28.94 with SMTP id l30mr2055088wbc.100.1302874356344; Fri, 15 Apr 2011 06:32:36 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.227.146.197 with HTTP; Fri, 15 Apr 2011 06:32:36 -0700 (PDT) Date: Fri, 15 Apr 2011 09:32:36 -0400 X-Google-Sender-Auth: IUswZar4uM-kM9LXSzV6d53yItE Message-ID: From: Barry Leiba To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "secdir@ietf.org" Subject: [secdir] What and who is SecDir? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:32:41 -0000 Over in the "secdir review of draft-kuegler-ipsecme-pace-ikev2" thread, Paul and Nico had this exchange, which I don't want to see lost in that thread that not everyone will be reading: Nico: >>> "We", secdir, are volunteers. =A0This volunteer would rather avoid whee= l >>> reinvention, and this volunteer, perhaps naively, had hoped others >>> would agree. =A0Perhaps other volunteers disagree (you do). =A0I >>> explicitly referred to secdir, not WG chairs, not ADs, nor did I refer >>> to actual current practice, but rather stated an opinion of what we >>> ought to do. Paul: >> Most people on secdir are here because they are chairs of WGs in the Sec= urity >> Area. Maybe you are thinking of the old secdir model. :-) Nico: > Perhaps I don't belong here any longer then? =A0And yes, I'm thinking of > the old secdir model. =A0When was it abandoned? =A0(We both seem to be ou= t > of date then regarding secdir practices!) As I see it -- and the ADs can chime in if they see it differently -- Nico and Paul are both right. We are volunteers who want to see security issues in IETF protocols brought up and discussed, and who are willing to help do that through reviews and discussion. The group is seeded with the chairs from the sec-area WGs, but it doesn't comprise those chairs exclusively. And I, at least, wouldn't like it to. For my part, I certainly think, Nico, that you do still belong here. I'd hate to see people leave this directorate just because they no longer chair any sec-area WGs. That we don't always agree, as a group, and that there are sometimes arguments about the appropriateness of one reviewers comments, from the point of view of another, is only natural. If those disagreements lead to interesting, useful discussions (even if they briefly become "arguments", and sometimes get a bit heated), that's all the better. No part of the IETF is strife-free. Just so long as we leave the twibills back in the armory. http://www.youtube.com/watch?v=3DteMlv3ripSM Barry From stephen.farrell@cs.tcd.ie Fri Apr 15 06:42:31 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D88B7E06B6 for ; Fri, 15 Apr 2011 06:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.932 X-Spam-Level: X-Spam-Status: No, score=-104.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2FoTcnRA3VH for ; Fri, 15 Apr 2011 06:42:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id B563FE06DB for ; Fri, 15 Apr 2011 06:42:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3EBD1171C9A; Fri, 15 Apr 2011 14:42:30 +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=1302874949; bh=Y51dJt18+pOggn nagD8yiKjH2W9tND+270rdzykyXoo=; b=UWe1L8hC4rgujF+e+ma2dlqq54Q4xf cUmNKbKGNvAwcrcgeAIw9rt7u/ocN6AfApMw+aHZa3AEjA3JSNEqIoGxBZ0u1MMp pCiKjXjI3i0teMQ7HHLJ1Dr1lORDw/otX9M7h/BaNN7ny7oP1OXD/eIq70ltT93u U6ucJzx+LeLn6P22aIjcSpXfQZ/8CTr9JHwVZzmdOz8RFaJZjh2t1t71hsPbvHAe Re4poNG+tbr258wN5RHg/FIdul6qq6oHs0kkBUPVJ4iCVly0HrraLlzrA8B4R10n h8epwyORB1EKZUaVwmhMNuhj5f4eMUMafc5KHm199M1chrdOS++91h+g== 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 OpAqdlwLxt8A; Fri, 15 Apr 2011 14:42:29 +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 9F160171C70; Fri, 15 Apr 2011 14:42:27 +0100 (IST) Message-ID: <4DA84B43.4090200@cs.tcd.ie> Date: Fri, 15 Apr 2011 14:42:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" Subject: Re: [secdir] What and who is SecDir? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 13:42:32 -0000 Nicely put. Only thing I'd add is that for some discussions it might be useful to move to saag or ietf-discuss if getting broader input is useful, since while secdir archives are open, posting is moderated. I don't think anyone needs permission for that, but I guess as ADs we should be watching out for discussions that would be better in a more open environment. In this case, it was a pretty quick flurry of mails that got resolved so that wasn't appropriate. S. On 15/04/11 14:32, Barry Leiba wrote: > Over in the "secdir review of draft-kuegler-ipsecme-pace-ikev2" > thread, Paul and Nico had this exchange, which I don't want to see > lost in that thread that not everyone will be reading: > > Nico: >>>> "We", secdir, are volunteers. This volunteer would rather avoid wheel >>>> reinvention, and this volunteer, perhaps naively, had hoped others >>>> would agree. Perhaps other volunteers disagree (you do). I >>>> explicitly referred to secdir, not WG chairs, not ADs, nor did I refer >>>> to actual current practice, but rather stated an opinion of what we >>>> ought to do. > > Paul: >>> Most people on secdir are here because they are chairs of WGs in the Security >>> Area. Maybe you are thinking of the old secdir model. :-) > > Nico: >> Perhaps I don't belong here any longer then? And yes, I'm thinking of >> the old secdir model. When was it abandoned? (We both seem to be out >> of date then regarding secdir practices!) > > As I see it -- and the ADs can chime in if they see it differently -- > Nico and Paul are both right. We are volunteers who want to see > security issues in IETF protocols brought up and discussed, and who > are willing to help do that through reviews and discussion. The group > is seeded with the chairs from the sec-area WGs, but it doesn't > comprise those chairs exclusively. And I, at least, wouldn't like it > to. > > For my part, I certainly think, Nico, that you do still belong here. > I'd hate to see people leave this directorate just because they no > longer chair any sec-area WGs. That we don't always agree, as a > group, and that there are sometimes arguments about the > appropriateness of one reviewers comments, from the point of view of > another, is only natural. If those disagreements lead to interesting, > useful discussions (even if they briefly become "arguments", and > sometimes get a bit heated), that's all the better. No part of the > IETF is strife-free. Just so long as we leave the twibills back in > the armory. > > http://www.youtube.com/watch?v=teMlv3ripSM > > Barry > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From derek@ihtfp.com Fri Apr 15 11:02:33 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6DE3FE08C5 for ; Fri, 15 Apr 2011 11:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdjtGQLNqiKG for ; Fri, 15 Apr 2011 11:02:29 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfc.amsl.com (Postfix) with ESMTP id A819BE08BA for ; Fri, 15 Apr 2011 11:02:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2FF2526032A; Fri, 15 Apr 2011 14:02:19 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28430-04; Fri, 15 Apr 2011 14:02:14 -0400 (EDT) Received: from pgpdev.ihtfp.org (c-24-98-103-116.hsd1.ga.comcast.net [24.98.103.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 085D526031B; Fri, 15 Apr 2011 14:02:13 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p3FI26Ej031557; Fri, 15 Apr 2011 14:02:06 -0400 From: Derek Atkins To: Barry Leiba References: Date: Fri, 15 Apr 2011 14:02:06 -0400 In-Reply-To: (Barry Leiba's message of "Fri, 15 Apr 2011 09:32:36 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "secdir@ietf.org" Subject: Re: [secdir] What and who is SecDir? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:02:33 -0000 Barry Leiba writes: > For my part, I certainly think, Nico, that you do still belong here. > I'd hate to see people leave this directorate just because they no > longer chair any sec-area WGs. That we don't always agree, as a If that were the case I'd have left the directorate a while ago, and a number of current members would never have been on it (because they have not been chairs of security-area working groups). I don't think that having a blue dot is a requirement to be on the sec-dir (although I think that the inverse is true, having a blue dot (in the security area) should require you to join sec-dir. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From smb@cs.columbia.edu Fri Apr 15 11:31:46 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38DB2E079D for ; Fri, 15 Apr 2011 11:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVgQkMNQ48kL for ; Fri, 15 Apr 2011 11:31:45 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfc.amsl.com (Postfix) with ESMTP id 741A1E06B0 for ; Fri, 15 Apr 2011 11:31:45 -0700 (PDT) Received: from [192.168.147.175] (74-202-225-34.static.twtelecom.net [74.202.225.34] (may be forged)) (user=smb2132 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p3FIVA30009012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Apr 2011 14:31:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Fri, 15 Apr 2011 14:31:09 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Derek Atkins X-Mailer: Apple Mail (2.1084) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: Barry Leiba , "secdir@ietf.org" Subject: Re: [secdir] What and who is SecDir? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:31:46 -0000 On Apr 15, 2011, at 2:02 06PM, Derek Atkins wrote: > Barry Leiba writes: > >> For my part, I certainly think, Nico, that you do still belong here. >> I'd hate to see people leave this directorate just because they no >> longer chair any sec-area WGs. That we don't always agree, as a > > If that were the case I'd have left the directorate a while ago, and a > number of current members would never have been on it (because they have > not been chairs of security-area working groups). I don't think that > having a blue dot is a requirement to be on the sec-dir (although I > think that the inverse is true, having a blue dot (in the security area) > should require you to join sec-dir. As the former SEC AD who set up the current structure, you're quite right. I (re)started it as a group of people whom I thought could contribute to security in IETF protocols, and shortly thereafter (I forget on whose suggestion) added the SEC WG chairs. --Steve Bellovin, https://www.cs.columbia.edu/~smb From kent@bbn.com Fri Apr 15 11:45:53 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C082AE06B0; Fri, 15 Apr 2011 11:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.686 X-Spam-Level: X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytiYINcEoz9A; Fri, 15 Apr 2011 11:45:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 07E8EE065F; Fri, 15 Apr 2011 11:45:51 -0700 (PDT) Received: from dhcp89-089-062.bbn.com ([128.89.89.62]:49209) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QAo1f-00068K-2f; Fri, 15 Apr 2011 14:45:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Fri, 15 Apr 2011 14:45:46 -0400 To: Sam Hartman From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-909229346==_ma============" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:45:53 -0000 --============_-909229346==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sam, In response to your comments on the res-certs draft, re the restrictive nature of the relying party checks in certs, we have prepare the following text that will be included as a new section in the document. Steve ----- Operational Considerations This profile requires that relying parties reject certificates or CRLs that do not conform to the profile. (Through the remainder of this section the term "certificate" is used to refer to both certificates and CRLs.) This includes certificates that contain extensions that are prohibited, but which are otherwise valid as per RFC 5280. This means that any change in the profile (e.g., extensions, permitted attributes or optional fields, or field encodings) for certificates used in the RPKI will not be backward compatible. In a general PKI context this constraint probably would cause serious problems. In the RPKI, several factors minimize the difficulty of effecting changes of this sort. Note that the RPKI is unique in that every relying party (RP) requires access to every certificate and every CRL issued by the CAs in this system. An important update of the certificates and CRLs used in the RPKI must be supported by all CAs and RPs in the system, lest views of the RPKI data differ across RPs. Thus incremental changes require very careful coordination. It would not be appropriate to introduce a new extension, or authorize use of an extant, standard extension, for a security-relevant purpose on a piecemeal basis. One might imagine that the "critical" flag in X.509 certificate and CRL extensions could be used to ameliorate this problem. However, this solution is not comprehensive, and does not address the problem of adding a new, security-critical extension. (This is because such an extension needs to be supported universally, by all CAs and RPs.) Also, while some standard extensions can be marked either critical or non-critical, at the discretion of the issuer, not all have this property, i.e., some standard extensions are always non-critical. Moreover, there is no notion of criticality for attributes within a name or optional fields within a field or an extension. Thus the critical flag is not a solution to this problem. In typical PKI deployments there are few CAs and many RPs. However, in the RPKI, essentially every CA in the RPKI is also an RP. Thus the set of entities that will need to change in order to issue certificates under a new format is the same set of entities that will need to change to accept these new certificates. To the extent that this is literally true it says that CA/RP coordination for a change is tightly linked anyway. In reality there is an important exception to this general observation. Small ISPs and holders of provider-independent allocations are expected to use managed CA services, offered by RIRs/NIRs and by large ISPs. (All RIRs already offer managed CA services as part of their initial RPKI deployment.) This reduces the number of distinct CA implementations that are needed, and makes it easier to effect changes for certificate issuance. It seems very likely that these entities also will make use of RP software provided by their managed CA service provider, which reduces the number of distinct RP software implementations. Also note that many small ISPs (and holders of provider-independent allocations) employ default routes, and thus need not perform RP validation of RPKI data, eliminating these entities as RPs. Widely available PKI RP software does not cache large numbers of certificates and CRLs, an essential strategy for the RPKI. It does not process manifest or ROA data structures, essential elements of the RPKI repository system. Experience shows that such software deals poorly with revocation status data. Thus extant RP software is not adequate for the RPKI, although some open source tools (e.g., OpenSSL and cryptlib) can be used as building blocks for an RPKI RP implementation. Thus it is anticipated that RPs will make use of software designed specifically for the RPKI environment, and available from a limited number of open sources. Several RIRs and two companies are providing such software today. Thus it is feasible to coordinate change to this software among the small number of developers/maintainers. If the resource certificate format is changed in the future, e.g., by adding a new extension or changing the allowed set of name attributes or encoding of these attributes, the following procedure will be employed to effect deployment in the RPKI. The model is analogous to that described in [draft-ietf-sidr-algorithm-agility-00], but is simpler. A new document will be issued as an update to this RFC. The CP for the RPKI [ID-sidr-cp] will be updated to reference the new certificate profile. The new CP will define a new policy OID for certificates issued under the new certificate profile. The updated CP also will define a timeline for transition to the new certificate (CRL) format. This timeline will define 3 phases and associated dates: 1- At the end of phase 1, all RPKI CAs MUST be capable of issuing certificates under the new profile, if requested by a subject. Any certificate issued under the new format will contain the new policy OID. 2- During phase 2 CAs MUST issue certificates under the new profile, and these certificates MUST co-exist with certificates issued under the old format. (CAs will continue to issue certificates under the old OID/format as well.) The old and new certificates MUST be identical, except for the policy OID and any new extensions, encodings, etc. Relying parties MAY make use of the old or the new certificate formats when processing signed objects retrieved from the RPKI repository system. During this phase, a relying party that elects to process both formats will acquire the same values for all certificate fields that overlap between the old and new formats. Thus if either certificate format is verifiable, the relying party accepts the data from that certificate. This allows CAs to issue certificates under 3- At the beginning of phase 3, all relying parties MUST be capable of processing certificates under the new format. During this phase CAs will issue new certificates ONLY under the new format. During this phase, certificates issued under the old OID will be replaced with certificates containing the new policy OID. The repository system will no longer require matching old and new certificates under the different formats. At the end of phase 3, all certificates under the old OID will have been replaced. The resource certificate profile RFC will be replaced to remove support for the old certificate format, and the CP will be replaced to remove reference to the old policy OID and to the old resource certificate profile RFC. The system will have returned to a new, steady state. --============_-909229346==_ma============ Content-Type: text/html; charset="us-ascii" Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Sam,

In response to your comments on the res-certs draft, re the restrictive nature of the relying party checks in certs, we have prepare the following text that will be included as a new section in the document.

Steve

-----

Operational Considerations

This profile requires that relying parties reject certificates or CRLs that do not conform to the profile. (Through the remainder of this section the term "certificate" is used to refer to both certificates and CRLs.)
This includes certificates that contain extensions that are prohibited, but which are otherwise valid as per RFC 5280. This means that any change in the profile (e.g., extensions, permitted attributes or optional fields, or field encodings) for certificates used in the RPKI will not be backward compatible. In a general PKI context this constraint probably would cause serious problems. In the RPKI, several factors minimize the difficulty of effecting changes of this sort.

Note that the RPKI is unique in that every relying party (RP) requires access to every certificate and every CRL issued by the CAs in this system. An important update of the certificates and CRLs used in the RPKI must be supported by all CAs and RPs in the system, lest views of the RPKI data differ across RPs. Thus incremental changes require very careful coordination. It would not be appropriate to introduce a new extension, or authorize use of an extant, standard extension, for a security-relevant purpose on a piecemeal basis.

One might imagine that the "critical" flag in X.509 certificate and CRL extensions could be used to ameliorate this problem. However, this solution is not comprehensive, and does not address the problem of adding a new, security-critical extension. (This is because such an extension needs to be supported universally, by all CAs and RPs.) Also, while some standard extensions can be marked either critical or non-critical, at the discretion of the issuer, not all have this property, i.e., some standard extensions are always non-critical. Moreover, there is no notion of criticality for attributes within a name or optional fields within a field or an extension. Thus the critical flag is not a solution to this problem.

In typical PKI deployments there are few CAs and many RPs. However, in the RPKI, essentially every CA in the RPKI is also an RP. Thus the set of entities that will need to change in order to issue certificates under a new format is the same set of entities that will need to change to accept these new certificates. To the extent that this is literally true it says that CA/RP coordination for a change is tightly linked anyway. In reality there is an important exception to this general observation. Small ISPs and holders of provider-independent allocations are expected to use managed CA services, offered by RIRs/NIRs and by large ISPs. (All RIRs already offer managed CA services as part of their initial RPKI deployment.) This reduces the number of distinct CA implementations that are needed, and makes it easier to effect changes for certificate issuance. It seems very likely that these entities also will make use of RP software provided by their managed CA service provider, which reduces the number of distinct RP software implementations. Also note that many small ISPs (and holders of provider-independent allocations) employ default routes, and thus need not perform RP validation of RPKI data, eliminating these entities as RPs.

Widely available PKI RP software does not cache large numbers of certificates and CRLs, an essential strategy for the RPKI. It does not process manifest or ROA data structures, essential elements of the RPKI repository system. Experience shows that such software deals poorly with revocation status data. Thus extant RP software is not adequate for the RPKI, although some open source tools (e.g., OpenSSL and cryptlib) can be used as building blocks for an RPKI RP implementation. Thus it is anticipated that RPs will make use of software designed specifically for the RPKI environment, and available from a limited number of open sources. Several RIRs and two companies are providing such software today. Thus it is feasible to coordinate change to this software among the small number of developers/maintainers.

If the resource certificate format is changed in the future, e.g., by  adding a new extension or changing the allowed set of name attributes or encoding of these attributes, the following procedure will be employed to effect deployment in the RPKI. The model is analogous to that described in [draft-ietf-sidr-algorithm-agility-00], but is simpler.

A new document will be issued as an update to this RFC.  The CP for the RPKI [ID-sidr-cp] will be updated to reference the new certificate profile. The new CP will define a new policy OID for certificates issued under the new certificate profile. The updated CP also will define a timeline for transition to the new certificate (CRL) format. This timeline will define 3 phases and associated dates:
        1- At the end of phase 1, all RPKI CAs MUST be capable of issuing certificates under the new profile, if requested by a subject. Any certificate issued under the new format will contain the new policy OID.

        2- During phase 2 CAs MUST issue certificates under the new profile, and these certificates MUST co-exist with certificates issued under the old format. (CAs will continue to issue certificates under the old OID/format as well.) The old and new certificates MUST be identical, except for the policy OID and any new extensions, encodings, etc. Relying parties MAY make use of the old or the new certificate formats when processing signed objects retrieved from the RPKI repository system. During this phase, a relying party that elects to process both formats will acquire the same values for all certificate fields that overlap between the old and new formats. Thus if either certificate format is verifiable, the relying party accepts the data from that certificate. This allows CAs to issue certificates under

        3- At the beginning of phase 3, all relying parties MUST be capable of processing certificates under the new format. During this phase CAs will issue new certificates ONLY under the new format. During this phase, certificates issued under the old OID will be replaced with certificates containing the new policy OID. The repository system will no longer require matching old and new certificates under the different formats.

At the end of phase 3, all certificates under the old OID will have been replaced. The resource certificate profile RFC will be replaced to remove support for the old certificate format, and the CP will be replaced to remove reference to the old policy OID and to the old resource certificate profile RFC. The system will have returned to a new, steady state.
--============_-909229346==_ma============-- From tobias.gondrom@gondrom.org Sat Apr 16 11:22:56 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A102E06EF for ; Sat, 16 Apr 2011 11:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.375 X-Spam-Level: X-Spam-Status: No, score=-95.375 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQmD7CjZiC2I for ; Sat, 16 Apr 2011 11:22:55 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfc.amsl.com (Postfix) with ESMTP id 8EAA7E0681 for ; Sat, 16 Apr 2011 11:22:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=DDrhFxhszeTheCvAjicYd3SgK3NUcSoe8ARDN7Cz9J6GtWz2drIv1Qkz+GwwcINRKygg5bjWqQo3iFIeoOWu07NivMm1DZlqOzPwi4Q0c8SaMLXcRl0U/JH5pDxujOlh; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 21689 invoked from network); 16 Apr 2011 20:22:25 +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; 16 Apr 2011 20:22:25 +0200 Message-ID: <4DA9DE82.2080105@gondrom.org> Date: Sat, 16 Apr 2011 19:22:58 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: secdir@ietf.org X-Priority: 4 (Low) References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] What and who is SecDir? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 18:22:56 -0000 On 04/15/2011 02:32 PM, Barry Leiba wrote: > Over in the "secdir review of draft-kuegler-ipsecme-pace-ikev2" > thread, Paul and Nico had this exchange, which I don't want to see > lost in that thread that not everyone will be reading: > > Nico: >>>> "We", secdir, are volunteers. This volunteer would rather avoid wheel >>>> reinvention, and this volunteer, perhaps naively, had hoped others >>>> would agree. Perhaps other volunteers disagree (you do). I >>>> explicitly referred to secdir, not WG chairs, not ADs, nor did I refer >>>> to actual current practice, but rather stated an opinion of what we >>>> ought to do. > Paul: >>> Most people on secdir are here because they are chairs of WGs in the Security >>> Area. Maybe you are thinking of the old secdir model. :-) > Nico: >> Perhaps I don't belong here any longer then? And yes, I'm thinking of >> the old secdir model. When was it abandoned? (We both seem to be out >> of date then regarding secdir practices!) > As I see it -- and the ADs can chime in if they see it differently -- > Nico and Paul are both right. We are volunteers who want to see > security issues in IETF protocols brought up and discussed, and who > are willing to help do that through reviews and discussion. The group > is seeded with the chairs from the sec-area WGs, but it doesn't > comprise those chairs exclusively. And I, at least, wouldn't like it > to. Big +1. ;-) And thank you for mentioning this on the secdir list. And loved the film. ;-) Tobias > For my part, I certainly think, Nico, that you do still belong here. > I'd hate to see people leave this directorate just because they no > longer chair any sec-area WGs. That we don't always agree, as a > group, and that there are sometimes arguments about the > appropriateness of one reviewers comments, from the point of view of > another, is only natural. If those disagreements lead to interesting, > useful discussions (even if they briefly become "arguments", and > sometimes get a bit heated), that's all the better. No part of the > IETF is strife-free. Just so long as we leave the twibills back in > the armory. > > http://www.youtube.com/watch?v=teMlv3ripSM > > Barry > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From tobias.gondrom@gondrom.org Sat Apr 16 14:12:21 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 402EBE06E2 for ; Sat, 16 Apr 2011 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.373 X-Spam-Level: X-Spam-Status: No, score=-95.373 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXuW2CdwEJf7 for ; Sat, 16 Apr 2011 14:12:21 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfc.amsl.com (Postfix) with ESMTP id 5C29EE06FE for ; Sat, 16 Apr 2011 14:12:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=gsXz1Fh1g7niULKmVQAh8m3xTF8peMbMMDPyEtPPWgPynlmYlFjpx8IqLVdIzB370juM7fMhOeS7IVZZvOMZMrMfq+6hVwU5CFQgIxtpfiQlEYPpSe2dXJu+9RGDgGqE; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 24180 invoked from network); 16 Apr 2011 23:11:43 +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; 16 Apr 2011 23:11:43 +0200 Message-ID: <4DAA0630.3020606@gondrom.org> Date: Sat, 16 Apr 2011 22:12:16 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-siprec-req.all@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rajnish.jain@ipc.com, leon.portman@nice.com, krehor@cisco.com, andrew.hutton@siemens-enterprise.com Subject: [secdir] Secdir review of draft-ietf-siprec-req X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 21:12:21 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. http://www.ietf.org/id/draft-ietf-siprec-req-09.txt The document is informational and describes use cases and requirements for SIP-based Media Recording. Overall I agree with the stated requirements in the document and consider the Privacy and Security Considerations sufficient. Privacy and Security sections could be enhanced by clarifying that the integrity and correctness of the recorded data is not ensured by (cryptographic) means to ensure that the CS has not been tampered with (also see below). At least AFAIK. This would have to be done by organizational and technical controls that prevent tampering with the recording UA and the data stream between end point UA and SRC. Best regards, Tobias Ps.: On a personal note a small suggestion/idea for the authors: - it seem the non-repudiation, authenticity and completeness (no dropped packets) of recorded CS linked to individual participants is basically unproven (if not impossible to prove in this setting?). I.e. an evil recording entity might twist incoming streams from participants to re-align given answers to different points in the stream or re-align its own statements. E.g. actual dialogue: 1. participant A "Do you want to buy this product?" 2. participant B: "No." 3. participant A "Do you want to abort this operation?" 4. participant B: "Yes." Could be twisted to: 1. participant A "Do you want to buy this product?" 4. participant B: "Yes." 3. participant A "Do you want to abort this operation?" 2. participant B: "No." or with only control of your own recorded data-stream: 3. participant A "Do you want to abort this operation?" 2. participant B: "No." 1. participant A "Do you want to buy this product?" 4. participant B: "Yes." I wonder whether authentication means (like signing) your session stream with a personal key and chronology integrity ensuring mechanisms (reliably linking messages to timestamps or previous messages from the other party) would be worth consideration and could prevent such an attack. From john-ietf@jck.com Sun Apr 17 06:27:37 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 137E4E074A; Sun, 17 Apr 2011 06:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9b-w3dVw+l8; Sun, 17 Apr 2011 06:27:36 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfc.amsl.com (Postfix) with ESMTP id 491F3E0694; Sun, 17 Apr 2011 06:27:36 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QBS0j-000PXc-Lc; Sun, 17 Apr 2011 09:27:33 -0400 Date: Sun, 17 Apr 2011 09:27:32 -0400 From: John C Klensin To: Stephen Kent , Sam Hartman Message-ID: <1446DA6A65B664240D8AA4F9@PST.JCK.COM> In-Reply-To: References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: draft-ietf-sidr-res-certs@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 13:27:37 -0000 Steve, Two things: (1) Given the variable amount of time it takes to get RFCs issued/ published after IESG signoff, are you and the WG sure that you want to tie the phases of the phase-in procedure to RFC publication? (2) There is an incomplete sentence at the end of (2): "This allows CAs to issue certificates under" (more context below). john --On Friday, April 15, 2011 14:45 -0400 Stephen Kent wrote: > 2- During phase 2 CAs MUST issue certificates under the new > profile, and these certificates MUST co-exist with > certificates issued under the old format. (CAs will continue > to issue certificates under the old OID/format as well.) The > old and new certificates MUST be identical, except for the > policy OID and any new extensions, encodings, etc. Relying > parties MAY make use of the old or the new certificate formats > when processing signed objects retrieved from the RPKI > repository system. During this phase, a relying party that > elects to process both formats will acquire the same values > for all certificate fields that overlap between the old and > new formats. Thus if either certificate format is verifiable, > the relying party accepts the data from that certificate. This > allows CAs to issue certificates under > > 3- At the beginning of phase 3, all relying parties MUST be > capable of processing certificates under the new format. >... From gwz@net-zen.net Sun Apr 17 23:02:21 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 615A9E068B for ; Sun, 17 Apr 2011 23:02:21 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDPzHf3i1whl for ; Sun, 17 Apr 2011 23:02:17 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by ietfc.amsl.com (Postfix) with SMTP id F173BE0655 for ; Sun, 17 Apr 2011 23:02:16 -0700 (PDT) Received: (qmail 422 invoked from network); 18 Apr 2011 06:02:16 -0000 Received: from unknown (124.120.180.55) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 18 Apr 2011 06:02:15 -0000 Message-ID: <4DABD3E3.4020209@net-zen.net> Date: Mon, 18 Apr 2011 13:02:11 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Derek Atkins References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------050105080102030801050104" Cc: Barry Leiba , "secdir@ietf.org" Subject: Re: [secdir] What and who is SecDir? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:02:21 -0000 This is a multi-part message in MIME format. --------------050105080102030801050104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/16/2011 1:02 AM, Derek Atkins wrote: > Barry Leiba writes: > >> For my part, I certainly think, Nico, that you do still belong here. >> I'd hate to see people leave this directorate just because they no >> longer chair any sec-area WGs. That we don't always agree, as a > > If that were the case I'd have left the directorate a while ago, and a > number of current members would never have been on it (because they have > not been chairs of security-area working groups). I don't think that > having a blue dot is a requirement to be on the sec-dir (although I > think that the inverse is true, having a blue dot (in the security area) > should require you to join sec-dir. It depends: if the goal is to gather security clue, a blue dot in the security area doesn't guarantee that; in fact, I can think of a couple who should probably be excluded... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNq9PjAAoJEG4XtfZZU7RflakIALYTyM/jZW9mGKACgfCwsdFW TLQmvhqQHIDx6LpuV0t7oP9Ggb/91RKlhO71ckF1faYIjc7PKkhoFwKHD2zpxZil Du1BPYnmXQfSI9VlfSMR4kTKHPlnEzBcxk5V8j7ax+LhiqO76VvQ0Xdf7V/zmCzf XP3zTV/SQ1j7wm9LwQ1P13jvtheeTtJr/RK4lOlAYzQYlXMqYaWi4Aqx0KXpxixa IdHSBABccZoJuEU5siXFxLjlXyT01QafqC5So7kbrywrCDDx5dw/HW73lSv3Ff2L 0kXseTC3QH7Mc+Wc2jPyUdxC1LXnwbFMGXIhKLVInac1/dLe5CbuCLQq2bt30Gw= =xKMM -----END PGP SIGNATURE----- --------------050105080102030801050104 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------050105080102030801050104-- From yaronf.ietf@gmail.com Mon Apr 18 06:56:12 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E63B6E0703; Mon, 18 Apr 2011 06:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR45EvaSevNm; Mon, 18 Apr 2011 06:56:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7E3BAE06F7; Mon, 18 Apr 2011 06:56:08 -0700 (PDT) Received: by wyb29 with SMTP id 29so4454651wyb.31 for ; Mon, 18 Apr 2011 06:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0ZONwNcZ7/ATAw1sNrJ8BbQWU4dhXckOz6GLYexJni8=; b=U4f827cxaAgzq2de4i0Arc7o/4dRk/b2H1lT2v9FRMgNwQRwwTXpMYOtiqBLmvqUJ0 i+gfGF65BXY10v2c1Sl4jv9mMVMvU5qX+kqQ9GZs+of90qr2EovUXmy0znu0YQdxcEA2 3Y64oFdW+PMfwKNJUqf9/F9wBsE4/pI95hXIM= 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=XWGzPkLTvYV/FsgePjkMZsnsIOJ5mfFt4hsIq5TuoNLPYEvz9Q/pVDPop8OOVspblu uUQrShNMlwnOzelxhTCOZU7DHBuCE4PP2DsfX3c2DbhAKJltIl39Uk1wGAagteks4UFH 807HlRDUKkyx3L/ULku7hQkrCRIasn3dfjwgU= Received: by 10.227.196.207 with SMTP id eh15mr2570577wbb.145.1303134967611; Mon, 18 Apr 2011 06:56:07 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-30-144.red.bezeqint.net [79.178.30.144]) by mx.google.com with ESMTPS id p5sm3283644wbg.11.2011.04.18.06.56.03 (version=SSLv3 cipher=OTHER); Mon, 18 Apr 2011 06:56:06 -0700 (PDT) Message-ID: <4DAC42F1.4080509@gmail.com> Date: Mon, 18 Apr 2011 16:56:01 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Benoit Claise References: <4D7F1516.6080401@gmail.com> <4D7F20B2.3070102@cisco.com> <4DAC3387.8030306@cisco.com> In-Reply-To: <4DAC3387.8030306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ipfix-structured-data.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-structured-data-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:56:13 -0000 Hi Benoit, the new text is fine with me. Thanks, Yaron On 04/18/2011 03:50 PM, Benoit Claise wrote: > Hi Yaron, > > Discussing with the other authors, we propose: > > OLD: > > 12. Security Considerations > > The same security considerations as for the IPFIX Protocol > [RFC5101 ] and the IPFIX > information model [RFC5102 ] apply. > > > NEW: > > 12. Security Considerations > > The addition of complex data types necessarily complicates the > implementation of the Collector. This could easily result in new > security vulnerabilities (e.g., buffer overflows); this creates > additional risk in cases where either DTLS is not used, or if the > Observation Point and Collector belong to different trust domains. > Otherwise, the same security considerations as for the IPFIX Protocol > [RFC5101 ] and the IPFIX > information model [RFC5102 ] apply. > > Regards, Benoit. >> Hi Yaron, >> >> Thanks for your feedback. >> Sure we should add your proposed sentence. >> >> Regards, Benoit. >>> 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. >>> >>> IPFIX is a structured information model and protocol for transmitting >>> information about data flows. This document extends the model with >>> structured data, basically several types of lists. >>> >>> I have not reviewed the document in full, rather I have looked at the >>> security aspects only. The Security Considerations refer the reader >>> to the IPFIX protocol and data model RFCs, and I mostly agree, with >>> one exception. I suggest to add text similar to the next paragraph: >>> >>> The addition of complex data types necessarily complicates the >>> implementation of the Collector. This could easily result in new >>> security vulnerabilities (e.g., buffer overflows); this creates >>> additional risk in cases where either DTLS is not used, or if the >>> Observation Point and Collector belong to different trust domains. >>> >>> Thanks, >>> Yaron > From barryleiba@gmail.com Mon Apr 18 09:59:40 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6417E07FF; Mon, 18 Apr 2011 09:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.797 X-Spam-Level: X-Spam-Status: No, score=-102.797 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1dc4OMIuyc1; Mon, 18 Apr 2011 09:59:39 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfc.amsl.com (Postfix) with ESMTP id 64D63E0670; Mon, 18 Apr 2011 09:59:39 -0700 (PDT) Received: by ywi6 with SMTP id 6so1679529ywi.31 for ; Mon, 18 Apr 2011 09:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=lLqqILXkF/46z4tWyDo19aNfmdKOfpwHNkE7w3iglJA=; b=QWIVEcpRVkOAj7R7KV6i9TXwWCPTT5Xm0ZurWHsZ8xjv5gs4+xfR85lpAx56QqYzQH v8TWiI9QEWnwHVYB/061hsk6KTU2xfXSxwZaPyf/R8/x3iJs5mJhr25nt9HikLifSQMZ kWGfAJ+BuRpPhgOlCPTVJGM0R73Cph5/3WWVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=YIgwJrq2vzpnzU9PsH5aFXr1ncLff+/O/CPV89Q0d+RZxdPecEjKu5uEp/nY1TCOIP Y42M4MH8MVAc8PYBx09rEb2NKlHjEqFc/6i/MNefPDKf8P/qY3qeFjp9ZQrbsSHQjO4x FTg+HoyuOfouqiUdBFZBv/T5JAhA/Vv37N4rs= MIME-Version: 1.0 Received: by 10.150.60.9 with SMTP id i9mr1156438yba.415.1303145978854; Mon, 18 Apr 2011 09:59:38 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.151.41.13 with HTTP; Mon, 18 Apr 2011 09:59:38 -0700 (PDT) Date: Mon, 18 Apr 2011 12:59:38 -0400 X-Google-Sender-Auth: Z7o3TJ_VWf84XNo6m1Jnc7qIubk Message-ID: From: Barry Leiba To: draft-ietf-vcarddav-vcardrev.all@tools.ietf.org, vcarddav@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-review@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir/apps-area/last-call review of draft-ietf-vcarddav-vcardrev-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:59:41 -0000 This is a "triple-play" review -- I've been asked to review draft-ietf-vcarddav-vcardrev-19 by the security directorate and the applications area review team, and I'd planned to do my own review as well. SECDIR boilerplate: 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. APPS-REVIEW boilerplate: I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. My plat du jour: I should note that I've participated in the vcarddav working group, and have made comments on and contributed text to this document. That said, I'm looking at this with a "from scratch" mind, to be sure I'm considering things afresh. General comments: The document is pretty much ready to ship. The comments I make below are minor, non-controversial, and easily fixed. This is a mature spec that's had quite a lot of review already. Also, I see no security-related issues with the document. Reviewers of the companion document, draft-ietf-vcarddav-vcardxml, will have to make sure the properties and parameters match up correctly. There is a general issue that this "legacy" vCard format does not have a hierarchy that allows nested elements, which limits its extensibility somewhat. The working group did consider whether to abandon this format in favour of using XML *only* for v4.0, and that was deemed infeasible: there remains extensive use of this format, and it needs to be retained, at least for now. Specific comments: ------------------------------ 3.1. Character Set The character set for vCard is UTF-8 as defined in [RFC3629]. There is no way to override this. It is invalid to specify a different character set in the "charset" MIME parameter (see Section 10.1). This isn't consistent with section 10.1. UTF-8 is an encoding, not a character set. Section 10.1 says this, in reference to parameters on the media type: "charset": as defined for text/plain [RFC2046]; encodings other than UTF-8 [RFC3629] MUST NOT be used. That is the correct characterization. The problem is that this is used inconsistently in general, and there's been an extended controversy in EAI about this very thing. RFC 3536 specifies internationalization terminology, and that's currently being updated by draft-hoffman-rfc3536bis. From that document: charset A charset is a method of mapping a sequence of octets to a sequence of abstract characters. A charset is, in effect, a combination of one or more CCSs with a CES. Charset names are registered by the IANA according to procedures documented in [RFC2978]. Many protocol definitions use the term "character set" in their descriptions. The terms "charset" or "character encoding scheme" and "coded character set" are strongly preferred over the term "character set" because "character set" has other definitions in other contexts and this can be confusing. I suggest re-wording 3.1 thus (and an informative reference to RFC 3536 would be reasonable): NEW 3.1. Charset The charset [see RFC3536 for internationalization terminology] for vCard is UTF-8 as defined in [RFC3629]. There is no way to override this. It is invalid to specify a value other than "UTF-8" in the "charset" MIME parameter (see Section 10.1). ------------------------------ 3.3. ABNF Format Definition OLD ; When parsing a content line, folded lines must first ; be unfolded according to the unfolding procedure ; described above. ; When generating a content line, lines longer than 75 ; characters SHOULD be folded according to the folding ; procedure described above. NEW ; When parsing a content line, folded lines must first ; be unfolded according to the unfolding procedure ; described in section 3.2. ; When generating a content line, lines longer than 75 ; characters SHOULD be folded according to the folding ; procedure described in section 3.2. OLD A line that begins with a white space character is a continuation of the previous line, as described above. NEW A line that begins with a white space character is a continuation of the previous line, as described in section 3.2. ------------------------------ Section 3.3 says this: Parameter values MAY be case sensitive or case insensitive, depending on their definition. Based on experience with vCard 3 interoperability, it is RECOMMENDED that property and parameter names be upper-case on output. Some of the parameter definitions ("value" (5.2) and "type" (5.6), for example) use text strings for their values, and give no guidance on case. I suggest changing the paragraph in section 3.3: NEW Parameter values MAY be case-sensitive or case-insensitive, depending on their definitions. Parameter values that are not explicitly defined as being case-sensitive are case-insensitive. Based on experience with vCard 3 interoperability, it is RECOMMENDED that property names and parameter names be upper-case on output. ------------------------------ 3.4. Property Value Escaping OLD Finally, BACKSLASH characters in values MUST be escaped with a BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values MUST be encoded by two characters: a BACKSLASH followed by an 'n' (ASCII decimal 110). This is inconsistent with section 4.1. NEW Finally, BACKSLASH characters in values MUST be escaped with a BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values MUST be encoded by two characters: a BACKSLASH followed by either an 'n' (ASCII decimal 110) or an 'N' (ASCII decimal 78). ------------------------------ 4.5. INTEGER I note that the ABNF allows "-0" (and, in fact, "-00000000") as a valid integer. If that's intended, that's fine; I just wanted to point it out. ------------------------------ 5.9. SORT-AS Is this parameter value intended to be case-sensitive? I think so, and that should be specified. Let's fix the "less/fewer" error, while we're here. OLD This parameter's value is a comma-separated list which MUST have as many or less elements as the corresponding property value has components. NEW This parameter's value is a comma-separated list which MUST have as many or fewer elements as the corresponding property value has components. This parameter's value is case-sensitive. ------------------------------ 6.3.1. ADR Special notes: The structured type value consists of a sequence of address components. The component values MUST be specified in their corresponding position. The structured type value corresponds, in sequence, to the post office box; the extended address (e.g. apartment or suite number); the street address; the locality (e.g., city); the region (e.g., state or province); the postal code; the country name (full name in the language specified in Section 5.1). When a component value is missing, the associated component separator MUST still be specified. SUGGESTION: I think this would be easier to read and get right as a compact list, rather than as a paragraph of text. Maybe like this: NEW Special notes: The structured type value consists of a sequence of address components. The component values MUST be specified in their corresponding position. The structured type value corresponds, in sequence, to the post office box; the extended address (e.g. apartment or suite number); the street address; the locality (e.g., city); the region (e.g., state or province); the postal code; the country name (full name in the language specified in Section 5.1). When a component value is missing, the associated component separator MUST still be specified. ------------------------------ 8. Example: Authors' vCards There's nothing wrong with leaving Pete Resnick's vCard in there as an example, but I'll point out that he hasn't been a document editor since -16 was posted. I'll also point out that these are not "authors", but "editors". Just sayin'.... ------------------------------ 9. Security Considerations I believe the specified security considerations are adequate, and I have no issues with them. ------------------------------ 10.1. MIME Type Registration Person & email address to contact for further information: Simon Perreault Section 10.2.1 specifies the creation of a mailing list, . Perhaps that should be the contact email address for the MIME type registration as well. ------------------------------ 10.2.1. Registration Procedure Nit: change "Standard Tracks RFC" to "Standards Track RFC", throughout. ------------------------------ That's all.... Barry From glenn@cysols.com Tue Apr 12 23:42:24 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AF21CE06EC; Tue, 12 Apr 2011 23:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_46=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBbo7V7FR-EI; Tue, 12 Apr 2011 23:42:24 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by ietfc.amsl.com (Postfix) with ESMTP id 99642E06D1; Tue, 12 Apr 2011 23:42:23 -0700 (PDT) Received: from [192.168.0.193] (cookie.win2004.cysol.co.jp [192.168.0.193]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id p3D6gIaq088424 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 15:42:20 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4DA545C5.4050708@cysols.com> Date: Wed, 13 Apr 2011 15:42:13 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Vincent Roca References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Apr 2011 10:19:34 -0700 Cc: draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 06:42:24 -0000 Hi, Thanks for the review. The response follows. > ** What about the completeness of the two lists provided in > section 6? > For instance the MIB defines the pmip6Capabilities object with > attribute MAX-ACCESS read-only (see p. 13). However this object > is not listed in the security considerations sections. Is it > a mistake? If yes, then does anything miss (I didn't check)? This is not a mistake. Since it is read only, its value cannot be changed by an attacker. And, revealing the capabilities cannot be as harmful as other objects e.g. pmip6Status. [ I will agree that a miscreant may want to physically destroy all objects that have LMA and or MAG capabilities in order to shutdown a PMIPv6 network. The pmip6Capabilities object may be misused in that manner. But that is a generic argument, and holds for ALL the PMIPv6MIB objects.] So, we have not listed this object as one which is "particularly sensitive and/or private". The generic risk aspects are covered in the last paragraph of the security considerations section [copied from the boilerplate]. The 2 lists are complete to our knowledge. Please let us know if there are any risks/vulnerabilities that are worth mentioning. The remaining comments relate to the boilerplate which we have followed to the dot. Cheers, Glenn > (2011/04/11 22:50), Vincent Roca wrote: > 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. > > > Globally, the "Security Considerations" section is well > written and provides details for the associated risks. > It clearly RECOMMENDs the use of SNMPv3, which should not come > as a surprise given the risks associated to previous versions. > This "Security Considerations" section is globally similar > to that of RFC4295 (MIPv6 MIB). > > A few comments: > > ** What about the completeness of the two lists provided in > section 6? > For instance the MIB defines the pmip6Capabilities object with > attribute MAX-ACCESS read-only (see p. 13). However this object > is not listed in the security considerations sections. Is it > a mistake? If yes, then does anything miss (I didn't check)? > > > ** Clarification needed: > It is said: > "Even if the network itself is secure (for example by using IPsec), > even then, there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the objects > in this MIB module." > I'm rather surprised that no ACL (or similar) functionality > be available. If IPsec is enabled, then hosts are authenticated > (using one of several techniques) and it's no longer a big deal > to check the authorizations associated to the peer. So that's > surprising. > > BTW, you can maybe remove the redundant "even then," in above > sentence. > > > ** Wrong reference: > It is said: > "It is RECOMMENDED that implementers consider the security features as > provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" > Section is not the section of interest as it only focuses > on the standardization status. More interesting sections in RFC3410 > are: > - section 6.3 "SNMPv3 security and administration", and in particular > - section 7, in particular section 7.8 "user based security model". > > NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an > issue, now it is. The last sentence of RFC3410/section 7.8 mentions > on-going work on using AES in the user-based security model. If this > work gave birth to an RFC, that's probably a good document to refer > too. > > > ** Obscur: > The last sentence of this section: > "It is then a customer/operator... them." > could easily be improved (split the sentence, please). As such it > remains rather obscure. > > > I hope this is useful. > Cheers, > > Vincent From dennis.kuegler@bsi.bund.de Thu Apr 14 09:39:39 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2758E079C for ; Thu, 14 Apr 2011 09:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0PiZMQI4siZ for ; Thu, 14 Apr 2011 09:39:39 -0700 (PDT) Received: from m4.mfw.bn.ivbb.bund.de (m4-bn.bund.de [77.87.228.76]) by ietfc.amsl.com (Postfix) with ESMTP id ECC1EE0716 for ; Thu, 14 Apr 2011 09:39:37 -0700 (PDT) Received: from m4.mfw.bn.ivbb.bund.de (localhost [127.0.0.1]) by m4.mfw.bn.ivbb.bund.de (8.14.3/8.14.3) with ESMTP id p3EGdVBL007429; Thu, 14 Apr 2011 18:39:31 +0200 (CEST) Received: (from localhost) by m4.mfw.bn.ivbb.bund.de (MSCAN) id 5/m4.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Thu Apr 14 18:39:31 2011 X-P350-Id: 6d3919f233c3d5e0 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: Dennis =?utf-8?q?K=C3=BCgler?= Organization: BSI Bonn To: Nico Williams Date: Thu, 14 Apr 2011 18:39:13 +0200 User-Agent: KMail/1.9.10 (enterprise35 20110321.6842210) References: <4DA69C8A.7000305@gmail.com> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201104141839.13739.dennis.kuegler@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.4.206; VDF: 7.11.6.109; host: sgasmtp2.bsi.de); id=24706-Ta81yY X-Mailman-Approved-At: Tue, 19 Apr 2011 10:19:34 -0700 Cc: "draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:39:40 -0000 Nico, > PACE does not use a standard PBKDF. That's not necessarily a problem, > of course, but it could be. There's no iteration count, for example, > in the SPwd nor KPwd derivations (an iteration count belongs in the > SPwd derivation, if anything). Nor is there any password salting(!), > nor any discussion regarding the absence of salting. The lack of > salting should be considered fatal, IMO. The lack of an iteration > count is less significant, but I'd still rather see an iteration > count. Note that negotiating a salt and iteration count requires an > extra round-trip. And note that iteration count negotiation has > security considerations. "Standard" PBKDF are used to artifically enhance the entopy of the password, because low-entropy passwords are easy targets for dictionary attacks. PACE is a cryptographic protocol that is designed to (mathematically) withstand (passive) dictionary attacks independent of the strength of the password and therefore there is no need for additional countermeasures like salting the password. > > Of course, PACE is targeting Experimental... do we care about > cryptographic issues in Experimental RFCs? I'd say we should, though > less so than for Standards Track RFCs since we can only spare so much > energy. > > I'm rather disappointed to see this wheel reinvented. SCRAM (RFC5802) > would fit right in instead of PACE, for example, and has the same > kinds of properties as PACE, but with a number of advantages over PACE > (SCRAM is on the Standards Track, received much more review, uses a > PBKDF with salt and iteration count, is implemented, is reusable in > many contexts, does channel binding, there's an LDAP schema for > storing SCRAM password verifiers, ...). Actually, the protocols have very different properties. SCRAM (more or less) requires a public key infrastucture in place, while PACE provides an authenticated and encrypted channel without any additional security layer. > > We, secdir, should be encouraging wheel reuse wherever possible over > wheel reinvention. Once you decide to abandon those simple and insecure password-based challenge/response protocols, feel free to make use of PACE instead of reinventing the wheel :-) Dennis From bclaise@cisco.com Mon Apr 18 06:29:52 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94429E07DD; Mon, 18 Apr 2011 06:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji1+yjk2zK71; Mon, 18 Apr 2011 06:29:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfc.amsl.com (Postfix) with ESMTP id 940A1E07D7; Mon, 18 Apr 2011 06:29:46 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3ICoJRt012243; Mon, 18 Apr 2011 14:50:19 +0200 (CEST) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p3ICoFTT000780; Mon, 18 Apr 2011 14:50:15 +0200 (CEST) Message-ID: <4DAC3387.8030306@cisco.com> Date: Mon, 18 Apr 2011 14:50:15 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Benoit Claise References: <4D7F1516.6080401@gmail.com> <4D7F20B2.3070102@cisco.com> In-Reply-To: <4D7F20B2.3070102@cisco.com> Content-Type: multipart/alternative; boundary="------------070003010409060808000907" X-Mailman-Approved-At: Tue, 19 Apr 2011 10:19:34 -0700 Cc: draft-ietf-ipfix-structured-data.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-structured-data-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:29:52 -0000 This is a multi-part message in MIME format. --------------070003010409060808000907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Yaron, Discussing with the other authors, we propose: OLD: 12. Security Considerations The same security considerations as for the IPFIX Protocol [RFC5101 ] and the IPFIX information model [RFC5102 ] apply. NEW: 12. Security Considerations The addition of complex data types necessarily complicates the implementation of the Collector. This could easily result in new security vulnerabilities (e.g., buffer overflows); this creates additional risk in cases where either DTLS is not used, or if the Observation Point and Collector belong to different trust domains. Otherwise, the same security considerations as for the IPFIX Protocol [RFC5101 ] and the IPFIX information model [RFC5102 ] apply. Regards, Benoit. > Hi Yaron, > > Thanks for your feedback. > Sure we should add your proposed sentence. > > Regards, Benoit. >> 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. >> >> IPFIX is a structured information model and protocol for transmitting >> information about data flows. This document extends the model with >> structured data, basically several types of lists. >> >> I have not reviewed the document in full, rather I have looked at the >> security aspects only. The Security Considerations refer the reader >> to the IPFIX protocol and data model RFCs, and I mostly agree, with >> one exception. I suggest to add text similar to the next paragraph: >> >> The addition of complex data types necessarily complicates the >> implementation of the Collector. This could easily result in new >> security vulnerabilities (e.g., buffer overflows); this creates >> additional risk in cases where either DTLS is not used, or if the >> Observation Point and Collector belong to different trust domains. >> >> Thanks, >> Yaron --------------070003010409060808000907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Yaron,

Discussing with the other authors, we propose:

OLD:
12. Security Considerations

The same security considerations as for the IPFIX Protocol
[RFC5101] and the IPFIX information model [RFC5102] apply.

NEW:
12. Security Considerations

The addition of complex data types necessarily complicates the implementation of the Collector. This could easily result in new security vulnerabilities (e.g., buffer overflows); this creates additional risk in cases where either DTLS is not used, or if the Observation Point and Collector belong to different trust domains. Otherwise, the same security considerations as for the IPFIX Protocol
[RFC5101] and the IPFIX information model [RFC5102] apply.
Regards, Benoit.
Hi Yaron,

Thanks for your feedback.
Sure we should add your proposed sentence.

Regards, Benoit.
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.

IPFIX is a structured information model and protocol for transmitting information about data flows. This document extends the model with structured data, basically several types of lists.

I have not reviewed the document in full, rather I have looked at the security aspects only. The Security Considerations refer the reader to the IPFIX protocol and data model RFCs, and I mostly agree, with one exception. I suggest to add text similar to the next paragraph:

The addition of complex data types necessarily complicates the implementation of the Collector. This could easily result in new security vulnerabilities (e.g., buffer overflows); this creates additional risk in cases where either DTLS is not used, or if the Observation Point and Collector belong to different trust domains.

Thanks,
    Yaron

--------------070003010409060808000907-- From new-work-bounces@ietf.org Tue Apr 19 09:37:53 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfc.amsl.com Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 11AD5E07E5; Tue, 19 Apr 2011 09:37:53 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 6D592E07DE; Tue, 19 Apr 2011 09:37:52 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110419163752.6D592E07DE@ietfc.amsl.com> Date: Tue, 19 Apr 2011 09:37:52 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 10:19:34 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Softwires (softwire) 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, 19 Apr 2011 16:37:53 -0000 A modified charter has been submitted for the Softwires (softwire) 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, April 26, 2011. Softwires (softwire) **DRAFT 2011-04-14** (v03) -------------------- Current Status: Active Chairs: Alain Durand Yong Cui Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: softwires@ietf.org To Subscribe: softwires-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/softwires/current/maillist.html Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for: "Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base Softwires encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this working group will be reviewed jointly with the DHC WG. RADIUS attributes developed in this working group will be reviewed jointly with the RADEXT WG. The MIB Doctors directorate will be asked to review any MIB modules developed in the SOFTWIRE working group. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). The specific work areas for this working group are: 1. Developments for Mesh softwires topology; the Mesh topology work will be reviewed in the l3vpn and idr WGs - multicast - MIB module 2. Developments for 6rd: - multicast - operational specification - RADIUS option for 6rd server - MIB module 3. Developments for Dual-Stack Lite (DS-Lite): - multicast - operational specification - RADIUS option for AFTR - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the B4 element - MIB module 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through WG last call until the solution motivation document has been published 5. Finalize discovery and configuration mechanisms for a gateway to use DS-Lite or 6rd; these discovery and configuration mechanisms must take into a account other operating environments such as dual-stack and tunneling mechanisms not defined by the softwire WG. Development of new mechanisms will involve the dhc and/or v6ops WGs as appropriate Other work items would require WG approval and rechartering. Goals and Milestones: Apr 2011 Submit DS-lite RADIUS option for Proposed Standard Apr 2011 Adopt DS-lite operational document as WG document Jul 2011 Submit 6rd RADIUS option for Proposed Standard Jul 2011 Submit GI DS-lite for Proposed Standard Jul 2011 Adopt B4NAT as WG document Aug 2011 Adopt 6rd operational document as WG document Aug 2011 Adopt Multicast extensions document as WG document Aug 2011 Submit DS-lite operational document for Informational Sep 2011 Submit B4NAT for Informational Nov 2011 Submit Multicast extensions document for Informational Nov 2011 Submit 6rd operational document for Informational Nov 2011 Adopt 6rd MIB module as WG document Nov 2011 Adopt DS-lite MIB module as WG document Nov 2011 Adopt Mesh topology MIB module as WG document Nov 2012 Submit 6rd MIB module for Proposed Standard Nov 2012 Submit DS-lite MIB module for Proposed Standard Nov 2012 Submit Mesh topology MIB module for Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Apr 19 09:48:59 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfc.amsl.com Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7A93EE0802; Tue, 19 Apr 2011 09:48:59 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id AD333E07B2; Tue, 19 Apr 2011 09:48:57 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110419164857.AD333E07B2@ietfc.amsl.com> Date: Tue, 19 Apr 2011 09:48:57 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 10:19:34 -0700 Subject: [secdir] [new-work] WG Review: Real-Time Communication in WEB-browsers (rtcweb) 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, 19 Apr 2011 16:48:59 -0000 A new IETF working group has been proposed in the Real-Time Applications and Infrastructure 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, April 26, 2011. Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ Current Status: Proposed Working Group Last Updated: 2011-04-14 Chairs: TBD RAI Area Directors: Gonzalo Camarillo Robert Sparks RAI Area Advisor: Gonzalo Camarillo Mailing Lists: Address: rtcweb@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtcweb Archive: http://www.ietf.org/mail-archive/web/rtcweb/ Description of Working Group: There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients. This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identify state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components. We will reach out to the developer community for consultation and early feedback on implementation. The security and privacy goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly need extensions, additions or replacement, and thus some support for negotiation between clients is required. The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security and privacy goals and specifies the security protocol mechanisms necessary to achieve those goals. 3. Define the solution - protocols and API requirements - for firewall and NAT traversal. 4. Define which media functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non media data is transported between clients in a secure and congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution. 9. The group will consider options for interworking with legacy VoIP equipment. This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG: RTSP, RSVP, NSIS, Location services, Resource Priority, and IM & Presence specific features. The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. Milestones: Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to W3C Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) to IESG as Informational Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document sent to IESG as Informational Dec 2011 RTCWeb protocol profiles and Media format specification(s) to IESG as PS Dec 2011 Information elements and events APIs Input to W3C Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Apr 19 09:57:36 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfc.amsl.com Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8BCC8E07FF; Tue, 19 Apr 2011 09:57:36 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfc.amsl.com Received: by ietfc.amsl.com (Postfix, from userid 30) id 2E31AE080B; Tue, 19 Apr 2011 09:57:35 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110419165735.2E31AE080B@ietfc.amsl.com> Date: Tue, 19 Apr 2011 09:57:35 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 10:19:34 -0700 Subject: [secdir] [new-work] WG Review: Protocol to Access White Space database (paws) 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, 19 Apr 2011 16:57:36 -0000 A new IETF working group has been proposed. 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, April 26, 2011. Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-04-14 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing lists: Address: paws@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Governments around the world continue to search for new pieces of radio spectrum which can be used by the expanding wireless communications industry to provide more services in the usable spectrum. The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by users. In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to determine its location in latitude and longitude. At power-on, before the device can transmit or use any of the spectrum set aside for secondary use, the device must identify the relevant database to query, contact the database, provide its geolocation and receive in return a list of unoccupied or "white space" spectrum (for example, in a TV White space implementation, the list of available channels at that location). The device can then select one of the channels from the list and begin to transmit and receive on the selected channel. The device must query the database subsequently on a periodic basis for a list of unoccupied channels based on certain conditions, e.g. a fixed amount of time has passed or the device has changed location beyond a specified threshold. The databases are expected to be reachable via the Internet and the devices querying these databases are expected to have some form of Internet connectivity, directly or indirectly. The databases may be country specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be country independent, thus extensibility of data structures will be required. The solution will not be tied to any specific spectrum, country, or phy/mac/air interface but may incorporate relevant aspects of these as needed for proper operation. The proposed working group will : - standardize a protocol for querying the database, which includes a location sensitive database discovery mechanism and security for the protocol, and application services. - Standardize the data structure to be carried by the query protocol. The protocol must protect both the channel enablement process and the privacy of users. Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services and unauthorized disclosure of a users location. Existing IETF location data structures and privacy mechanisms may be considered for use. The WG will also investigate the need for other mechanisms and related protocols to the White Space DB. The Working Group will set up and maintain appropriate contact and liaison with other relevant standards bodies and groups, including IEEE 802.11af and IEEE 802.22 to begin with. The working group may also consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific bands. Goals and Milestones Sep 2011 Submit 'Requirements and Framework' to the IESG for publication as Informational Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to the IESG for publication as Proposed Standard Apr 2012 Submit 'Data Model for Whitespace query protocol' to the IESG for publication as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From rbarnes@bbn.com Wed Apr 20 11:55:36 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08494E067D; Wed, 20 Apr 2011 11:55: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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66GpC2A1z9jz; Wed, 20 Apr 2011 11:55:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 80206E066B; Wed, 20 Apr 2011 11:55:35 -0700 (PDT) Received: from [192.1.255.191] (port=55636 helo=col-dhcp-192-1-255-191.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QCcYp-000Phk-8j; Wed, 20 Apr 2011 14:55:35 -0400 From: Richard L. Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 14:55:33 -0400 Message-Id: <1E5F005F-8CC3-41B9-B860-A36ABA95E708@bbn.com> To: secdir@ietf.org, The IESG , draft-harkins-ipsecme-spsk-auth@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [secdir] secdir review of draft-harkins-ipsecme-spsk-auth-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:55: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 defines a new mechanism for using pre-shared keys for = IPsec authentication in IKE, in a way that addresses some = vulnerabilities of the current mechanism. I am not a cryptographer, but the cryptographic protocol described in = this document seems basically sound, and its security properties are = explained well in the Security Considerations. A question and couple of minor comments follow. --Richard Question: I haven't thought deeply about it, but it's not clear to me = what the advantage is over this cryptographic protocol vs. the SRP = protocol that has been used for TLS [RFC5054], besides the fact that SRP = requires a user "identity" in addition to a password. Minor: There appears to be a typo at the top of Page 7. It seems that = the equation should be as follows: scalar-op(x,Y) =3D element-op(Y, scalar-op(x-1), Y)), for x > 1 Also, for completeness, you might note that scalar-op(0,Y) is the = identity element of the group. Minor: It might be helpful to mention somewhere that scalars are always = non-negative integers. From clonvick@cisco.com Wed Apr 20 16:29:51 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4624DE06F9; Wed, 20 Apr 2011 16:29:51 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJCLT7J1vpQN; Wed, 20 Apr 2011 16:29:50 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 56B0AE0673; Wed, 20 Apr 2011 16:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=912; q=dns/txt; s=iport; t=1303342190; x=1304551790; h=date:from:to:subject:message-id:mime-version; bh=KDnPPGenuXuTpbx4eDzY2ytzNJE+C0TXBXUzVxFs9zA=; b=e0IbiGzcpELUjQIlVja/GtmGEww/lRD3rOGJZR2sQtE70b5QSBjjxEJ/ SEAWgR+wr9HJD9mfPv240y4rmzOqLr3eMnBXunVgc8phMDUj7lFtG1htK YPxWWVUcZ2QiduRGDUqdjHQs0sK754omxhqlM0Wj/aomgPOwFRMgWPj1o U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FACprr02rRDoH/2dsb2JhbACXegGNS3eqZZxihXEEhXQ X-IronPort-AV: E=Sophos;i="4.64,248,1301875200"; d="scan'208";a="341669571" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 20 Apr 2011 23:29:49 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3KNTnhw009451; Wed, 20 Apr 2011 23:29:49 GMT Date: Wed, 20 Apr 2011 16:29:49 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-josefsson-gss-capsulate.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-josefsson-gss-capsulate-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:29:51 -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 ready to progress. One editorial suggestion I'd make would be to either include or directly reference the security section of RFC 2743 in your own security considerations section. Also, I'm just not partial towards the use of "otherwise" to describe a return code from gss_oid_equal. Personally, I think it should be directly specified. Finally, I think you have a formatting inconsistency in Section 4.1; the "otherwise" should be tabbed out to line up in the other column. Regards, Chris From weiler+secdir@watson.org Thu Apr 21 15:16:48 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3A6CE066E for ; Thu, 21 Apr 2011 15:16: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-++-i2LDSpI for ; Thu, 21 Apr 2011 15:16:48 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfc.amsl.com (Postfix) with ESMTP id 0AA07E065C for ; Thu, 21 Apr 2011 15:16:47 -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 p3LMGlgR021259 for ; Thu, 21 Apr 2011 18:16:47 -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 p3LMGkEp021256 for ; Thu, 21 Apr 2011 18:16:47 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 21 Apr 2011 18:16:46 -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]); Thu, 21 Apr 2011 18:16:47 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 22:16:48 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2011-04-28 Reviewer LC end Draft Dave Cridland T 2011-04-13 draft-ietf-ipsecme-ipsecha-protocol-05 Alan DeKok T 2011-04-15 draft-ietf-kitten-digest-to-historic-03 Donald Eastlake T 2011-04-11 draft-ietf-mif-current-practices-09 Shawn Emery T 2011-02-21 draft-ietf-ecrit-phonebcp-17 Shawn Emery T 2011-04-18 draft-ietf-sidr-roa-validation-10 Phillip Hallam-Baker T 2011-04-12 draft-ietf-softwire-dual-stack-lite-07 Scott Kelly T 2011-04-25 draft-ietf-dnsop-as112-ops-06 Tero Kivinen T 2011-04-25 draft-ietf-dnsop-as112-under-attack-help-help-05 Julien Laganier T 2011-04-25 draft-ietf-dnsop-default-local-zones-15 David McGrew T - draft-ietf-ecrit-framework-12 Catherine Meadows T 2011-04-20 draft-paxson-tcpm-rfc2988bis-02 Alexey Melnikov T 2011-04-29 draft-ietf-grow-unique-origin-as-00 Kathleen Moriarty T 2011-04-28 draft-ietf-trill-adj-06 Russ Mundy T 2011-04-29 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Juergen Schoenwaelder TR2011-01-10 draft-ietf-sipping-sip-offeranswer-14 Nico Williams T 2011-03-24 draft-ietf-sidr-rpki-manifests-10 Glen Zorn T 2011-04-10 draft-ietf-netext-redirect-07 For telechat 2011-05-12 Reviewer LC end Draft Rob Austein T 2011-05-03 draft-haleplidis-forces-implementation-experience-02 Stephen Kent T 2011-04-20 draft-ietf-ippm-tcp-throughput-tm-12 David McGrew T 2011-05-09 draft-lear-iana-timezone-database-03 For telechat 2011-05-26 Reviewer LC end Draft Love Hornquist-Astrand T 2011-05-12 draft-daboo-et-al-icalendar-in-xml-08 Matt Lepinski T 2011-04-20 draft-ietf-vcarddav-vcardxml-09 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2011-04-27 draft-arkko-mikey-iana-00 Uri Blumenthal 2011-04-18 draft-ietf-idr-bgp-identifier-13 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Dan Harkins 2011-05-03 draft-mavrogiannopoulos-ssl-version3-03 Sam Hartman 2011-04-23 draft-shin-augmented-pake-05 Jeffrey Hutzelman 2011-04-26 draft-ietf-avtext-multicast-acq-rtcp-xr-04 Charlie Kaufman 2011-04-20 draft-ietf-dime-extended-naptr-06 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Sandy Murphy 2011-04-29 draft-ietf-grow-geomrt-01 Magnus Nystrom 2011-05-02 draft-ietf-genarea-datatracker-iana-rfced-extns-01 Vincent Roca 2011-02-07 draft-reed-urn-dgiwg-02 Sam Weiler 2011-03-24 draft-ietf-sidr-roa-format-10 From catherine.meadows@nrl.navy.mil Thu Apr 21 15:32:45 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C42BE0695; Thu, 21 Apr 2011 15:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXVyxYCEkauo; Thu, 21 Apr 2011 15:32:44 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfc.amsl.com (Postfix) with ESMTP id 18665E067F; Thu, 21 Apr 2011 15:32:44 -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 p3LMWhDU028628; Thu, 21 Apr 2011 18:32:43 -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 p3LMWhos021078; Thu, 21 Apr 2011 18:32:43 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011042118324228880 ; Thu, 21 Apr 2011 18:32:42 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-11-848347838 Date: Thu, 21 Apr 2011 18:39:38 -0400 Message-Id: <0741F726-D534-4C5E-B83C-0701D42B7183@nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org, draft-paxson-tcpm-rfc2988bis.all@ltools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-paxson-tcpm-rfc2988bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 22:32:45 -0000 --Apple-Mail-11-848347838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes the algorithm that a TCP sender uses to manage its = retransmission timer. The sender uses the algorithm to keep track of round-trip times of sent packets and acknowledgements, so it can = determine when a packet is likely to have been lost and needs to be = resent. As the draft points out, the retransmission timing algorithm is very = important to the efficient operation of the Internet, since it is = necessary for the avoidance of congestion arising from too many re-sent messages. = Thus, it is a natural target for exploitation for a denial of service = attack, in which an attacker convinces a sender to lower its RTO to an unsafe value, = causing it to retransmit its packets that are not really lost, and thus = lead to congestion. The Security Considerations section is devoted to discussing these and = their potential impact, which is not considered to be great. The main = crux of the argument is that an attacker would need to be able to spoof acknowledgements from the receiver, and if it could do this there = are much more devastating attacks it could implement. Moreover, congestion would lead to genuinely lost packets, which means = that the RTO would increase. I had some trouble with this argument, since it is rather high-level and = depends on assertions that I can't verify. On the other hand, I don't think you should have to have a whole essay on this topic in this ID. = But I kept on asking questions as I read: how hard is it to spoof an = acknowledgement? What information would the attacker need to know about = the packets in the connection? If the sender backed off once a packet was genuinely lost, how hard = would it be for the attacker could bring the RTO down again? What if = the attacker were applying this attack to multiple senders. Are there = cases in which an attacker could spoof an acknowledgement without having actually have seen a packet? These questions may have obvious answers to people who are more expert = in TCP than I. But I think it might be helpful to provide guidance on how = implementations of TCP or possible changes to TCP could affect the = vulnerability of RTO to DOS attacks. In particular, anything that would = make it easier for a receiver to acknowledge a packet without having = seen it would be undesirable. 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-11-848347838 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have reviewed this document as part of the security = directorate's
ongoing effort to review all IETF documents being = processed by the
IESG.  These comments were written primarily = for the benefit of the
security area directors.  Document = editors and WG chairs should treat
these comments just like any other = last call comments.


This draft describes the = algorithm that a TCP sender uses to manage its retransmission timer. =  The sender uses the algorithm to keep track of
round-trip = times of sent packets and acknowledgements, so it can determine when a = packet is likely to have been lost and needs to be = resent.

As the draft points out, the = retransmission timing algorithm is very important to the efficient = operation of the Internet, since it is necessary for
the = avoidance of congestion arising from too many re-sent messages. =  Thus, it is a natural target for exploitation for a denial of = service attack, in which
an attacker convinces a sender to = lower its RTO to an unsafe value, causing it to retransmit its packets = that are not really lost, and thus lead to congestion.
The = Security Considerations section is devoted to discussing these and their = potential impact, which is not considered to be great.  The main = crux of the argument is that an attacker would need to be able = to
spoof acknowledgements from the receiver, and if it could = do this there are much more devastating attacks it could = implement.
Moreover, congestion would lead to genuinely lost = packets, which means that the RTO would = increase.

I had some trouble with this = argument, since it is rather high-level and depends on assertions that I = can't verify.  On the other hand, I don't
think you = should have to have a whole essay on this topic in this ID.  But I = kept on asking questions as I read: how hard is it to spoof an = acknowledgement?  What information would the attacker need to know = about the packets in the connection?
If the sender backed off = once a packet was genuinely lost, how hard would it be for the attacker = could bring the RTO down again?  What if the attacker were applying = this attack to multiple senders.  Are there cases in which an = attacker could spoof an acknowledgement without
having = actually have seen a packet?

These questions = may have obvious answers to people who are more expert in TCP than = I.
But I think it might be helpful to provide guidance on how = implementations of TCP or possible changes to TCP could affect the = vulnerability of RTO to DOS attacks.  In particular, anything that = would make it easier for a receiver to acknowledge a packet without = having seen it would be = undesirable.


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-11-848347838-- From weiler@watson.org Thu Apr 21 15:55:38 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C038DE06E0 for ; Thu, 21 Apr 2011 15:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8K8nTkvKvEQ3 for ; Thu, 21 Apr 2011 15:55:38 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfc.amsl.com (Postfix) with ESMTP id 3F15FE06CE for ; Thu, 21 Apr 2011 15:55:38 -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 p3LMtbSJ025800 for ; Thu, 21 Apr 2011 18:55:37 -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 p3LMtb5M025797 for ; Thu, 21 Apr 2011 18:55:37 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 21 Apr 2011 18:55:37 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 21 Apr 2011 18:55:38 -0400 (EDT) Subject: [secdir] secdir membership updates X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 22:55:38 -0000 It's been some time since I've sent the "X & Y are joining the secdir" notes. Time to make make up for my lapses. Ondrej Sury and Warren Kumari, the DANE chairs, are joining us now. Matt Lepinski joined in January and Kathleen Moriarty in August. Alexey Melnikov is back from his extended secdir holiday, as is Tim Polk. -- Sam From catherine.meadows@nrl.navy.mil Thu Apr 21 15:55:54 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE629E06E0; Thu, 21 Apr 2011 15:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOupHrM0kg9b; Thu, 21 Apr 2011 15:55:53 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfc.amsl.com (Postfix) with ESMTP id AED58E06CE; Thu, 21 Apr 2011 15:55:53 -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 p3LMtqkp001260; Thu, 21 Apr 2011 18:55:52 -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 p3LMtjed021831; Thu, 21 Apr 2011 18:55:52 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011042118555028906 ; Thu, 21 Apr 2011 18:55:50 -0400 From: Catherine Meadows Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-849735944 Date: Thu, 21 Apr 2011 19:02:46 -0400 References: <0741F726-D534-4C5E-B83C-0701D42B7183@nrl.navy.mil> To: draft-paxson-tcpm-rfc2988bis.all@tools.ietf.org Message-Id: <2A6D3E9C-75A6-42D7-B122-AF9AC035B2E8@nrl.navy.mil> X-Mailer: Apple Mail (2.1084) Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] Fwd: Secdir review of draft-paxson-tcpm-rfc2988bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 22:55:55 -0000 --Apple-Mail-12-849735944 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: I messed up the tools email address on this My apologies for the = resend. Cathy > From: Catherine Meadows > Date: April 21, 2011 6:39:38 PM EDT > To: iesg@ietf.org, secdir@ietf.org, = draft-paxson-tcpm-rfc2988bis.all@ltools.ietf.org > Subject: Secdir review of draft-paxson-tcpm-rfc2988bis-02 >=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 >=20 > This draft describes the algorithm that a TCP sender uses to manage = its retransmission timer. The sender uses the algorithm to keep track = of > round-trip times of sent packets and acknowledgements, so it can = determine when a packet is likely to have been lost and needs to be = resent. >=20 > As the draft points out, the retransmission timing algorithm is very = important to the efficient operation of the Internet, since it is = necessary for > the avoidance of congestion arising from too many re-sent messages. = Thus, it is a natural target for exploitation for a denial of service = attack, in which > an attacker convinces a sender to lower its RTO to an unsafe value, = causing it to retransmit its packets that are not really lost, and thus = lead to congestion. > The Security Considerations section is devoted to discussing these and = their potential impact, which is not considered to be great. The main = crux of the argument is that an attacker would need to be able to > spoof acknowledgements from the receiver, and if it could do this = there are much more devastating attacks it could implement. > Moreover, congestion would lead to genuinely lost packets, which means = that the RTO would increase. >=20 > I had some trouble with this argument, since it is rather high-level = and depends on assertions that I can't verify. On the other hand, I = don't > think you should have to have a whole essay on this topic in this ID. = But I kept on asking questions as I read: how hard is it to spoof an = acknowledgement? What information would the attacker need to know about = the packets in the connection? > If the sender backed off once a packet was genuinely lost, how hard = would it be for the attacker could bring the RTO down again? What if = the attacker were applying this attack to multiple senders. Are there = cases in which an attacker could spoof an acknowledgement without > having actually have seen a packet? >=20 > These questions may have obvious answers to people who are more expert = in TCP than I. > But I think it might be helpful to provide guidance on how = implementations of TCP or possible changes to TCP could affect the = vulnerability of RTO to DOS attacks. In particular, anything that would = make it easier for a receiver to acknowledge a packet without having = seen it would be undesirable. >=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 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-12-849735944 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Catherine Meadows = <catherine.meadows@nrl.navy.= mil>
Date: April 21, 2011 6:39:38 PM EDT
Subject: Secdir review of = draft-paxson-tcpm-rfc2988bis-02

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


This draft = describes the algorithm that a TCP sender uses to manage its = retransmission timer.  The sender uses the algorithm to keep track = of
round-trip times of sent packets and acknowledgements, so it can = determine when a packet is likely to have been lost and needs to be = resent.

As the draft points out, the = retransmission timing algorithm is very important to the efficient = operation of the Internet, since it is necessary for
the = avoidance of congestion arising from too many re-sent messages. =  Thus, it is a natural target for exploitation for a denial of = service attack, in which
an attacker convinces a sender to = lower its RTO to an unsafe value, causing it to retransmit its packets = that are not really lost, and thus lead to congestion.
The = Security Considerations section is devoted to discussing these and their = potential impact, which is not considered to be great.  The main = crux of the argument is that an attacker would need to be able = to
spoof acknowledgements from the receiver, and if it could = do this there are much more devastating attacks it could = implement.
Moreover, congestion would lead to genuinely lost = packets, which means that the RTO would = increase.

I had some trouble with this = argument, since it is rather high-level and depends on assertions that I = can't verify.  On the other hand, I don't
think you = should have to have a whole essay on this topic in this ID.  But I = kept on asking questions as I read: how hard is it to spoof an = acknowledgement?  What information would the attacker need to know = about the packets in the connection?
If the sender backed off = once a packet was genuinely lost, how hard would it be for the attacker = could bring the RTO down again?  What if the attacker were applying = this attack to multiple senders.  Are there cases in which an = attacker could spoof an acknowledgement without
having = actually have seen a packet?

These questions = may have obvious answers to people who are more expert in TCP than = I.
But I think it might be helpful to provide guidance on how = implementations of TCP or possible changes to TCP could affect the = vulnerability of RTO to DOS attacks.  In particular, anything that = would make it easier for a receiver to acknowledge a packet without = having seen it would be = undesirable.


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


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-12-849735944-- From dharkins@lounge.org Thu Apr 21 17:12:03 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36EB7E074C; Thu, 21 Apr 2011 17:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbHNN35sGQH8; Thu, 21 Apr 2011 17:12:02 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfc.amsl.com (Postfix) with ESMTP id 05044E06DD; Thu, 21 Apr 2011 17:12:01 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 006DC1022404E; Thu, 21 Apr 2011 17:12:00 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 21 Apr 2011 17:12:01 -0700 (PDT) Message-ID: <0090e9b435a992eaf44a521642c5f513.squirrel@www.trepanning.net> In-Reply-To: <1E5F005F-8CC3-41B9-B860-A36ABA95E708@bbn.com> References: <1E5F005F-8CC3-41B9-B860-A36ABA95E708@bbn.com> Date: Thu, 21 Apr 2011 17:12:01 -0700 (PDT) From: "Dan Harkins" To: "Richard L. Barnes" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: draft-harkins-ipsecme-spsk-auth@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-harkins-ipsecme-spsk-auth-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 00:12:03 -0000 Hi Richard, Thank you for reviewing my draft. Responses inline.... On Wed, April 20, 2011 11:55 am, 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. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. > > This document defines a new mechanism for using pre-shared keys for IPsec > authentication in IKE, in a way that addresses some vulnerabilities of the > current mechanism. > > I am not a cryptographer, but the cryptographic protocol described in this > document seems basically sound, and its security properties are explained > well in the Security Considerations. > > A question and couple of minor comments follow. > --Richard > > > Question: I haven't thought deeply about it, but it's not clear to me what > the advantage is over this cryptographic protocol vs. the SRP protocol > that has been used for TLS [RFC5054], besides the fact that SRP requires a > user "identity" in addition to a password. SRP is a client-server protocol in which one side has salt and a verifier and the other has a password. Since IKE is not a client-server protocol, and either side can initiate to the other, each side needs access to the password. To implement SRP though, they would have to agree on some salt and produce a verifier to store along with the password. That sort of defeats the whole point of using a verifier protocol like SRP. And it seems like we'd be shoehorning in a protocol that isn't really a good fit. > Minor: There appears to be a typo at the top of Page 7. It seems that the > equation should be as follows: > scalar-op(x,Y) = element-op(Y, scalar-op(x-1), Y)), for x > 1 > Also, for completeness, you might note that scalar-op(0,Y) is the identity > element of the group. Yes, thanks for catching that. > Minor: It might be helpful to mention somewhere that scalars are always > non-negative integers. You're right; that would be helpful. I'll do that. Thanks again for the review, Dan. From d3e3e3@gmail.com Thu Apr 21 20:43:25 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 565F2E07B7; Thu, 21 Apr 2011 20:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.022 X-Spam-Level: X-Spam-Status: No, score=-103.022 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thc5WjFdvVYR; Thu, 21 Apr 2011 20:43:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id CDB8BE07AE; Thu, 21 Apr 2011 20:43:24 -0700 (PDT) Received: by vxg33 with SMTP id 33so302433vxg.31 for ; Thu, 21 Apr 2011 20:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=C+vybb5OJLUSlBJYB862e3bZsp8SUHroQ+GX24DE1uI=; b=BGWoh3miegfGm8FLSxDmOejXlBf/4ohAleQLvtRN34KOP5vjseAo3N/LiypzvAIDoQ OFWejI55UKu5tTjv4DHCUwPxHLozSH9zHUsdNSi+2wknXkhurou8ZHLdOtBPjU5t2Gpm oAhlBERw/Sn7OoiyzIh/6rHW+u+NyZDoJh7Vc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=TbPyN0EY0xYPnycVeAgBcRC2AOO911XjVSP9ZEyYxB4dFJwvdXzmK/msz/RlPnEuql NSV5sepwxOT4TaK8BcX4vQ84XO/EFPwb12mCnrC7cGVI6rv4BfbURUkcN99Kl8AV9/hf cwEhSpxNJWlwSfvD5B2rSKyGb9vQcyUlvJHOs= Received: by 10.52.18.47 with SMTP id t15mr1054545vdd.48.1303443804196; Thu, 21 Apr 2011 20:43:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.167.193 with HTTP; Thu, 21 Apr 2011 20:43:03 -0700 (PDT) From: Donald Eastlake Date: Thu, 21 Apr 2011 20:43:03 -0700 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mif-current-practice.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] draft-ietf-mif-current-practices-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 03:43:25 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. draft-ietf-mif-current-practices-09.txt describes a number of current operating system implementations from the point of view of how they handle the issues raised in the multiple interfaces (MIF) working group problem statement. It concentrates on operational issues and does not include much, if any, consideration of security issues. As such, I find the Security Considerations section to be accurate and complete. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From d3e3e3@gmail.com Thu Apr 21 20:46:21 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 249FEE07BA; Thu, 21 Apr 2011 20:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bShKN0KaBa1U; Thu, 21 Apr 2011 20:46:20 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9439CE0770; Thu, 21 Apr 2011 20:46:20 -0700 (PDT) Received: by vws12 with SMTP id 12so295073vws.31 for ; Thu, 21 Apr 2011 20:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=Pra6J5bVWWYT12M8DaJtqtVYUr4uZkTeG9cHzRna9to=; b=ZahXebrVJVusmL1tnFbPpO2ThvnvvQZ/SMInNVyS0zA9R+E+2b8HLBBD9kUPXkyeB6 ZHwnOE+Xi0WbSf/BR0PBO9xnArLm6fko0ciZRbUnN0JB7m4BacfnUPYDpCAAzB5HMjsW a0ivLcWbwCjt93fLDXQxLg3uDGmVdlfhd5rLQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=wFbClH4IR/VBnIwGXYyChz9nzzbMfiFVMy7hpnO9eeqP1lLunGNpbY+4py9ej08211 WpUYYoxPDIfLhKXXpHLND6vyYF9aSzn+168LjakTBOStadKgSNnJoUbtBwIJ50aSDQRC /DVLyEDRIz0JEVtPlLmfMA5nIoK4+NFvBOkhk= Received: by 10.52.91.71 with SMTP id cc7mr982234vdb.288.1303443980220; Thu, 21 Apr 2011 20:46:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.167.193 with HTTP; Thu, 21 Apr 2011 20:46:00 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 21 Apr 2011 20:46:00 -0700 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mif-current-practices.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [secdir] draft-ietf-mif-current-practices-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 03:46:21 -0000 Correcting draft-ietf-mif-current-practices.all@tools.ietf.org email addres= s. Donald On Thu, Apr 21, 2011 at 8:43 PM, Donald Eastlake wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. =A0Document editors and WG chairs should treat these comments just > like any other last call comments. > > draft-ietf-mif-current-practices-09.txt describes a number of current > operating system implementations from the point of view of how they > handle the issues raised in the multiple interfaces (MIF) working > group problem statement. It concentrates on operational issues and > does not include much, if any, consideration of security issues. As > such, I find the Security Considerations section to be accurate and > complete. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street > =A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > From rbarnes@bbn.com Fri Apr 22 01:58:17 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EE233E0796; Fri, 22 Apr 2011 01:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymm2yuVKMEpd; Fri, 22 Apr 2011 01:58:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 1F667E078E; Fri, 22 Apr 2011 01:58:17 -0700 (PDT) Received: from [128.89.253.73] (port=49483 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QDCBs-000Olt-HH; Fri, 22 Apr 2011 04:58:16 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" X-Priority: 3 (Normal) In-Reply-To: <0090e9b435a992eaf44a521642c5f513.squirrel@www.trepanning.net> Date: Fri, 22 Apr 2011 04:58:12 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <1E5F005F-8CC3-41B9-B860-A36ABA95E708@bbn.com> <0090e9b435a992eaf44a521642c5f513.squirrel@www.trepanning.net> To: "Dan Harkins" X-Mailer: Apple Mail (2.1082) Cc: draft-harkins-ipsecme-spsk-auth@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-harkins-ipsecme-spsk-auth-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 08:58:18 -0000 Hi Dan, >> Question: I haven't thought deeply about it, but it's not clear to me what >> the advantage is over this cryptographic protocol vs. the SRP protocol >> that has been used for TLS [RFC5054], besides the fact that SRP requires a >> user "identity" in addition to a password. > > SRP is a client-server protocol in which one side has salt and a > verifier and the other has a password. Since IKE is not a client-server > protocol, and either side can initiate to the other, each side needs > access to the password. To implement SRP though, they would have to agree > on some salt and produce a verifier to store along with the password. > That sort of defeats the whole point of using a verifier protocol like > SRP. And it seems like we'd be shoehorning in a protocol that isn't really > a good fit. Thanks, that answer makes sense. Consider my comments resolved! --Richard From alexey.melnikov@isode.com Fri Apr 22 03:51:39 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B43F3E06B6; Fri, 22 Apr 2011 03:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3yJ4q3tRw2R; Fri, 22 Apr 2011 03:51:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfc.amsl.com (Postfix) with ESMTP id A4A6DE068B; Fri, 22 Apr 2011 03:51:38 -0700 (PDT) Received: from [188.29.6.68] (188.29.6.68.threembb.co.uk [188.29.6.68]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 22 Apr 2011 11:50:08 +0100 Message-ID: <4DB15D51.7070800@isode.com> Date: Fri, 22 Apr 2011 11:49:53 +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: iesg@ietf.org, secdir@ietf.org, draft-ietf-grow-unique-origin-as.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-grow-unique-origin-as-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 10:51:39 -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 makes recommendations regarding the use of per-node unique origin ASNs for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms can benefit from use of these new discriminators. Routing security is outside of my field of expertise, but I think the document made a compelling argument why use of per-node unique origin ASNs (as opposed to one ASN for all anycast nodes) improves the ability to detect rogue anycast nodes (assuming all nodes use unique ASNs). The proposed mechanism also better co-exists with SIDR, which is an extra plus. So overall I think the document is in a good shape and the Security Considerations section seems adequate. Best Regards, Alexey -- Internet Messaging Team Lead, JID: same as my email address twitter: aamelnikov From j.schoenwaelder@jacobs-university.de Fri Apr 22 04:45:20 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 27BB8E06B1; Fri, 22 Apr 2011 04:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URn0U6i03P6s; Fri, 22 Apr 2011 04:45:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfc.amsl.com (Postfix) with ESMTP id 6BE3EE06C1; Fri, 22 Apr 2011 04:45:19 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95DF820C2C; Fri, 22 Apr 2011 13:45:18 +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 nqdHgg93cinG; Fri, 22 Apr 2011 13:45:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C00CC20C19; Fri, 22 Apr 2011 13:45:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 890501778218; Fri, 22 Apr 2011 13:45:17 +0200 (CEST) Date: Fri, 22 Apr 2011 13:45:17 +0200 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org Message-ID: <20110422114517.GA2512@elstar.local> Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.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-sipping-sip-offeranswer-14.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 22 Apr 2011 11:45:20 -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 reviewed earlier versions of this I-D in Feburary 2009 and in December 2010. This revision has more explicit text in the security considerations, which essentially states that the clarifications on offer/answer exchanges do not add any new security issues. It took me some time to parse the sentences, perhaps a simpler wording could have been used (e.g. s/exclude from use/exclude). I appreciate the more explicit text and the concrete pointers to the relevant RFCs. However, these references raise a procedural question. It seems all these relevant specifications are on the standards track while this clarification, which tries to handle situations that can lead to "failed or degraded calls", is submitted as an Informational document. Should this not be standards track, formerly updating the relevant RFCs? I see in the IESG writeup that this has been discussed before, the proposed move to publish this as Informational still sounds surprising to me as an outsider. If there is consensus to resolve the ambiguities as described in the document, then why not via a standards-track action? Or is the idea that this resolution simply can be ignored or that something very different might be invented? That latter would more speak for Experimental then. Getting back to security considerations, if the intention is not to require implementations to follow the disambiguation described in the document (that is not moving to standards-track), can malware exploit the fact that the underlying RFCs allow for ambiguities to cause "failed or degraded calls"? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From scott@hyperthought.com Fri Apr 22 11:56:06 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 05C00E079F for ; Fri, 22 Apr 2011 11:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.83 X-Spam-Level: X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLLyDUXZpW95 for ; Fri, 22 Apr 2011 11:56:05 -0700 (PDT) Received: from smtp192.iad.emailsrvr.com (smtp192.iad.emailsrvr.com [207.97.245.192]) by ietfc.amsl.com (Postfix) with ESMTP id 84296E0757 for ; Fri, 22 Apr 2011 11:56:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp59.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id F40293F03F3; Fri, 22 Apr 2011 14:56:04 -0400 (EDT) X-Virus-Scanned: OK Received: from dynamic10.wm-web.iad.mlsrvr.com (dynamic10.wm-web.iad1a.rsapps.net [192.168.2.217]) by smtp59.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B61653F038C; Fri, 22 Apr 2011 14:56:04 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic10.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 9CE5847880A3; Fri, 22 Apr 2011 14:56:04 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 22 Apr 2011 11:56:04 -0700 (PDT) Date: Fri, 22 Apr 2011 11:56:04 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-dnsop-as112-ops.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1303498564.639322965@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-dnsop-as112-ops-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 18:56:06 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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.=0A=0AThis document is intended for Informationa= l status. It describes operational considerations for AS112 nameservers, wh= ose purpose in life is to provide a distributed sink for reverse DNS querie= s corresponding to private-use IP addresses (e.g. RFC 1918 addresses). =0A= =0AThe security considerations section seems well thought out, and I see no= security issues with this document. =0A=0A--Scott=0A From jari.arkko@piuha.net Fri Apr 22 12:21:14 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BA851E083C; Fri, 22 Apr 2011 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya8wgDdPeKS5; Fri, 22 Apr 2011 12:21:14 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfc.amsl.com (Postfix) with ESMTP id 23E49E0655; Fri, 22 Apr 2011 12:21:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0DA722CC38; Fri, 22 Apr 2011 22:21:13 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLh2Z5YrqpqX; Fri, 22 Apr 2011 22:21:12 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 592CB2CC2F; Fri, 22 Apr 2011 22:21:12 +0300 (EEST) Message-ID: <4DB1D528.5090106@piuha.net> Date: Fri, 22 Apr 2011 22:21:12 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Donald Eastlake References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mif-current-practices.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-mif-current-practices-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 19:21:14 -0000 Thanks for your review, Donald! Jari Donald Eastlake kirjoitti: > Correcting draft-ietf-mif-current-practices.all@tools.ietf.org email address. > > Donald > > On Thu, Apr 21, 2011 at 8:43 PM, Donald Eastlake wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. Document editors and WG chairs should treat these comments just >> like any other last call comments. >> >> draft-ietf-mif-current-practices-09.txt describes a number of current >> operating system implementations from the point of view of how they >> handle the issues raised in the multiple interfaces (MIF) working >> group problem statement. It concentrates on operational issues and >> does not include much, if any, consideration of security issues. As >> such, I find the Security Considerations section to be accurate and >> complete. >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> > > From shawn.emery@oracle.com Fri Apr 22 13:37:52 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A0200E080D; Fri, 22 Apr 2011 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flQQRicumMHR; Fri, 22 Apr 2011 13:37:50 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfc.amsl.com (Postfix) with ESMTP id DA9FFE07EF; Fri, 22 Apr 2011 13:37:49 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3MKblHk025475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Apr 2011 20:37:49 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p3MKbju0022863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2011 20:37:45 GMT Received: from abhmt018.oracle.com (abhmt018.oracle.com [141.146.116.27]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3MKbevg020383; Fri, 22 Apr 2011 15:37:40 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Apr 2011 13:37:39 -0700 Message-ID: <4DB1E712.9040005@oracle.com> Date: Fri, 22 Apr 2011 14:37:38 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110329 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4DB1E71D.002D:SCFMA922111,ss=1,fgs=0 Cc: iesg@ietf.org, draft-ietf-ecrit-phonebcp.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-ecrit-phonebcp-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 20:37:53 -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 outlines best current practices for devices, networks, and services to use standards on placing emergency calls over IP networks. The security considerations section does exist and defers to RFC 5069 and the geo-priv architecture draft for security considerations. After reading the RFC and the referenced draft, I don't believe that this BCP is adding any new security concerns. General comments: None. Editorial comments: s/[RFC5031]. MUST/[RFC5031] MUST/ Shawn. -- From catherine.meadows@nrl.navy.mil Fri Apr 22 13:55:57 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 70486E07C6; Fri, 22 Apr 2011 13:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p70ld8MU9Y+F; Fri, 22 Apr 2011 13:55:56 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfc.amsl.com (Postfix) with ESMTP id ADF3EE071B; Fri, 22 Apr 2011 13:55:56 -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 p3MKtsYk021604; Fri, 22 Apr 2011 16:55:55 -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 p3MKtrBS023605; Fri, 22 Apr 2011 16:55:53 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011042216555330062 ; Fri, 22 Apr 2011 16:55:53 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3-928933738 From: Catherine Meadows In-Reply-To: <20110422020921.97DF53A92334@lawyers.icir.org> Date: Fri, 22 Apr 2011 17:02:44 -0400 Message-Id: <2066F5DE-3200-46B6-8350-E72966821B85@nrl.navy.mil> References: <20110422020921.97DF53A92334@lawyers.icir.org> To: draft-paxson-tcpm-rfc2988bis.all@tools.ietf.org X-Mailer: Apple Mail (2.1084) Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-paxson-tcpm-rfc2988bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 20:55:57 -0000 --Apple-Mail-3-928933738 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I, on the other hand, would say that if the security considerations = section is 11 years old, it is in need of an update or at least another look. Judging from the = remarks that have been made so far, there is a lot of wisdom about the security impact of RTO = that is not captured in the current security considerations section. At the very least, I think a reference to the security considerations in = RFC5681 would be in order. Cathy On Apr 21, 2011, at 10:09 PM, Mark Allman wrote: >=20 > I agree with everything Vern said. But, two more points. >=20 >> Thus, it is a natural target for exploitation for a denial of service >> attack, in which an attacker convinces a sender to lower its RTO to = an >> unsafe value, causing it to retransmit its packets that are not = really >> lost, and thus lead to congestion. >=20 > First, I don't think this makes sense. Even if some attacker can > convince a sender to reduce its RTO and hence trip the RTO early this > will *reduce* the sender's rate (RFC5681). That is certainly an > impairment attack on the connection itself, but that does not "lead to > congestion". I.e., it is not somehow an attack on the broader = network. > In fact, the connection would "lead to congestion" with a higher > probability if it were to continue unimpaired at a higher sending = rate. >=20 > Second, I am loathe to change a security considerations section that = has > been good enough for 11 years unless there are actually new security > considerations. >=20 > allman >=20 >=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 --Apple-Mail-3-928933738 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I, on = the other hand, would say that if the security considerations section is = 11 years old,
it is in need of an update or at least another look. =  Judging from the remarks that have been
made so far, = there is a lot of wisdom about the security impact of RTO that is not = captured in the current security considerations section.
At = the very least, I think a reference to the security considerations in = RFC5681 would be in = order.

Cathy

On Apr 21, = 2011, at 10:09 PM, Mark Allman wrote:


I = agree with everything Vern said.  But, two more = points.

Thus, it is a natural target = for exploitation for a denial of service
attack, in which an attacker convinces a sender to lower = its RTO to an
unsafe value, = causing it to retransmit its packets that are not = really
lost, and thus lead to = congestion.

First, I don't think this makes sense. =  Even if some attacker can
convince a sender to reduce its RTO = and hence trip the RTO early this
will *reduce* the sender's rate = (RFC5681).  That is certainly an
impairment attack on the = connection itself, but that does not "lead to
congestion". =  I.e., it is not somehow an attack on the broader network.
In = fact, the connection would "lead to congestion" with a = higher
probability if it were to continue unimpaired at a higher = sending rate.

Second, I am loathe to change a security = considerations section that has
been good enough for 11 years unless = there are actually new = security
considerations.

allman




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-3-928933738-- From vern@ICIR.org Thu Apr 21 18:52:55 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25748E074D; Thu, 21 Apr 2011 18:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzUvHkxyiSaU; Thu, 21 Apr 2011 18:52:54 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfc.amsl.com (Postfix) with ESMTP id 731AEE06E2; Thu, 21 Apr 2011 18:52:54 -0700 (PDT) Received: from akane.icir.org (akane.icir.org [192.150.187.87]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6489536A36C; Thu, 21 Apr 2011 18:52:53 -0700 (PDT) To: Catherine Meadows In-Reply-To: <2A6D3E9C-75A6-42D7-B122-AF9AC035B2E8@nrl.navy.mil> (Thu, 21 Apr 2011 19:02:46 EDT). Date: Thu, 21 Apr 2011 18:52:53 -0700 From: Vern Paxson Message-Id: <20110422015253.6489536A36C@taffy.ICSI.Berkeley.EDU> X-Mailman-Approved-At: Sat, 23 Apr 2011 08:08:33 -0700 Cc: draft-paxson-tcpm-rfc2988bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Fwd: Secdir review of draft-paxson-tcpm-rfc2988bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:52:55 -0000 Here are some comments on the points you raise: > how hard is it to spoof an acknowledgement? It requires essentially the same level of information as is needed to inject data into an established TCP connection. For modern TCPs, this is viewed as quite difficult, due to the widespread randomization of initial sequence numbers. > What information would the attacker need to know about the packets in > the connection? The sequence numbers in both directions, as well as the port numbers. There's some slop possible for the sequence numbers (they need to be within the advertised window, per page 26 of RFC 793), but the search space here for blind spoofing is large. > If the sender backed off once a packet was genuinely lost, how hard would > it be for the attacker could bring the RTO down again? Quite difficult if they are off-path. This requires that they anticipate exactly when the sender will send *new* data (can't be a retransmission, since those aren't used to recompute RTO) and then send a bogus ACK very shortly after. If the attacker is on-path *and* near the sender, then they can manipulate the sender readily. However, it's very difficult for an attacker to be near a *lot* of attackers. If the attacker is on-path but not near, then they can likely at best manipulate the RTO towards the RTT between the attacker and the sender. They can do better if they can guess future transmissions with exceptional accuracy. > What if the attacker were applying this attack to multiple senders. Are > there cases in which an attacker could spoof an acknowledgement without > having actually have seen a packet? Per the above, this is presumed very difficult to achieve today. If it weren't, then we are in much deeper trouble due to the ability of attackers to inject data rather than simply manipulate RTO estimates. Vern From mallman@icir.org Thu Apr 21 19:09:23 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 911BDE0756; Thu, 21 Apr 2011 19:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG1sCC8+duhC; Thu, 21 Apr 2011 19:09:23 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id D3D58E075D; Thu, 21 Apr 2011 19:09:22 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3M29Lf8018639; Thu, 21 Apr 2011 19:09:21 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 97DF53A92334; Thu, 21 Apr 2011 22:09:21 -0400 (EDT) To: Catherine Meadows From: Mark Allman In-Reply-To: <2A6D3E9C-75A6-42D7-B122-AF9AC035B2E8@nrl.navy.mil> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Nobody Told Me MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma58193-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Apr 2011 22:09:21 -0400 Sender: mallman@icir.org Message-Id: <20110422020921.97DF53A92334@lawyers.icir.org> X-Mailman-Approved-At: Sat, 23 Apr 2011 08:08:33 -0700 Cc: draft-paxson-tcpm-rfc2988bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Fwd: Secdir review of draft-paxson-tcpm-rfc2988bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 02:09:23 -0000 ----------ma58193-1 Content-Type: text/plain Content-Disposition: inline I agree with everything Vern said. But, two more points. > Thus, it is a natural target for exploitation for a denial of service > attack, in which an attacker convinces a sender to lower its RTO to an > unsafe value, causing it to retransmit its packets that are not really > lost, and thus lead to congestion. First, I don't think this makes sense. Even if some attacker can convince a sender to reduce its RTO and hence trip the RTO early this will *reduce* the sender's rate (RFC5681). That is certainly an impairment attack on the connection itself, but that does not "lead to congestion". I.e., it is not somehow an attack on the broader network. In fact, the connection would "lead to congestion" with a higher probability if it were to continue unimpaired at a higher sending rate. Second, I am loathe to change a security considerations section that has been good enough for 11 years unless there are actually new security considerations. allman ----------ma58193-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2w41EACgkQWyrrWs4yIs5X/wCfX4dhlNsAZIKc90B91w7RaQH/ I9gAn1Bb62LCJNsWv2SkVUToVdIo3qZV =Udvs -----END PGP SIGNATURE----- ----------ma58193-1-- From vern@ICIR.org Thu Apr 21 19:28:14 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CA118E077B; Thu, 21 Apr 2011 19:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cusJhgiOcwBO; Thu, 21 Apr 2011 19:28:14 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfc.amsl.com (Postfix) with ESMTP id 12296E0756; Thu, 21 Apr 2011 19:28:14 -0700 (PDT) Received: from akane.icir.org (akane.icir.org [192.150.187.87]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id A211A36A36C; Thu, 21 Apr 2011 19:28:13 -0700 (PDT) To: mallman@icir.org In-Reply-To: <20110422020921.97DF53A92334@lawyers.icir.org> (Thu, 21 Apr 2011 22:09:21 EDT). Date: Thu, 21 Apr 2011 19:28:13 -0700 From: Vern Paxson Message-Id: <20110422022813.A211A36A36C@taffy.ICSI.Berkeley.EDU> X-Mailman-Approved-At: Sat, 23 Apr 2011 08:08:33 -0700 Cc: draft-paxson-tcpm-rfc2988bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Fwd: Secdir review of draft-paxson-tcpm-rfc2988bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 02:28:14 -0000 > ... Even if some attacker can > convince a sender to reduce its RTO and hence trip the RTO early this > will *reduce* the sender's rate (RFC5681). D'oh, yeah, I should have directly flagged that, because that's pretty much the argument in a nutshell: any time the sender acts on RTO, its sending rate is going to near-nil, and the DoS issues get greatly diminished with this. Vern From shawn.emery@oracle.com Sun Apr 24 23:00:08 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8758E06B0; Sun, 24 Apr 2011 23:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXQKTqXeCqsZ; Sun, 24 Apr 2011 23:00:08 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfc.amsl.com (Postfix) with ESMTP id 54901E06A3; Sun, 24 Apr 2011 23:00:07 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3P605EL021849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Apr 2011 06:00:06 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p3P604An026334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Apr 2011 06:00:04 GMT Received: from abhmt016.oracle.com (abhmt016.oracle.com [141.146.116.25]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3P5xwAi009875; Mon, 25 Apr 2011 00:59:58 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 24 Apr 2011 22:59:58 -0700 Message-ID: <4DB50DDC.4010207@oracle.com> Date: Sun, 24 Apr 2011 23:59:56 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110329 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4DB50DE7.0053:SCFMA922111,ss=1,fgs=0 Cc: draft-ietf-sidr-roa-validation.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-sidr-roa-validation-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 06:00:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational draft describes how a Route Origin Authorization (ROA) is interpreted in respect to a consumer of the Resource Public Key Infrastructure (RPKI). This interpretation is used in turn to validate the origination of routes advertised by the Border Gateway Protocol. The security considerations section does exist and gives guidance on various validation implications in regards to prefix lengths, issuance sequence, and aggregation. After reading draft-ietf-sidr-arch, draft-ietf-sidr-pfx-validate, et. al., I didn't find any additional concerns/limitations. General comments: None. Editorial comments: None. Shawn. -- From hartmans@mit.edu Mon Apr 25 09:02:54 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D9B8E075C; Mon, 25 Apr 2011 09:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnCdoMwH5Jxp; Mon, 25 Apr 2011 09:02:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id 7F60EE0665; Mon, 25 Apr 2011 09:02:53 -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 7480920378; Mon, 25 Apr 2011 11:59:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E821C4543; Mon, 25 Apr 2011 12:02:40 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Mon, 25 Apr 2011 12:02:40 -0400 In-Reply-To: (Stephen Kent's message of "Fri\, 15 Apr 2011 14\:45\:46 -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-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:02:54 -0000 Steve, thanks for your note. I realize the certificate resource profile document has been approved, but I'd still like to understand what is happening here. I'm having trouble reconciling the new text you've added to the document with draft-ietf-sidr-signed-object. 2- During phase 2 CAs MUST issue certificates under the new profile, and these certificates MUST co-exist with certificates issued under the old format. (CAs will continue to issue certificates under the old OID/format as well.) The old and new certificates MUST be identical, except for the policy OID and any new extensions, encodings, etc. Relying parties MAY make use of the old or the new certificate formats when processing signed objects retrieved from the RPKI repository system. During this phase, a relying party that elects to process both formats will acquire the same values for all certificate fields that overlap between the old and new formats. Thus if either certificate format is verifiable, the relying party accepts the data from that certificate. This allows CAs to issue certificates under However, when I look at section 2.1.4 in the signed-object document , the signer can only include one certificate. How does that work during phase 2 when some of the RPs support the new format and some only support the old format? Your text above suggests that RPs grab the certificates from the RPKI repository, but it seems at least for end entity certificates they are included in the signed object. What happens for end entity certificates during this form of upgrade? From hilarie@purplestreak.com Mon Apr 25 12:24:03 2011 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8F3A0E0691; Mon, 25 Apr 2011 12:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FptqUzqYsS1; Mon, 25 Apr 2011 12:24:03 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by ietfc.amsl.com (Postfix) with ESMTP id D1360E067C; Mon, 25 Apr 2011 12:24:02 -0700 (PDT) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QERO1-0007y4-WE; Mon, 25 Apr 2011 13:23:58 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QERO1-0006Ng-1I; Mon, 25 Apr 2011 13:23:57 -0600 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3PJLkkd020708; Mon, 25 Apr 2011 13:21:46 -0600 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id p3PJLi6R020707; Mon, 25 Apr 2011 13:21:44 -0600 Date: Mon, 25 Apr 2011 13:21:44 -0600 Message-Id: <201104251921.p3PJLi6R020707@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: ietf@ietf.org, secdir@ietf.org, draft-ietf-ippm-tcp-throughput-tm@tools.ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;ietf@ietf.org, secdir@ietf.org, draft-ietf-ippm-tcp-throughput-tm@tools.ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com) Subject: [secdir] Review of draft-ietf-ippm-tcp-throughput-tm-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 19:24:03 -0000 Security review of draft-ietf-ippm-tcp-throughput-tm-12.txt Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments. >From the document Intro: This framework recommends a methodology for measuring TCP Throughput in order to provide meaningful results with respect to user experience. I had a little bit of trouble understanding the purpose of the document, having stumbled across these two statements which when juxtaposed, seem to contradict one another: Introduction ... Note that the primary focus of this methodology is managed business class IP networks; i.e. those Ethernet terminated services for which organizations are provided an SLA from the network provider. Because of the SLA, the expectation is that the TCP Throughput should achieve the guaranteed bandwidth. ... 2. Scope and Goals ... - This methodology is not intended to measure TCP Throughput as part of an SLA [Remember the New Yorker magazine's "Our Forgetful Authors"?] It is difficult to frame the security requirements for a measurement framework, and this document does not try: 6. Security Considerations The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656] and [RFC5357]. I am not sure what to infer from this statement. That the RFCs define all possible security requirements and considerations? That their definitions coincide with what the authors of the current document recommend? That the solutions defined by the other RFCs SHOULD be be part of the framework defined by the current document? MAY? It depends? It's my recommendation that the security considerations be expanded to explicitly list the security requirements for the framework. From nico@cryptonector.com Mon Apr 25 16:02:58 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB22E06C1 for ; Mon, 25 Apr 2011 16:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LPcj3zlz-g2 for ; Mon, 25 Apr 2011 16:02:57 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1472CE068F for ; Mon, 25 Apr 2011 16:02:57 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id C82BD50806D for ; Mon, 25 Apr 2011 16:02:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=gZCLXIQdZ8Hw8JbOYxztJknDbHrd/yqMKFgqXEGl+2Z4 xfY5u29Ra0jy456fk1hp/NBSY+VqztNGeNN43XHrDW8xv3ZftBOmaZRch0/LWtX1 H9O08QyPOho3HGAfD2bgJvcjtytvAuBHafdvn8VEOnqtIZimUZUDgsRpWz0orfc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ZTxIaQW8j8OJCOtA646vBtGpypk=; b=rXkfU3U95Q6 ni3Btqtohue35aE/C9aq8DJ/GvPQJ56/G4YVCM6/+2AH4IEbLojXAaT5YRFkHO36 bC/aEdwAEHLCg/iXFg5mezsye4Uc0NyHX/lNPrNbU19sxdmkXZt9wapgvpZyiD+S a+jSDm+A8cTtOxhjN9mY8mT/U8jZJGjY= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 85CC1508063 for ; Mon, 25 Apr 2011 16:02:56 -0700 (PDT) Received: by vxg33 with SMTP id 33so77002vxg.31 for ; Mon, 25 Apr 2011 16:02:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.101 with SMTP id ch5mr79862vdc.129.1303772575780; Mon, 25 Apr 2011 16:02:55 -0700 (PDT) Received: by 10.52.163.71 with HTTP; Mon, 25 Apr 2011 16:02:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Apr 2011 18:02:55 -0500 Message-ID: From: Nico Williams To: secdir@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-sidr-rpki-manifests.all@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-sidr-rpki-manifests-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 23:02:58 -0000 [Resend, from the correct address.] I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is almost ready for publication. =C2=A0My comments are below. A summary of my comments is: =C2=A0- Text on versioning of the manifest ASN.1 would be useful. =C2=A0- Handling of boundary conditions on manifest validation could use so= me =C2=A0improvement, such as regarding clock skew. =C2=A0See specific comment= s =C2=A0below. =C2=A0- Some "SHOULDs" could use some additional commentary regarding when =C2=A0an implementation might act otherwise. =C2=A0- Nits (typos, out of date references). Nico > 2. =C2=A0Manifest Scope > > =C2=A0 =C2=A0[...] > =C2=A0 =C2=A0Where an EE certificate is placed in the Cryptographic Messa= ge Syntax > =C2=A0 =C2=A0(CMS) wrapper of a published RPKI signed object > =C2=A0 =C2=A0[ID.sidr-signed-object] there is no requirement to separatel= y publish > =C2=A0 =C2=A0the EE certificate in the CA's repository publication point. > =C2=A0 =C2=A0[...] Any guidance on when to place EE certs in CMS wrappers and when not to? BTW, the reference to ID.sidr-signed-object needs to be updated (the current version is -03). > 3. =C2=A0Manifest Signing > > =C2=A0 =C2=A0A CA's manifest is verified using an EE certificate The =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^ Missing period. s/EE certificate The/EE certificate. =C2=A0The/ > =C2=A0 =C2=A0SubjectInfoAccess (SIA) field of this EE certificate contain= s the > =C2=A0 =C2=A0access method OID of id-ad-signedObject. > =C2=A0 =C2=A0[...] > > 4.2. =C2=A0eContent > > =C2=A0 =C2=A0The content of a Manifest is defined as follows: > > =C2=A0 =C2=A0 =C2=A0Manifest ::=3D SEQUENCE { > =C2=A0 =C2=A0 =C2=A0 version =C2=A0 =C2=A0 [0] INTEGER DEFAULT 0, > =C2=A0 =C2=A0 =C2=A0 manifestNumber =C2=A0INTEGER (0..MAX), > =C2=A0 =C2=A0 =C2=A0 thisUpdate =C2=A0 =C2=A0 =C2=A0GeneralizedTime, > =C2=A0 =C2=A0 =C2=A0 nextUpdate =C2=A0 =C2=A0 =C2=A0GeneralizedTime, > =C2=A0 =C2=A0 =C2=A0 fileHashAlg =C2=A0 =C2=A0 OBJECT IDENTIFIER, > =C2=A0 =C2=A0 =C2=A0 fileList =C2=A0 =C2=A0 =C2=A0 =C2=A0SEQUENCE SIZE (0= ..MAX) OF FileAndHash > =C2=A0 =C2=A0 =C2=A0 } > > =C2=A0 =C2=A0 FileAndHash ::=3D =C2=A0 =C2=A0 SEQUENCE { > =C2=A0 =C2=A0 =C2=A0 file =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IA5Str= ing, > =C2=A0 =C2=A0 =C2=A0 hash =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BIT ST= RING > =C2=A0 =C2=A0 =C2=A0 } IA5String? =C2=A0Not UTF8String? =C2=A0What goes into file naming? > 4.2.1. =C2=A0Manifest > > =C2=A0 =C2=A0The data elements of the Manifest structure are defined as f= ollows: > > =C2=A0 =C2=A0version: > =C2=A0 =C2=A0 =C2=A0 The version number of this version of the manifest s= pecification > =C2=A0 =C2=A0 =C2=A0 MUST be 0. Some text on how versioning is intended to be used would be nice. Specifically, how might extensions be added? =C2=A0Or perhaps extensibility here is seen as unnecessary? If extensibility is inteded to be done by turning the version field of the above SEQUENCE into a CHOICE then say so -- implementors with sufficiently capable ASN.1 compilers and runtimes may prefer to modify the above to use an extensible CHOICE. In general I would much prefer that we make use of ASN.1's explicit extensibility features (namely, the extensibility marker in SEQUENCEs, SETs, and CHOICEs) and/or typed-holes as appropriate. > =C2=A0 =C2=A0manifestNumber: > =C2=A0 =C2=A0 =C2=A0 This field is an integer that is incremented each ti= me a new > =C2=A0 =C2=A0 =C2=A0 manifest is issued for a given publication point. = =C2=A0This field > =C2=A0 =C2=A0 =C2=A0 allows an RP to detect gaps in a sequence of publish= ed manifests. > > =C2=A0 =C2=A0 =C2=A0 As the manifest is modeled on the CRL specification,= the > =C2=A0 =C2=A0 =C2=A0 ManifestNumber is analogous to the CRLNumber, and th= e guidance in > =C2=A0 =C2=A0 =C2=A0 [RFC5280] for CRLNumber values is appropriate as to = the range of > =C2=A0 =C2=A0 =C2=A0 number values that can be used for the manifestNumbe= r. =C2=A0Manifest > =C2=A0 =C2=A0 =C2=A0 numbers can be expected to contain long integers. = =C2=A0Manifest > =C2=A0 =C2=A0 =C2=A0 verifiers MUST be able to handle number values up to= 20 octets. > =C2=A0 =C2=A0 =C2=A0 Conforming Manifest issuers MUST NOT use number valu= es longer than > =C2=A0 =C2=A0 =C2=A0 20 octets Why not write that MAX value explicitly in the constraint for this field? =C2=A0(Because it's a fairly long number?) > 5.1. =C2=A0Manifest Generation Procedure > > =C2=A0 =C2=A06. =C2=A0In the case of a key pair that is to be used only o= nce, in > =C2=A0 =C2=A0 =C2=A0 =C2=A0conjunction with a "one-time-use" EE certifica= te, the private key > =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with this key pair SHOULD now be de= stroyed. Any reason not to make this SHOULD a MUST? =C2=A0Any guidance as to when on= e might not heed this SHOULD? > 5.2. =C2=A0Considerations for Manifest Generation > > =C2=A0 =C2=A0A new manifest MUST be issued on or before the nextUpdate ti= me. Well, a new manifest must be published on or before the nextUpdate time. Since RPs clocks will have some skew, new manifests should really be published some time ahead of the nextUpdate time. =C2=A0A few seconds or minutes will do. =C2=A0See comments on section 6.2. What happens if an authority fails to publish a new manifest in a timely fashion? =C2=A0This would surely be an important operational consideration.= .. > =C2=A0 =C2=A0When a CA entity is performing a key rollover, the entity MA= Y chose s/chose/choose/ > =C2=A0 =C2=A0to have two CAs instances simultaneously publishing into the= same s/CAs instances/CA instances/ > =C2=A0 =C2=A0repository publication point. =C2=A0In this case there will = be one > =C2=A0 =C2=A0manifest associated with each active CA instance that is pub= lishing > =C2=A0 =C2=A0into the common repository publication point (directory). > 6.1. =C2=A0Tests for Determining Manifest State > > =C2=A0 =C2=A0For a given publication point, the RP SHOULD perform the fol= lowing > =C2=A0 =C2=A0tests to determine the manifest state of the publication poi= nt: > > =C2=A0 =C2=A01. =C2=A0For each CA using this publication point, select th= e CA's current > =C2=A0 =C2=A0 =C2=A0 =C2=A0manifest (The "current" manifest is the manife= st issued by this > =C2=A0 =C2=A0 =C2=A0 =C2=A0CA having highest manifestNumber among all val= id manifests, and > =C2=A0 =C2=A0 =C2=A0 =C2=A0where manifest validity is defined in Section = 4.4). > > =C2=A0 =C2=A0 =C2=A0 =C2=A0If the publication point does not contain a va= lid manifest, see > =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 6.2. =C2=A0Lacking a valid manifest, t= he following tests > =C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be performed. > > =C2=A0 =C2=A02. =C2=A0To verify completeness, an RP MAY check that every = file at each > =C2=A0 =C2=A0 =C2=A0 =C2=A0publication point appears in one and only one = current manifest, > =C2=A0 =C2=A0 =C2=A0 =C2=A0and that every file listed in a current manife= st that is > =C2=A0 =C2=A0 =C2=A0 =C2=A0published at the same publication point as the= manifest. See comment on (4) below. > =C2=A0 =C2=A03. =C2=A0Check that the current time (translated to UTC) is = between > =C2=A0 =C2=A0 =C2=A0 =C2=A0thisUpdate and nextUpdate. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0If the current time does not lie within this i= nterval then see > =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 6.4, but still continue with the follo= wing tests. This appears to be in conflict with (1) above. =C2=A0The manifest can't be valid if the current time does not fall in the manifest's validity period, so what's the point in continuing? =C2=A0I suppose I'll find out wh= en I get to section 6.4! > =C2=A0 =C2=A04. =C2=A0Verify that listed hash value of every file listed = in each > =C2=A0 =C2=A0 =C2=A0 =C2=A0manifest matches the value obtained by hashing= the file at the > =C2=A0 =C2=A0 =C2=A0 =C2=A0publication point. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0If the computed hash value of a file listed on= the manifest does > =C2=A0 =C2=A0 =C2=A0 =C2=A0not match the hash value contained in the mani= fest, then see > =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 6.6. Will the RP need to check every file? =C2=A0Why not just those that are of interest? > =C2=A0 =C2=A0For each signed object, if all of the following conditions h= old: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0[...] > > =C2=A0 =C2=A0then the RP can conclude that no attack against the reposito= ry system > =C2=A0 =C2=A0has compromised the given signed object, and the signed obje= ct MUST > =C2=A0 =C2=A0be treated as valid. No scope for local policy exemptions to the above MUST? > 6.2. =C2=A0Missing Manifests > > =C2=A0 =C2=A0The absence of a current manifest at a publication point cou= ld occur > =C2=A0 =C2=A0due to an error by the publisher or due to (malicious or acc= idental) > =C2=A0 =C2=A0deletion or corruption of all valid manifests. > > =C2=A0 =C2=A0When no valid manifest is available, there is no protection = against > =C2=A0 =C2=A0attacks that delete signed objects or replay old versions of= signed > =C2=A0 =C2=A0objects. =C2=A0All signed objects at the publication point, = and all > =C2=A0 =C2=A0descendant objects that are validated using a certificate at= this > =C2=A0 =C2=A0publication point SHOULD be viewed as suspect, but MAY be us= ed by the > =C2=A0 =C2=A0RP, as per local policy. I wonder if we shouldn't have a latestNextUpdate field specifying a time past which RPs MUST NOT accept expired manifests. =C2=A0Alternatively, loca= l policy ought to specify how old an expired manifest may be accepted, with RECOMMENDED guidance as to what that maximum age should be. Additionally, CA operators should get guidance to publish new manifests somewhat sooner than the expiration of current manifests being replaced so as to have some time to cope with operations failures during manifest generation and publication. > =C2=A0 =C2=A0The primary risk in using signed objects at this publication= point is > =C2=A0 =C2=A0that a superseded (but not stale) CRL would cause an RP to i= mproperly > =C2=A0 =C2=A0accept a revoked certificate as valid (and thus rely upon si= gned > =C2=A0 =C2=A0objects that are validated using that certificate). =C2=A0Th= is risk is > =C2=A0 =C2=A0somewhat mitigated if the CRL for this publication point has= a short > =C2=A0 =C2=A0time between thisUpdate and nextUpdate (and the current time= is > =C2=A0 =C2=A0within this interval). =C2=A0The risk in discarding signed o= bjects at this > =C2=A0 =C2=A0publication point is that an RP may incorrectly discard a la= rge > =C2=A0 =C2=A0number of valid objects. =C2=A0This gives significant power = to an > =C2=A0 =C2=A0adversary that is able to delete a manifest at the publicati= on point. I.e., there's a trade-off between DoS and more severe attacks. =C2=A0Howeve= r, we can't protect against DoS attacks here anyways, so might as well give guidance in preference of protecting against the other attacks. Additionally, guidance to interleave new manifest publication such that there's enough time to cope with operations failures and DoS attacks should help. > =C2=A0 =C2=A0Regardless of whether signed objects from this publication a= re deemed > =C2=A0 =C2=A0fit for use by an RP, this situation SHOULD result in a warn= ing to > =C2=A0 =C2=A0the effect that: "No manifest is available for , and > =C2=A0 =C2=A0thus there may have been undetected deletions or replay subs= titutions > =C2=A0 =C2=A0from the publication point." I imagine this isn't a MUST because of log squelching considerations. Right? > =C2=A0 =C2=A0In the case where an RP has access to a local cache of previ= ously > =C2=A0 =C2=A0issued manifests that are valid, the RP MAY use the most rec= ently > =C2=A0 =C2=A0previously issued valid manifests for this RPKI repository > =C2=A0 =C2=A0publication collection in this case for each entity that pub= lishes at > =C2=A0 =C2=A0his publication point. Subject to the same considerations, surely. Any advice as to when to poll for new manifests ahead the current, cached manifest's nextUpdate? > 6.4. =C2=A0Stale Manifests My comments on section 6.2 apply here as well. > =C2=A0 =C2=A0Note that there is also the potential for the current time t= o be > =C2=A0 =C2=A0before the thisUpdate time for the manifest. =C2=A0This case= could be due > =C2=A0 =C2=A0to publisher error, or a local clock error, and in such a ca= se this > =C2=A0 =C2=A0situation SHOULD result in a warning to the effect that: "A = manifest > =C2=A0 =C2=A0found at has an incorrect thisUpdate field.= =C2=A0This > =C2=A0 =C2=A0could be due to publisher error, or a local clock error, and > =C2=A0 =C2=A0processing for this publication point will continue using th= is > =C2=A0 =C2=A0otherwise valid manifest." This can also happen due to having a slow clock on the RP or a fast clock at the CA, or both. =C2=A0Clock skew is hardly an error, since there will always be some skew, even if only on the order of nanoseconds in the case of good hardware setup with good time distribution mechanisms and good hardware time sources. =C2=A0A bit more text (any!) regarding cloc= k skew would be useful. > 8. =C2=A0Security Considerations > ... > =C2=A0 =C2=A0the manifest structure . s/ \././ From kivinen@iki.fi Tue Apr 26 04:35:37 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82799E06ED; Tue, 26 Apr 2011 04:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAtNrXfXUKMv; Tue, 26 Apr 2011 04:35:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D700E06E4; Tue, 26 Apr 2011 04:35:34 -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 p3QBZUHm028646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 14:35:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p3QBZT1q016737; Tue, 26 Apr 2011 14:35:30 +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: <19894.44545.962868.167907@fireball.kivinen.iki.fi> Date: Tue, 26 Apr 2011 14:35:29 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dnsop-as112-under-attack-help-help.all@ltools.ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 6 min Subject: [secdir] Secdir review of draft-ietf-dnsop-as112-under-attack-help-help-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:35:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document provides background information for adminstrators who think they are under attack because they are sending reverse dns queries of the private use addresses and are getting responses back. Security considerations section do point out that sending those queries out from the site might leak information related to the private infrastructure, which might represent a security risk. I do not have any comments related to this document. -- kivinen@iki.fi From derek@ihtfp.com Wed Apr 27 14:33:59 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1A8E081D; Wed, 27 Apr 2011 14:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJQgeTuceLKR; Wed, 27 Apr 2011 14:33:58 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 88FEDE0804; Wed, 27 Apr 2011 14:33:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id EE3A8260364; Wed, 27 Apr 2011 17:33:56 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 00312-02; Wed, 27 Apr 2011 17:33:54 -0400 (EDT) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id D0AF526023A; Wed, 27 Apr 2011 17:33:54 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id p3RLXqk8026029; Wed, 27 Apr 2011 17:33:52 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Wed, 27 Apr 2011 17:33:52 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: ari.keranen@ericsson.com, jari.arkko@piuha.net, john.mattsson@ericsson.com Subject: [secdir] sec-dir review of draft-arkko-mikey-iana-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:33:59 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, 6043, and obsoletes RFC 4909. I see no issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From jari.arkko@piuha.net Wed Apr 27 21:32:08 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1EE0682; Wed, 27 Apr 2011 21:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeDJEXXQL6fb; Wed, 27 Apr 2011 21:32:07 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7E42AE0680; Wed, 27 Apr 2011 21:32:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C7BA12CC4B; Thu, 28 Apr 2011 07:32:01 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsvvpHkddP+X; Thu, 28 Apr 2011 07:32:01 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 354602CC2F; Thu, 28 Apr 2011 07:32:01 +0300 (EEST) Message-ID: <4DB8EDC0.1010808@piuha.net> Date: Thu, 28 Apr 2011 07:32:00 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Derek Atkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ari.keranen@ericsson.com, iesg@ietf.org, john.mattsson@ericsson.com, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-arkko-mikey-iana-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 04:32:08 -0000 Thank you for your review, Derek! Jari Derek Atkins kirjoitti: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document clarifies and relaxes the IANA rules for Multimedia > Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, > 5410, 6043, and obsoletes RFC 4909. > > I see no issues with this document. > > -derek > > From j.schoenwaelder@jacobs-university.de Thu Apr 28 04:40:43 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8965E06B6; Thu, 28 Apr 2011 04:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.151 X-Spam-Level: X-Spam-Status: No, score=-103.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqFDkBMj7cc1; Thu, 28 Apr 2011 04:40:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 62046E068D; Thu, 28 Apr 2011 04:40:42 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCB1B20C04; Thu, 28 Apr 2011 13:40:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XJEbniSsJg0w; Thu, 28 Apr 2011 13:40:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACA7320C12; Thu, 28 Apr 2011 13:40:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7A3221835A25; Thu, 28 Apr 2011 13:40:38 +0200 (CEST) Date: Thu, 28 Apr 2011 13:40:38 +0200 From: Juergen Schoenwaelder To: Paul Kyzivat Message-ID: <20110428114038.GB1926@elstar.local> Mail-Followup-To: Paul Kyzivat , iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org, presnick@qualcomm.com References: <20110422114517.GA2512@elstar.local> <4DB8B27D.1090100@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DB8B27D.1090100@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: presnick@qualcomm.com, iesg@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sipping-sip-offeranswer-14.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 11:40:43 -0000 On Wed, Apr 27, 2011 at 08:19:09PM -0400, Paul Kyzivat wrote: > >However, these references raise a procedural question. It seems all > >these relevant specifications are on the standards track while this > >clarification, which tries to handle situations that can lead to > >"failed or degraded calls", is submitted as an Informational document. > >Should this not be standards track, formerly updating the relevant > >RFCs? I see in the IESG writeup that this has been discussed before, > >the proposed move to publish this as Informational still sounds > >surprising to me as an outsider. If there is consensus to resolve the > >ambiguities as described in the document, then why not via a > >standards-track action? Or is the idea that this resolution simply > >can be ignored or that something very different might be invented? > >That latter would more speak for Experimental then. > > We have been around this track several times. We decided this > approach was the most appropriate one for these issues. The > following message is part of one of the more recent threads on the > topic. > > http://www.ietf.org/mail-archive/web/rai/current/msg00833.html I followed the URL but all I could see was that this question was raised and discussed before. I still miss the convincing argument why this should be Informational and not standards-track or Experimental. Perhaps you have another pointer where this becomes clear? > >Getting back to security considerations, if the intention is not to > >require implementations to follow the disambiguation described in the > >document (that is not moving to standards-track), can malware exploit > >the fact that the underlying RFCs allow for ambiguities to cause > >"failed or degraded calls"? > > The participants in the SIP offer/answer exchange presumably *want* > the exchange to succeed. If not, there are a multitude of things > they can do to make the call fail or degrade. This sounds a bit like "a not well behaving client has other ways to cause damage, so we do not have to worry much about this way to cause damage", which I find not a very convincing approach. Anyway, I am probably a bit picky here since this document is intended to be informational, so any standards compliant implementation can ignore this specification and hence use standards track compliant mechanisms to cause failed or degraded calls. > SIP already provides mechanisms to protect the offer/answer exchange > from tampering by 3rd parties. For instance: > > Enhancements for Authenticated Identity Management > in the Session Initiation Protocol (SIP) > http://tools.ietf.org/html/rfc4474 > > Section 26.3.2 Security Solutions of RFC 3261 > http://datatracker.ietf.org/doc/rfc3261/ > > If the participants choose to ignore those mechanisms, then again > there are many things that a third party can do to degrade the call. Then this should probably be mentioned in the Security Considerations. Right now, there is no reference to RFC 4474 at all. So if that one is relevant to prevent tampering by 3rd parties, I would rather have this spelled out and a reference included. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Leon.Portman@nice.com Wed Apr 27 12:23:27 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE9E0813; Wed, 27 Apr 2011 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.941, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PupPOdgyRJu1; Wed, 27 Apr 2011 12:23:26 -0700 (PDT) Received: from mailil.nice.com (unknown [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 75A6DE081D; Wed, 27 Apr 2011 12:23:26 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 27 Apr 2011 22:23:25 +0300 From: Leon Portman To: Tobias Gondrom , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-siprec-req.all@tools.ietf.org" , "Elwell, John" Date: Wed, 27 Apr 2011 22:23:24 +0300 Thread-Topic: Secdir review of draft-ietf-siprec-req Thread-Index: Acv8euVMl1LykO0rTty0WyAVR/HTFgIh1B4A Message-ID: <07465C1D981ABC41A344374066AE1A2C38AB7A1CCF@TLVMBX01.nice.com> References: <4DAA0630.3020606@gondrom.org> In-Reply-To: <4DAA0630.3020606@gondrom.org> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 29 Apr 2011 03:03:00 -0700 Cc: "rajnish.jain@ipc.com" , "krehor@cisco.com" , "andrew.hutton@siemens-enterprise.com" Subject: Re: [secdir] Secdir review of draft-ietf-siprec-req X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 19:23:27 -0000 Tobias Hello Thank you very much for the review. Is the adding the following paragraph to the security section can clarify = better your point below: "A malicious or corrupt SRC can tamper with media and metadata relating to = a CS before sending to an SRS. Also CS media and signaling can be tampered = with in the network prior to reaching an SRC, unless proper means are provi= ded to ensure integrity protection during transmission on the CS. Means for= ensuring the integrity and correctness of media and metadata emitted by an= SRC are outside the scope of this work. Other organizational and technical= controls will need to be used to prevent tampering." Regarding your personal note below, currently this issue is out of scope fo= r SIPREC working group, however we definitely should give some thought rega= rding it. Thank you very much again Leon -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org]=20 Sent: Sunday, April 17, 2011 12:12 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-siprec-req.all@tools.ietf.or= g Cc: krehor@cisco.com; Leon Portman; andrew.hutton@siemens-enterprise.com; r= ajnish.jain@ipc.com Subject: Secdir review of draft-ietf-siprec-req 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. http://www.ietf.org/id/draft-ietf-siprec-req-09.txt The document is informational and describes use cases and requirements for = SIP-based Media Recording. Overall I agree with the stated requirements in the document and consider t= he Privacy and Security Considerations sufficient. Privacy and Security sections could be enhanced by clarifying that the inte= grity and correctness of the recorded data is not ensured by (cryptographic) means to ensure that the CS has not been tampered with (als= o see below). At least AFAIK. This would have to be done by organizational = and technical controls that prevent tampering with the recording UA and the= data stream between end point UA and SRC. Best regards, Tobias Ps.: On a personal note a small suggestion/idea for the authors: - it seem the non-repudiation, authenticity and completeness (no dropped packets) of recorded CS linked to individual participants is basically unpr= oven (if not impossible to prove in this setting?). I.e. an evil recording = entity might twist incoming streams from participants to re-align given ans= wers to different points in the stream or re-align its own statements. E.g. actual dialogue: 1. participant A "Do you want to buy this product?"=20 2. participant B: "No." 3. participant A "Do you want to abort this operation?" 4. participant B: "Yes." Could be twisted to: 1. participant A "Do you want to buy this product?"=20 4. participant B: "Yes." 3. participant A "Do you want to abort this operation?" 2. participant B: "No." or with only control of your own recorded data-stream: 3. participant A "Do you want to abort this operation?" 2. participant B: "No." 1. participant A "Do you want to buy this product?"=20 4. participant B: "Yes." I wonder whether authentication means (like signing) your session stream wi= th a personal key and chronology integrity ensuring mechanisms (reliably li= nking messages to timestamps or previous messages from the other party) wou= ld be worth consideration and could prevent such an attack. From pkyzivat@cisco.com Wed Apr 27 17:19:11 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E234E084D; Wed, 27 Apr 2011 17:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.472 X-Spam-Level: X-Spam-Status: No, score=-110.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qaot6EuCVr0n; Wed, 27 Apr 2011 17:19:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0C796E0691; Wed, 27 Apr 2011 17:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3461; q=dns/txt; s=iport; t=1303949950; x=1305159550; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Z/U/8KCYtMDyUzSTCAQpmlZN0MC8bNsqoXrFrvP2HAQ=; b=jYc/qyrh2ppnIoJbaYzFb8zEYBlN3P5m1oRA8wVAW7ECJyx3LIJN6Yj+ 085OKEppq+18qCSk91LJam1SQrVaBqqo9R24zXulaJnsZV63Nonb7eyh4 XjUHF2ue0aAInR5g9+VBr2YsrPFMFg/ZVvAK80tuB6jeQqGyR8dyQNW64 M=; X-IronPort-AV: E=Sophos;i="4.64,277,1301875200"; d="scan'208";a="437767992" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 28 Apr 2011 00:19:10 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3S0J9ht024964; Thu, 28 Apr 2011 00:19:09 GMT Message-ID: <4DB8B27D.1090100@cisco.com> Date: Wed, 27 Apr 2011 20:19:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org References: <20110422114517.GA2512@elstar.local> In-Reply-To: <20110422114517.GA2512@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Apr 2011 03:03:00 -0700 Cc: presnick@qualcomm.com Subject: Re: [secdir] secdir review of draft-ietf-sipping-sip-offeranswer-14.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 00:19:11 -0000 Juergen, Thank you for your careful review. (This has been a long slog for everyone.) I'm sorry to be tardy in responding to you. I started to prepare a response in a timely way and then got side tracked. :-( Responses inline. On 4/22/2011 7:45 AM, Juergen Schoenwaelder wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I reviewed earlier versions of this I-D in Feburary 2009 and in > December 2010. This revision has more explicit text in the security > considerations, which essentially states that the clarifications on > offer/answer exchanges do not add any new security issues. It took me > some time to parse the sentences, perhaps a simpler wording could have > been used (e.g. s/exclude from use/exclude). I appreciate the more > explicit text and the concrete pointers to the relevant RFCs. The wording was done carefully in order to get the intended level of precision. I agree that your suggested substitution ( s/exclude from use/exclude ) would be fine. If you wish I can make that change. > However, these references raise a procedural question. It seems all > these relevant specifications are on the standards track while this > clarification, which tries to handle situations that can lead to > "failed or degraded calls", is submitted as an Informational document. > Should this not be standards track, formerly updating the relevant > RFCs? I see in the IESG writeup that this has been discussed before, > the proposed move to publish this as Informational still sounds > surprising to me as an outsider. If there is consensus to resolve the > ambiguities as described in the document, then why not via a > standards-track action? Or is the idea that this resolution simply > can be ignored or that something very different might be invented? > That latter would more speak for Experimental then. We have been around this track several times. We decided this approach was the most appropriate one for these issues. The following message is part of one of the more recent threads on the topic. http://www.ietf.org/mail-archive/web/rai/current/msg00833.html > Getting back to security considerations, if the intention is not to > require implementations to follow the disambiguation described in the > document (that is not moving to standards-track), can malware exploit > the fact that the underlying RFCs allow for ambiguities to cause > "failed or degraded calls"? The participants in the SIP offer/answer exchange presumably *want* the exchange to succeed. If not, there are a multitude of things they can do to make the call fail or degrade. SIP already provides mechanisms to protect the offer/answer exchange from tampering by 3rd parties. For instance: Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) http://tools.ietf.org/html/rfc4474 Section 26.3.2 Security Solutions of RFC 3261 http://datatracker.ietf.org/doc/rfc3261/ If the participants choose to ignore those mechanisms, then again there are many things that a third party can do to degrade the call. Thanks, Paul From kathleen.moriarty@emc.com Wed Apr 27 19:10:48 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F31E08E3; Wed, 27 Apr 2011 19:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iLftCdo8bG7; Wed, 27 Apr 2011 19:10:47 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4F629E08DE; Wed, 27 Apr 2011 19:10:47 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3S2AgPD007369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 22:10:42 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 27 Apr 2011 22:10:32 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3S2AN6E028977; Wed, 27 Apr 2011 22:10:23 -0400 Received: from mx06a.corp.emc.com ([169.254.1.49]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 27 Apr 2011 22:10:22 -0400 From: To: , , Date: Wed, 27 Apr 2011 22:10:21 -0400 Thread-Topic: Sec-Dir review of draft-ietf-trill-adj-06 Thread-Index: AcwFSW2ZPBzjO7LYQB+HgtesuoSRkA== 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 X-EMM-MHVC: 1 X-Mailman-Approved-At: Fri, 29 Apr 2011 03:03:00 -0700 Cc: Radia@alum.mit.edu, vishwas@ipinfusion.com, ddutt@cisco.com, anoop@brocade.com Subject: [secdir] Sec-Dir review of draft-ietf-trill-adj-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 02:10:48 -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. I see no security issues with this document. Summary: "This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU and pseudonode procedures, with state machines. There is no change for IS-IS point- to-point Hellos used on links configured as point-to-point in TRILL." The TRILL Hello protocol serves the following purposes: "a) To determine which RBridge neighbors have acceptable connectivity to be reported as part of the topology (Section 3) b) To elect a unique Designated RBridge on the link (Section 4) c) To determine the MTU with which it is possible to communicate with each RBridge neighbor (Section 5)" At layer 3, they are all combined. TRILL does not accept the same behavior= as TRILL Hello protocol due to possible loops. I do not see any security = issues that are raised by the addition of these capabilities that have not = been addressed in the document. Nit: the following line on Page 24 is missing a period between sentences: "entire range is covered reasonably promptly Delays in sending TRILL" Best regards, Kathleen From weiler@watson.org Fri Apr 29 18:18:46 2011 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB832E067A for ; Fri, 29 Apr 2011 18:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6avPFPjPPDR for ; Fri, 29 Apr 2011 18:18:45 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id A909AE0677 for ; Fri, 29 Apr 2011 18:18:45 -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 p3U1IiPf060413 for ; Fri, 29 Apr 2011 21:18:44 -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 p3U1Ii5l060410 for ; Fri, 29 Apr 2011 21:18:44 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 29 Apr 2011 21:18:44 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 29 Apr 2011 21:18:44 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 30 Apr 2011 01:18:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Vincent Roca is next in the rotation. For telechat 2011-05-12 Reviewer LC end Draft Rob Austein T 2011-05-03 draft-haleplidis-forces-implementation-experience-02 David McGrew T 2011-05-09 draft-lear-iana-timezone-database-03 Vincent Roca T 2011-02-07 draft-reed-urn-dgiwg-02 For telechat 2011-05-26 Love Hornquist-Astrand T 2011-05-12 draft-daboo-et-al-icalendar-in-xml-08 Matt Lepinski T 2011-04-20 draft-ietf-vcarddav-vcardxml-09 Last calls and special requests: Uri Blumenthal 2011-04-18 draft-ietf-idr-bgp-identifier-13 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Dan Harkins 2011-05-03 draft-mavrogiannopoulos-ssl-version3-03 Sam Hartman 2011-04-23 draft-shin-augmented-pake-05 Jeffrey Hutzelman 2011-04-26 draft-ietf-avtext-multicast-acq-rtcp-xr-04 Charlie Kaufman 2011-04-20 draft-ietf-dime-extended-naptr-06 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Sandy Murphy 2011-04-29 draft-ietf-grow-geomrt-01 Magnus Nystrom 2011-05-02 draft-ietf-genarea-datatracker-iana-rfced-extns-01 Radia Perlman 2011-05-20 draft-hoffman-alt-streams-tracker-13 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Eric Rescorla 2011-05-12 draft-ietf-mmusic-ice-options-registry-01 Sam Weiler 2011-03-24 draft-ietf-sidr-roa-format-10