From turners@ieca.com Tue Jun 1 07:56:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE4D3A6A33 for ; Tue, 1 Jun 2010 07:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu5jfBDmRVid for ; Tue, 1 Jun 2010 07:56:13 -0700 (PDT) Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id 8F0983A6A35 for ; Tue, 1 Jun 2010 07:56:13 -0700 (PDT) Received: (qmail 90532 invoked from network); 1 Jun 2010 14:55:53 -0000 Received: from thunderfish.local (turners@96.241.1.49 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 01 Jun 2010 07:55:53 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: CqlcPcMVM1kBjSCgf33hAn9.9eY_ItzbEbnUeq7TPqfBWh2fp_JJlTn4c_Bg9b._n2HXJsc.0tVw1qQ8va7ILXnVO71SjJ4LcGc9jE6Xv2X_xG6pOW7L.WLJ05sqauM1Q93k.6cMz4X1tAnz3xkRlwAZ0sv_ao3o2aTfvcJYNZUJb12Cx5Psxh69EEY2sbOMAkhct3kS8UttUMB.W4tuACkrDfgKoDJJpF7lJOGLkyFw5xyXk2D_XWP8uI.5FiWE2VhwVyEpFZwVbY9i2b6TOSpcg1b3MF01nUquUNRbkRsKf9az0i0Z.UQ7j8Jkgc.YAeS0lBy1G93zBlJ_lBftiYs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C051F78.2080600@ieca.com> Date: Tue, 01 Jun 2010 10:55:52 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org, saag@ietf.org References: <4BFD1FE5.10207@ieca.com> <4BFD38F9.20800@gmail.com> In-Reply-To: <4BFD38F9.20800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [secdir] [saag] The IETF Security Area Wiki and our new AD blogs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 14:56:14 -0000 I asked Henrik if Tim and I could get real blog with an RSS feed. Turns out we can. It's currently empty and I can pretty much guarantee that it won't be witty or entertaining but I'm hoping it will get you the information you need. It can be found by clicking on the "blog" link in the toolbar on the following page: http://trac.tools.ietf.org/area/sec/trac/wiki Tim and I are also updating the name of what we were calling the "TimsBlog" and "SeansBlog". I'm going to rename mine SeansMonthlyStatus and it will be the same as the email I'll send out. spt Yaron Sheffer wrote: > Hi Sean, > > the security AD blog is a very good idea. But (unless I'm missing > something) the Trac wiki doesn't support RSS or any other kind of > subscription, which makes it much less useful than plain old email. So I > hope you are still planning to mail out the AD notes. > > Thanks, > Yaron > > > On 05/26/2010 04:19 PM, Sean Turner wrote: >> While at the IESG retreat, Tim and I decided to update the Security Area >> wiki, which if you didn't know is located at: >> http://trac.tools.ietf.org/area/sec/trac/wiki >> >> Tim and I also decided to add a blog for each of us, which is going to >> be eerily similar to monthly AD notes: >> >> http://trac.tools.ietf.org/area/sec/trac/wiki/TimsBlog >> http://trac.tools.ietf.org/area/sec/trac/wiki/SeansBlog >> >> I'm hoping that we'll both update on it on a regular basis. >> >> spt >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > From tlyu@mit.edu Tue Jun 1 15:22:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0070728C1D6; Tue, 1 Jun 2010 15:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ho8uKajqdZZ; Tue, 1 Jun 2010 15:22:44 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 10D5228C1D4; Tue, 1 Jun 2010 15:22:43 -0700 (PDT) X-AuditID: 12074424-b7b9dae000002832-1b-4c058827a161 Received: from mailhub-auth-3.mit.edu (MAILHUB-AUTH-3.MIT.EDU [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 4A.42.10290.728850C4; Tue, 1 Jun 2010 18:22:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id o51MMTuD006728; Tue, 1 Jun 2010 18:22:30 -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 o51MMQ68004580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Jun 2010 18:22:27 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o51MMQd7002732; Tue, 1 Jun 2010 18:22:26 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, v6ops-chairs@tools.ietf.org, draft-krishnan-v6ops-teredo-update.all@tools.ietf.org From: Tom Yu Date: Tue, 01 Jun 2010 18:22:26 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Subject: [secdir] secdir re-review of draft-krishnan-v6ops-teredo-update-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 22:22:45 -0000 This is a re-review of draft-krishnan-v6ops-teredo-update-07, which I previously reviewed in its -03 version. Most of my concerns from the previous review have been adequately addressed. I concur with the ballot comment by Russ Housley about quantifying the resistance of this randomization scheme to address scanning in relation to the general IPv6 address scanning risk. For example, if the attacker knows the Teredo server's IPv4 address and client's external IPv4 address but the client's Teredo UDP port number, the effective search space after the flag randomization is 28 bits. Effective address search spaces for similar scenarios can be computed easily. Explicitly comparing the values in section 2.3 of RFC 5157 with the search space sizes resulting from implementing the technique in this update may be helpful to the reader. From suresh.krishnan@ericsson.com Tue Jun 1 22:51:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D733A6850; Tue, 1 Jun 2010 22:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=-1.646, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9Zo1F9Ol6zQ; Tue, 1 Jun 2010 22:51:07 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 2A7553A69E2; Tue, 1 Jun 2010 22:50:29 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o525o08B025039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jun 2010 00:50:00 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Jun 2010 01:49:59 -0400 Message-ID: <4C05F076.7050303@ericsson.com> Date: Wed, 2 Jun 2010 01:47:34 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Richard L. Barnes" References: <00CEF527-9674-47CF-BC3E-66A9FC7289F7@bbn.com> <4C034A8C.9020205@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: The IETF , "iesg@ietf.org" , "draft-ietf-csi-send-cert@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-csi-send-cert-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 05:51:17 -0000 Hi Richard, Removing the stuff we agreed upon. On 10-05-31 08:22 PM, Richard L. Barnes wrote: > Hey Suresh, > > Most of these comments look OK to me. Couple of responses inline. > > --Richard > >>> Sec 6 Para 4 >>> The requirement for RFC 3779 extension seems to contradict the use of >>> ETAs as Trust Anchor Material, i.e., the last sentence of the first >>> paragraph in this section. >> >> Good catch. I am not sure how to resolve this. One way would be to >> specify that the ETA EE certificates are exempt from requiring the >> RFC3779 extensions. Do you have any suggestions? > > I think the rest of the section is clear enough -- the TA material > either has to be a self-signed certificate or it has to be an ETA. So > maybe you could just delete the phrase "and MUST always refer to a > certificate that includes a RFC 3779 address extension"? Hmm. The ETA certificate itself does not need to have the RFC3779 extension in it, but the relying party needs to fetch an RTA certificate which will contain a RFC3779 extension. > > As an aside, do you want to specify that in the first case (the non-ETA > case), the self-signed TA cert MUST conform to the RPKI profile? Will do. Thanks Suresh From suresh.krishnan@ericsson.com Tue Jun 1 22:54:13 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA38D3A6A59; Tue, 1 Jun 2010 22:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXcXOEoi+m-i; Tue, 1 Jun 2010 22:54:08 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1B6063A6A50; Tue, 1 Jun 2010 22:52:52 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o525xADs014110; Wed, 2 Jun 2010 00:59:10 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0706.eamcs.ericsson.se (147.117.20.91) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Jun 2010 01:52:37 -0400 Message-ID: <4C05F114.8020607@ericsson.com> Date: Wed, 2 Jun 2010 01:50:12 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Tom Yu References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-krishnan-v6ops-teredo-update.all@tools.ietf.org" , "v6ops-chairs@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir re-review of draft-krishnan-v6ops-teredo-update-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 05:54:14 -0000 Hi Tom, Thanks again for your comments on the new revision. I will try to work out with Russ, David and you as to how to best do this comparison and I will update the document after we agree. Thanks Suresh On 10-06-01 06:22 PM, Tom Yu wrote: > This is a re-review of draft-krishnan-v6ops-teredo-update-07, which I > previously reviewed in its -03 version. Most of my concerns from the > previous review have been adequately addressed. > > I concur with the ballot comment by Russ Housley about quantifying the > resistance of this randomization scheme to address scanning in > relation to the general IPv6 address scanning risk. For example, if > the attacker knows the Teredo server's IPv4 address and client's > external IPv4 address but the client's Teredo UDP port number, the > effective search space after the flag randomization is 28 bits. > Effective address search spaces for similar scenarios can be computed > easily. Explicitly comparing the values in section 2.3 of RFC 5157 > with the search space sizes resulting from implementing the technique > in this update may be helpful to the reader. From weiler@watson.org Wed Jun 2 21:37:23 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11AAA28C0EE; Wed, 2 Jun 2010 21:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, 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 RdgZY+OIuXPp; Wed, 2 Jun 2010 21:37:21 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A3E903A68B8; Wed, 2 Jun 2010 21:37:20 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o534b6Ws055826; Thu, 3 Jun 2010 00:37:06 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o534b6ug055820; Thu, 3 Jun 2010 00:37:06 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 3 Jun 2010 00:37:05 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org, iesg@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, 03 Jun 2010 00:37:06 -0400 (EDT) Subject: [secdir] secdir review of draft-hoffman-tls-additional-random-ext X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 04:37:24 -0000 I don't have much to add to the discussion of this draft (and the related draft-hoffman-tls-master-secret-input-01) that happened on the IETF list already. At a first pass, I'm a fan of at least adding an applicability statement; the current draft doesn't say much to implementors about why they might or might not want to use this extension. And, putting myself in those shoes, I think I'd find the existence of this draft more confusing than helpful. And I observe quite a bit of opposition to publication of this doc on the IETF list. -- Sam From weiler@watson.org Wed Jun 2 22:07:07 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C353A69C5; Wed, 2 Jun 2010 22:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF6WU3dmrK4Z; Wed, 2 Jun 2010 22:07:06 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B1C673A693B; Wed, 2 Jun 2010 22:07:06 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o5356rXV060612; Thu, 3 Jun 2010 01:06:53 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o5356qlQ060607; Thu, 3 Jun 2010 01:06:53 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 3 Jun 2010 01:06:52 -0400 (EDT) From: Samuel Weiler To: draft-ietf-v6ops-rogue-ra.all@tools.ietf.org, iesg@ietf.org, 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, 03 Jun 2010 01:06:53 -0400 (EDT) Subject: [secdir] secdir review of draft-ietf-v6ops-rogue-ra X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 05:07:07 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This expired doc has been in the secdir queue for some time. It's not clear what the current state is, but I gave it a once-over now and will look at it again if it's ever revived. While the security considerations sectional is minimal, that's generally fine for an informational doc such as this. That said, I would like to see more thought given to malicious RAs and whether each of these methods could be effectively applied against them (e.g. how easy is each to subvert?). And if none of the methods are applicable, as the current security considerations says, then also call that out in the abstract and intro. Second, I'm surprised that the only end-host based solutions are staticly-configured packet filters (3.7) and delays (3.9). Why not simply "try, try again": accept multiple RAs, see which ones work, and discard (or at least don't use) the rest? Lastly, the table in section 4 is a little unclear: does "Y" mean "helps (somewhat)" or "is completely sufficient"? I think it means the former, but clarity would be good. From weiler+secdir@watson.org Thu Jun 3 09:19:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB923A6934 for ; Thu, 3 Jun 2010 09:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e27QuEfT8itC for ; Thu, 3 Jun 2010 09:19:56 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 7DC5C3A6874 for ; Thu, 3 Jun 2010 09:19:56 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o53GJgmf056042 for ; Thu, 3 Jun 2010 12:19:42 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o53GJgrT056039 for ; Thu, 3 Jun 2010 12:19:42 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 3 Jun 2010 12:19:42 -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, 03 Jun 2010 12:19:42 -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: Thu, 03 Jun 2010 16:19:57 -0000 Sandy Murphy is next in the rotation. Several of the new assignments are already scheduled for the telechat on June 17th. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Please try to complete reviews by the end of IETF LC. For docs already on the telechat agenda, the LC usually ends before the telechat date. -- Sam For telechat 2010-06-17 Reviewer Deadline Draft Rob Austein T 2010-06-15 draft-ietf-bmwg-protection-term-08 Shawn Emery T 2010-06-15 draft-ietf-mboned-ipv4-uni-based-mcast-06 Stephen Farrell T 2010-06-15 draft-kucherawy-authres-header-b-01 Love Hornquist-Astrand T 2010-06-15 draft-ietf-ipsecme-eap-mutual-03 Barry Leiba T 2010-06-15 draft-ietf-dnsext-dns-tcp-requirements-03 Chris Lonvick T 2010-06-15 draft-ietf-hip-bone-06 David McGrew T 2010-06-15 draft-ietf-hip-hiccups-02 Catherine Meadows T 2010-06-15 draft-ietf-hip-via-01 Russ Mundy T 2010-06-15 draft-ietf-mpls-tp-data-plane-03 Last calls and special requests: Reviewer Deadline Draft Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 Alan DeKok 2010-05-12 draft-ietf-netconf-monitoring-14 Tobias Gondrom 2010-05-11 draft-ietf-tsvwg-dtls-for-sctp-05 Sam Hartman 2010-05-27 draft-ietf-avt-srtp-not-mandatory-05 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Charlie Kaufman 2010-06-15 draft-ietf-behave-address-format-08 Scott Kelly 2010-06-15 draft-ietf-behave-dns64-09 Stephen Kent 2010-06-15 draft-ietf-behave-v6v4-framework-09 Tero Kivinen 2010-06-15 draft-ietf-behave-v6v4-xlate-20 Julien Laganier 2010-06-15 draft-ietf-behave-v6v4-xlate-stateful-11 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows 2010-05-04 draft-ietf-tsvwg-dtls-for-sctp-05 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-05 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From william.polk@nist.gov Thu Jun 3 11:15:59 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F41928C0F7 for ; Thu, 3 Jun 2010 11:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.807 X-Spam-Level: X-Spam-Status: No, score=-4.807 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g3fOo1Pmpj9 for ; Thu, 3 Jun 2010 11:15:57 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 2AFD83A6899 for ; Thu, 3 Jun 2010 11:15:57 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o53IFTgE012912; Thu, 3 Jun 2010 14:15:29 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 3 Jun 2010 14:15:09 -0400 From: "Polk, William T." To: "secdir@ietf.org" Date: Thu, 3 Jun 2010 14:15:08 -0400 Thread-Topic: [secdir] Assignments Thread-Index: AcsDOLWkl22FqiEkTwuRQ2fCDt1MRQADlvqq Message-ID: References: In-Reply-To: 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" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 18:15:59 -0000 For the folks with documents on the next telechat, Sean and I would be especially grateful if the reviews could arrive by Friday June 11. Sean and I would like to try an experiment to better manage the document reviews. We intend to split up the standards track reviews, then confer to decide which documents need two reviewers. This requires us to start earlier, but should clear time just before the telechat. That would help us concentrate on getting our wg documents approved, which is to everyone's benefit! To best conduct this experiment, it would be really helpful if we could get the reviews Friday --- or at least by the start of business Monday. Thanks, Tim ________________________________________ From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of Samuel Weiler [weiler+secdir@watson.org] Sent: Thursday, June 03, 2010 12:19 PM To: secdir@ietf.org Subject: [secdir] Assignments Sandy Murphy is next in the rotation. Several of the new assignments are already scheduled for the telechat on June 17th. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Please try to complete reviews by the end of IETF LC. For docs already on the telechat agenda, the LC usually ends before the telechat date. -- Sam For telechat 2010-06-17 Reviewer Deadline Draft Rob Austein T 2010-06-15 draft-ietf-bmwg-protection-term-08 Shawn Emery T 2010-06-15 draft-ietf-mboned-ipv4-uni-based-mcast-06 Stephen Farrell T 2010-06-15 draft-kucherawy-authres-header-b-01 Love Hornquist-Astrand T 2010-06-15 draft-ietf-ipsecme-eap-mutual-03 Barry Leiba T 2010-06-15 draft-ietf-dnsext-dns-tcp-requirements-03 Chris Lonvick T 2010-06-15 draft-ietf-hip-bone-06 David McGrew T 2010-06-15 draft-ietf-hip-hiccups-02 Catherine Meadows T 2010-06-15 draft-ietf-hip-via-01 Russ Mundy T 2010-06-15 draft-ietf-mpls-tp-data-plane-03 Last calls and special requests: Reviewer Deadline Draft Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-05 Alan DeKok 2010-05-12 draft-ietf-netconf-monitoring-14 Tobias Gondrom 2010-05-11 draft-ietf-tsvwg-dtls-for-sctp-05 Sam Hartman 2010-05-27 draft-ietf-avt-srtp-not-mandatory-05 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Charlie Kaufman 2010-06-15 draft-ietf-behave-address-format-08 Scott Kelly 2010-06-15 draft-ietf-behave-dns64-09 Stephen Kent 2010-06-15 draft-ietf-behave-v6v4-framework-09 Tero Kivinen 2010-06-15 draft-ietf-behave-v6v4-xlate-20 Julien Laganier 2010-06-15 draft-ietf-behave-v6v4-xlate-stateful-11 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Catherine Meadows 2010-05-04 draft-ietf-tsvwg-dtls-for-sctp-05 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-05 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From catherine.meadows@nrl.navy.mil Thu Jun 3 13:34:19 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA42828C12C; Thu, 3 Jun 2010 13:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh5j-MMZTN3I; Thu, 3 Jun 2010 13:34:14 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 53F463A68B3; Thu, 3 Jun 2010 13:34:14 -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 o53KXrt4011436; Thu, 3 Jun 2010 16:33:53 -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 o53KXmx9022572; Thu, 3 Jun 2010 16:33:48 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010060316334817031 ; Thu, 03 Jun 2010 16:33:48 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-5-937510487 Date: Thu, 3 Jun 2010 16:37:33 -0400 Message-Id: <0F572519-857A-44A2-B676-85F58D3FF585@nrl.navy.mil> To: Gonzalo.Camarillo@ericsson.com, secdir@ietf.org, iesg@ietf.org, dward@juniper.net, Ari.Keranen@ericsson.com Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [secdir] review of draft-ietf-hip-via-01.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 20:34:19 -0000 --Apple-Mail-5-937510487 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 document concerns extensions to the Host Identity Protocol (HIP) to = provide multi-hop routing. The first is that a host sending a HIP packet can define a set of hosts = the packet should traverse. The other allows a HIP packet to carry and record the list of hosts that = forwarded it. The only security concern mentioned is the possibility of malicious = hosts creating forwarding loops. However, it appears to me that their are also the usual problems of = malicious hosts tampering with and spoofing packets. =20 It's not clear to me though why issues such as malicious hosts spoofing = or tampering with routing lists is not addressed, especially since HIP is a security protocol. = Are there features of HIP or other HIP documents where this is addressed? If so, they should be pointed to = here. If not, this should be pointed out, and if possible, other recommendations made. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-5-937510487 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 document concerns extensions = to the Host Identity Protocol (HIP) to provide multi-hop = routing.
The first is that a host sending a HIP packet can define a = set of hosts the packet should traverse.
The other allows a = HIP packet to carry and record the list of hosts that forwarded = it.

The only security concern mentioned is the = possibility of malicious hosts creating forwarding = loops.
However, it appears to me that their are also the usual = problems of malicious hosts tampering
with and spoofing = packets.  

It's not clear to me though why = issues such as malicious hosts spoofing or tampering with = routing
lists is not addressed, especially since HIP is a = security protocol.  Are there features of HIP or = other
HIP documents where this is addressed?  If so, they = should be pointed to here.  If not, this should be pointed = out,
and if possible, other recommendations = made.


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

= --Apple-Mail-5-937510487-- From barryleiba.mailing.lists@gmail.com Thu Jun 3 13:36:34 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0ACE28C0FB; Thu, 3 Jun 2010 13:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF3iedfXaU6b; Thu, 3 Jun 2010 13:36:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id EFC073A687B; Thu, 3 Jun 2010 13:36:31 -0700 (PDT) Received: by fxm6 with SMTP id 6so406880fxm.31 for ; Thu, 03 Jun 2010 13:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=nlH2k0WEr/cQCEIK/btN0JlWmF06tSeIVemiHVWTCWk=; b=aLa39Cs9WfsyEsaCozeH5ANKk9B01FJBvPeSjqkKRr4zgzDpRZKNLxpXYD7U17ffoG CpbxLZkVsEb2dOCh2UrzmGcH6EIJqyLhK3I47NGwcBjA6yDfE4/akQAxov2mJPCMlsz0 MdYj8iAfWXl1fH7ScOgNAxO5+/ssJyXYgDD9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=FE58T+NfL2XwZWyR7z6QNO2EwHkqtVe3oLDEumm5KR0ZB0U0RPUERqeGSdEDJy5r9y OADpLg8KtKKWT0kOBCPelx5t3Cy14bz5C2GccVUAxr0Bm4+EWTShMk23KtJj2D1AFfBW 1iMUNkGTkbbGwJX/qliLXfT4OiONHAOWC68pc= MIME-Version: 1.0 Received: by 10.223.20.218 with SMTP id g26mr10894580fab.18.1275597375785; Thu, 03 Jun 2010 13:36:15 -0700 (PDT) Received: by 10.223.122.141 with HTTP; Thu, 3 Jun 2010 13:36:15 -0700 (PDT) Date: Thu, 3 Jun 2010 16:36:15 -0400 Message-ID: From: Barry Leiba To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-dnsext-dns-tcp-requirements.all@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-dnsext-dns-tcp-requirements-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 20:36:34 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a good document, and I have no significant issues with it. It's ready to go. I have only one minor comment, in the Security Considerations section: At the time of writing the vast majority of TLD authority servers and all of the root name servers support TCP and the author knows of no evidence to suggest that TCP-based DoS attacks against existing DNS infrastructure are commonplace. Since this is a working group document, not an individual or independent submission, I'd rather see "and the dnsext working group knows of no evidence", to stress that the fact was reviewed by the working group, and the statement has working group consensus. This is, of course, assuming that that's truly the case -- if it is not, then I do have an issue with that. -- Barry Leiba From catherine.meadows@nrl.navy.mil Thu Jun 3 15:11:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37F93A68ED; Thu, 3 Jun 2010 15:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fas0XZMn4pc2; Thu, 3 Jun 2010 15:11:22 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id F215B28C122; Thu, 3 Jun 2010 15:11:21 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id o53MAvaA022308; Thu, 3 Jun 2010 18:10:57 -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 o53MAt3S026217; Thu, 3 Jun 2010 18:10:55 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010060318105417144 ; Thu, 03 Jun 2010 18:10:54 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-7-943336534 Date: Thu, 3 Jun 2010 18:14:39 -0400 Message-Id: <4C4B3C19-EC89-460B-A248-B90BBC5D5BB8@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, gorry@erg.abdn.ac.uk, tuexen@fh-muenster.de, seggelmann@fh-muenster.de, ekr@networkresonance.com Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [secdir] Review of draft-ietf-tsvwg-dtls-for-sctp-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: Thu, 03 Jun 2010 22:11:24 -0000 --Apple-Mail-7-943336534 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 document describes the usage of the Datagram Transport Layer = Security (DTLS) protocol over the Stream Control Transmission Protocol = (SCTP). Most of the document deals with the different DTLS features, that must, = must not, may, or should be used in this case. =20 I don't see any security issues other than the one the authors have = already noted, that is, that certain information is unavoidably sent in = the clear because it is in the header, and security decisions should not be made when = certificates based on IP-addresses are used, since SCTP associations use = multiple addresses per SCTP endpoint. Thus, I have no further comments to make. 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-7-943336534 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 document describes the usage of the = Datagram Transport Layer Security (DTLS) protocol over the Stream = Control Transmission Protocol (SCTP).
Most of the document = deals with the different DTLS features, that must, must not, may, or = should be used in this case.  

I don't see = any security issues other than the one the authors have already noted, = that is, that certain information is unavoidably sent in the clear = because
it is in the header, and security decisions should not = be made when certificates based on IP-addresses are used, since SCTP = associations use multiple addresses
per SCTP endpoint. =  Thus, I have no further comments to = make.



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-7-943336534-- From tjc@ecs.soton.ac.uk Thu Jun 3 05:31:52 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2660D28C13C; Thu, 3 Jun 2010 05:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SXiqPX53sTA; Thu, 3 Jun 2010 05:31:46 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 423EE28C0DF; Thu, 3 Jun 2010 05:30:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o53CUbWq024102; Thu, 3 Jun 2010 13:30:37 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o53CUbWq024102 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1275568238; bh=fV2KTTT1phNLKZJHM0G6nkdE3iQ=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=J2LOuX+1YGTOsLbKMpnB0QqS452F7x18n8Du1Y2mI39QMi291bDkT/OT1G3oMymnU pj9h1liYHwncgl/9H4Omr5a0Z2j7j7BxRoxeV/i/GU7cezIoeWInK6NuKak+Mzyrmz bf/9O2CgxHWjBqYbnCw+fFjqRSWRzXK14Xnm58Io= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id m52DUb0540005256aj ret-id none; Thu, 03 Jun 2010 13:30:38 +0100 Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o53CUXVx008362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jun 2010 13:30:33 +0100 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-ID: Content-Transfer-Encoding: quoted-printable From: Tim Chown Date: Thu, 3 Jun 2010 13:30:32 +0100 To: secdir-secretary@mit.edu X-Mailer: Apple Mail (2.1078) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=m52DUb054000525600; tid=m52DUb0540005256aj; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: o53CUbWq024102 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Fri, 04 Jun 2010 10:48:09 -0700 Cc: draft-ietf-v6ops-rogue-ra.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-rogue-ra X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 12:31:52 -0000 Hi, The document was originally being pushed through alongside Gunter's RA = guard draft, with the Rogue RA text as the problem statement and = Gunter's text as a/one solution. Both have been somewhere in the = upwards pipe towards publication for a year or so now, hence the expiry. = The RA guard draft was 'tickled' to keep it rom expiring, see = http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-05, so if Stig and = I need to do the same for our draft, please let us know. Regarding your comment on malicious attacks, that's a good observation, = but the text was steered away from that direction in previous updates = based on feedback from the WG (specifically the chart in Section 4 used = to have a 'Malicious RA' column, which was later removed), so personally = I'd rather not put that perspective back in the text and risk reopening = the (same) WG discussion. On your second point, yes, in theory, but you're pretty much stepping = into multihomed host solutions which are rather out of scope for this = draft. For genuine multiple RAs (or RAs with multiple prefixes) = there's also RFC3484 address selection. What our draft basically says = is that unintended RAs can cause 'badness', and here are some solutions = to them that enterprise administrators could apply.=20 On the third point, yes, your assumption is correct. We could make that = more explicit. It would be really great to get this text published, as it's been queued = for quite a while, and it gets cited quite frequently along with RA = Guard in various mailing list discussions. Tim On 3 Jun 2010, at 06:06, Samuel Weiler wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This expired doc has been in the secdir queue for some time. It's not = clear what the current state is, but I gave it a once-over now and will = look at it again if it's ever revived. >=20 > While the security considerations sectional is minimal, that's = generally fine for an informational doc such as this. >=20 > That said, I would like to see more thought given to malicious RAs and = whether each of these methods could be effectively applied against them = (e.g. how easy is each to subvert?). And if none of the methods are = applicable, as the current security considerations says, then also call = that out in the abstract and intro. >=20 > Second, I'm surprised that the only end-host based solutions are = staticly-configured packet filters (3.7) and delays (3.9). Why not = simply "try, try again": accept multiple RAs, see which ones work, and = discard (or at least don't use) the rest? >=20 > Lastly, the table in section 4 is a little unclear: does "Y" mean = "helps (somewhat)" or "is completely sufficient"? I think it means the = former, but clarity would be good. From Nicolas.Williams@oracle.com Fri Jun 4 12:09:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8418E3A698E; Fri, 4 Jun 2010 12:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.139 X-Spam-Level: X-Spam-Status: No, score=-5.139 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgIo-MjNgfgR; Fri, 4 Jun 2010 12:09:46 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2CC553A68A3; Fri, 4 Jun 2010 12:09:45 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o54J9Sv3030743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jun 2010 19:09:30 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o549UeWW024428; Fri, 4 Jun 2010 19:09:27 GMT Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 322942021275678560; Fri, 04 Jun 2010 12:09:20 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Jun 2010 12:09:20 -0700 Date: Fri, 4 Jun 2010 14:09:15 -0500 From: Nicolas Williams To: secdir-secretary@mit.edu Message-ID: <20100604190915.GU9605@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4C094F6A.01B4:SCFMA922111,ss=1,fgs=0 Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-hoffman-tls-additional-random-ext 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, 04 Jun 2010 19:09:47 -0000 On Thu, Jun 03, 2010 at 12:37:05AM -0400, Samuel Weiler wrote: > I don't have much to add to the discussion of this draft (and the > related draft-hoffman-tls-master-secret-input-01) that happened on > the IETF list already. > > At a first pass, I'm a fan of at least adding an applicability > statement; the current draft doesn't say much to implementors about > why they might or might not want to use this extension. And, > putting myself in those shoes, I think I'd find the existence of > this draft more confusing than helpful. > > And I observe quite a bit of opposition to publication of this doc > on the IETF list. Do the ADs need to see a summary of commentary on this (and the other, associated I-D, draft-hoffman-tls-master-secret-input)? Nico -- From jhutz@cmu.edu Tue Jun 8 12:48:10 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0EEE3A6823 for ; Tue, 8 Jun 2010 12:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS36wLjTSfkr for ; Tue, 8 Jun 2010 12:48:10 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 271383A67A7 for ; Tue, 8 Jun 2010 12:48:05 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o58JlpYK017514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2010 15:47:51 -0400 (EDT) Date: Tue, 08 Jun 2010 15:47:51 -0400 From: Jeffrey Hutzelman To: Marcia Beaulieu Message-ID: <144502BFBFBB72CCEE0F849E@minbar.fac.cs.cmu.edu> In-Reply-To: <75B29E8F-339F-4D60-969B-08068A185730@amsl.com> References: <75B29E8F-339F-4D60-969B-08068A185730@amsl.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: secdir@ietf.org, klensin@jck.com, Wanda Lo Subject: Re: [secdir] PGP Key Signgin X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:48:11 -0000 --On Tuesday, June 08, 2010 01:22:18 PM -0500 Marcia Beaulieu wrote: > Hi Jeff, > > Are you planning on holding the PGP Key Signing in Maastricht? If you > are, when do you want to hold it. We are going back to the regular > schedule which means Tuesday will end at 6:10pm since that is the night > the social will be held though we don't have the specifics on the social > event yet. At the 77th, the PGP Key Signing was held on Tuesday evening. Good question. When we discussed this last, we decided to go with Tuesday evening for IETF77, but talked about targeting Sunday after the reception for future meetings. Unfortunately, I don't think I'll be able to make it to Maastricht, or to Beijing. So, if we're going to have these sessions, we need someone else to run them(*). To that end, I'm copying John Klensin, who's been involved before, and the Security Directorate, in the hopes that someone there will be interested enough to volunteer. -- Jeff (*) I can, however, continue to collect the keyrings via email and publish them on the web, if that's useful. From weiler@watson.org Wed Jun 9 10:01:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF38A28C0F1; Wed, 9 Jun 2010 10:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_40=-0.185] 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 Vc+igKk2lzle; Wed, 9 Jun 2010 10:01:45 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 071FF3A69A9; Wed, 9 Jun 2010 10:01:44 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o59H1E3n097565; Wed, 9 Jun 2010 13:01:14 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o59H1Dgr097560; Wed, 9 Jun 2010 13:01:13 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 9 Jun 2010 13:01:13 -0400 (EDT) From: Samuel Weiler To: Tim Chown In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 09 Jun 2010 13:01:14 -0400 (EDT) Cc: draft-ietf-v6ops-rogue-ra.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-rogue-ra 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, 09 Jun 2010 17:01:46 -0000 Thanks for the explanation re: why the malicious RA text was removed. On Thu, 3 Jun 2010, Tim Chown wrote: [reordering text for ease of reading] >> Second, I'm surprised that the only end-host based solutions are >> staticly-configured packet filters (3.7) and delays (3.9). Why not >> simply "try, try again": accept multiple RAs, see which ones work, >> and discard (or at least don't use) the rest? > > On your second point, yes, in theory, but you're pretty much > stepping into multihomed host solutions which are rather out of > scope for this draft. For genuine multiple RAs (or RAs with > multiple prefixes) there's also RFC3484 address selection. What our > draft basically says is that unintended RAs can cause 'badness', and > here are some solutions to them that enterprise administrators could > apply. I'm not convinced that "test before use" is necessarily equivalent to multihoming. And the doc is already covering some host-based mitigations (in 3.7 and 3.9). Why discard this one? -- Sam From weiler+secdir@watson.org Wed Jun 9 11:16:37 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B633A67B4 for ; Wed, 9 Jun 2010 11:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GSGhZyFekcy for ; Wed, 9 Jun 2010 11:16:33 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A38CE28C112 for ; Wed, 9 Jun 2010 11:16:16 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o59IGH0G011806 for ; Wed, 9 Jun 2010 14:16:17 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o59IGH0u011801 for ; Wed, 9 Jun 2010 14:16:17 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 9 Jun 2010 14:16:17 -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, 09 Jun 2010 14:16:17 -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, 09 Jun 2010 18:16:37 -0000 Juergen Schoenwaelder is next in the rotation. Two of the new assignments are already scheduled for the telechat on July 1st. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The ADs would appreciate having reviews for the docs on telechat no later than this Friday. See Tim's note on Thursday, June 3rd for details. For other docs, please try to complete reviews by the end of IETF LC. -- Sam For telechat 2010-06-17 (please review by this Friday, June 11th) Rob Austein T 2010-06-15 draft-ietf-bmwg-protection-term-08 Alan DeKok T 2010-06-15 draft-ietf-enum-enumservices-transition-05 Alan DeKok T 2010-06-15 draft-ietf-netconf-monitoring-14 Shawn Emery T 2010-06-15 draft-ietf-mboned-ipv4-uni-based-mcast-06 Stephen Farrell T 2010-06-15 draft-kucherawy-authres-header-b-02 Love Hornquist-Astrand T 2010-06-15 draft-ietf-ipsecme-eap-mutual-03 Chris Lonvick T 2010-06-15 draft-ietf-hip-bone-06 David McGrew T 2010-06-15 draft-ietf-hip-hiccups-02 Russ Mundy T 2010-06-15 draft-ietf-mpls-tp-data-plane-03 Radia Perlman T 2010-06-15 draft-ietf-nsis-applicability-mobility-signaling-17 For telechat 2010-07-01 (please complete by Friday, June 25th or the end of IETF LC, whichever is sooner.) Sandy Murphy T 2010-06-29 draft-ietf-csi-proxy-send-04 Magnus Nystrom T 2010-06-29 draft-c1222-transport-over-ip-03 Last calls and special requests: Sam Hartman 2010-05-27 draft-ietf-avt-srtp-not-mandatory-05 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Charlie Kaufman 2010-06-15 draft-ietf-behave-address-format-08 Scott Kelly 2010-06-15 draft-ietf-behave-dns64-09 Stephen Kent 2010-06-15 draft-ietf-behave-v6v4-framework-09 Tero Kivinen 2010-06-15 draft-ietf-behave-v6v4-xlate-20 Julien Laganier 2010-06-15 draft-ietf-behave-v6v4-xlate-stateful-11 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Hilarie Orman 2010-06-22 draft-ietf-martini-reqs-07 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Vincent Roca 2010-06-21 draft-ietf-simple-msrp-sessmatch-06 Joe Salowey 2010-06-22 draft-ietf-sipcore-invfix-01 Stefan Santesson 2010-07-07 draft-ietf-proto-wgdocument-states-07 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-05 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From scott@hyperthought.com Wed Jun 9 11:28:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1769C3A680D for ; Wed, 9 Jun 2010 11:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnk9z388OlUO for ; Wed, 9 Jun 2010 11:28:57 -0700 (PDT) Received: from smtp242.iad.emailsrvr.com (smtp242.iad.emailsrvr.com [207.97.245.242]) by core3.amsl.com (Postfix) with ESMTP id 1284E3A6783 for ; Wed, 9 Jun 2010 11:28:57 -0700 (PDT) Received: from relay14.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay14.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 6A1E323A832; Wed, 9 Jun 2010 14:28:58 -0400 (EDT) Received: from dynamic4.wm-web.iad.mlsrvr.com (dynamic4.wm-web.iad.mlsrvr.com [192.168.2.153]) by relay14.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 5F7E923A811; Wed, 9 Jun 2010 14:28:58 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic4.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 3AF3A1D48073; Wed, 9 Jun 2010 14:28:58 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Wed, 9 Jun 2010 11:28:58 -0700 (PDT) Date: Wed, 9 Jun 2010 11:28:58 -0700 (PDT) From: scott@hyperthought.com To: "iesg@ietf.org" , secdir@ietf.org, draft-ietf-behave-dns64.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: <1276108138.248491@192.168.2.230> X-Mailer: webmail8 Subject: [secdir] secdir review of draft-ietf-behave-dns64-09 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, 09 Jun 2010 18:28:58 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 describes a DNS mechanism th= at is used with an IPv6/IPv4 translator to enable an IPv6-only client and I= Pv4-only server to communicate. The document is well-written, and the secur= ity considerations seem adequate. I see no issues with this document.=0A=0A= --Scott=0A From stephen.farrell@cs.tcd.ie Wed Jun 9 16:24:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA7B3A67B3 for ; Wed, 9 Jun 2010 16:24:41 -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_05=-1.11] 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 vhCYYLRw0+s1 for ; Wed, 9 Jun 2010 16:24:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id A1AB53A67A3 for ; Wed, 9 Jun 2010 16:24:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id F04DD3E408E; Thu, 10 Jun 2010 00:24:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1276125878; bh=34FsKdy+lh4UgyLc3vNyPPz4 ACQaQAEhF/GPC01wuOM=; b=dkjdrpfTDL2lP2fDCtbPVnOy5dbkX3V8FU7T/DYW YQavXa84EbJmmv+kzN0AKJpCjTFB2fMZnjFVYPSEUfHbZk7TYaGakd9VV4YH6uN0 Wu4//didkLgXsuREM1E2Iv/zs7sF2FvJDcjdErdFQwsL4s9UsJXxT1CcifVc4i5K QAK6AgC4eDxftbIml/CwBJ/nDBykJMiPJcOp7xpqWRs3twr6f+1ewKX5A2b+MMcc gmbnG0XdpHCgzeN57uru2/bhMpy3PaKN5OQr+R+8pFMqC/STb3QV7pBPOEO0kGZS PjWIofE8pzqTBhhyECsaM12rCrbuGfmQPGlMKzyoj4r5DQ== 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 J+eYKKI36bj8; Thu, 10 Jun 2010 00:24:38 +0100 (IST) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A6E183E408A; Thu, 10 Jun 2010 00:24:38 +0100 (IST) Message-ID: <4C1022B6.7000500@cs.tcd.ie> Date: Thu, 10 Jun 2010 00:24:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" , secdir@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-kucherawy-authres-header-b-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 23:24:41 -0000 Nice little document. (Which is much better than a nice big document:-) I see no substantive security issues here. Two nits below. I've no real problem if they're ignored. Stephen. 1. What if someone defines a MACing scheme for DKIM with a teensy-weensy MAC? There might be no way to get 8 characters then. Suggest allowing the full authenticator in that case if its <8 bytes long. Very unlikely but maybe worth a sentence. 2. Apppendix A says: "Presumably due to a change in one of the five header fields covered by the two signatures, the former signature failed to verify while the latter passed." I think that could only happen if they use different c14n, if so maybe say so. Or could be better to say the results may differ due for key mgmt reasons (e.g. an inaccessible public key) or because the signature values have been corrupted. Reason to prefer those is that they're more likely. (Or am I missing something?) From ari.keranen@ericsson.com Wed Jun 9 08:59:03 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DB928C10A; Wed, 9 Jun 2010 08:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2nll6++4z4r; Wed, 9 Jun 2010 08:59:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 493C73A698D; Wed, 9 Jun 2010 08:59:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-19-4c0fba45fe5a Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 63.91.29106.54ABF0C4; Wed, 9 Jun 2010 17:59:01 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 17:59:01 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 17:59:00 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A244124C0; Wed, 9 Jun 2010 18:59:00 +0300 (EEST) Message-ID: <4C0FBA44.2060506@ericsson.com> Date: Wed, 09 Jun 2010 18:59:00 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Catherine Meadows References: <0F572519-857A-44A2-B676-85F58D3FF585@nrl.navy.mil> In-Reply-To: <0F572519-857A-44A2-B676-85F58D3FF585@nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2010 15:59:00.0977 (UTC) FILETIME=[AD348E10:01CB07EC] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 10 Jun 2010 06:49:50 -0700 Cc: "iesg@ietf.org" , "dward@juniper.net" , Gonzalo Camarillo , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-hip-via-01.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 15:59:03 -0000 Hi Catherine, Thanks for the review and comments! Most of the usual attacks are taken care of by the standard HIP mechanisms (e.g., signatures, puzzles, and the ENCRYPTED parameter), but you're right that the Destination and Via lists could be tampered with in an attempt to do a (fairly low impact) DoS attack. I added text about this kind of attacks and recommendations on how to mitigate them to the security considerations section. A new version of the draft is available here: http://users.piuha.net/akeranen/drafts/draft-ietf-hip-via-02-pre1.txt (only the section 6 has changed) Comments are welcome. Cheers, Ari On 06/03/2010 11:37 PM, Catherine Meadows wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > > This document concerns extensions to the Host Identity Protocol (HIP) to > provide multi-hop routing. > The first is that a host sending a HIP packet can define a set of hosts > the packet should traverse. > The other allows a HIP packet to carry and record the list of hosts that > forwarded it. > > The only security concern mentioned is the possibility of malicious > hosts creating forwarding loops. > However, it appears to me that their are also the usual problems of > malicious hosts tampering > with and spoofing packets. > > It's not clear to me though why issues such as malicious hosts spoofing > or tampering with routing > lists is not addressed, especially since HIP is a security protocol. > Are there features of HIP or other > HIP documents where this is addressed? If so, they should be pointed to > here. If not, this should be pointed out, > and if possible, other recommendations made. > > > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil > > From msk@cloudmark.com Wed Jun 9 21:38:11 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A56E3A6985 for ; Wed, 9 Jun 2010 21:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWv8YIETl7A4 for ; Wed, 9 Jun 2010 21:38:10 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 89EB03A6898 for ; Wed, 9 Jun 2010 21:38:10 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 9 Jun 2010 21:38:12 -0700 From: "Murray S. Kucherawy" To: Stephen Farrell , "secdir@ietf.org" Date: Wed, 9 Jun 2010 21:38:11 -0700 Thread-Topic: secdir review of draft-kucherawy-authres-header-b-02 Thread-Index: AcsIKvCxJ08bWbICRvSc+liNi1UsfQAK2LmA Message-ID: References: <4C1022B6.7000500@cs.tcd.ie> In-Reply-To: <4C1022B6.7000500@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 10 Jun 2010 06:49:50 -0700 Subject: Re: [secdir] secdir review of draft-kucherawy-authres-header-b-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 04:38:11 -0000 Hi Stephen, thanks for the review! > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, June 09, 2010 4:25 PM > To: Murray S. Kucherawy; secdir@ietf.org > Subject: secdir review of draft-kucherawy-authres-header-b-02 >=20 > 1. What if someone defines a MACing scheme for DKIM with > a teensy-weensy MAC? There might be no way to get 8 > characters then. Suggest allowing the full authenticator > in that case if its <8 bytes long. Very unlikely but > maybe worth a sentence. I had that in originally, but a LC reviewer suggested it be removed on the = grounds that such a signature method is collision-prone, and thus this spec= should try not to support it. Instead, I think I'll add it back in with a= new subsection in Security Considerations making this concern clear and re= minding consumers that collisions must be ignored. > 2. Apppendix A says: >=20 > "Presumably due to a change in one of the five header fields covered > by the two signatures, the former signature failed to verify while > the latter passed." >=20 > I think that could only happen if they use different c14n, if > so maybe say so. Or could be better to say the results may > differ due for key mgmt reasons (e.g. an inaccessible public key) > or because the signature values have been corrupted. Reason to > prefer those is that they're more likely. (Or am I missing > something?) An inaccessible key produces a result of "neutral" or "temperror" (I forget= which) so a "fail" would only be the former case of one c14n surviving whi= le the other didn't. I'll add a little more explanatory text to point that= out. Cheers, -MSK From tjc@ecs.soton.ac.uk Thu Jun 10 06:12:08 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6001628C0E2; Thu, 10 Jun 2010 06:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 cdo6jE7SFc-N; Thu, 10 Jun 2010 06:12:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 7B5F728C0E8; Thu, 10 Jun 2010 06:12:05 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o5ADBw9k012507; Thu, 10 Jun 2010 14:11:58 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o5ADBw9k012507 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1276175519; bh=tp64VpENGa/zVz/UEpx6FDC96j4=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=WUd1f+wTo2bjR6c3Lmu+MlM5SWWvhlzvCqIE6PU/NSpEKFWoZqiJUPfCV6BAOCCVC iuJvhSAbMs6w2guAnUFWmGauZniXb1nj7c2ytdnqg0Sv2ivcn3QtQhEXXvJoXsawcY 9690slGS5ryAXoF66O6dgSF1dHF+3OUA4ymaPm5Y= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id m59EBw0540048079bQ ret-id none; Thu, 10 Jun 2010 14:11:59 +0100 Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o5ADBsuS008577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jun 2010 14:11:55 +0100 References: <1F7AAE6F-B3FC-4198-A9DD-C82E6B4F65C2@ecs.soton.ac.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-ID: Content-Transfer-Encoding: quoted-printable From: Tim Chown Date: Thu, 10 Jun 2010 14:11:54 +0100 To: secdir-secretary@mit.edu X-Mailer: Apple Mail (2.1078) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=m59EBw054004807900; tid=m59EBw0540048079bQ; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: o5ADBw9k012507 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Thu, 10 Jun 2010 06:49:50 -0700 Cc: draft-ietf-v6ops-rogue-ra.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-rogue-ra X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:12:08 -0000 On 9 Jun 2010, at 18:01, Samuel Weiler wrote: > Thanks for the explanation re: why the malicious RA text was removed. >=20 > On Thu, 3 Jun 2010, Tim Chown wrote: >=20 > [reordering text for ease of reading] >=20 >>> Second, I'm surprised that the only end-host based solutions are = staticly-configured packet filters (3.7) and delays (3.9). Why not = simply "try, try again": accept multiple RAs, see which ones work, and = discard (or at least don't use) the rest? >>=20 >> On your second point, yes, in theory, but you're pretty much stepping = into multihomed host solutions which are rather out of scope for this = draft. For genuine multiple RAs (or RAs with multiple prefixes) there's = also RFC3484 address selection. What our draft basically says is that = unintended RAs can cause 'badness', and here are some solutions to them = that enterprise administrators could apply. >=20 > I'm not convinced that "test before use" is necessarily equivalent to = multihoming. And the doc is already covering some host-based = mitigations (in 3.7 and 3.9). Why discard this one? Fair point Sam. I think 3.9 (wait before use) was a suggestion from = one IETF WG meeting, which really isn't that practical, so could = actually be quite reasonably dropped. The original aim of the draft = was to cite practical steps an administrator could take, but 3.2 (RA = snooping/RA Guard), 3.4 (use SeND) and 3.11 (add options to DHCPv6) are = all methods that are also, as yet, not available. So we could add your = suggestion. One consideration in 'test before use' though is that connectivity might = work, from a user/application perspective, but it might not work as = intended or with undesirable consequences/side effects, e.g. via an = unintended VLAN or router. Tim From clonvick@cisco.com Thu Jun 10 19:22:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD903A6844; Thu, 10 Jun 2010 19:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.645 X-Spam-Level: X-Spam-Status: No, score=-8.645 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GRRnu2w1qyg; Thu, 10 Jun 2010 19:22:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6CB5C3A682D; Thu, 10 Jun 2010 19:22:35 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFADg6EUyrR7Ht/2dsb2JhbACSaQGMDnGkT5oLhRgEg0s X-IronPort-AV: E=Sophos;i="4.53,401,1272844800"; d="scan'208";a="210596193" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 11 Jun 2010 02:22:37 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5B2Mb79004249; Fri, 11 Jun 2010 02:22:37 GMT Date: Thu, 10 Jun 2010 19:22:37 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-hip-bone.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] secdir review of draft-ietf-hip-bone 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, 11 Jun 2010 02:22:36 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I have not been keeping up with the discussions of this working group. I read through this document and skimmed through RFC-5201. I remain confused on a couple of topics. If they are explained somewhere, please just give me a general pointer and don't bother explaining to me (as I will likely continue to not keep up with this WG. :-) - Obviously a host can join two HIP instantitions. What happens when the overlay identifiers conflict? Must the overlay identifiers be globally unique or can they have local context? - When a host joins a HIP instantiation, is this exclusive? Can a host that has joined a HIP instantiation continue to directly communicate with IPv4 and IPv6 hosts or must it communicate through a gateway? Here I'm thinking of a device that fires up IPsec - in my experience the policy is to encrypt all traffic to the gateway and then let the gateway forward traffic. Is this what is envisioned for a client joining a HIP instatiation? The only real security concern I have in the document is in section 6.1, where you RECOMMEND 32 bits of randomness be used in the OVERLAY_ID parameter. I don't understand why this is recommended or what purpose it may have. What I'm saying is that even if you have 2 HIP BONE instances throughout the Internet, there is a non-zero chance that the OVERLAY_ID parameters will be identical unless people intervene and choose the values. The chances increase with more instances regardless of how many bits of randomness you may recommend - reference the "birthday attack". I'd suggest that you drop the recommendation for randomness and just recommend that people attempt to prevent a collision via any means possible. Continuing to recommend some amount of randomness would give people a false sense that a collision may not occur. Some nits from the document: In Section 2 two things: CURRENT: Node ID: A value that uniquely identifies a node in an overlay network. The value is not usually human-friendly, but for example a hash of a public key. PERHAPS SHOULD BE: Node ID: A value that uniquely identifies a node in an overlay network. The value is not usually human-friendly. As an example it may be a hash of a public key. CURRENT: Valid locator: A Locator (as defined in [RFC5206]; usually an IP address or an address and a port number) that a host is known to be reachable at, for example, because there is an active HIP association with the host. PERHAPS SHOULD BE: Valid locator: A Locator (as defined in [RFC5206]; usually an IP address, or an address and a port number) that a host is known to be reachable at because there is an active HIP association with the host. >From that, what is a "HIP association"? Perhaps you mean to say that the host is part of a HIP overlay network? Just fyi, "HIP association" is used elsewhere in the text and in RFC-5201. If it's important then you may want to define it here as well. Regards, Chris From aland@deployingradius.com Fri Jun 11 00:52:34 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C0D3A6888; Fri, 11 Jun 2010 00:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.578 X-Spam-Level: X-Spam-Status: No, score=0.578 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_40=-0.185] 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 MHqHWNUSZuKN; Fri, 11 Jun 2010 00:52:33 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id B0B9C3A67A7; Fri, 11 Jun 2010 00:52:33 -0700 (PDT) Message-ID: <4C11EB43.7040003@deployingradius.com> Date: Fri, 11 Jun 2010 09:52:35 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org, IESG IESG , draft-ietf-enum-enumservices-transition@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-enum-enumservices-transition 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, 11 Jun 2010 07:52:34 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines XML service registrations for enumservices. There appear to be no security considerations with the document. From aland@deployingradius.com Fri Jun 11 01:00:42 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3AF3A69DD; Fri, 11 Jun 2010 01:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqbyaJ00XdbM; Fri, 11 Jun 2010 01:00:41 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 404CB3A69D5; Fri, 11 Jun 2010 01:00:41 -0700 (PDT) Message-ID: <4C11ED2B.1070707@deployingradius.com> Date: Fri, 11 Jun 2010 10:00:43 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org, IESG IESG , draft-ietf-netconf-monitoring@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-netconf-monitoring 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, 11 Jun 2010 08:00:42 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a data model for netconf monitoring. The security considerations section says in part: Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g. via get, get-config or notification) to these data nodes. What is unclear from the document is whether or not the data is secure *after* access is gained. i.e. is there a secure transport layer? Should one be used? If not, why? A statement about privacy and security, with a reference to an existing netconf document would be good. From j.schoenwaelder@jacobs-university.de Fri Jun 11 01:10:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6966C3A68E0; Fri, 11 Jun 2010 01:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.384 X-Spam-Level: X-Spam-Status: No, score=0.384 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWDycLXR-ett; Fri, 11 Jun 2010 01:10:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D47E23A68F0; Fri, 11 Jun 2010 01:10:12 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26D1FC0016; Fri, 11 Jun 2010 10:10:11 +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 phpEH8gtXIOu; Fri, 11 Jun 2010 10:10:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A7BCC0032; Fri, 11 Jun 2010 10:09:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3881512F9717; Fri, 11 Jun 2010 10:09:56 +0200 (CEST) Date: Fri, 11 Jun 2010 10:09:56 +0200 From: Juergen Schoenwaelder To: Alan DeKok Message-ID: <20100611080956.GA5257@elstar.local> Mail-Followup-To: Alan DeKok , "secdir@ietf.org" , IESG IESG , "draft-ietf-netconf-monitoring@tools.ietf.org" References: <4C11ED2B.1070707@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C11ED2B.1070707@deployingradius.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "draft-ietf-netconf-monitoring@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring 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: Fri, 11 Jun 2010 08:10:14 -0000 On Fri, Jun 11, 2010 at 10:00:43AM +0200, Alan DeKok wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document defines a data model for netconf monitoring. The security > considerations section says in part: > > Some of the readable data nodes in this YANG module may be > considered sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get, > get-config or notification) to these data nodes. > > What is unclear from the document is whether or not the data is secure > *after* access is gained. i.e. is there a secure transport layer? > Should one be used? If not, why? NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In other words, all existing NETCONF transports are "secure". The revision of the NETCONF specification being worked on is going to make this hopefully clearer by calling the transport layer "secure transports". There has been progress very recently on formulating a security considerations template for documents that contain NETCONF/YANG data models and I think it would be good if this document would indeed follow these guidelines. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From aland@deployingradius.com Fri Jun 11 01:30:31 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE593A68F1; Fri, 11 Jun 2010 01:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_05=-1.11] 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 kFz5zmabKUjn; Fri, 11 Jun 2010 01:30:30 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 8C4513A68B5; Fri, 11 Jun 2010 01:30:30 -0700 (PDT) Message-ID: <4C11F428.4030403@deployingradius.com> Date: Fri, 11 Jun 2010 10:30:32 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Martin Bjorklund References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> <20100611.101949.192441308.mbj@tail-f.com> In-Reply-To: <20100611.101949.192441308.mbj@tail-f.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-netconf-monitoring@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring 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, 11 Jun 2010 08:30:31 -0000 Martin Bjorklund wrote: >> NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. I saw that. > In other >> words, all existing NETCONF transports are "secure". The revision of >> the NETCONF specification being worked on is going to make this >> hopefully clearer by calling the transport layer "secure transports". OK. > Actually, this document follows the latest security considerations > template. > > However, the template does not mention that NETCONF runs over a secure > transport. Maybe the template (and this document) should be updated > to make this clear? That would be good. I saw the discussion on the template in the list archives, and was surprised that it mentioned only access to data, and not security or privacy. Alan DeKok. From j.schoenwaelder@jacobs-university.de Fri Jun 11 01:55:10 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921EE3A69D6; Fri, 11 Jun 2010 01:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.381 X-Spam-Level: X-Spam-Status: No, score=0.381 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbOBkzfv7SZz; Fri, 11 Jun 2010 01:55:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4B74C3A68F8; Fri, 11 Jun 2010 01:55:08 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 672A7C001E; Fri, 11 Jun 2010 10:55:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5TjdbO0TUae6; Fri, 11 Jun 2010 10:55:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33F62C0016; Fri, 11 Jun 2010 10:55:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7E0F612F9B4B; Fri, 11 Jun 2010 10:55:06 +0200 (CEST) Date: Fri, 11 Jun 2010 10:55:06 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100611085506.GE5257@elstar.local> Mail-Followup-To: Martin Bjorklund , "aland@deployingradius.com" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-netconf-monitoring@tools.ietf.org" , Bert Wijnen References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> <20100611.101949.192441308.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100611.101949.192441308.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "draft-ietf-netconf-monitoring@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , Bert Wijnen Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring 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: Fri, 11 Jun 2010 08:55:10 -0000 On Fri, Jun 11, 2010 at 10:19:49AM +0200, Martin Bjorklund wrote: > Actually, this document follows the latest security considerations > template. I guess I have to dig out the latest guidelines now... OK, I stand corrected - the template is indeed pretty short for a read-only module. > However, the template does not mention that NETCONF runs over a secure > transport. Maybe the template (and this document) should be updated > to make this clear? Yes, it seems some introductionary text in the security considerations about NETCONF might be useful, especially since not all people are familiar with NETCONF yet. Here is a first draft: The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742]. I am CCing Bert Wijnen since he drove the development of the security considerations template. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kivinen@iki.fi Fri Jun 11 05:05:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065E23A6817; Fri, 11 Jun 2010 05:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yws1F4af4Hji; Fri, 11 Jun 2010 05:05:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F2A933A68C6; Fri, 11 Jun 2010 05:05:55 -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 o5BC5rq8013386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 15:05:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o5BC5qmo003388; Fri, 11 Jun 2010 15:05:52 +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: <19474.9888.922292.408395@fireball.kivinen.iki.fi> Date: Fri, 11 Jun 2010 15:05:52 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 22 min X-Total-Time: 32 min Cc: draft-ietf-behave-v6v4-xlate.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-behave-v6v4-xlate-20 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, 11 Jun 2010 12:05:58 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the translation algorithm between ipv6 and ipv4. The security considerations section say: The use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols and in the routing protocols that are used to make the packets reach the translator. There are potential issues that might arise by deriving an IPv4 address from an IPv6 address - particularly addresses like broadcast or loopback addresses and the non IPv4-translatable IPv6 addresses, etc. The [I-D.ietf-behave-address-format] addresses these issues. This text is fine but the next paragraph describing the AH is bit misleading: As the Authentication Header [RFC4302] is specified to include the IPv4 Identification field and the translating function is not able to always preserve the Identification field, it is not possible for an IPv6 endpoint to verify the AH on received packets that have been translated from IPv4 packets. Thus AH does not work through a translator. The Authentication Header includes also the addresses etc in the ICV thus it is not only the IPv4 Identification field that causes problems also the changing the IPv4 address to IPv6 addresses and vice versa, changing the IP version field, payload length etc makes AH incompatible with this translation. If the text was supposed to say that some implementation which knows both AH and this translation could be made to know that this packet has gone through this translation and could then check the ICV by reversing the translation before checking the ICV, then this text should more clearly say that. I.e instead of saying that endpoing cannot verify AH and that AH does not work (standard AH as defined in RFC4302 will always fail the verification), it should be said that it is not possible to make specification which specifies how AH should be modified to understand this translation and even then it would be impossible to completely reverse translation as some information (like parts of the Identification field) is not available. I also think that in addition to the Identification field the translation is loosing information about the IP extensions. The last paragraph of security considerations section talks about ESP: Packets with ESP can be translated since ESP does not depend on header fields prior to the ESP header. Note that ESP transport mode is easier to handle than ESP tunnel mode; in order to use ESP tunnel mode, the IPv6 node MUST be able to generate an inner IPv4 header when transmitting packets and remove such an IPv4 header when receiving packets. Even with ESP there is complications, as in transport mode the transport layer protocols inside the ESP do contain checksums which cannot be modified by the translator, thus they will keep the original IP addresses in there, and if the translation is not checksum neutral then end node will throw away the packet after ESP processing as the transport layer checksums are incorrect. For tunnel mode the transport layer protocol checksums contains the inner IP header thus they are ok. Actually for ESP the situation is even more different, as the IPsec will detect this kind of translation as NAT along the path, and will enable NAT-Traversal, meaning ESP packets will get UDP encapsulated, and the IPsec itself will do the checksum fixup as specified in the RFC3847. On the other hand I do not know how many existing implementations know how to handle checksum fixup when changing from IPv4 address to IPv6 address or other way around, altough some of them do full checksum recalculation (or simply skip the transport layer checksum checking) anyways so they might work. -- kivinen@iki.fi From bertietf@bwijnen.net Fri Jun 11 07:59:55 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84333A6921; Fri, 11 Jun 2010 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.157 X-Spam-Level: ** X-Spam-Status: No, score=2.157 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETYBODfuKbl3; Fri, 11 Jun 2010 07:59:54 -0700 (PDT) Received: from relay.versatel.net (relay60.tele2.vuurwerk.nl [62.250.3.60]) by core3.amsl.com (Postfix) with ESMTP id 8DA073A6918; Fri, 11 Jun 2010 07:59:53 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1ON5i4-0002rc-VK; Fri, 11 Jun 2010 16:59:53 +0200 Message-ID: <211423AAAF024289A47B1713400BD4A3@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Juergen Schoenwaelder" , "Martin Bjorklund" References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> <20100611.101949.192441308.mbj@tail-f.com> <20100611085506.GE5257@elstar.local> In-Reply-To: <20100611085506.GE5257@elstar.local> Date: Fri, 11 Jun 2010 16:49:50 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , draft-ietf-netconf-monitoring@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring 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, 11 Jun 2010 14:59:55 -0000 Juergen, I will add your text to the template. I am assuming that Dan will check this further with the securioty ADs. The status (as far as I know) is that the security ADs are/were evaluating our latest template (modulo one typio and your new text). Bert ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Martin Bjorklund" Cc: ; ; ; ; "Bert Wijnen" Sent: Friday, June 11, 2010 10:55 AM Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring On Fri, Jun 11, 2010 at 10:19:49AM +0200, Martin Bjorklund wrote: > Actually, this document follows the latest security considerations > template. I guess I have to dig out the latest guidelines now... OK, I stand corrected - the template is indeed pretty short for a read-only module. > However, the template does not mention that NETCONF runs over a secure > transport. Maybe the template (and this document) should be updated > to make this clear? Yes, it seems some introductionary text in the security considerations about NETCONF might be useful, especially since not all people are familiar with NETCONF yet. Here is a first draft: The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742]. I am CCing Bert Wijnen since he drove the development of the security considerations template. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From weiler@watson.org Fri Jun 11 15:07:30 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDB93A67EE for ; Fri, 11 Jun 2010 15:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ystNHSVdUQsz for ; Fri, 11 Jun 2010 15:07:29 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 41F723A659A for ; Fri, 11 Jun 2010 15:07:29 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o5BM7UOo005599 for ; Fri, 11 Jun 2010 18:07:30 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o5BM7U3h005595 for ; Fri, 11 Jun 2010 18:07:30 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 11 Jun 2010 18:07:30 -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, 11 Jun 2010 18:07:30 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 22:07:30 -0000 Yes, I just sent assignments on Wednesday. Enough's changed to make an update seem reasonable. I'm next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The ADs would appreciate having reviews for the docs on next week's telechat no later than TODAY. See Tim's note on Thursday, June 3rd for details. For other docs, please try to complete reviews by the end of IETF LC. -- Sam For telechat 2010-06-17 Rob Austein T 2010-06-15 draft-ietf-bmwg-protection-term-08 Shawn Emery T 2010-06-15 draft-ietf-mboned-ipv4-uni-based-mcast-06 Love Hornquist-Astrand T 2010-06-15 draft-ietf-ipsecme-eap-mutual-03 Chris Lonvick T 2010-06-15 draft-ietf-hip-bone-06 David McGrew T 2010-06-15 draft-ietf-hip-hiccups-02 Russ Mundy T 2010-06-15 draft-ietf-mpls-tp-data-plane-03 Radia Perlman T 2010-06-15 draft-ietf-nsis-applicability-mobility-signaling-17 For telechat 2010-07-01 Sandy Murphy T 2010-06-29 draft-ietf-csi-proxy-send-04 Magnus Nystrom T 2010-06-29 draft-c1222-transport-over-ip-03 Vincent Roca T 2010-06-29 draft-ietf-6man-dns-options-bis-03 Yaron Sheffer T 2010-06-29 draft-ietf-nsis-tunnel-11 Last calls and special requests: Richard Barnes 2010-06-21 draft-ietf-simple-msrp-sessmatch-06 Sam Hartman 2010-05-27 draft-ietf-avt-srtp-not-mandatory-05 Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Charlie Kaufman 2010-06-15 draft-ietf-behave-address-format-08 Stephen Kent 2010-06-15 draft-ietf-behave-v6v4-framework-09 Julien Laganier 2010-06-15 draft-ietf-behave-v6v4-xlate-stateful-11 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Hilarie Orman 2010-06-22 draft-ietf-martini-reqs-07 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Joe Salowey 2010-06-22 draft-ietf-sipcore-invfix-01 Stefan Santesson 2010-07-07 draft-ietf-proto-wgdocument-states-07 Juergen Schoenwaelder 2010-06-24 draft-ietf-ipsecme-ipsec-ha-06 Tina TSOU 2010-07-09 draft-mcgrew-fundamental-ecc-03 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-05 Carl Wallace 2010-07-09 draft-stone-mgcp-vbd-07 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-05 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From sra@hactrn.net Fri Jun 11 21:21:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84F33A6867; Fri, 11 Jun 2010 21:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.007 X-Spam-Level: *** X-Spam-Status: No, score=3.007 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172] 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 DhixchG1pl7h; Fri, 11 Jun 2010 21:21:16 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 99B773A67FB; Fri, 11 Jun 2010 21:21:16 -0700 (PDT) Received: from nargothrond.hactrn.net (h-64-105-143-250.snvacaid.static.covad.net [64.105.143.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by cyteen.hactrn.net (Postfix) with ESMTPS id 25BB92844E; Sat, 12 Jun 2010 04:21:16 +0000 (UTC) Received: from nargothrond.hactrn.net (localhost [IPv6:::1]) by nargothrond.hactrn.net (Postfix) with ESMTP id 3616FF750B; Fri, 11 Jun 2010 18:03:55 -0400 (EDT) Date: Fri, 11 Jun 2010 18:03:55 -0400 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org, draft-ietf-bmwg-protection-term.all@tools.ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100611220355.3616FF750B@nargothrond.hactrn.net> Subject: [secdir] Review of draft-ietf-bmwg-protection-term-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 04:21:18 -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 is entirely about terminology and test methodology (primarily the former) for benchmarking of sub-IP layer mechanisms in a laboratory environment not connected to the Internet or any other production network. The draft's intended status is Informational. I have no security concerns regarding this document. From shawn.emery@oracle.com Sat Jun 12 00:28:06 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D303A68EA; Sat, 12 Jun 2010 00:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8n-dOT-RiaL; Sat, 12 Jun 2010 00:28:04 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5799F3A68E6; Sat, 12 Jun 2010 00:27:58 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5C7Rvp6003311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jun 2010 07:27:59 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5BDcane016323; Sat, 12 Jun 2010 07:27:56 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 340907591276327554; Sat, 12 Jun 2010 00:25:54 -0700 Received: from [129.150.48.15] (/129.150.48.15) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Jun 2010 00:25:54 -0700 Message-ID: <4C133681.3060908@oracle.com> Date: Sat, 12 Jun 2010 01:25:53 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4C133700.0142:SCFMA922111,ss=1,fgs=0 Cc: draft-ietf-mboned-ipv4-uni-based-mcast.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-mboned-ipv4-uni-based-mcast-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 07:28:06 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes a mechanism for mapping an organization's unicast to multicast address in IPv4. The security considerations section does exist and (as also stated in RFC 3180) the dynamic means for constructing multicast addressing using this scheme reduces DoS attacks for allocations from outside the organization. Which I agree with. General comments: None. Editorial comments: None. Shawn. -- From charliek@microsoft.com Sun Jun 13 00:07:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29BB3A68B2; Sun, 13 Jun 2010 00:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYU-U2R8wtCN; Sun, 13 Jun 2010 00:07:12 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E7DD53A68B0; Sun, 13 Jun 2010 00:07:11 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 13 Jun 2010 00:07:15 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.58]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0160.007; Sun, 13 Jun 2010 00:07:16 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-behave-address-format.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-behave-address-format-08.txt Thread-Index: AcsKxwuZ3ScanT4WQ7eYfl1Y0uvxEg== Date: Sun, 13 Jun 2010 07:07:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-behave-address-format-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 07:07:12 -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. This document discusses formats and algorithms around dealing with the tran= slation of IPv4 addresses to IPv6 addresses and vice versa. Such translatio= n is necessary when two endpoints and the network between them do not all s= upport a single version of IP. I found the document quite comprehensible, its decisions well considered, a= nd I have only minor comments. Security Related: Section 5 discusses two threats related to routers that handle IPv6 address= es that embed IPv4 addresses. I believe an important third attack in the sa= me category is where firewalls filter traffic based on IPv4 addresses. In a= ll such scenarios, admins should assure that packets that embed those IPv4 = addresses inside IPv6 addresses perform the same filtering on the IPv6 addr= esses. Otherwise, lots of traffic that was previously blocked might be able= to pass through the firewalls disguised as IPv6 packets. Section 3.1 says that the Well-Known Prefix MUST NOT be used to represent n= on global IPv4 addresses, such as those defined in [RFC1918]. First, especi= ally given that this is a MUST, there should be an explicit list of forbidd= en IPv4 addresses rather than a vague reference to RFC1918. Second, the tex= t should probably explicitly say that any translator that extracts an IPv4 = address from an IPv6 address MUST check the IPv4 address against the forbid= den list and drop the packet if it has such a forbidden address. Otherwise,= the text could be interpreted as only forbidding encapsulation. In most at= tacks, the attacker does the encapsulation and the good guy does the decaps= ulation, so forbidding encapsulation doesn't help. The last sentence of section 2.2 says "These bits are reserved for future e= xtensions and SHOULD be set to zero." In any spec where it says that some b= its SHOULD or MUST be set to zero, there should be corresponding text sayin= g what an implementation SHOULD or MUST do if it receives data containing n= on-zero values. In this case, I couldn't tell whether the intended action w= as to ignore the non-zero bits or to drop the packet. The bits will be much= more useful for future uses if we have confidence about how existing imple= mentations handle them. Typos: P5 middle: "prefic" -> "prefix" P9 middle: "return them message in" -> "return them in" From yaronf.ietf@gmail.com Sun Jun 13 00:58:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8970A3A68B2; Sun, 13 Jun 2010 00:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCpxVoo-KC9s; Sun, 13 Jun 2010 00:58:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id AA9593A6452; Sun, 13 Jun 2010 00:58:45 -0700 (PDT) Received: by wyi11 with SMTP id 11so1869342wyi.31 for ; Sun, 13 Jun 2010 00:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=z4fC6wcCWK2qZ4QMKWk/6PcBWAL2Q5OBl4/Ix+muQYs=; b=UlPIAYvpTt6RTKsoRUJ+yH00Fv1bje4rdu/nHuB255tzHl+LYHGFwuwnWch1CBbx/W DkQb3YgUq8GhLE+gZD7Q9cZeL7dvmccRVPGO+ch2D9yHFnQBlDP5GJ5UQxfPfjZuoZHM scIxQ6vF/t+hdvVjJfkAg5snHMQHYULDoSw9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=PrTxvR/Pnhf3NeW9ob5cj9NhB9DbsrG9LtNeI7Z15QGc4FMMPY03lbkwb4AZmU3QE2 hwnWkIY1swWD5MzIRSrj4d0fkq3OW9flYhEpO+QtYttSV320ZGWzVHzlhpXGTo66FCJr Qt0qGZ03vw9GbI0d6QRwOeqErmPePqOZcD+d4= Received: by 10.227.155.71 with SMTP id r7mr4126501wbw.102.1276415925446; Sun, 13 Jun 2010 00:58:45 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-178-30-177.red.bezeqint.net [79.178.30.177]) by mx.google.com with ESMTPS id y31sm25666643wby.16.2010.06.13.00.58.43 (version=SSLv3 cipher=RC4-MD5); Sun, 13 Jun 2010 00:58:44 -0700 (PDT) Message-ID: <4C148FB1.8060709@gmail.com> Date: Sun, 13 Jun 2010 10:58:41 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-nsis-tunnel.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-nsis-tunnel-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 07:58:47 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft discusses the problem of NSIS messages (particularly, QoS reservation flows) being encapsulated into various IP tunneling protocols, which prevent the correct QoS setup from being performed. The draft proposes a solution for NSIS tunnel-aware tunnel endpoints, which basically adds an NSIS signaling flow between the tunnel endpoints, but outside of the tunnel. General The draft presents the problem, and the solution, reasonably well. The draft goes for the "no new security issues" approach. I think this is incorrect, and in fact a number of security issues should be analyzed and possibly resolved. In addition, as a complete outsider to NSIS, I have identified one major unspecified piece, leading me to believe that the draft has not had enough review. Security The main security issue is that the draft fails to consider security-oriented tunnels. IPsec tunnels (and the commonly used GRE-over-IPsec) provide security services: normally encryption and integrity protection with ESP, less commonly integrity-protection only with AH, ESP with null encryption, or the new WESP (RFC 5840). The proposed solution raises at least three major security issues related to these tunnels: 1. A so-called covert channel that results from NSIS flows in the protected networks directly triggering NSIS protocol exchanges in an unprotected network (i.e. between the tunnel endpoints). Please see Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue. 2. A more serious interaction in the other direction: unprotected NSIS flows outside the tunnel interact with NSIS flows in the protected networks and inside the tunnel, and so, an attacker in the unprotected network can possibly influence QoS behavior in protected networks. 3. A practical result of (2) is that the NSIS protocol stack on the tunnel endpoint is now exposed to unprotected networks and therefore suddenly becomes security-critical. Non-Security The draft defines extra UDP encapsulation in some cases ("the tunnel entry-point inserts an additional UDP header"), but the format (specifically, the port number) is not specified. This omission is strange, because the protocol cannot be implemented in the absence of this information! From kent@bbn.com Sun Jun 13 06:32:05 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7973A68F2 for ; Sun, 13 Jun 2010 06:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xScqgL2JdsGx for ; Sun, 13 Jun 2010 06:32:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 95F893A690A for ; Sun, 13 Jun 2010 06:32:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49493 helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONnIF-000Mwz-6t; Sun, 13 Jun 2010 09:32:07 -0400 Mime-Version: 1.0 Message-Id: Date: Sun, 13 Jun 2010 09:27:45 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-935686566==_ma============" Cc: congxiao@cernet.edu.cn, xing@cernet.edu.cn, fred@cisco.com, kyin@cisco.com Subject: [secdir] review of draft-ietf-behave-v6v4-framework-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 13:32:05 -0000 --============_-935686566==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. As its name implies, draft-ietf-behave-v6v4-framework-09 provides a context for the discussion of translation between IPv4 and IPv6 networks, during the transition from IOv4 to Ipv6. Although I did not read the document very carefully, it appears to be very well written. It begins with an introduction that provides context setting and history, followed by a discussion on the need for translation between IPv4 and IPv6 networks, and a good terminology section. I wish all RFCs were as well structured as this one. The security considerations section is just one sentence, perhaps a new record for brevity in the post "no security considerations" era :). This is a framework document and as such the authors refer the reader to the individual IPv4/IPv6 translation documents, which they cite. I am a little disappointed that there is not even a high level discussion of security considerations here, one that might capture security-relevant issues that are common to all of the translation methods that are described in detail in the cited documents. Nonetheless, given the overall high quality of the writing in this document, the brevity seems acceptable. (I do have minor quibble with the wording in the security considerations section; the cites are preceded by "i.e.," which literally implies that there will be no other such documents. If, as I suspect, the list is not meant to be exhaustive, in perpetuity, "e.g.," would be the appropriate Latin abbreviation.) --============_-935686566==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-behave-v6v4-framework-09
I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
As its name implies, draft-ietf-behave-v6v4-framework-09 provides a context for the discussion of translation between IPv4 and IPv6 networks, during the transition from IOv4 to Ipv6. Although I did not read the document very carefully, it appears to be very well written. It begins with an introduction that provides context setting and history, followed by a discussion on the need for translation between IPv4 and IPv6 networks, and a good terminology section. I wish all RFCs were as well structured as this one.

The security considerations section is just one sentence, perhaps a new record for brevity in the post "no security considerations" era :). This is a framework document and as such the authors refer the reader to the individual IPv4/IPv6 translation documents, which they cite. I am a little disappointed that there is not even a high level discussion of security considerations here, one that might capture security-relevant issues that are common to all of the translation methods that are described in detail in the cited documents. Nonetheless, given the overall high quality of the writing in this document, the brevity seems acceptable.

(I do have minor quibble with the wording in the security considerations section; the cites are preceded by "i.e.," which literally implies that there will be no other such documents. If, as I suspect, the list is not meant to be exhaustive, in perpetuity, "e.g.," would be the appropriate Latin abbreviation.)

--============_-935686566==_ma============-- From secdir-bounces@mit.edu Mon Jun 14 04:27:04 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7516C3A6803 for ; Mon, 14 Jun 2010 04:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFIFHKep6wqf for ; Mon, 14 Jun 2010 04:27:03 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A89463A67A7 for ; Mon, 14 Jun 2010 04:27:03 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5EBR7fD032084 for ; Mon, 14 Jun 2010 07:27:07 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5EBR5JN032081 for ; Mon, 14 Jun 2010 07:27:05 -0400 Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id o5EBQvS6028777 for ; Mon, 14 Jun 2010 07:27:05 -0400 X-AuditID: 1209190c-b7bd2ae000005d05-fe-4c1612081a8d Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id B2.15.23813.902161C4; Mon, 14 Jun 2010 07:27:05 -0400 (EDT) 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 B56D4201C9; Mon, 14 Jun 2010 07:27:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D1A2440D4; Mon, 14 Jun 2010 07:26:58 -0400 (EDT) From: Sam Hartman To: secdir@mit.edu, iesg@ietf.org Date: Mon, 14 Jun 2010 07:26:58 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] secdir review of draft-ietf-avt-srtp-not-mandatory X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 11:27:04 -0000 Hi. I've reviewed draft-ietf-avt-srtp-not-mandatory for the security directorate. The security ADs should read this draft very carefully, although I think that's obvious from the filename. However, after doing a careful reading of my own, I didn't find any problems. I might wish for a stronger statement in section 5 that particular profiles of RTP need to specify a mandatory to implement security mechanism. However, this is not a BCP, and I can understand why you wouldn't put that statement in an informational document. Also, it's a bit tricky to get that statement right, considering for example the implications of a profile of RTP that might of itself be a framework. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From hartmans@mit.edu Mon Jun 14 04:27:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C894C3A68C0; Mon, 14 Jun 2010 04:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea3vhI9YsuPH; Mon, 14 Jun 2010 04:27:54 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id A18E63A68BD; Mon, 14 Jun 2010 04:27:54 -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 93570201C9; Mon, 14 Jun 2010 07:27:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CD9B940D4; Mon, 14 Jun 2010 07:27:52 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org,iesg@ietf.org User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) Date: Mon, 14 Jun 2010 07:27:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] secdir review of draft-ietf-avt-srtp-not-mandatory 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, 14 Jun 2010 11:27:54 -0000 Hi. I've reviewed draft-ietf-avt-srtp-not-mandatory for the security directorate. The security ADs should read this draft very carefully, although I think that's obvious from the filename. However, after doing a careful reading of my own, I didn't find any problems. I might wish for a stronger statement in section 5 that particular profiles of RTP need to specify a mandatory to implement security mechanism. However, this is not a BCP, and I can understand why you wouldn't put that statement in an informational document. Also, it's a bit tricky to get that statement right, considering for example the implications of a profile of RTP that might of itself be a framework. From secdir-bounces@mit.edu Mon Jun 14 05:28:09 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25443A6905 for ; Mon, 14 Jun 2010 05:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=2.191, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo07nWxKJk7N for ; Mon, 14 Jun 2010 05:28:09 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id CE7DF3A68ED for ; Mon, 14 Jun 2010 05:28:08 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5ECSCU5022777 for ; Mon, 14 Jun 2010 08:28:12 -0400 Received: from mailhub-dmz-1.mit.edu (MAILHUB-DMZ-1.MIT.EDU [18.9.21.41]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5ECS9kw022764 for ; Mon, 14 Jun 2010 08:28:10 -0400 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id o5ECS91D002417 for ; Mon, 14 Jun 2010 08:28:09 -0400 X-AuditID: 1209190f-b7b20ae000003f85-c4-4c16205881ba Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id AA.CD.16261.850261C4; Mon, 14 Jun 2010 08:28:09 -0400 (EDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 493F6C0042; Mon, 14 Jun 2010 14:28:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id izSoo7du8WnO; Mon, 14 Jun 2010 14:28:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02D7FC000D; Mon, 14 Jun 2010 14:28:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 596B3130AE64; Mon, 14 Jun 2010 14:27:58 +0200 (CEST) Date: Mon, 14 Jun 2010 14:27:58 +0200 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@mit.edu, draft-ietf-ipsecme-ipsec-ha.all@tools.ietf.org Message-ID: <20100614122758.GA31894@elstar.local> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Brightmail-Tracker: AAAAAA== X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] secdir review of draft-ietf-ipsecme-ipsec-ha-06.txt X-BeenThere: secdir@ietf.org Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 12:28:09 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document (intended status informational) contains a problem statement for implementing IKE/IPsec on clusters. The security considerations section seems adequate and I have no other technical remarks. Editorial nits: - p4: The text says: "High Availability" is a condition of a system [...] Would 'property' not be a better term here instead of 'condition'? - p4: s/depends on application/depends on the application/ - p4: The text says: "Fault Tolerance" is a condition [...] Would 'property' not be a better term here instead of 'condition'? - p4: s/the the/the/ - p4: s/where a one/where one/ - p4: s/hapens/happens/ - p7: s/issue, is/issue is/ - p8: s/doomed. the/doomed. The/ - p10: s/solution, is/solution is/ - Some RFC references use the RFC number as in [RFC4301] while others use a label such as [REDIRECT]. I suggest to pick one style. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From mbj@tail-f.com Fri Jun 11 01:19:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6AA28C136; Fri, 11 Jun 2010 01:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhXacRTT068k; Fri, 11 Jun 2010 01:19:44 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8A89F3A677D; Fri, 11 Jun 2010 01:19:44 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 607DA616002; Fri, 11 Jun 2010 10:19:45 +0200 (CEST) Date: Fri, 11 Jun 2010 10:19:49 +0200 (CEST) Message-Id: <20100611.101949.192441308.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100611080956.GA5257@elstar.local> References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jun 2010 08:03:01 -0700 Cc: draft-ietf-netconf-monitoring@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring 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, 11 Jun 2010 08:19:45 -0000 Hi, Juergen Schoenwaelder wrote: > On Fri, Jun 11, 2010 at 10:00:43AM +0200, Alan DeKok wrote: > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > The document defines a data model for netconf monitoring. The security > > considerations section says in part: > > > > Some of the readable data nodes in this YANG module may be > > considered sensitive or vulnerable in some network environments. > > It is thus important to control read access (e.g. via get, > > get-config or notification) to these data nodes. > > > > What is unclear from the document is whether or not the data is secure > > *after* access is gained. i.e. is there a secure transport layer? > > Should one be used? If not, why? > > NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In other > words, all existing NETCONF transports are "secure". The revision of > the NETCONF specification being worked on is going to make this > hopefully clearer by calling the transport layer "secure transports". > > There has been progress very recently on formulating a security > considerations template for documents that contain NETCONF/YANG data > models and I think it would be good if this document would indeed > follow these guidelines. Actually, this document follows the latest security considerations template. However, the template does not mention that NETCONF runs over a secure transport. Maybe the template (and this document) should be updated to make this clear? /martin From mehmet.ersue@nsn.com Mon Jun 14 01:33:50 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78AAF3A67ED; Mon, 14 Jun 2010 01:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3knscs1rLS0w; Mon, 14 Jun 2010 01:33:45 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 304533A6403; Mon, 14 Jun 2010 01:33:44 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8Xcxr016371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jun 2010 10:33:38 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8XcW6001119; Mon, 14 Jun 2010 10:33:38 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:33:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB0B9C.48D1DB2B" Date: Mon, 14 Jun 2010 10:33:36 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64984329@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring Thread-Index: AcsJPDm7J0T/WgkZRiK5BECk8I3z6wBwixgwAAClTwA= References: From: "Ersue, Mehmet (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 14 Jun 2010 08:33:38.0106 (UTC) FILETIME=[4932C9A0:01CB0B9C] X-Mailman-Approved-At: Mon, 14 Jun 2010 08:03:01 -0700 Cc: "ext Romascanu, Dan \(Dan\)" , draft-ietf-netconf-monitoring@tools.ietf.org, netconf@ietf.org Subject: Re: [secdir] [Netconf] FW: secdir review of draft-ietf-netconf-monitoring 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, 14 Jun 2010 08:33:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0B9C.48D1DB2B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Alan, I agree that the security consideration section should inform on the use of secure transport with NETCONF. We addressed this issue in the new version of the security considerations template (see attached mail). As defined in RFC 4741 NETCONF protocol has to be used on top of a secure transport and a NETCONF implementation MUST support SSH as secure transport. I hope this addresses your request. Cheers, Mehmet =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu,=20 > Dan (Dan) > Sent: Sunday, June 13, 2010 3:44 PM > To: netconf@ietf.org > Subject: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring >=20 >=20 > =20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of > Alan DeKok > Sent: Friday, June 11, 2010 11:01 AM > To: secdir@ietf.org; IESG IESG; > draft-ietf-netconf-monitoring@tools.ietf.org > Subject: secdir review of draft-ietf-netconf-monitoring >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed=20 > 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 > The document defines a data model for netconf monitoring. =20 > The security > considerations section says in part: >=20 > Some of the readable data nodes in this YANG module may be > considered sensitive or vulnerable in some network environments. > It is thus important to control read access (e.g. via get, > get-config or notification) to these data nodes. >=20 > What is unclear from the document is whether or not the=20 > data is secure > *after* access is gained. i.e. is there a secure transport layer? > Should one be used? If not, why? >=20 > A statement about privacy and security, with a reference to an > existing netconf document would be good. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 ------_=_NextPart_001_01CB0B9C.48D1DB2B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by DEMUEXC006.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:22:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:22:25 +0200 Received: from demumfd002.nsn-inter.net (DEMUMFD002 [93.183.12.31]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8MPSj025288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jun 2010 10:22:25 +0200 Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8MNUH017501 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Mon, 14 Jun 2010 10:22:24 +0200 Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jun 2010 04:22:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jun 2010 04:22:21 -0400 Content-class: urn:content-classes:message Subject: FW: [netmod] [Fwd: 5th draft for yang module security considerations] Date: Mon, 14 Jun 2010 10:22:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] [Fwd: 5th draft for yang module security considerations] Thread-Index: AcsLmehxLiGRZkV0SL6tOyvWiuoa8QAALJIw From: "ext Romascanu, Dan (Dan)" To: "Sean Turner" , Cc: , "Ersue, Mehmet (NSN - DE/Munich)" , "David Partain" , "Kessens, David (NSN - US/Mountain View)" =20 -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen Sent: Monday, June 14, 2010 11:16 AM To: netmod Working Group Subject: [netmod] [Fwd: 5th draft for yang module security considerations] Since the 4th draft, we have been informed of one typo that is fixed in this revision. Further, the security ADs wanted something added about secure transport of the data, and the secdir review of the netconf-monitoring draft also had questions about that. As a result, Juergen Schoenwaelder has suggested to add some text about that. The resulting text is now as below. Bert --- draft 5 for tang module security considerations: Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at [ed: URL TBD]). In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. Further, if new RPC operations have been defined, then the security considerations of each new RPC operation MUST be explained. X. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742]. -- if you have any writeable data nodes (those are all the -- "config true" nodes, and remember, that is the default) -- describe their specific sensitivity or vulnerability. There are a number of data nodes defined in this YANG module which are writable/creatable/deletable (i.e. config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g. edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: -- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties) Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g. via get, get-config or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------_=_NextPart_001_01CB0B9C.48D1DB2B-- From Ray.Bellis@nominet.org.uk Mon Jun 14 03:49:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2733A6885; Mon, 14 Jun 2010 03:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.305 X-Spam-Level: X-Spam-Status: No, score=-9.305 tagged_above=-999 required=5 tests=[AWL=1.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1EXhAjczzF2; Mon, 14 Jun 2010 03:49:37 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 952093A688B; Mon, 14 Jun 2010 03:49:36 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=krIgTIu8w7O2gl86O/+uzVVtZLlrFlcjMAqmlgxhZiZUIKY+7Q+rv1sZ aoZxsIQ3+rCuTW/MaRCaqdNDee158WOAbYLaF55vgqX4pOWLCF1bxtqVL doaZQpDdoAkcW4W; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1276512581; x=1308048581; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20secdir=20review=20of=20draft-ietf-dnsex t-dns-tcp-requirements-03|Date:=20Mon,=2014=20Jun=202010 =2010:49:37=20+0000|Message-ID:=20|To:=20""=20|CC:=20""=20,=20""=20,=0D=0A=09""=0D=0A=09|MIME-Version:=201.0 |In-Reply-To:=20|References:=20; bh=k7SlM6SE4tzTcXskgwG5RSHQVZcZldBnsucLOJT78BE=; b=q1JGzg5vTom9lkUahpc+jkF4x7adqb99FPrvttnikG/vOxK82Il4DiIX Y04kgwYxzx9UUxJ4X7ATuP4FJ3fcA4LiNOnuF2SXAv2FQVn3fOoiu7HMM VSAqdutDi5MCvY4; X-IronPort-AV: E=Sophos;i="4.53,413,1272841200"; d="scan'208,217";a="19289450" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 14 Jun 2010 11:49:39 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%20]) with mapi; Mon, 14 Jun 2010 11:49:38 +0100 From: Ray Bellis To: "" Thread-Topic: secdir review of draft-ietf-dnsext-dns-tcp-requirements-03 Thread-Index: AQHLA1x1KY8lbbDqwkqxPSjehhszdJKBRxSA Date: Mon, 14 Jun 2010 10:49:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AA39C80F246740BDBF20AE7C31A82BC2nominetorguk_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 14 Jun 2010 08:03:01 -0700 Cc: "" , "" , "" Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dns-tcp-requirements-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 10:49:38 -0000 --_000_AA39C80F246740BDBF20AE7C31A82BC2nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have only one minor comment, in the Security Considerations section: At the time of writing the vast majority of TLD authority servers and all of the root name servers support TCP and the author knows of no evidence to suggest that TCP-based DoS attacks against existing DNS infrastructure are commonplace. Since this is a working group document, not an individual or independent submission, I'd rather see "and the dnsext working group knows of no evidence", to stress that the fact was reviewed by the working group, and the statement has working group consensus. This is, of course, assuming that that's truly the case -- if it is not, then I do have an issue with that. Well, during the substantial WG review the working group didn't tell me of = any TCP-based DoS attacks against DNS, so in that respect the author _still= _ knows of no evidence... ;-) Olafur - what would you recommend? Ray --_000_AA39C80F246740BDBF20AE7C31A82BC2nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
<= font class=3D"Apple-style-span" color=3D"#000000">
I have only on= e minor comment, in the Security Considerations section:

 &nbs= p;At the time of writing the vast majority of TLD authority servers and
=   all of the root name servers support TCP and the author knows = of no
  evidence to suggest that TCP-based DoS attacks agains= t existing DNS
  infrastructure are commonplace.

Since= this is a working group document, not an individual or
independent subm= ission, I'd rather see "and the dnsext working group
knows of no ev= idence", to stress that the fact was reviewed by the
working group,= and the statement has working group consensus.  This
is, of course= , assuming that that's truly the case -- if it is not,
then I do have an= issue with that.

Well, during the sub= stantial WG review the working group didn't tell me of any TCP-based DoS at= tacks against DNS, so in that respect the author _still_ knows of no eviden= ce... ;-)

Olafur - what would you recommend?
=

Ray



<= /body>= --_000_AA39C80F246740BDBF20AE7C31A82BC2nominetorguk_-- From rbarnes@bbn.com Mon Jun 14 10:21:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6515D3A68DC; Mon, 14 Jun 2010 10:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fp4KJmQO211r; Mon, 14 Jun 2010 10:21:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 60E833A68CC; Mon, 14 Jun 2010 10:21:53 -0700 (PDT) Received: from ros-dhcp192-1-51-71.bbn.com ([192.1.51.71]:51891) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OODMC-000H28-Gt; Mon, 14 Jun 2010 13:21:56 -0400 Message-Id: <5A638DC0-41CF-4C0C-B00D-6793C43FB708@bbn.com> From: "Richard L. Barnes" To: secdir@ietf.org, iesg@ietf.org, The IETF , draft-ietf-simple-msrp-sessmatch@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 14 Jun 2010 13:21:55 -0400 X-Mailer: Apple Mail (2.936) Subject: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 17:21:54 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document changes the URI matching algorithm used in MSRP. MSRP sessions are typically initiated using SDP bodies in SIP. These SDP bodies contain MSRP URIs that the peers use to contact each other. When one peer receives a request to initiate a session, he verifies that the URI being requested is one that he initiated in SDP, thereby using the URI as a shared secret to authenticate that the originator of the session actually received the SDP body in question. According to the current SDP specification, this comparison is performed over the whole URI; this document restricts the comparison to the "session-id" component, omitting the host, port, and transport components. The goal of the document is to facilitate a certain class of man-in-the-middle attack, namely to allow a signaling intermediary to insert a media intermediary. The restriction on the URI comparison is needed in order for the media intermediary not to have to modify URIs in MSRP packets to reflect the modifications to URIs in SDP bodies performed to redirect traffic through the media intermediary. I have a few significant reservations about this document: This extension makes it more difficult for MSRP entities to secure their communications against attackers in the signaling path. The current model provides a basic integrity protection, in that signaling intermediaries cannot redirect traffic to an arbitrary third party; they must at least advise the third party about how to modify MSRP packets. The proposed modification would remove even this cost. Moreover, it raises the cost of providing integrity protection to messages, since Alice must now employ both integrity and confidentiality protections on an end-to-end basis; if her messages are only integrity-protected, then a proxy can remove the integrity protection and redirect traffic without it being observable to Alice. The document needs to clarify what the impacts are for authentication in secure modes of MSRP. In particular: -- The distinction between "self-signed" and "public" certificates is inappropriate. The proper distinction is between the name-based authentication in Section 14.2 of RFC 4975 and the fingerprint-based authentication in Section 14.4. -- In either case, changing the host name need not result in an authentication failure, since the media intermediary can simply authenticate as itself to both endpoints, having changed the respective MSRP URIs appropriately. -- There is currently no requirement that a endpoint identity in the To-Path URI matches the endpoint identity authenticated at the TLS layer, because these two are required to be the same. This document changes that assumption, and should note that these two identities can differ. The document also precludes any name-based multiplexing, where a single MSRP process (single IP address and port) directs requests to different virtual recipients based on the domain name in the To-Path header. (In analogy to Host-based multiplexing in HTTP, which is very widely deployed.) Since with this extension, the domain in the To- Path is completely unpredictable from the recipient's perspective, it is useless to the recipient. The document has no backward-compatibility. MSRP implementations that do not support this extension will not be able to receive MSRP sessions from implementations that do. In that regard, this document seems more like an new version of MSRP rather than an update. From ted.ietf@gmail.com Mon Jun 14 11:52:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CC43A6948; Mon, 14 Jun 2010 11:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.683 X-Spam-Level: X-Spam-Status: No, score=0.683 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plmZB-S2VEGP; Mon, 14 Jun 2010 11:52:15 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C3C813A6927; Mon, 14 Jun 2010 11:52:15 -0700 (PDT) Received: by pwi8 with SMTP id 8so3295441pwi.31 for ; Mon, 14 Jun 2010 11:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gaPXv5c0ipR6FE8rti36MaKrW6foPhA0T3OhubJoUjM=; b=lozJCNVRo0BTM1oqGlv0zZTLohTTnyx1xRZI+l8kBp5Q908c56VvsM4RQMv3yhdJ8y EWku/evdZYvdsdWTXAHhOktfEA9T2Vzcxe/FKroLGCRgDVssDvXPjzXcxsdyjKp5+4Ui sH59JaaKCAqKr4mEdzoWLXlpmpFAGVIDQOslA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UApPogJthWHD93HR79QTZQ9XVUGm0/3blXJepjJm9J+6Bnc9S8ZUz4xBEw4BuQwEG0 kWUDgddTCY/oiYrbtmcRC2yWyhalOrB+LevWAksYH8ZlBQ9SfgUDhy1dT0ALHSsBw3L/ vwwzN3SOAwuj71n/CWBvSoFVgCYMqOOWOgMf0= MIME-Version: 1.0 Received: by 10.142.10.3 with SMTP id 3mr4266551wfj.120.1276541537389; Mon, 14 Jun 2010 11:52:17 -0700 (PDT) Received: by 10.142.98.10 with HTTP; Mon, 14 Jun 2010 11:52:17 -0700 (PDT) In-Reply-To: <5A638DC0-41CF-4C0C-B00D-6793C43FB708@bbn.com> References: <5A638DC0-41CF-4C0C-B00D-6793C43FB708@bbn.com> Date: Mon, 14 Jun 2010 11:52:17 -0700 Message-ID: From: Ted Hardie To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Jun 2010 12:08:19 -0700 Cc: draft-ietf-simple-msrp-sessmatch@tools.ietf.org, The IETF , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 18:52:17 -0000 I join Richard in believing that this document makes changes beyond that which could be understood as "updating" the MSRP URI scheme processing. To highlight one particular aspect, RFC 4975 does not require session-ids to be present, a fact noted both in the ABNF and in this text: 4. The session-id part is compared as case sensitive. A URI without a session-id part is never equivalent to one that includes one. A matching scheme which relies on a URI section which is not guaranteed to be present has some interesting problems ahead of it. If this effective= ly makes their use mandatory, that requires a change to the fundamental ABNF and text. I also note that the security considerations, in addition to having some fairly disingenuous language about the impact of this change, seems to fail to mention MSRPS URIs and what, if any, impact this would have on them. regards, Ted Hardie On Mon, Jun 14, 2010 at 10:21 AM, Richard L. Barnes wrote= : > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. =A0These > comments were written primarily for the benefit of the security area > directors. =A0Document editors and WG chairs should treat these comments = just > like any other last call comments. > > This document changes the URI matching algorithm used in MSRP. =A0MSRP > sessions are typically initiated using SDP bodies in SIP. =A0These SDP bo= dies > contain MSRP URIs that the peers use to contact each other. =A0When one p= eer > receives a request to initiate a session, he verifies that the URI being > requested is one that he initiated in SDP, thereby using the URI as a sha= red > secret to authenticate that the originator of the session actually receiv= ed > the SDP body in question. > > According to the current SDP specification, this comparison is performed > over the whole URI; this document restricts the comparison to the > "session-id" component, omitting the host, port, and transport components= . > =A0The goal of the document is to facilitate a certain class of > man-in-the-middle attack, namely to allow a signaling intermediary to ins= ert > a media intermediary. =A0The restriction on the URI comparison is needed = in > order for the media intermediary not to have to modify URIs in MSRP packe= ts > to reflect the modifications to URIs in SDP bodies performed to redirect > traffic through the media intermediary. > > I have a few significant reservations about this document: > > This extension makes it more difficult for MSRP entities to secure their > communications against attackers in the signaling path. =A0The current mo= del > provides a basic integrity protection, in that signaling intermediaries > cannot redirect traffic to an arbitrary third party; they must at least > advise the third party about how to modify MSRP packets. =A0The proposed > modification would remove even this cost. =A0Moreover, it raises the cost= of > providing integrity protection to messages, since Alice must now employ b= oth > integrity and confidentiality protections on an end-to-end basis; if her > messages are only integrity-protected, then a proxy can remove the integr= ity > protection and redirect traffic without it being observable to Alice. > > The document needs to clarify what the impacts are for authentication in > secure modes of MSRP. =A0In particular: > -- The distinction between "self-signed" and "public" certificates is > inappropriate. =A0The proper distinction is between the name-based > authentication in Section 14.2 of RFC 4975 and the fingerprint-based > authentication in Section 14.4. -- In either case, changing the host name > need not result in an authentication failure, since the media intermediar= y > can simply authenticate as itself to both endpoints, having changed the > respective MSRP URIs appropriately. > -- There is currently no requirement that a endpoint identity in the To-P= ath > URI matches the endpoint identity authenticated at the TLS layer, because > these two are required to be the same. =A0This document changes that > assumption, and should note that these two identities can differ. > The document also precludes any name-based multiplexing, where a single M= SRP > process (single IP address and port) directs requests to different virtua= l > recipients based on the domain name in the To-Path header. =A0(In analogy= to > Host-based multiplexing in HTTP, which is very widely deployed.) =A0Since= with > this extension, the domain in the To-Path is completely unpredictable fro= m > the recipient's perspective, it is useless to the recipient. > > The document has no backward-compatibility. =A0MSRP implementations that = do > not support this extension will not be able to receive MSRP sessions from > implementations that do. =A0 In that regard, =A0this document seems more = like an > new version of MSRP rather than an update. > > > > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From mcgrew@cisco.com Mon Jun 14 14:38:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE1E3A6917; Mon, 14 Jun 2010 14:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2FlQC2HgzxC; Mon, 14 Jun 2010 14:38:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 453FF3A69F0; Mon, 14 Jun 2010 14:38:05 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABc+FkyrR7Ht/2dsb2JhbACea3GmPZoTgmCCOgSDTQ X-IronPort-AV: E=Sophos;i="4.53,416,1272844800"; d="scan'208";a="261577682" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2010 21:38:09 +0000 Received: from stealth-10-32-254-213.cisco.com (stealth-10-32-254-213.cisco.com [10.32.254.213]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5ELc8X6005862; Mon, 14 Jun 2010 21:38:09 GMT Message-Id: From: David McGrew To: IESG , secdir@ietf.org, draft-ietf-hip-hiccups.all@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 14 Jun 2010 14:38:08 -0700 X-Mailer: Apple Mail (2.936) Subject: [secdir] Review of draft-ietf-hip-hiccups-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 21:38:13 -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. There are several points where the draft could be made more clear, some of which might impact security. I've listed those below, intermingled with some nits. Abstract and Section 1. "secure" is used where "authenticated" would be better, since this protocol does not provide any confidentiality services or encryption. RFC 4949 lists "message integrity code (MIC)" as a deprecated term, but this term is defined and used. In this case what is meant is "collision-resistant hash"; that phrase should be used in Sections 2 and 7. "Checksum" is an inappropriate term for a collision-resistant hash and it should be replaced in Section 4. For the security considerations section: does the hash need strong collision- resistance, or just second preimage resistance (also called weak collision-resistance)? Section 4 nits: "with help of MIC." -> "with the help of the MIC." "HIP DATA packet"-> "The HIP DATA packet" "Hash algorithm used to generate MIC is same " -> "The hash algorithm used to generate the MIC is the same " Section 4.1. I suggest emphasizing the requirement for the "Sequence Number" fields in distinct SEQ_DATA parameters to be distinct. Section 4.3. says "Payload Data 8 last bytes of the payload data over which the MIC is calculated. This field is used to uniquely bind PAYLOAD_MIC parameter to next header, in case there are multiple copies of same type." It seems to me that this uniqueness is not guaranteed, but that if the last-8-bytes is not unique, the MIC verification process would fail, but that there is no way that an attacker could exploit this fact. I suggest noting this property in the security considerations. Section 4.3: The PAYLOAD_MIC parameter has a field called "Payload MIC". It would be less confusing if the latter was called "MIC Value" or some other named that is distinct from the parameter name. Section 4.3 nit: "Identifies the data that protected by this MIC." add "is". Section 5.1 nit: "A HIP DATA packet MUST contain SEQ_DATA or ACK_DATA parameter if both parameters are missing then packet MUST be dropped as invalid." -> "A HIP DATA packet MUST contain either a SEQ_DATA or ACK_DATA parameter; if both parameters are missing, then the packet MUST be dropped as invalid." Section 5.2 says "The receiver MUST validate these MICs." It should also describe how to validate them, and S 5.3 would be a more appropriate place to detail that process. Section 5.2 says " ... no SEQ_DATA sequence number is reused before the receiver has closed the processing window for the previous packet using the same SEQ_DATA sequence number." Important question: what enables the receiver to tell the difference? I assume that there are some other fields (e.g. nonces) associated with the connection that might serve this purpose; if that is right, I suggest documenting that fact. regards, David From kent@bbn.com Tue Jun 15 15:19:34 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC213A69EA for ; Tue, 15 Jun 2010 15:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB1ll9jZ6CLt for ; Tue, 15 Jun 2010 15:19:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D39003A699A for ; Tue, 15 Jun 2010 15:19:33 -0700 (PDT) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]:49240) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOeTp-0001ky-GP for secdir@ietf.org; Tue, 15 Jun 2010 18:19:37 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 15 Jun 2010 18:19:35 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [secdir] another TA observation X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 22:19:34 -0000 In explaining the differences between the new TA proposal and the compound TA proposal to a staff member, I realized that there is another (perhaps minor) difference that I failed to include in my analysis last week. The new (simple) TA proposal requires each RP to fetch the trust anchor (the self-signed cert) to make sure that the RP has the current version re the 3779 resources contained therein. I don't recall that Sam's I-D specified how frequently an RP should (SHOULD?) perform this fetch. The simple, safe answer might be to perform the fetch every time the RP does a tree walk to gather new certs, CRLs, etc. In the compound TA mode the ETA is constant for a very long period (indicated by the validity interval in the self-signed cert). The CMS blob that contains the RTA is fetched (presumably as part of the tree walk), and verified using the (single-use?) EE cert contained in the blob, to obtain the up-to-date TA for RPKI cert validation. Not sure if anyone cares about this difference, but I thought I would mention it for completeness. Steve From weiler@watson.org Tue Jun 15 15:22:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0E03A69D5 for ; Tue, 15 Jun 2010 15:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.952, 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 TIxfiyz8v+6r for ; Tue, 15 Jun 2010 15:22:09 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 806653A69A0 for ; Tue, 15 Jun 2010 15:22:09 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o5FMMAEI092061; Tue, 15 Jun 2010 18:22:10 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o5FMMALt092058; Tue, 15 Jun 2010 18:22:10 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 15 Jun 2010 18:22:10 -0400 (EDT) From: Samuel Weiler To: Stephen Kent In-Reply-To: Message-ID: References: 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]); Tue, 15 Jun 2010 18:22:10 -0400 (EDT) Cc: secdir@ietf.org Subject: Re: [secdir] another TA observation X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 22:22:17 -0000 I think Steve didn't mean to send this to the secdir list. Discussion on the sidr WG mailing list for those interested. -- Sam From Nicolas.Williams@oracle.com Tue Jun 15 17:24:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64C53A6A7D; Tue, 15 Jun 2010 17:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.825 X-Spam-Level: X-Spam-Status: No, score=-4.825 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3K0tTnKfc5q; Tue, 15 Jun 2010 17:24:28 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CD4893A6A89; Tue, 15 Jun 2010 17:24:28 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5G0OTRl012268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jun 2010 00:24:31 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5FKvjpH016828; Wed, 16 Jun 2010 00:24:29 GMT Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 328600621276647839; Tue, 15 Jun 2010 17:23:59 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Jun 2010 17:23:59 -0700 Date: Tue, 15 Jun 2010 19:23:54 -0500 From: Nicolas Williams To: IESG , secdir@ietf.org Message-ID: <20100616002354.GS24077@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090205.4C1819C0.001A:SCFMA4539811,ss=1,fgs=0 Cc: draft-ietf-v6ops-ra-guard.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-v6ops-ra-guard-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 00:24:29 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. In my opinion this document is not quite ready for publication. "RA-Guard" is a filtering service that is intended to run in layer-2 network fabrics to help protect routers from attackers. However, this is not exactly clear from the text of the abstract. The possible types of filters ("filter criteria") given are: - stateless filters based on link-layer address of sender, switch port on which the RA is received, sender IP address, and "prefix list" (what is that?); - stateful filters: stateless filters (see above) learned during a learning period; - stateful filters based on SEND status. Issues: - The Abstract needs a lot of wordsmithing, and needs to expand acronyms on first use. Here's an attempt at a re-write: " Routing protocols are often susceptible to spoof attacks. The canonical solution to this is Secure Neighbor Discovery (SEND) [RFC3971], a solution that is difficult to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. " (Not much more needs to be said in the abstract.) - The Introduction needs a lot of wordsmithing, and needs to expand acronyms on first use. - Are there particular routing protocols that this solution applies to, or not? - I don't understand why "Ethernet" is described as incompatible with RA-Guard. There clearly exist switched Ethernet L2 fabrics... Perhaps the authors intended to be more specific? - The Security Considerations section is too short. Not enough examples of filtering criteria are given in the body of the document, and none of the security considerations of using such any specific RA-Guard filtering criteria are discussed. Nor are security considerations of use of specific filtering criteria with and without also using SEND are discussed. Nor are the security considerations of using learning mode discussed. - I suppose there's no need for a standard filter interchange language, but perhaps this could be stated explicitly. Even so, examples with a pseudo-language for writing filters may well be useful. Nico -- From ari.keranen@ericsson.com Tue Jun 15 08:34:11 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9793A69A1; Tue, 15 Jun 2010 08:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSyyVJA3ZH-0; Tue, 15 Jun 2010 08:34:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 91BAF3A6988; Tue, 15 Jun 2010 08:34:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-97-4c179d71bc02 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 92.10.29106.17D971C4; Tue, 15 Jun 2010 17:34:09 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 17:34:09 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 17:34:08 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 846DD27BF; Tue, 15 Jun 2010 18:34:08 +0300 (EEST) Message-ID: <4C179D70.1080807@ericsson.com> Date: Tue, 15 Jun 2010 18:34:08 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Chris Lonvick References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2010 15:34:09.0060 (UTC) FILETIME=[326E9640:01CB0CA0] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 16 Jun 2010 06:28:17 -0700 Cc: "draft-ietf-hip-bone.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-hip-bone X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 15:34:11 -0000 Hi Chris, Thanks for the review! Comments inline. On 06/11/2010 05:22 AM, Chris Lonvick wrote: > I have not been keeping up with the discussions of this working group. I > read through this document and skimmed through RFC-5201. I remain > confused on a couple of topics. If they are explained somewhere, please > just give me a general pointer and don't bother explaining to me (as I > will likely continue to not keep up with this WG. :-) > > - Obviously a host can join two HIP instantitions. What happens when the > overlay identifiers conflict? Must the overlay identifiers be globally > unique or can they have local context? The idea behind overlay identifiers is that they are statistically unique, i.e., the chance for two overlays picking up the same ID is really low. However, if this happens, a node that is already part of an overlay can not join the other overlay with the same ID. The exact behavior, error message signaling, etc. depends on the HIP BONE instance and the peer protocol that the instance is using (e.g., draft-ietf-hip-reload-instance and its peer protocol draft-ietf-p2psip-base). So, the identifiers need not to be globally unique as long as a single node does not see the same ID more than once at the same time. That said, nothing prevents using a centralized entity giving out Overlay IDs that would not clash. > - When a host joins a HIP instantiation, is this exclusive? Can a host > that has joined a HIP instantiation continue to directly communicate with > IPv4 and IPv6 hosts or must it communicate through a gateway? Here I'm > thinking of a device that fires up IPsec - in my experience the policy is > to encrypt all traffic to the gateway and then let the gateway forward > traffic. Is this what is envisioned for a client joining a HIP > instatiation? A host can continue using standard IPv4 and v6 connections despite being part of an overlay, but also a "default gateway" kind of scenario you mentioned is possible. Section 5.2 has some text about deciding whether messages should be sent via an overlay, but essentially, it's about local policy and configuration. > The only real security concern I have in the document is in section 6.1, > where you RECOMMEND 32 bits of randomness be used in the OVERLAY_ID > parameter. I don't understand why this is recommended or what purpose it > may have. What I'm saying is that even if you have 2 HIP BONE instances > throughout the Internet, there is a non-zero chance that the OVERLAY_ID > parameters will be identical unless people intervene and choose the > values. The chances increase with more instances regardless of how many > bits of randomness you may recommend - reference the "birthday attack". > I'd suggest that you drop the recommendation for randomness and just > recommend that people attempt to prevent a collision via any means > possible. Continuing to recommend some amount of randomness would give > people a false sense that a collision may not occur. OK. The idea here was to have a minimum amount of randomness to give sufficiently small chances for an ID clash. I'll rephrase that to recommended "any other means possible" instead. > Some nits from the document: > In Section 2 two things: > CURRENT: > Node ID: A value that uniquely identifies a node in an overlay > network. The value is not usually human-friendly, but for example > a hash of a public key. > PERHAPS SHOULD BE: > Node ID: A value that uniquely identifies a node in an overlay > network. The value is not usually human-friendly. As an example > it may be a hash of a public key. Makes sense, I'll fix this. > CURRENT: > Valid locator: A Locator (as defined in [RFC5206]; usually an IP > address or an address and a port number) that a host is known to > be reachable at, for example, because there is an active HIP > association with the host. > PERHAPS SHOULD BE: > Valid locator: A Locator (as defined in [RFC5206]; usually an IP > address, or an address and a port number) that a host is known to > be reachable at because there is an active HIP association with the > host. A host could be known to be reachable even if there is no active HIP association, so I'd keep the original form for the definition giving the HIP association only as an example. > From that, what is a "HIP association"? Perhaps you mean to say that the > host is part of a HIP overlay network? Just fyi, "HIP association" is > used elsewhere in the text and in RFC-5201. If it's important then you > may want to define it here as well. As RFC5201 defines it, HIP association is "an IP-layer communications context" (established using HIP). I'll add that to the terminology section. Cheers, Ari From kent@bbn.com Wed Jun 16 07:47:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821683A6A62 for ; Wed, 16 Jun 2010 07:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11] 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 YEbFOeNBbPUf for ; Wed, 16 Jun 2010 07:47:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 577763A6B3F for ; Wed, 16 Jun 2010 07:47:07 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57303 helo=[10.242.52.205]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOttS-0009u2-Je; Wed, 16 Jun 2010 10:47:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 16 Jun 2010 10:26:13 -0400 To: secdir-secretary@mit.edu From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: secdir@ietf.org Subject: Re: [secdir] another TA observation 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, 16 Jun 2010 14:47:13 -0000 At 6:22 PM -0400 6/15/10, Samuel Weiler wrote: >I think Steve didn't mean to send this to the secdir list. >Discussion on the sidr WG mailing list for those interested. > >-- Sam you're right. my auto-completion typing did me in! Sorry 'bout that. Steve From hartmans@mit.edu Wed Jun 16 09:48:15 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C7A3A68BF; Wed, 16 Jun 2010 09:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFbbgPR-W2yj; Wed, 16 Jun 2010 09:48:14 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CF0693A68BA; Wed, 16 Jun 2010 09:48:14 -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 E558320394; Wed, 16 Jun 2010 12:48:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 73D1E40D4; Wed, 16 Jun 2010 12:48:04 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <20100616002354.GS24077@oracle.com> Date: Wed, 16 Jun 2010 12:48:04 -0400 In-Reply-To: <20100616002354.GS24077@oracle.com> (Nicolas Williams's message of "Tue, 15 Jun 2010 19:23:54 -0500") 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-v6ops-ra-guard.all@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-v6ops-ra-guard-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 16:48:15 -0000 Has this document been reviewed in the SAVI working group? If not, I'd strongly argue for such a review. It's not strictly within SAVI's charter, but I think that they have familiarity with the concepts involved sufficient to help clean up the document. From mundy@sparta.com Wed Jun 16 12:09:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5803A6B98; Wed, 16 Jun 2010 12:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYxZQdDpSWey; Wed, 16 Jun 2010 12:09:41 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id C3CFB3A6B82; Wed, 16 Jun 2010 12:09:40 -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 o5GJ9iiA029731; Wed, 16 Jun 2010 14:09:44 -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 o5GJ9i3g018390; Wed, 16 Jun 2010 14:09:44 -0500 Received: from hobbes.columbia.sparta.com ([157.185.80.174]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 15:09:43 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by hobbes.columbia.sparta.com (Postfix) with ESMTP id 3195D23B143D; Wed, 16 Jun 2010 15:09:43 -0400 (EDT) Date: Wed, 16 Jun 2010 15:09:42 -0400 From: mundy@sparta.com To: secdir@ietf.org Message-ID: <20100616150942672981.16a87680@sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.9 X-OriginalArrivalTime: 16 Jun 2010 19:09:44.0030 (UTC) FILETIME=[7AB01FE0:01CB0D87] Cc: draft-ietf-mpls-tp-data-plane.all@tools.ietf.org, iesg@ietf.org, mundy@sparta.com Subject: [secdir] Review of draft-ietf-mpls-tp-data-plane-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 19:09:42 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes the set of functions that constitute the MPLS Transport Profile (MPLS-TP) data plane. The document Security Considerations section clearly states that the data plane itself does not provide any security mechanisms, other portions of the document appear to be consistent with that statement. The brief description of management or control plane use of security features as well as the discussion about enhanced security in Security Considerations appear to be adequate. Russ Mundy From hartmans@mit.edu Wed Jun 16 17:26:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963013A67FA; Wed, 16 Jun 2010 17:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvNB2-7QsO4J; Wed, 16 Jun 2010 17:26:43 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C5E193A67B5; Wed, 16 Jun 2010 17:26:40 -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 243EF20394; Wed, 16 Jun 2010 20:26:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DCEEC40D4; Wed, 16 Jun 2010 20:26:33 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> Date: Wed, 16 Jun 2010 20:26:33 -0400 In-Reply-To: <20100611080956.GA5257@elstar.local> (Juergen Schoenwaelder's message of "Fri, 11 Jun 2010 10:09:56 +0200") 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: netconf@ietf.org, "draft-ietf-netconf-monitoring@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 00:26:44 -0000 >>>>> "Juergen" == Juergen Schoenwaelder writes: >> The document defines a data model for netconf monitoring. The >> security considerations section says in part: >> >> Some of the readable data nodes in this YANG module may be >> considered sensitive or vulnerable in some network environments. >> It is thus important to control read access (e.g. via get, >> get-config or notification) to these data nodes. >> >> What is unclear from the document is whether or not the data is >> secure *after* access is gained. i.e. is there a secure >> transport layer? Should one be used? If not, why? Juergen> NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In Juergen> other words, all existing NETCONF transports are Juergen> "secure". The revision of the NETCONF specification being Juergen> worked on is going to make this hopefully clearer by Juergen> calling the transport layer "secure transports". I'll admit that if I read the netconf document and it described something as "secure transport," it would raise a concern in my mind. "secure" as an adjective is generally meaningless. Typically it's applied to make people feel that security objectives are met without actually stating those objectives. Presumably by secure, you mean something like: * Transport authenticates identity of server to client and client to server * Transport provides integrity protection and confidentiality for data transported * Transport provides replay protection on a per-session level as well as within a session I'd be far more interested in the core document making these security services explicit than in having it replace all instances of transport with "secure transport." From j.schoenwaelder@jacobs-university.de Thu Jun 17 00:23:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6813A6A27; Thu, 17 Jun 2010 00:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.22 X-Spam-Level: X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDao+QSH3uVG; Thu, 17 Jun 2010 00:23:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B08363A6A14; Thu, 17 Jun 2010 00:23:55 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8323FC0006; Thu, 17 Jun 2010 09:24:00 +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 763au0Pxr9ZS; Thu, 17 Jun 2010 09:23:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11F49C0004; Thu, 17 Jun 2010 09:23:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A5AC1341B6B; Thu, 17 Jun 2010 09:23:50 +0200 (CEST) Date: Thu, 17 Jun 2010 09:23:50 +0200 From: Juergen Schoenwaelder To: Sam Hartman Message-ID: <20100617072350.GA13466@elstar.local> Mail-Followup-To: Sam Hartman , Alan DeKok , "netconf@ietf.org" , "draft-ietf-netconf-monitoring@tools.ietf.org" , IESG IESG , "secdir@ietf.org" References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IESG IESG , "draft-ietf-netconf-monitoring@tools.ietf.org" , "secdir@ietf.org" , "netconf@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 07:23:57 -0000 On Thu, Jun 17, 2010 at 02:26:33AM +0200, Sam Hartman wrote: > >>>>> "Juergen" == Juergen Schoenwaelder writes: > > >> The document defines a data model for netconf monitoring. The > >> security considerations section says in part: > >> > >> Some of the readable data nodes in this YANG module may be > >> considered sensitive or vulnerable in some network environments. > >> It is thus important to control read access (e.g. via get, > >> get-config or notification) to these data nodes. > >> > >> What is unclear from the document is whether or not the data is > >> secure *after* access is gained. i.e. is there a secure > >> transport layer? Should one be used? If not, why? > > Juergen> NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In > Juergen> other words, all existing NETCONF transports are > Juergen> "secure". The revision of the NETCONF specification being > Juergen> worked on is going to make this hopefully clearer by > Juergen> calling the transport layer "secure transports". > > I'll admit that if I read the netconf document and it described > something as "secure transport," it would raise a concern in my mind. > "secure" as an adjective is generally meaningless. Typically it's > applied to make people feel that security objectives are met without > actually stating those objectives. > > Presumably by secure, you mean something like: > > * Transport authenticates identity of server to client and client to > server > * Transport provides integrity protection and confidentiality for data > transported > * Transport provides replay protection on a per-session level as well as > within a session > > I'd be far more interested in the core document making these security > services explicit than in having it replace all instances of transport > with "secure transport." Yes, I agree. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Jun 17 04:20:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831FF3A699C; Thu, 17 Jun 2010 04:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtYShkVDmjdO; Thu, 17 Jun 2010 04:19:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 753F53A6991; Thu, 17 Jun 2010 04:19:59 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4A66C001E; Thu, 17 Jun 2010 13:20:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2lCBb1Levami; Thu, 17 Jun 2010 13:20:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 546A0C001A; Thu, 17 Jun 2010 13:20:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C63E01342766; Thu, 17 Jun 2010 13:19:55 +0200 (CEST) Date: Thu, 17 Jun 2010 13:19:55 +0200 From: Juergen Schoenwaelder To: Sam Hartman Message-ID: <20100617111955.GA13803@elstar.local> Mail-Followup-To: Sam Hartman , Alan DeKok , "netconf@ietf.org" , "draft-ietf-netconf-monitoring@tools.ietf.org" , IESG IESG , "secdir@ietf.org" References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IESG IESG , "draft-ietf-netconf-monitoring@tools.ietf.org" , "secdir@ietf.org" , "netconf@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 11:20:25 -0000 On Thu, Jun 17, 2010 at 02:26:33AM +0200, Sam Hartman wrote: > I'll admit that if I read the netconf document and it described > something as "secure transport," it would raise a concern in my mind. > "secure" as an adjective is generally meaningless. Typically it's > applied to make people feel that security objectives are met without > actually stating those objectives. > > Presumably by secure, you mean something like: > > * Transport authenticates identity of server to client and client to > server > * Transport provides integrity protection and confidentiality for data > transported > * Transport provides replay protection on a per-session level as well as > within a session > > I'd be far more interested in the core document making these security > services explicit than in having it replace all instances of transport > with "secure transport." There is text in section 2 of draft-ietf-netconf-4741bis-02 talking about security requirements of the transports - and this text is pretty much the same as the text that can be found in section 2 of RFC 4741. I will go over the text to see whether it can be further tightened or detailed (e.g. I see replay protection is not explicitely mentioned). But it definitely not the case that "secure transport" is a meaningless adjective in the NETCONF world even today. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From hartmans@mit.edu Thu Jun 17 06:01:46 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDB63A6901; Thu, 17 Jun 2010 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dptNKHHZOnP1; Thu, 17 Jun 2010 06:01:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BFA9A3A68B3; Thu, 17 Jun 2010 06:01:44 -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 3D1B220036; Thu, 17 Jun 2010 09:01:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D615240D4; Thu, 17 Jun 2010 09:01:32 -0400 (EDT) From: Sam Hartman To: Sam Hartman References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local> <20100617111955.GA13803@elstar.local> Date: Thu, 17 Jun 2010 09:01:32 -0400 In-Reply-To: <20100617111955.GA13803@elstar.local> (Juergen Schoenwaelder's message of "Thu, 17 Jun 2010 13:19:55 +0200") 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: IESG IESG , "draft-ietf-netconf-monitoring@tools.ietf.org" , "secdir@ietf.org" , "netconf@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 13:01:47 -0000 OK. I did review the netconf core spec when it came before the IESG and was happy with it at the time. From kent@bbn.com Thu Jun 17 06:30:28 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18CE3A687A; Thu, 17 Jun 2010 06:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-PgCSa4mGPf; Thu, 17 Jun 2010 06:30:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6E5183A68C1; Thu, 17 Jun 2010 06:30:20 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34245 helo=[172.28.179.87]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPFAe-000OTi-43; Thu, 17 Jun 2010 09:30:16 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C05F076.7050303@ericsson.com> References: <00CEF527-9674-47CF-BC3E-66A9FC7289F7@bbn.com> <4C034A8C.9020205@ericsson.com> <4C05F076.7050303@ericsson.com> Date: Wed, 16 Jun 2010 18:07:31 -0400 To: Suresh Krishnan From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "secdir@ietf.org" , The IETF , "draft-ietf-csi-send-cert@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-csi-send-cert-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 13:30:28 -0000 At 1:47 AM -0400 6/2/10, Suresh Krishnan wrote: >>... > >Hmm. The ETA certificate itself does not need to have the RFC3779 >extension in it, but the relying party needs to fetch an RTA >certificate which will contain a RFC3779 extension. more precisely the ETA MUST NOT have such an extension. Steve From clonvick@cisco.com Fri Jun 18 16:58:53 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C183A6AA7; Fri, 18 Jun 2010 16:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.604 X-Spam-Level: X-Spam-Status: No, score=-8.604 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OibMgCEqFgGq; Fri, 18 Jun 2010 16:58:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 682A23A69D7; Fri, 18 Jun 2010 16:58:52 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,442,1272844800"; d="scan'208";a="547149516" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 18 Jun 2010 23:58:51 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5INwpw0017833; Fri, 18 Jun 2010 23:58:51 GMT Date: Fri, 18 Jun 2010 16:58:50 -0700 (PDT) From: Chris Lonvick To: Stephen Hanna , draft-ietf-syslog-dtls.all@tools.ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] FW: secdir review of draft-ietf-syslog-dtls-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: Fri, 18 Jun 2010 23:58:53 -0000 Hi Steve, I appreciate your review and apologize for the delay in responding. Comments in-line. On Wed, 9 Jun 2010, Stephen Hanna wrote: > > > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Monday, May 17, 2010 6:13 PM > To: draft-ietf-syslog-dtls.all@tools.ietf.org > Cc: secdir@ietf.org; iesg@ietf.org > Subject: secdir review of draft-ietf-syslog-dtls-05 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other comments. > > This document defines a DTLS transport for syslog. The document is > well-written, clear, and seems to serve a worthwhile purpose. > > Although the security considerations section is brief (mainly just > referring to the security considerations in RFC 5425, RFC 5246, > and RFC 4347), it is largely adequate. I see only one omission. > > One difference between the security considerations for syslog over > DTLS and those for syslog over TLS (unnoted in the current Security > Considerations section) is that DTLS does not provide retransmission. > If an attacker can cause a packet to be dropped (especially one > carrying significant information about an attack), the transport > receiver may not consider this a significant event and so the syslog > server may be completely unaware of the occurrence. This contrasts > with syslog over TLS where a dropped packet would be retransmitted > until acknowledged or until the TLS connection goes down (indicating > to the transport sender and receiver and perhaps to the syslog client > and server that a significant event has occurred). Maybe it would be > a good idea to recommend that the transport receiver notice gaps in > the DTLS sequence numbers and notify the syslog server. Still, this > is not as good from a security standpoint as syslog over TLS since > none of the client code will be aware that the dropped message was > not received. At least, there should be a discussion of this issue > in the Security Considerations section of this document. It's discussed in section 5.4 (Unreliable Delivery - in the Security Considerations section) in RFC 5426 and throughout Section 3.1 (Loss-Insensitive Messaging) in RFC 4347. I'm thinking that it would be good to note this in Section 4 (Using DTLS to Secure Syslog) in the draft. Overall, the community is comfortable with the loss of information as they've been using syslog/udp for many years and know the problems with that. RFC 5424 also notes that implementers who wish a lossless stream should be using tls/tcp as their transport. From that, it's probably best to reference RFC 5848 (referenced as draft-ietf-syslog-sign in the draft) which can also provide an indication of loss of messages. > > In addition to this concern, I have noticed a few areas that could > use some clarification and maybe some fixes. > > Section 5.3 says "Implementations MUST support the denial of service > countermeasures defined by DTLS." That's good but it's not clear > whether this means that these countermeasures MUST always be enabled. > Since that is not explicitly stated, it seems that a server could > have those countermeasures enabled by default and a client could > have them disabled by default. That would result in a client and > server that would not interoperate until the administrator tracked > down the problem and changed their configuration. I suggest that > the document be changed to require not only that implementations > support these countermeasures but that they be enabled by default. Good catch. > > Section 7 says "The security policies for syslog over DTLS are the > same as those described in [RFC5425]." Does that mean that all the > normative text in section 5 of RFC 5425 applies to implementations > of this document as well? I hope so but if that's the intent, it > should be explicitly stated (for example by adding the text "and > all the normative requirements of section 5 of [RFC5425] apply"). That is the intent and the added text looks good. > > Once these issues are addressed, I'm sure that the document will > be a worthwhile and relatively secure addition to the RFC series. > Congratulations and thanks to the editors/authors for their work. I'm going to open these as issues for the authors to address. We have several other open issues resulting from other LC reviews and IESG COMMENTS and DISUCSSes which we will resolve in a new ID. Best regards, Chris From yaronf.ietf@gmail.com Sun Jun 20 04:46:46 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E113A696F for ; Sun, 20 Jun 2010 04:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVWtThkUzf86 for ; Sun, 20 Jun 2010 04:46:34 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 137AA3A6816 for ; Sun, 20 Jun 2010 04:46:33 -0700 (PDT) Received: by wya21 with SMTP id 21so1932813wya.31 for ; Sun, 20 Jun 2010 04:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=uQDHtOz+qujiWWnwEvZK3HnAPi1GV1Yr4/V5jPJOLa0=; b=cAznRn7J6M6rHYzZvqdAZVeXCdlM7xewG68nSnQcQOpaNrs7lcNWuwkFRYnlF5I/4d 8R4nxJjxrOkdF3SYoCaLfrQqgLdCtDp/rEq2dooCvBBGBOVLzPvVjlW32dfpVLYeKehL RZFWusOIJkzfNqmLH8m6qT/UVkxIFOnjbC2Ec= 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=CgYOFxjNUp15glE+LplYfbNU7+BeEF2JD0UQefmpqBdmJFxzqPZDO+vxH+NZJCsWC1 c434sGj16/Hun3a3eLMBlE6yF+0re0MZxFcnygXowwPMML3jTJ4Wchu/4dEWWFhwxfRb 78ASb4Pau9v5QAI1bSpPjq3cKjwdL0N8xx/LI= Received: by 10.227.143.212 with SMTP id w20mr3300399wbu.107.1277034397123; Sun, 20 Jun 2010 04:46:37 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-178-30-177.red.bezeqint.net [79.178.30.177]) by mx.google.com with ESMTPS id u36sm32868370wbv.6.2010.06.20.04.46.34 (version=SSLv3 cipher=RC4-MD5); Sun, 20 Jun 2010 04:46:36 -0700 (PDT) Message-ID: <4C1DFF97.1020103@gmail.com> Date: Sun, 20 Jun 2010 14:46:31 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Charles Shen References: <4C148FB1.8060709@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Henning Schulzrinne , draft-ietf-nsis-tunnel.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 11:46:47 -0000 [Removed the IESG.] Hi Charles, please see my comments inline. Thanks, Yaron On 06/20/2010 06:52 AM, Charles Shen wrote: > Hi Yaron, thank you for your careful review. Please see comments inline. > > On Sun, Jun 13, 2010 at 3:58 AM, Yaron Sheffer > wrote: > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the IESG. > > These comments were written primarily for the benefit of the security > > area directors. Document editors and WG chairs should treat these > > comments just like any other last call comments. > > > > This draft discusses the problem of NSIS messages (particularly, QoS > > reservation flows) being encapsulated into various IP tunneling > protocols, > > which prevent the correct QoS setup from being performed. The draft > proposes > > a solution for NSIS tunnel-aware tunnel endpoints, which basically > adds an > > NSIS signaling flow between the tunnel endpoints, but outside of the > tunnel. > > > > General > > > > The draft presents the problem, and the solution, reasonably well. > > > > The draft goes for the "no new security issues" approach. I think > this is > > incorrect, and in fact a number of security issues should be > analyzed and > > possibly resolved. In addition, as a complete outsider to NSIS, I have > > identified one major unspecified piece, leading me to believe that > the draft > > has not had enough review. > > > > Security > > > > The main security issue is that the draft fails to consider > > security-oriented tunnels. IPsec tunnels (and the commonly used > > GRE-over-IPsec) provide security services: normally encryption and > integrity > > protection with ESP, less commonly integrity-protection only with > AH, ESP > > with null encryption, or the new WESP (RFC 5840). The proposed solution > > raises at least three major security issues related to these tunnels: > > > > 1. A so-called covert channel that results from NSIS flows in the > protected > > networks directly triggering NSIS protocol exchanges in an unprotected > > network (i.e. between the tunnel endpoints). Please see Appendix B.1 of > > draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue. > > > > With regard to this specific draft, I see the problem as a more > generic issue which exists also for other protocols (e.g., RSVP) > requiring per-hop processing to interact with IPSec. E.g., RFC4302 > mentions that "NOTE: Use of the Router Alert option is potentially > incompatible with use of IPsec. Although the option is immutable, its > use implies that each router along a packet's path will "process" the > packet and consequently might change the packet.". I think that > mentioning of this potential incompatibility will be beneficial. But I > don't quite see how "limiting the bandwidth of the covert channel" as > discussed in Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 can be > applied here. Please correct me if I were wrong. > You can say this solution is incompatible with IPsec and be done with it. Otherwise, there is a "covert channel " - someone can create spurious NSIS signaling flows within the protected network, just to create signaling in the outside network, which then someone else is monitoring. For highly secure networks, this would be seen as a way to smuggle information out of the network, and you would want to rate-limit this channel. > > 2. A more serious interaction in the other direction: unprotected > NSIS flows > > outside the tunnel interact with NSIS flows in the protected > networks and > > inside the tunnel, and so, an attacker in the unprotected network can > > possibly influence QoS behavior in protected networks. > > > > 3. A practical result of (2) is that the NSIS protocol stack on the > tunnel > > endpoint is now exposed to unprotected networks and therefore suddenly > > becomes security-critical. > > > > IMHO, if we have a segment of the path which is compromised, the QoS > of the rest of the path segments (and the end-to-end QoS) can be > easily affected anyway, whether you have a tunnel segment in the path > or not. Therefore, it doesn't seem to me as a new threat introduced by > this document per se. But it will certainly also be helpful to mention > this scenario in the security considerations section. What I'm saying in #3 is that any security vulnerability (e.g. buffer overflow) in the NSIS stack is suddenly exposed to the big bad Internet, even when the customer may have expected all their traffic to be protected by a VPN gateway, where the VPN software is normally the only software that needs to be hardened. > > > Non-Security > > > > The draft defines extra UDP encapsulation in some cases ("the tunnel > > entry-point inserts an additional UDP header"), but the format > > (specifically, the port number) is not specified. This omission is > strange, > > because the protocol cannot be implemented in the absence of this > > information! > > > > To me this is an intended feature. The mechanism does not require a > pre-allocated fixed UDP port, but allows the port to be dynamically > chosen and conveyed during the tunnel flow/session binding operations. > Sure, I missed this point. Can you please mention it explicitly. > Thanks > > Charles From charles.newyork@gmail.com Sat Jun 19 20:52:49 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666153A686B; Sat, 19 Jun 2010 20:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouuS9Kc7YjRi; Sat, 19 Jun 2010 20:52:48 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 1A7843A67C1; Sat, 19 Jun 2010 20:52:48 -0700 (PDT) Received: by qyk5 with SMTP id 5so21577qyk.31 for ; Sat, 19 Jun 2010 20:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+FSnrpftDE/uZ3wUv+unxjKSOjE1jjWWvK1ofrPmTGA=; b=NFaQwSMYmBTTgPVh//nYzlOf10rWcm/2EbKZj8XVKzy7tECUNiIW9ba3Y+KXnNfJe4 FDguqKkubkuXFI7qzRKbrbGkMBTDC3qQ7W7p6SBdtkmqvXwpsb4+Vak9Q/Ct2jFGauMH N3mXTqR0AKA+28gTab8LvenKL/dK4m2MaWPXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xlmO+0zIMtu1fHlcXObJE8IUy/bybEeU0z7/7lpCG3370FihkVEyKfeaIorqcGkDPp /+KE8zaZtEGUIHftwv65KVLlod2LLyhbQ2j1Ms4v3RVjzUr0wAqUwlLjnyNIwY0EvzYl kVPaFXfhfkkjc+g3VBeoSbu1CLGeK1y1fejNw= MIME-Version: 1.0 Received: by 10.224.39.18 with SMTP id d18mr2218476qae.158.1277005971720; Sat, 19 Jun 2010 20:52:51 -0700 (PDT) Sender: charles.newyork@gmail.com Received: by 10.224.45.136 with HTTP; Sat, 19 Jun 2010 20:52:51 -0700 (PDT) In-Reply-To: <4C148FB1.8060709@gmail.com> References: <4C148FB1.8060709@gmail.com> Date: Sat, 19 Jun 2010 23:52:51 -0400 X-Google-Sender-Auth: WNhbowQ89MKC-OBeNnegUV3eyVM Message-ID: From: Charles Shen To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Jun 2010 05:23:19 -0700 Cc: Henning Schulzrinne , iesg@ietf.org, draft-ietf-nsis-tunnel.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 03:52:49 -0000 Hi Yaron, thank you for your careful review. Please see comments inline. On Sun, Jun 13, 2010 at 3:58 AM, Yaron Sheffer wrot= e: > 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. =C2=A0Document editors and WG chairs should treat these > comments just like any other last call comments. > > This draft discusses the problem of NSIS messages (particularly, QoS > reservation flows) being encapsulated into various IP tunneling protocols= , > which prevent the correct QoS setup from being performed. The draft propo= ses > a solution for NSIS tunnel-aware tunnel endpoints, which basically adds a= n > NSIS signaling flow between the tunnel endpoints, but outside of the tunn= el. > > General > > The draft presents the problem, and the solution, reasonably well. > > The draft goes for the "no new security issues" approach. I think this is > incorrect, and in fact a number of security issues should be analyzed and > possibly resolved. In addition, as a complete outsider to NSIS, I have > identified one major unspecified piece, leading me to believe that the dr= aft > has not had enough review. > > Security > > The main security issue is that the draft fails to consider > security-oriented tunnels. IPsec tunnels (and the commonly used > GRE-over-IPsec) provide security services: normally encryption and integr= ity > protection with ESP, less commonly integrity-protection only with AH, ESP > with null encryption, or the new WESP (RFC 5840). The proposed solution > raises at least three major security issues related to these tunnels: > > 1. A so-called covert channel that results from NSIS flows in the protect= ed > networks directly triggering NSIS protocol exchanges in an unprotected > network (i.e. between the tunnel endpoints). Please see Appendix B.1 of > draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue. > With regard to this specific draft, I see the problem as a more generic issue which exists also for other protocols (e.g., RSVP) requiring per-hop processing to interact with IPSec. E.g., RFC4302 mentions that "NOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet.". I think that mentioning of this potential incompatibility will be beneficial. But I don't quite see how "limiting the bandwidth of the covert channel" as discussed in Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 can be applied here. Please correct me if I were wrong. > 2. A more serious interaction in the other direction: unprotected NSIS fl= ows > outside the tunnel interact with NSIS flows in the protected networks and > inside the tunnel, and so, an attacker in the unprotected network can > possibly influence QoS behavior in protected networks. > > 3. A practical result of (2) is that the NSIS protocol stack on the tunne= l > endpoint is now exposed to unprotected networks and therefore suddenly > becomes security-critical. > IMHO, if we have a segment of the path which is compromised, the QoS of the rest of the path segments (and the end-to-end QoS) can be easily affected anyway, whether you have a tunnel segment in the path or not. Therefore, it doesn't seem to me as a new threat introduced by this document per se. But it will certainly also be helpful to mention this scenario in the security considerations section. > Non-Security > > The draft defines extra UDP encapsulation in some cases ("the tunnel > entry-point inserts an additional UDP header"), but the format > (specifically, the port number) is not specified. This omission is strang= e, > because the protocol cannot be implemented in the absence of this > information! > To me this is an intended feature. The mechanism does not require a pre-allocated fixed UDP port, but allows the port to be dynamically chosen and conveyed during the tunnel flow/session binding operations. Thanks Charles From weiler+secdir@watson.org Mon Jun 21 07:51:49 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99463A6857 for ; Mon, 21 Jun 2010 07:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FumbvCa5dVFe for ; Mon, 21 Jun 2010 07:51:49 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id E82A33A682E for ; Mon, 21 Jun 2010 07:51:48 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o5LEpsOW052554 for ; Mon, 21 Jun 2010 10:51:54 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o5LEpsV8052551 for ; Mon, 21 Jun 2010 10:51:54 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 21 Jun 2010 10:51:54 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 21 Jun 2010 10:51:54 -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: Mon, 21 Jun 2010 14:51:49 -0000 Thanks to all who have recently gotten in a review; our backlog seems to be shrinking. Only two new assignments this week. Tom Yu is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-07-01 (please review by this Friday): Sandy Murphy T 2010-06-29 draft-ietf-csi-proxy-send-04 Magnus Nystrom T 2010-06-29 draft-c1222-transport-over-ip-03 Radia Perlman T 2010-06-29 draft-ietf-nsis-applicability-mobility-signaling-18 Vincent Roca T 2010-06-29 draft-ietf-6man-dns-options-bis-03 Last calls and special requests: Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Julien Laganier 2010-06-15 draft-ietf-behave-v6v4-xlate-stateful-11 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Hilarie Orman 2010-06-22 draft-ietf-martini-reqs-07 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Joe Salowey 2010-06-22 draft-ietf-sipcore-invfix-01 Stefan Santesson 2010-07-07 draft-ietf-proto-wgdocument-states-07 Tina TSOU 2010-07-09 draft-mcgrew-fundamental-ecc-03 Carl Wallace 2010-05-06 draft-ietf-mpls-tp-survive-fwk-06 Carl Wallace 2010-07-09 draft-stone-mgcp-vbd-07 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-06 Nico Williams 2010-07-16 draft-turner-suiteb-cmc-02 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From jsalowey@cisco.com Mon Jun 21 15:53:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50CB03A6828; Mon, 21 Jun 2010 15:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.443 X-Spam-Level: X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 OZCH1RQhYzZk; Mon, 21 Jun 2010 15:52:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9EA953A67C2; Mon, 21 Jun 2010 15:52:59 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO+JH0yrR7Ht/2dsb2JhbACfCHGoSJpHhRsEg1Q X-IronPort-AV: E=Sophos;i="4.53,456,1272844800"; d="scan'208";a="547962288" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 21 Jun 2010 22:53:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5LMr6OR001219; Mon, 21 Jun 2010 22:53:07 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 15:53:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jun 2010 15:53:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-sipcore-invfix-01 Thread-Index: AcsRlILLTFp2G4ILQgacbrDPkC9RMg== From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 21 Jun 2010 22:53:06.0501 (UTC) FILETIME=[833FA750:01CB1194] Subject: [secdir] secdir review of draft-ietf-sipcore-invfix-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:53:00 -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. The document fixes a real problem and seems to address some existing security issues, namely the forwarding of stray responses. This is good. It does introduce more of a possibility of denial of service since state must be maintained to track valid responses and this is noted in the security considerations as well. I'm not all that familiar with SIP, but there are techniques used in other protocols to avoid "flood" type of attacks by delaying committing state until the client has successfully processed a server message. TCP cookies, IKEv2 and DTLS have examples of this. This would be something to consider if implementations were vulnerable to flood type attacks in deployments. =20 Joe=20 From hilarie@purplestreak.com Mon Jun 21 18:47:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BE43A691A for ; Mon, 21 Jun 2010 18:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPZpAaKZV5Bc for ; Mon, 21 Jun 2010 18:47:07 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id AAA4F3A6835 for ; Mon, 21 Jun 2010 18:47:06 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OQsZz-00010d-BZ; Mon, 21 Jun 2010 19:47:11 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OQsZw-0002dT-OY; Mon, 21 Jun 2010 19:47:10 -0600 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o5M1mfiB006862; Mon, 21 Jun 2010 19:48:41 -0600 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o5M1mdgA006857; Mon, 21 Jun 2010 19:48:39 -0600 Date: Mon, 21 Jun 2010 19:48:39 -0600 Message-Id: <201006220148.o5M1mdgA006857@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: ; sa07 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;secdir@ietf.org X-Spam-Relay-Country: _RELAYCOUNTRY_ X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Cc: Bernard_Aboba@hotmail.com, gonzalo.camarillo@ericsson.com, hkaplan@acmepacket.com, spencer@wonderhamster.org, john.elwell@siemens-enterprise.com, rjsparks@nostrum.com Subject: [secdir] review of draft-ietf-martini-reqs-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 01:47:18 -0000 Security review of draft-ietf-martini-reqs-07.txt, Multiple AOR reachability in SIP Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract: This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. There are 21 requirements, and two of them address security. I think requirement 14 leaves out a couple of things: REQ14 - The mechanism MUST be able to operate over a transport that provides integrity protection and confidentiality. It should probably require "end-to-end" integrity protection and confidentiality between the two entities (SIP-PBX and the SSP). And I think requirement 15 should say something about how the two entites are expected to agree on an authentication method, and that the authentication should apply to every registration message exchanged by the entities. That is, once they have authenticated, then that information should be tied to requirement 14 and ensure that the integrity and/or confidentiality is defined between the two entities (by use of, for example, an authenticated key exchange protocol) on all subsequent messages between the two. REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa. I'd also add that it MUST support termination of authenticaton and re-authentication. Minor non-security things: Requirement 4 has a triple negative ("not" "prevent" "without"), and I'm not sure what the heck it means. Requirement 5 has a typo, probably "internally" for "internal". Hilarie From john.elwell@siemens-enterprise.com Mon Jun 21 23:43:42 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8A23A6942 for ; Mon, 21 Jun 2010 23:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_40=-0.185, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7943eM+juGC for ; Mon, 21 Jun 2010 23:43:41 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 07A593A67F0 for ; Mon, 21 Jun 2010 23:43:40 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-584175; Tue, 22 Jun 2010 08:43:46 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6BD8723F0278; Tue, 22 Jun 2010 08:43:46 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 22 Jun 2010 08:43:46 +0200 From: "Elwell, John" To: Hilarie Orman , "secdir@ietf.org" Date: Tue, 22 Jun 2010 08:43:44 +0200 Thread-Topic: review of draft-ietf-martini-reqs-07.txt Thread-Index: AcsRrNf3iQcBLAwuSGGCporU9M2CQwAJhl5w Message-ID: References: <201006220148.o5M1mdgA006857@fermat.rhmr.com> In-Reply-To: <201006220148.o5M1mdgA006857@fermat.rhmr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 22 Jun 2010 10:15:11 -0700 Cc: "Bernard_Aboba@hotmail.com" , "hkaplan@acmepacket.com" , "gonzalo.camarillo@ericsson.com" , "spencer@wonderhamster.org" , "rjsparks@nostrum.com" Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 06:43:42 -0000 Hilarie, Thanks for your review. See responses below:=20 > -----Original Message----- > From: hilarie@purplestreak.com=20 > [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman > Sent: 22 June 2010 02:49 > To: secdir@ietf.org > Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org;=20 > gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; Elwell,=20 > John; hkaplan@acmepacket.com > Subject: review of draft-ietf-martini-reqs-07.txt >=20 > Security review of draft-ietf-martini-reqs-07.txt, > Multiple AOR reachability in SIP=20 >=20 > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. >=20 > The abstract: > This document states requirements for a standardized SIP registration > mechanism for multiple addresses of record, the mechanism being > suitable for deployment by SIP service providers on a large scale in > support of small to medium sized Private Branch Exchanges (PBXs). > The requirements are for a solution that can, as a minimum, support > AORs based on E.164 numbers. >=20 > There are 21 requirements, and two of them address security. >=20 > I think requirement 14 leaves out a couple of things: > REQ14 - The mechanism MUST be able to operate over a transport that > provides integrity protection and confidentiality. > It should probably require "end-to-end" integrity protection and > confidentiality between the two entities (SIP-PBX and the SSP). [JRE] In the next version I will change it to: "The mechanism MUST be able to operate over a transport that provides end-t= o-end integrity protection and confidentiality between the SIP-PBX and the = SSP." >=20 > And I think requirement 15 should say something about how the two > entites are expected to agree on an authentication method, and that > the authentication should apply to every registration message > exchanged by the entities. That is, once they have authenticated, > then that information should be tied to requirement 14 and ensure that > the integrity and/or confidentiality is defined between the two > entities (by use of, for example, an authenticated key exchange > protocol) on all subsequent messages between the two. =20 [JRE] I am reluctant to make any changes here. We don't anticipate any new = security mechanism, and indeed the solution that is moving forward in the W= G allows use of TLS, which is already allowed for in SIP. For authenticatio= n it allows both TLS mutual authentication or SIP digest authentication + T= LS server authentication, again, in line with what is already allowed in SI= P. SIP has a wealth of material in this area, including aspects of RFC 3263= and RFC 3329. I don't think it worthwhile adding a bunch of requirements t= hat in the end will not lead to any new mechanisms or influence use of exis= ting mechanisms. REQ14 and REQ15 I think are sufficient pointers to needs i= n this area. > REQ15 - The mechanism MUST support authentication of the SIP-PBX by > the SSP and vice versa. > I'd also add that it MUST support termination of authenticaton and > re-authentication. [JRE] I am not sure exactly what you are looking for here. Is this referrin= g to what happens when a certificate expires, say? Again, I would doubt we = really need to add anything here, since we don't anticipate new security me= chanisms. >=20 > Minor non-security things: >=20 > Requirement 4 has a triple negative ("not" "prevent" "without"), and > I'm not sure what the heck it means. [JRE] Yes, in the next version I will change it to: "The mechanism MUST allow UAs attached to a SIP-PBX to register with the SI= P-PBX for AORs based on assigned telephone numbers, in order to receive req= uests targeted at those telephone numbers, without needing to involve the S= SP in the registration process." >=20 > Requirement 5 has a typo, probably "internally" for "internal". [JRE] It intentionally says "internally" at present - an adverb modifying t= he verb "handle". I am not sure how to reword it to prevent misinterpretati= on. John >=20 > Hilarie > = From charles.newyork@gmail.com Mon Jun 21 08:15:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E6F3A6880 for ; Mon, 21 Jun 2010 08:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdLGMH90Vdjy for ; Mon, 21 Jun 2010 08:15:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C63F63A6896 for ; Mon, 21 Jun 2010 08:15:14 -0700 (PDT) Received: by iwn9 with SMTP id 9so600697iwn.31 for ; Mon, 21 Jun 2010 08:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=L54bGqy6SHnRKVfj+xl3T2SPKJhpwBW8LpWMmKZjQEs=; b=qm9cQCKpq4pYgU+1A+ER2rXHfwwUE7IIwC8dVsdclwmzOHUUpN1DcqYCzMNaQtk9SY Mn1xRrlUV5DeWO2Pee/O0NN5EVc1rZqQAN/OXwBIwgeRJCDoSyWQ7OlpPNZdII1mAS9A 2z6Kgwn2fEwix69+TueP5Y6bOUYl8EoSjGp+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IuKMGRLiGm88BsilzVCTFGaIhYFtSbvBV8u1vrXqJN2yyoR4RQdDA/Zb1swTQD598g rCVJc3FQ7Y7VY1XdSKqpQQ21JFr/GguJYA3GLsTcejVNYByc4dRVyXgNbO3K7UTTCjSM S4ozjSQ++LwHObyhr31UmFZ/l8032q8dv1ECI= MIME-Version: 1.0 Received: by 10.231.156.1 with SMTP id u1mr6216773ibw.46.1277133318306; Mon, 21 Jun 2010 08:15:18 -0700 (PDT) Sender: charles.newyork@gmail.com Received: by 10.231.200.136 with HTTP; Mon, 21 Jun 2010 08:15:18 -0700 (PDT) In-Reply-To: <4C1DFF97.1020103@gmail.com> References: <4C148FB1.8060709@gmail.com> <4C1DFF97.1020103@gmail.com> Date: Mon, 21 Jun 2010 11:15:18 -0400 X-Google-Sender-Auth: U1NiotVUXx-CrCaRiDYW3wdgxbQ Message-ID: From: Charles Shen To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 22 Jun 2010 10:15:13 -0700 Cc: Henning Schulzrinne , draft-ietf-nsis-tunnel.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11 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, 21 Jun 2010 15:15:44 -0000 X-List-Received-Date: Mon, 21 Jun 2010 15:15:44 -0000 X-List-Received-Date: Mon, 21 Jun 2010 15:15:44 -0000 Thanks Yaron, please see inline. On Sun, Jun 20, 2010 at 7:46 AM, Yaron Sheffer wrot= e: > [Removed the IESG.] > > Hi Charles, > > please see my comments inline. > > Thanks, > =C2=A0 =C2=A0Yaron > > On 06/20/2010 06:52 AM, Charles Shen wrote: >> >> Hi Yaron, thank you for your careful review. Please see comments inline. >> >> On Sun, Jun 13, 2010 at 3:58 AM, Yaron Sheffer >> =C2=A0wrote: >> > I have reviewed this document as part of the security directorate's >> > ongoing effort to review all IETF documents being processed by the IES= G. >> > These comments were written primarily for the benefit of the security >> > area directors. =C2=A0Document editors and WG chairs should treat thes= e >> > comments just like any other last call comments. >> > >> > This draft discusses the problem of NSIS messages (particularly, QoS >> > reservation flows) being encapsulated into various IP tunneling >> > protocols, >> > which prevent the correct QoS setup from being performed. The draft >> > proposes >> > a solution for NSIS tunnel-aware tunnel endpoints, which basically add= s >> > an >> > NSIS signaling flow between the tunnel endpoints, but outside of the >> > tunnel. >> > >> > General >> > >> > The draft presents the problem, and the solution, reasonably well. >> > >> > The draft goes for the "no new security issues" approach. I think this >> > is >> > incorrect, and in fact a number of security issues should be analyzed >> > and >> > possibly resolved. In addition, as a complete outsider to NSIS, I have >> > identified one major unspecified piece, leading me to believe that the >> > draft >> > has not had enough review. >> > >> > Security >> > >> > The main security issue is that the draft fails to consider >> > security-oriented tunnels. IPsec tunnels (and the commonly used >> > GRE-over-IPsec) provide security services: normally encryption and >> > integrity >> > protection with ESP, less commonly integrity-protection only with AH, >> > ESP >> > with null encryption, or the new WESP (RFC 5840). The proposed solutio= n >> > raises at least three major security issues related to these tunnels: >> > >> > 1. A so-called covert channel that results from NSIS flows in the >> > protected >> > networks directly triggering NSIS protocol exchanges in an unprotected >> > network (i.e. between the tunnel endpoints). Please see Appendix B.1 o= f >> > draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue. >> > >> >> With regard to this specific draft, I see the problem as a more >> generic issue which exists also for other protocols (e.g., RSVP) >> requiring per-hop processing to interact with IPSec. E.g., RFC4302 >> mentions that "NOTE: Use of the Router Alert option is potentially >> incompatible with use of IPsec. Although the option is immutable, its >> use implies that each router along a packet's path will "process" the >> packet and consequently might change the packet.". I think that >> mentioning of this potential incompatibility will be beneficial. But I >> don't quite see how "limiting the bandwidth of the covert channel" as >> discussed in Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 can be >> applied here. Please correct me if I were wrong. >> > You can say this solution is incompatible with IPsec and be done with it. > Otherwise, there is a "covert channel > " - someone can create spuri= ous > NSIS signaling flows within the protected network, just to create signali= ng > in the outside network, which then someone else is monitoring. For highly > secure networks, this would be seen as a way to smuggle information out o= f > the network, and you would want to rate-limit this channel. >> That makes sense. My understanding is that the rate-limit does not complete solve the problem, but does reduce the potential harm. >> > 2. A more serious interaction in the other direction: unprotected NSIS >> > flows >> > outside the tunnel interact with NSIS flows in the protected networks >> > and >> > inside the tunnel, and so, an attacker in the unprotected network can >> > possibly influence QoS behavior in protected networks. >> > >> > 3. A practical result of (2) is that the NSIS protocol stack on the >> > tunnel >> > endpoint is now exposed to unprotected networks and therefore suddenly >> > becomes security-critical. >> > >> >> IMHO, if we have a segment of the path which is compromised, the QoS >> of the rest of the path segments (and the end-to-end QoS) can be >> easily affected anyway, whether you have a tunnel segment in the path >> or not. Therefore, it doesn't seem to me as a new threat introduced by >> this document per se. But it will certainly also be helpful to mention >> this scenario in the security considerations section. > > What I'm saying in #3 is that any security vulnerability (e.g. buffer > overflow) in the NSIS stack is suddenly exposed to the big bad Internet, > even when the customer may have expected all their traffic to be protecte= d > by a VPN gateway, where the VPN software is normally the only software th= at > needs to be hardened. I agree. What I had been thinking is that compromise of other nodes (non-tunnel end-points) may similarly affect end-to-end QoS signaling, even if the end-to-end path includes a secure tunnel. >> >> > Non-Security >> > >> > The draft defines extra UDP encapsulation in some cases ("the tunnel >> > entry-point inserts an additional UDP header"), but the format >> > (specifically, the port number) is not specified. This omission is >> > strange, >> > because the protocol cannot be implemented in the absence of this >> > information! >> > >> >> To me this is an intended feature. The mechanism does not require a >> pre-allocated fixed UDP port, but allows the port to be dynamically >> chosen and conveyed during the tunnel flow/session binding operations. >> > Sure, I missed this point. Can you please mention it explicitly. > Sure! Thanks Charles From new-work-bounces@ietf.org Tue Jun 22 10:00:05 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE9128C12B; Tue, 22 Jun 2010 10:00:05 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1115F3A688A; Tue, 22 Jun 2010 10:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100622170002.1115F3A688A@core3.amsl.com> Date: Tue, 22 Jun 2010 10:00:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 22 Jun 2010 10:15:10 -0700 Subject: [secdir] [New-work] WG Review: Call Control UUI for SIP (cuss) 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, 22 Jun 2010 17:00:05 -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, June 29, 2010. Call Control UUI for SIP (cuss) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-06-21 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: TBD Description of Working Group: The Call Control UUI for SIP (CUSS) working group is chartered to define a Session Initiation Protocol (SIP) mechanism for transporting call-control related user-to-user information (UUI) between User Agents. The mechanism developed in this working group is applicable in the following situations: 1. The information is generated and consumed by an application using SIP during session setup but the application is not necessarily even SIP aware. 2. The behavior of SIP entities that support it is not significantly changed (as discussed in Section 4 of RFC 5727). 3. Generally only the User Agent Client (UAC) and User Agent Server (UAS) are interested in the information. 4. The information is expected to survive retargeting, redirection, and transfers. 5. SIP elements may need to apply policy about passing and screening the information. 6. Multi-vendor interoperability is important. This mechanism is not applicable in the following situations: 1. The behavior of SIP entities that support it is significantly changed (as discussed in Section 4 of RFC 5727). 2. The information is generated and consumed at the SIP layer by SIP elements. 3. SIP elements besides the UAC and UAS might be interested in consuming (beyond applying policy) the information. 4. There are specific privacy issues involved with the information being transported (e.g., geolocation or emergency-related information). User data of the mechanism will be clearly marked with the application, encoding, semantics, and content type, allowing policy to be applied by UAs. The working group will define the information that each application must specify to utilize the mechanism. This type of application-specific information will be specified in standards-track documents. One important application of this mechanism is interworking with the ISDN User to User Information Service. This application defined by ITU-T Q.931 is extensively deployed in the PSTN today supporting such applications as contact centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP. For interworking with ISDN, minimal information about the content of the UUI is available to the PSTN-SIP gateways. In this case only, the content will just indicate ISDN UUI Service 1 interworking rather than the actual content. Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction, and must survive proxy retargeting, redirection, and transfers. The mechanism must utilize a minimum of SIP extensions since it will need to be supported by many simple SIP user agents such as PSTN gateways. The mechanism must interwork with the existing ISDN service but should also be extensible for use by other applications and non-ISDN protocols. Even though interworking with the PSTN is an important requirement, call control UUI can be exchanged between native SIP clients that do not have any ISUP support. Therefore, existing SIP-T encapsulation-based approaches defined in RFC3372 do not meet the requirements to transport this type of information. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases. The group will produce: - A problem statement and requirements document for implementing a SIP call control UUI mechanism - A specification of the SIP extension to best meet those requirements. Goals and Milestones ==================== Sep 10 - Problem statement and requirements document to IESG (Informational) Mar 11 - SIP call control UUI specification to IESG (PS) _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Jun 22 10:15:28 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6AF28C141; Tue, 22 Jun 2010 10:15:21 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F106728C0DD; Tue, 22 Jun 2010 10:15:02 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100622171502.F106728C0DD@core3.amsl.com> Date: Tue, 22 Jun 2010 10:15:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 22 Jun 2010 10:27:22 -0700 Subject: [secdir] [New-work] WG Review: Sip ALerting for User Devices (salud) 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, 22 Jun 2010 17:15:31 -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, June 29, 2010. Sip ALerting for User Devices (salud) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-06-21 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: TBD Description of Working Group: The SALUD (Sip ALerting for User Devices) working group is chartered to define a new URN namespace that allows SIP to convey a particular alert indication using a name instead of a referenced URI. The Alert-Info URN namespace addresses issues encountered in current systems that use the Alert-Info header field. It is expected that this group will collaborate with the Applications area on the definition of the URN namespace. RFC 3261 allows a user agent server to provide a specific ringing tone, which can be played to the calling user, as a reference (e.g., an HTTP URI) in the Alert-Info header. In some situations, the calling user may not be able to understand the meaning of the ringing tone being played. For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country. Similarly, a hearing impaired person may prefer to get a visual call waiting indication instead of a call waiting tone. RFC 3261 also allows a user agent client to provide a reference to a specific alerting tone, which can be played to the called user (e.g., tones for emergency announcements sent over PBX systems or over the local telephone network). As in the previous examples, in some situations, the calling user may not be able to understand the meaning of the alerting tone being played. These issues can be resolved with a mechanism for user agents to exchange this type of alerting information in a semantic way. In this way, different user agents can use different renderings for the same semantics. For example, a user agent client instructed to inform its user about a call waiting service being provided can use the personalized tones that were previously configured by the user. Traditionally, SIP has used status codes to encode session state information (e.g., 180 Ringing). Status codes are used by SIP entities in an automatic fashion. The information this working group is concerned with is related to rendering and may not represent the state of the session. Additionally, the exchange of this information does not affect the way SIP entities process the session. That is why status codes are not an appropriate vehicle to encode this type of information. This working group will work on encoding this information in URNs. In addition to defining URNs that are associated to particular events (e.g., a call waiting service is being applied), this working group will also define URNs that describe the characteristics of the alerting to be applied (e.g., play a short tone followed by a long tone). There are a variety of non-interoperable URI conventions and proprietary Alert-Info header field parameters to provide this type of information today. A standardized set of Alert-Info URNs will increase SIP interoperability for this header field by replacing proprietary conventions. The group will produce a specification that: * describes the problem statement. * describes requirements and use cases. * defines an Alert-Info URN-scheme which allows to resolve the interoperability problems described in the use cases. * defines the specific Alert-Info URNs identifiers for some of the use cases above. The Alert-Info URN namespace must be open, so that additional Alert-Info URNs can be defined later if necessary. Goals and Milestones ==================== Aug 2011 - Alert-Info URN specification to IESG (PS) _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From CWallace@cygnacom.com Wed Jun 23 07:03:04 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6C628C0EA; Wed, 23 Jun 2010 07:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.484 X-Spam-Level: X-Spam-Status: No, score=-5.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZn+v1nGwWE0; Wed, 23 Jun 2010 07:03:02 -0700 (PDT) Received: from mail122.messagelabs.com (mail122.messagelabs.com [216.82.241.227]) by core3.amsl.com (Postfix) with SMTP id BAF1128C0EE; Wed, 23 Jun 2010 07:03:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-5.tower-122.messagelabs.com!1277301727!19100769!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.19] Received: (qmail 12158 invoked from network); 23 Jun 2010 14:02:08 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.19) by server-5.tower-122.messagelabs.com with SMTP; 23 Jun 2010 14:02:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {CCCC82B7-BF74-4862-B61F-DFBA1C4CAC3C} x-cr-hashedpuzzle: Afo6 FkuU KK// KpSy NsTd O/Nx PoHb QV2s Q63J SbgR UTww ci4t dMSM e7VK j0I4 vXZT; 4; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGkAZQBzAGcAQABpAGUAdABmAC4AbwByAGcAOwBuAHUAcgBpAHQALgBzAHAAcgBlAGMAaABlAHIAQABuAHMAbgAuAGMAbwBtADsAcwBlAGMAZABpAHIAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {CCCC82B7-BF74-4862-B61F-DFBA1C4CAC3C}; YwB3AGEAbABsAGEAYwBlAEAAYwB5AGcAbgBhAGMAbwBtAC4AYwBvAG0A; Wed, 23 Jun 2010 14:01:54 GMT; cwBlAGMAZABpAHIAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBtAHAAbABzAC0AdABwAC0AcwB1AHIAdgBpAHYAZQAtAGYAdwBrAC0AMAA2AA== Content-class: urn:content-classes:message Date: Wed, 23 Jun 2010 10:01:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-mpls-tp-survive-fwk-06 Thread-Index: AcsS3KL/HvV7N0qiTIGlzApueqbJBg== From: "Carl Wallace" To: Cc: adrian@olddog.co.uk, nurit.sprecher@nsn.com, iesg@ietf.org Subject: [secdir] secdir review of draft-ietf-mpls-tp-survive-fwk-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 14:03:04 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes the architecture and mechanisms for survivability within an MPLS-TP network. The security considerations briefly highlight aspects that are required to provide adequate security along with a reference to a security framework document that goes into much greater detail. This seems to be appropriate and sufficient for this document. From CWallace@cygnacom.com Wed Jun 23 08:02:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EAE73A6940; Wed, 23 Jun 2010 08:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.926 X-Spam-Level: X-Spam-Status: No, score=-4.926 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pufbt+jrFKv5; Wed, 23 Jun 2010 08:02:47 -0700 (PDT) Received: from mail152.messagelabs.com (mail152.messagelabs.com [216.82.253.19]) by core3.amsl.com (Postfix) with SMTP id 3CDFC3A6883; Wed, 23 Jun 2010 08:02:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-13.tower-152.messagelabs.com!1277305373!14441976!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.19] Received: (qmail 12438 invoked from network); 23 Jun 2010 15:02:54 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.19) by server-13.tower-152.messagelabs.com with SMTP; 23 Jun 2010 15:02:54 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 23 Jun 2010 11:02:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-stone-mgcp-vbd-07 Thread-Index: AcsS5SiAzRrqHLOYRH+RyifUiUWN1g== From: "Carl Wallace" To: Cc: s.sharma@cablelabs.com, rkumar@cisco.com, joestone@cisco.com, iesg@ietf.org Subject: [secdir] secdir review of draft-stone-mgcp-vbd-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:02:48 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines new MGCP packages. This document is pretty far outside my sandbox, but I did have a couple of questions and comments. - Why is this an Informational document instead of Standards track? It seems to be defining new packages that are not already defined elsewhere. - I struggled with the presentation a bit and found myself reading references to understand some of the shorthand in this document. For example, in section 3.1 the column headers are not described in this draft.=20 - The security considerations section is brief and primarily references RFC 3435, which essentially has two security considerations: use IPSec and use SDP encryption keys. The latter is not recommended in the current SDP draft. This section should directly state the security considerations it wants to assert. =20 From rjsparks@nostrum.com Wed Jun 23 14:34:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12963A6867; Wed, 23 Jun 2010 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cutFwh170K02; Wed, 23 Jun 2010 14:34:39 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EE4423A69FD; Wed, 23 Jun 2010 14:34:35 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5NLYUo9001834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Jun 2010 16:34:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Wed, 23 Jun 2010 16:34:29 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0F999805-9A9F-477D-88DD-EB2F7A6AEB1B@nostrum.com> References: To: Joseph Salowey (jsalowey) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: iesg@ietf.org, draft-ietf-sipcore-invfix.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sipcore-invfix-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, 23 Jun 2010 21:34:44 -0000 Joseph - As one of the document editors, I'd like to thank you for your review. As the document notes, the additional state that is being maintained is necessary for correct operation, and that state is taken on only when the server has decided to accept the INVITE request with a 200 OK. The techniques you point to would be useful if applied before getting to this point, and the concept is called out in the security considerations section of RFC3261 in section 26.3.2.4. I will suggest adding a pointer to that section in the security considerations in this document. Thanks! RjS On Jun 21, 2010, at 5:53 PM, Joseph Salowey (jsalowey) wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document fixes a real problem and seems to address some existing > security issues, namely the forwarding of stray responses. This is > good. It does introduce more of a possibility of denial of service > since state must be maintained to track valid responses and this is > noted in the security considerations as well. I'm not all that familiar > with SIP, but there are techniques used in other protocols to avoid > "flood" type of attacks by delaying committing state until the client > has successfully processed a server message. TCP cookies, IKEv2 and > DTLS have examples of this. This would be something to consider if > implementations were vulnerable to flood type attacks in deployments. > > > Joe From new-work-bounces@ietf.org Tue Jun 22 10:30:27 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8013A69D1; Tue, 22 Jun 2010 10:30:27 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7642B3A67D3; Tue, 22 Jun 2010 10:30:05 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100622173013.7642B3A67D3@core3.amsl.com> Date: Tue, 22 Jun 2010 10:30:05 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 24 Jun 2010 08:51:08 -0700 Subject: [secdir] [New-work] WG Review: Loosely-coupled SIP Devices (LSD) 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, 22 Jun 2010 17:30:28 -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, June 29, 2010. Loosely-coupled SIP Devices (LSD) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-06-21 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: TBD Description of Working Group: Loosely-coupled SIP Devices (LSD) -------------------------------------------- Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams coming from different devices under his or her control so that they are treated by the far end of the session as a single media session. Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the multimedia session. There are a number of existing mechanisms that can be used to coordinate different devices under user's control and to involve them in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] and SIP 3pcc [RFC3725]). However, these mechanisms are intended to be used in "tightly coupled" scenarios. The use of all those mechanisms requires the presence of a "master" device. That is, at least one among the different devices under the control of the same user must support the control mechanism and be able to become a controller for the other devices in the call. Moreover, the "master" device is supposed to remain involved in the user's session for its entire duration given that performing a handover of the master role is typically cumbersome and sometimes impossible. The objective of this working group is to develop a framework for disaggregated media in "loosely-coupled" scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master. Coordination among devices in this type of scenario is less tight than in the scenarios described above since they do not assume central elements with complete knowledge of the whole media session. While the framework may describe how to use existing mechanisms (e.g., the SIP REFER method) to coordinate devices, the working group will not develop new device coordination mechanisms. The framework may identify the need for new (non-device-coordination) mechanisms to enable the implementation of loosely-coupled scenarios. In case the need for such new mechanisms is identified, the working group will specify them. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key considerations for the exchange of disaggregated media in SIP. The document will include use cases and examples. The document may indentify the need for new mechanisms or extensions to existing mechanisms. 2. Specifications of new mechanisms or extensions to existing mechanisms if the need is identified in the framework. Goals and Milestones ==================== Feb 2011 - Framework document sent to the IESG (Informational) _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From vincent.roca@inrialpes.fr Fri Jun 25 04:05:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5131D3A6895; Fri, 25 Jun 2010 04:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21qyy8k1ewtr; Fri, 25 Jun 2010 04:05:56 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id D7A373A67C0; Fri, 25 Jun 2010 04:05:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,480,1272837600"; d="scan'208";a="62125894" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 25 Jun 2010 13:06:02 +0200 Message-ID: <4C248D9A.5080508@inrialpes.fr> Date: Fri, 25 Jun 2010 13:06:02 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-dns-options-bis.all@tools.ietf.org Subject: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 11:05:58 -0000 Dear All, 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. IMHO current proposal generates additional security threats, as explained below: ** Section 7 "Security considerations" I don't share all the ideas of the authors. If I understand the point of view, the authors say that the situation is not worse than before, without these DNS options. "...learning DNS information via the RA options cannot be worse than learning bad router information via the RA options." Well, it depends on the security level we consider... >From the point of view of the ND protocol itself, I agree. But from the end user point of view, the situation is quite different, since sending forged packets (for instance) and controlling which DNS server is trusted by the client opens the way to, for instance, fishing attacks. This attack enables an attacker to make a client use a compromised DNS server that behaves perfectly except for one particular DNS query. If the attacker can send an email to this client, then many things can happen. This attack could be launched e.g. during next IETF plenary ;-). The attacker knows the email off all participants, so if he can control their DNS configuration as well, many things may happen... IMHO a serious threat is introduced by this document that needs to be seriously discussed. ** Section 7: Another point... the authors explain than network devices like switches can be configured in such a way to disable ND/DHCP from some ports. That's great and I agree it helps preventing attacks. However this is limited to wired networks. Nothing is said concerning ND configurations in wireless networks. The situation is rather different since any host can issue ND/DHCP traffic as if it were a legitimate server if I understand correctly. The document MUST include this kind of discussion. ** Section 7: Yet another remark: SEND is listed as one potential solution to add signatures in ND packets issued from servers. I don't know SEND at all, so may be my remarks are flawed (but in that case the text should be at least clarified). - Shouldn't the use of SEND be RECOMMENDED as a solution to mitigate attacks? Current document is not clear. - Does SEND enable an authentication of the sender (the document only mentions integrity protection)? If there's no sender authentication, then I agree that the added value of SEND would be limited. I'd like the authors to clarify this as well. ** Section 7: Finally, I have the feeling that the text describing the two attacks in first paragraph (i.e. (1) pretend to be the legitimate server by fooling the switch, and (2) simply send RA packets) should be improved. The authors may say explicitly they consider two ND attacks (in order to show that an attack is feasible and easy if no counter measure is taken), and then describe them in specific bullets. The current description of (1) also says that this attack can be used to "tell the hosts to send their traffic somewhere else." I agree but we need to focus here on attacks that target DNS, not the client routing part. It adds some confusion to the text ** Section 5.3.1 "Procedure of DNS configuration" In the DNS option processing, it's probably worth mentioning that the RDNSS/DNSSL lifetime entries MUST be carefully checked. Otherwise an attacker can easily send RA with very short lifetimes to make legitimate DNS entries quickly timeout in a client and replace them with his own entries that point to a corrupted DNS server. This raises another question: can an existing entry be revised before its expiration? In current text, I read: "If the DNS options are valid, the host SHOULD copy the values of the options into the DNS Repository and the Resolver Repository..." Copy is automatic once the option is validated. It's perhaps too permissive. ** Section 5.3.1 "Procedure of DNS configuration" It is said that: "In the case where the DNS options of RDNSS and DNSSL can be obtained from multiple sources, such as RA and DHCP, the IPv6 host can keep some DNS options from RA and some from DHCP..." Well, this strategy is a little bit strange. Why should it be so and not something else? If the use of solution 1 is more secure than solution 2, then the document should say that solution 1 is RECOMMENDED. This is not the case for the moment. Also what happens if several ND servers send RA with different DNS options (e.g. one is sent by a valid ND server and the other one by the attacker)? This is not considered in the above paragraph. I hope these comments will be useful in improving the document. Best regards, Vincent From weiler@watson.org Fri Jun 25 08:55:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B993A693F for ; Fri, 25 Jun 2010 08:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.538 X-Spam-Level: X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-5Pxvch7qC8 for ; Fri, 25 Jun 2010 08:55:53 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 1F7EC3A67CC for ; Fri, 25 Jun 2010 08:55:52 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o5PFu1Sq022095 for ; Fri, 25 Jun 2010 11:56:01 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o5PFu0Ga022091 for ; Fri, 25 Jun 2010 11:56:00 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 25 Jun 2010 11:56:00 -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, 25 Jun 2010 11:56:01 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 15:55:54 -0000 Glen Zorn is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-07-01 Richard Barnes TR2010-06-29 draft-ietf-behave-turn-ipv6-09 Sandy Murphy T 2010-06-29 draft-ietf-csi-proxy-send-04 Magnus Nystrom T 2010-06-29 draft-c1222-transport-over-ip-03 Radia Perlman T 2010-06-29 draft-ietf-nsis-applicability-mobility-signaling-18 Vincent Roca T 2010-06-29 draft-ietf-6man-dns-options-bis-03 For telechat 2010-07-15 Larry Zhu T 2010-07-13 draft-ietf-opsawg-mpls-tp-oam-def-06 Last calls and special requests: Love Hornquist-Astrand 2010-04-07 draft-ietf-eai-mailinglist-06 Julien Laganier 2010-06-15 draft-ietf-behave-v6v4-xlate-stateful-11 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Stefan Santesson 2010-07-07 draft-ietf-proto-wgdocument-states-07 Tina TSOU 2010-07-09 draft-mcgrew-fundamental-ecc-03 Brian Weis 2010-07-16 draft-daboo-srv-caldav-05 Nico Williams 2010-07-16 draft-turner-suiteb-cmc-02 Tom Yu 2010-07-08 draft-ietf-netmod-yang-usage-07 Kurt Zeilenga 2010-07-23 draft-hammer-hostmeta-13 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-07 From rbarnes@bbn.com Fri Jun 25 11:49:07 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B103A6897; Fri, 25 Jun 2010 11:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.533 X-Spam-Level: X-Spam-Status: No, score=-0.533 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coYONAXV-LL1; Fri, 25 Jun 2010 11:49:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DF15A3A683D; Fri, 25 Jun 2010 11:49:01 -0700 (PDT) Received: from ros-dhcp192-1-51-71.bbn.com ([192.1.51.71]:50812) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OSDxd-000NrT-7O; Fri, 25 Jun 2010 14:49:10 -0400 Message-Id: <47C35048-FF47-4E92-821B-6EB21343B9B1@bbn.com> From: "Richard L. Barnes" To: Simon Perreault In-Reply-To: <4BBBD185.7090606@viagenie.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 25 Jun 2010 14:49:07 -0400 References: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> <4BBBD185.7090606@viagenie.ca> X-Mailer: Apple Mail (2.936) Cc: draft-ietf-behave-turn-ipv6@tools.ietf.org, "behave@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-ipv6-09 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, 25 Jun 2010 18:49:07 -0000 Hi Simon, Just following up, since this draft is up for telechat next week. Still waiting to see a revision with the agreed comments. >> Section 9, >> Might some of the Teredo / 6to4 loop attacks apply as well? If >> not, why >> not? >> -- Spoof 4-to-6 allocate request from relay's v4 address >> -- Spoof authorization relay's v6 address >> -- Spoof packet from either of relay's addresses > > Sure, these are ways of spoofing IPv6 packets that are enabled by > Teredo > and 6to4. There are many others. Is there a reference we can cite? > Would > citing the Usenix paper be OK? I think it makes sense to describe the attack here, because it's not the same as the Usenix attack. Here's how it works. Consider the following setup: +--------------------------------+ | | | 2001:DB8::1 2001:DB8::2 | +-----------------+ +------------+ | Tunnel Endpoint | | TURN Relay | +-----------------+ +------------+ | 192.0.2.1 192.0.2.2 | | | +--------------------------------+ Suppose an attacker knows that a tunnel endpoint will forward encapsulated packets from a given IPv6 address (this doesn't necessarily need to be the tunnel endpoint's address). Suppose he then spoofs two packets from this address: 1. An allocate request asking for a v4 address, and 2. A ChannelBind request establishing a channel to the IPv4 address of the tunnel endpoint Then he has set up an amplification attack: -- The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it to the tunnel endpoint -- The tunnel endpoint will decapsulate packets from the v4 interface and send them to v6 So if the attacker sends a packet of the following form... IPv6: src=2001:DB9::1 dst=2001:DB8::2 UDP: TURN: IPv6: src=2001:DB9::1 dst=2001:DB8::2 UDP: TURN: IPv6: src=2001:DB9::1 dst=2001:DB8::2 UDP: TURN: ... Then the TURN relay and the tunnel endpoint will send it back and forth until the last TURN header is consumed, at which point the TURN relay will send an empty packet, which the tunnel endpoint will drop. The amplification potential here is limited by the MTU, so it's not huge: IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one amplification out of a 1500-byte packet. But the attacker could still increase traffic volume by sending multiple packets or by establishing multiple channels spoofed from different addresses behind the same tunnel endpoint. This attack is kind of like the TURN loop attack in RFC 5766 (which definitely still applies here!), but nicer for the attacker, since the attacker never needs to see the response to a spoofed packet, since he doesn't care about the relayed-transport address. I think the moral here is that TURN relays shouldn't be involved in tunnels -- no need for two v4/v6 compatibility measures at once. So I would suggest the document say something like: " It is RECOMMENDED that TURN relays not accept allocation or channel binding requests from addresses known to be tunneled, and that they not forward data to such addresses. In particular, a TURN relay MUST NOT accept Teredo or 6to4 addresses in these requests. " From secdir-bounces@mit.edu Sat Jun 26 02:36:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565633A690D for ; Sat, 26 Jun 2010 02:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=1.249, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM0W9Ovy1ErR for ; Sat, 26 Jun 2010 02:36:19 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 6C4C63A68F6 for ; Sat, 26 Jun 2010 02:36:18 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5Q9aOWH017615 for ; Sat, 26 Jun 2010 05:36:24 -0400 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5Q9aKHA017601 for ; Sat, 26 Jun 2010 05:36:20 -0400 Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o5Q9aCum003692 for ; Sat, 26 Jun 2010 05:36:20 -0400 X-AuditID: 12074422-b7b0eae000000a2e-33-4c25ca1347ef Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with SMTP id E6.12.02606.31AC52C4; Sat, 26 Jun 2010 05:36:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 331652CCCF; Sat, 26 Jun 2010 12:36:16 +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 ODhtqa1NJbbX; Sat, 26 Jun 2010 12:36:15 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 33EC12CC62; Sat, 26 Jun 2010 12:36:09 +0300 (EEST) Message-ID: <4C25CA06.1080809@piuha.net> Date: Sat, 26 Jun 2010 12:36:06 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Vincent Roca References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> In-Reply-To: <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> X-Brightmail-Tracker: AAAAAhTf0JkU4LMb X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Jaehoon Jeong , "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" , "secdir@mit.edu" , IESG Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 09:36:45 -0000 Vincent, Thank you for your review! I have some comments on the issues that you raise below as well as some suggested new text: > ** Section 7 "Security considerations" > I don't share all the ideas of the authors. If I understand the point > of view, the authors say that the situation is not worse than before, > without these DNS options. > "...learning DNS information via the RA options cannot be worse than > learning bad router information via the RA options." > > Well, it depends on the security level we consider... > >From the point of view of the ND protocol itself, I agree. But from > the end user point of view, the situation is quite different, since > sending forged packets (for instance) and controlling which DNS server > is trusted by the client opens the way to, for instance, fishing > attacks. This attack enables an attacker to make a client use a > compromised DNS server that behaves perfectly except for one particular > DNS query. If the attacker can send an email to this client, then many > things can happen. This attack could be launched e.g. during next IETF > plenary ;-). The attacker knows the email off all participants, so if > he can control their DNS configuration as well, many things may > happen... IMHO a serious threat is introduced by this document that > needs to be seriously discussed. > I agree that in general the ability to redirect specific traffic instead of all traffic is an interesting attack. However, in this case the specific attack already exists in plain ND. If you want to redirect DNS server traffic to a malicious node, this can be done not just with RA DNS options, but also with ICMP Redirects or unsolicited Neighbor Advertisements. > ** Section 7: > Another point... the authors explain than network devices like > switches can be configured in such a way to disable ND/DHCP from > some ports. That's great and I agree it helps preventing attacks. > However this is limited to wired networks. Nothing is said concerning > ND configurations in wireless networks. The situation is rather > different since any host can issue ND/DHCP traffic as if it were a > legitimate server if I understand correctly. The document MUST > include this kind of discussion. > But this is generic issue with spoofing RAs and I am not sure it is the task of this document to specify the solutions. One solution exists in SEND (RFC 3791). > ** Section 7: > Yet another remark: SEND is listed as one potential solution to > add signatures in ND packets issued from servers. > I don't know SEND at all, so may be my remarks are flawed (but in > that case the text should be at least clarified). > - Shouldn't the use of SEND be RECOMMENDED as a solution to > mitigate attacks? Current document is not clear. > - Does SEND enable an authentication of the sender (the document > only mentions integrity protection)? If there's no sender > authentication, then I agree that the added value of SEND would be > limited. I'd like the authors to clarify this as well. > The details are in RFC 3791 and its companion documents. SEND does enable a host to verify that the sender of an RA is actually a router authorized to act as a router. All this being said I also re-read the Security Considerations section, and was not super happy with it myself. I would suggest the following change: OLD: Also, an attacker could configure a host to send out an RA with a fraudulent RDNSS address, which is presumably an easier avenue of attack than becoming a rogue router and having to process all traffic for the subnet. It is necessary to disable the RA RDNSS option or DNSSL option in both routers and clients administratively to avoid this problem. All of this can be done independently of implementing ND. Therefore, it can be claimed that the RA options for RDNSS and DNSSL has vulnerabilities similar to those existing in unauthenticated DHCPv6. NEW: Also, an attacker could send an RA with a fraudulent RDNSS address, which is presumably an easier avenue of attack than becoming a rogue router and having to process all traffic for the subnet. This attack is similar to Neighbor Discovery attacks that use Redirect or Neighbor Advertisement messages to redirect traffic to individual addresses to malicious parties. In general, the attacks related to RDNS and DNSSL are similar to both Neighbor Discovery attacks and attacks against unauthenticated DHCP, as both can be used for both "wholesale" traffic redirection and more specific attacks. Jari _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From gonzalo.camarillo@ericsson.com Sat Jun 26 09:33:28 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BE23A692E for ; Sat, 26 Jun 2010 09:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.749 X-Spam-Level: X-Spam-Status: No, score=-101.749 tagged_above=-999 required=5 tests=[AWL=-1.977, BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227, 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 Y109Wy9xsnS0 for ; Sat, 26 Jun 2010 09:33:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 00DC53A691B for ; Sat, 26 Jun 2010 09:33:26 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-3e-4c262bde7e01 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2C.AB.19600.EDB262C4; Sat, 26 Jun 2010 18:33:34 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Jun 2010 18:32:43 +0200 Received: from [131.160.126.160] ([131.160.126.160]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 26 Jun 2010 18:25:45 +0200 Message-ID: <4C262A09.5070008@ericsson.com> Date: Sat, 26 Jun 2010 19:25:45 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Elwell, John" References: <201006220148.o5M1mdgA006857@fermat.rhmr.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2010 16:25:45.0451 (UTC) FILETIME=[3A919BB0:01CB154C] X-Brightmail-Tracker: AAAAAA== Cc: "secdir@ietf.org" , "Bernard_Aboba@hotmail.com" , "hkaplan@acmepacket.com" , "spencer@wonderhamster.org" , "rjsparks@nostrum.com" Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 16:33:28 -0000 Hi John, please, agree with Hilarie on how to address these comments and submit a new revision of the draft. Please, also include any other IETF LC comments you have received. I have updated the draft's state in the tracker to Revised ID Needed. Thanks, Gonzalo On 22/06/2010 9:43 AM, Elwell, John wrote: > Hilarie, > > Thanks for your review. See responses below: > >> -----Original Message----- >> From: hilarie@purplestreak.com >> [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman >> Sent: 22 June 2010 02:49 >> To: secdir@ietf.org >> Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org; >> gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; Elwell, >> John; hkaplan@acmepacket.com >> Subject: review of draft-ietf-martini-reqs-07.txt >> >> Security review of draft-ietf-martini-reqs-07.txt, >> Multiple AOR reachability in SIP >> >> Do not be alarmed. I have reviewed this document as part of the >> security directorate's ongoing effort to review all IETF documents >> being processed by the IESG. These comments were written primarily >> for the benefit of the security area directors. Document editors and >> WG chairs should treat these comments just like any other last call >> comments. >> >> The abstract: >> This document states requirements for a standardized SIP registration >> mechanism for multiple addresses of record, the mechanism being >> suitable for deployment by SIP service providers on a large scale in >> support of small to medium sized Private Branch Exchanges (PBXs). >> The requirements are for a solution that can, as a minimum, support >> AORs based on E.164 numbers. >> >> There are 21 requirements, and two of them address security. >> >> I think requirement 14 leaves out a couple of things: >> REQ14 - The mechanism MUST be able to operate over a transport that >> provides integrity protection and confidentiality. >> It should probably require "end-to-end" integrity protection and >> confidentiality between the two entities (SIP-PBX and the SSP). > [JRE] In the next version I will change it to: > "The mechanism MUST be able to operate over a transport that provides end-to-end integrity protection and confidentiality between the SIP-PBX and the SSP." > >> >> And I think requirement 15 should say something about how the two >> entites are expected to agree on an authentication method, and that >> the authentication should apply to every registration message >> exchanged by the entities. That is, once they have authenticated, >> then that information should be tied to requirement 14 and ensure that >> the integrity and/or confidentiality is defined between the two >> entities (by use of, for example, an authenticated key exchange >> protocol) on all subsequent messages between the two. > [JRE] I am reluctant to make any changes here. We don't anticipate any new security mechanism, and indeed the solution that is moving forward in the WG allows use of TLS, which is already allowed for in SIP. For authentication it allows both TLS mutual authentication or SIP digest authentication + TLS server authentication, again, in line with what is already allowed in SIP. SIP has a wealth of material in this area, including aspects of RFC 3263 and RFC 3329. I don't think it worthwhile adding a bunch of requirements that in the end will not lead to any new mechanisms or influence use of existing mechanisms. REQ14 and REQ15 I think are sufficient pointers to needs in this area. > >> REQ15 - The mechanism MUST support authentication of the SIP-PBX by >> the SSP and vice versa. >> I'd also add that it MUST support termination of authenticaton and >> re-authentication. > [JRE] I am not sure exactly what you are looking for here. Is this referring to what happens when a certificate expires, say? Again, I would doubt we really need to add anything here, since we don't anticipate new security mechanisms. > >> >> Minor non-security things: >> >> Requirement 4 has a triple negative ("not" "prevent" "without"), and >> I'm not sure what the heck it means. > [JRE] Yes, in the next version I will change it to: > "The mechanism MUST allow UAs attached to a SIP-PBX to register with the SIP-PBX for AORs based on assigned telephone numbers, in order to receive requests targeted at those telephone numbers, without needing to involve the SSP in the registration process." > >> >> Requirement 5 has a typo, probably "internally" for "internal". > [JRE] It intentionally says "internally" at present - an adverb modifying the verb "handle". I am not sure how to reword it to prevent misinterpretation. > > John > > >> >> Hilarie From magnusn@gmail.com Sun Jun 27 10:31:05 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB563A693B; Sun, 27 Jun 2010 10:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OHa0MdRbzNV; Sun, 27 Jun 2010 10:31:04 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DE44B3A6929; Sun, 27 Jun 2010 10:31:01 -0700 (PDT) Received: by gyh4 with SMTP id 4so6050941gyh.31 for ; Sun, 27 Jun 2010 10:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=j7edmXkX8io2RWmsIqruSY+Ti4HZC0ZAjNL/iC6YkSg=; b=FwVKmtR5GGkvKtSwZRFA1IFhjnooVyYfMaqXGDUPJQCw7k54ukMwKGFUjW5NWfEfXC 67/Rn+67N/jW31F5tOWIWZpQkrLvN3UlruSY1YiHSqmbbKrN4cVd2sQ5xBQWTu2xuqzN tQB5MEktyOFMIlqzveBLN0zAshh539CxV6/Ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=uWKDeY3vZG94iDU3NkPbIKnh5ZP1iQitLb+7piHqomC42+pYYF5uU0tsnRTo2AXnwQ PVLMuw2MMcofEfp/HEHI2UdCL7/jn+3LSwhhnOZOACuk/PqpjOZU33souz1qR/jNKo8P 0kumx6CGnVy9DKe6fWQKVn1o5OlgnaHmnlAPQ= MIME-Version: 1.0 Received: by 10.100.110.10 with SMTP id i10mr754093anc.152.1277659868142; Sun, 27 Jun 2010 10:31:08 -0700 (PDT) Received: by 10.100.124.16 with HTTP; Sun, 27 Jun 2010 10:31:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Jun 2010 10:31:08 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: secdir@ietf.org, iesg@ietf.org, draft-c1222-transport-over-ip.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 17:31:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily for the benefit of the security area directors. =A0Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a framework for transporting ANSI C12.22 advanced metering infrastructure (AMI) messages on IP networks. AMI is intended for interaction with various types of utility meters; as such, it is clear that security services such as data authenticity, integrity and confidentiality will be quite important. This draft defers to ANSI C12.22 for application-layer security and states that any transport (or IP) network layer security security functionality shall act "only to enhance and preserve [and] ... not be a substitute for ... ANSI C12.22 ... security provisions." This is all good but I have not had access to C12.22 for this review and so cannot comment further on it. It seems to me, however, that the layering of C12.22 on top of IP networks may warrant a discussion about potential methods to enhance C12.22 security? For example, could privacy be enhanced beyond what C12.22 offers through use of a transport network's confidentiality services? Other than this I have no particular comments on this draft; it reads good to me. -- Magnus From phoffman@imc.org Sun Jun 27 14:44:53 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160373A6980; Sun, 27 Jun 2010 14:44:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char F6 hex): To: Magnus Nystr\366m In-Reply-To: References: Date: Sun, 27 Jun 2010 14:44:57 -0700 To: Magnus Nyström , secdir@ietf.org, iesg@ietf.org, draft-c1222-transport-over-ip.all@tools.ietf.org From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: Re: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 21:44:53 -0000 Given that I have made this same copy-and-paste error in the past: this review is for draft-c1222-transport-over-ip, not the one in the Subject: line. At 10:31 AM -0700 6/27/10, Magnus Nyström wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >This document defines a framework for transporting ANSI C12.22 >advanced metering infrastructure (AMI) messages on IP networks. > >AMI is intended for interaction with various types of utility meters; >as such, it is clear that security services such as data authenticity, >integrity and confidentiality will be quite important. This draft >defers to ANSI C12.22 for application-layer security and states that >any transport (or IP) network layer security security functionality >shall act "only to enhance and preserve [and] ... not be a substitute >for ... ANSI C12.22 ... security provisions." This is all good but I >have not had access to C12.22 for this review and so cannot comment >further on it. It seems to me, however, that the layering of C12.22 >on top of IP networks may warrant a discussion about potential methods >to enhance C12.22 security? For example, could privacy be enhanced >beyond what C12.22 offers through use of a transport network's >confidentiality services? > >Other than this I have no particular comments on this draft; it reads >good to me. >-- Magnus >_______________________________________________ >secdir mailing list >secdir@ietf.org >https://www.ietf.org/mailman/listinfo/secdir From radiaperlman@gmail.com Sun Jun 27 15:36:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413563A6A07; Sun, 27 Jun 2010 15:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqMVvZPsQI+P; Sun, 27 Jun 2010 15:35:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8945A3A6A06; Sun, 27 Jun 2010 15:35:58 -0700 (PDT) Received: by iwn35 with SMTP id 35so211228iwn.31 for ; Sun, 27 Jun 2010 15:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=Lz3lCZuDcVvnXsJ5UsOlHmO+J4Ond+WCDd4GQveAm38=; b=O06jSEGo1djb6icPzilMyYnrjOEALyzwmGxfdeCnXNCaR2HzZEfMo2bPSGBr82SK29 xJRF2eDcvL2SuYvppm7OOtGCtGFpcVJ1wJcd1m6zqKEQusoBhJden6LrS4YKcjsXmfwm gLGwvliJBpLVv9igYcunp2fiZS1apRtoJ5iBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=JYEnlXln46boBC4oo8S6tKp/p7OaIBmpQxgXkYF5jZVYgD57dXYSsMF0Te+hrJ6LHA KqvypGr6tnouIcOF6PIX43kUnt9ymbP4seqFjFEm52u/4kK0bvRHwCKjp1HcAjYtJ77/ etYGzYGdWkHwB2elCDbCnWRy8DUrDGoDN3p+M= MIME-Version: 1.0 Received: by 10.231.149.202 with SMTP id u10mr4500243ibv.56.1277678168227; Sun, 27 Jun 2010 15:36:08 -0700 (PDT) Received: by 10.231.79.149 with HTTP; Sun, 27 Jun 2010 15:36:08 -0700 (PDT) Date: Sun, 27 Jun 2010 15:36:08 -0700 Message-ID: From: Radia Perlman To: secdir@ietf.org, iesg@ietf.org, draft-ietf-nsis-applicability-mobility-signaling@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [secdir] Secdir review of draft-ietf-nsis-applicability-mobility-signaling-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 22:36:00 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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 sufficiently abstract that it=92s not clear how one would explicitly state =93Security Considerations=94. It is targeting informational status and essentially lists example scenarios where mobility protocols and NSIS protocols might interact and what problems one might face in trying to resolve them. An example (perhaps the simplest case) might be where a mobile node has reserved bandwidth to some server for the streaming of a video and then the mobile node moves. While a simple solution would be to tear down the old connection and set up a new one, the handover potentially be faster and more efficient if there were a way to avoid updating routers that were along both the old and new paths. This requires, for example, that routers be able to identify the connection by something other than the Source and Destination IP addresses and ports (since those will change). While the integration will undoubtedly introduce security challenges, it=92s not obvious whether there will be new ones or whether they are the same security challenges faced by mobility protocols and NSIS independently. Section 3.7 explicitly mentions authorization issues if the required state changes are determined by a different entity that was involved before. As the designs become more concrete (in future standards track RFCs), they will face more concrete problems, but for now I believe their =93no new security issues=94 claim is probably right. From magnusn@gmail.com Sun Jun 27 21:19:26 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D963A689B; Sun, 27 Jun 2010 21:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIzSWaCiz0Qy; Sun, 27 Jun 2010 21:19:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id CBF943A6884; Sun, 27 Jun 2010 21:19:24 -0700 (PDT) Received: by gxk5 with SMTP id 5so26374gxk.31 for ; Sun, 27 Jun 2010 21:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=6y7g623n/OiDrfddRi272uuSAhr8IZP7tccXcO6s6PI=; b=hRqQD+5EY6YICgzHDJRXDPU6oG75I3WadnN4HluQ/Uv942pN0AoEy3ldtyUs6ox3eD HbaFtxWTtqhZqgtPq4LRFABDGNknCkuXzCAIwhb7uCTXTqL+RPVS1LinLAQGNAJftLe8 MnIMYgGcRTaGqKsCDqjARLOqJAcocEVE4NYl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JC5IEAeRSj3R2XnAzC+4WxKLv6YLHPDCfm6AhPpnDArozPDeXBRx15VoHbFhy3Ms6i Px7Cf64XN6VySone0l50Usi0zZ1ITZu/5VnCmfWxeg5XvuzWXKGajNK0J28IJnkJ714+ 7dLwjabCB/5cVI4mMn7drh/lNYEy7rRwMjR9E= MIME-Version: 1.0 Received: by 10.101.203.27 with SMTP id f27mr5529023anq.239.1277698770198; Sun, 27 Jun 2010 21:19:30 -0700 (PDT) Received: by 10.100.124.16 with HTTP; Sun, 27 Jun 2010 21:19:30 -0700 (PDT) Date: Sun, 27 Jun 2010 21:19:30 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: iesg@ietf.org, draft-c1222-transport-over-ip.all@tools.ietf.org, secdir@ietf.org Subject: [secdir] Secdir review of draft-c1222-transport-over-ip [WAS: Re: Secdir review of draft-altmann-tls-channel-bindings-10] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 04:19:26 -0000 Yes, sorry about that - it is for the draft-c1222 .../Magnus On Sun, Jun 27, 2010 at 2:44 PM, Paul Hoffman wrote: > Given that I have made this same copy-and-paste error in the past: this r= eview is for draft-c1222-transport-over-ip, not the one in the Subject: lin= e. > > At 10:31 AM -0700 6/27/10, Magnus Nystr=F6m 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. =A0These comments were written primarily for the benefit of the >>security area directors. =A0Document editors and WG chairs should treat >>these comments just like any other last call comments. >> >>This document defines a framework for transporting ANSI C12.22 >>advanced metering infrastructure (AMI) messages on IP networks. >> >>AMI is intended for interaction with various types of utility meters; >>as such, it is clear that security services such as data authenticity, >>integrity and confidentiality will be quite important. =A0This draft >>defers to ANSI C12.22 for application-layer security and states that >>any transport (or IP) network layer security security functionality >>shall act "only to enhance and preserve [and] ... not be a substitute >>for ... ANSI C12.22 ... security provisions." This is all good but I >>have not had access to C12.22 for this review and so cannot comment >>further on it. It seems to me, however, that the layering of C12.22 >>on top of IP networks may warrant a discussion about potential methods >>to enhance C12.22 security? For example, could privacy be enhanced >>beyond what C12.22 offers through use of a transport network's >>confidentiality services? >> >>Other than this I have no particular comments on this draft; it reads >>good to me. >>-- Magnus >>_______________________________________________ >>secdir mailing list >>secdir@ietf.org >>https://www.ietf.org/mailman/listinfo/secdir > > --=20 -- Magnus From CWallace@cygnacom.com Mon Jun 28 05:34:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C13B3A6989; Mon, 28 Jun 2010 05:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.847 X-Spam-Level: X-Spam-Status: No, score=-4.847 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMxYQbIhOlxq; Mon, 28 Jun 2010 05:34:14 -0700 (PDT) Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by core3.amsl.com (Postfix) with SMTP id 610F73A659A; Mon, 28 Jun 2010 05:34:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-9.tower-75.messagelabs.com!1277728462!25008556!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.25] Received: (qmail 7998 invoked from network); 28 Jun 2010 12:34:23 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.25) by server-9.tower-75.messagelabs.com with SMTP; 28 Jun 2010 12:34:23 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB16BE.3C4E4E19" Content-class: urn:content-classes:message Date: Mon, 28 Jun 2010 08:34:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF4A7B323@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-stone-mgcp-vbd-07 Thread-Index: AcsS5SiAzRrqHLOYRH+RyifUiUWN1gDVoMPQACCH8CA= References: <76AC5FEF83F1E64491446437EA81A61F7CF4A7B323@srvxchg> From: "Carl Wallace" To: "Sandeep Sharma" , Cc: "Flemming Andreasen \(fandreas\)" , rkumar@cisco.com, joestone@cisco.com, iesg@ietf.org, Sumanth Channabasappa Subject: Re: [secdir] secdir review of draft-stone-mgcp-vbd-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 12:34:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB16BE.3C4E4E19 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Informational track is fine, I was just asking why it was chosen. =20 =20 If you and the ADs are satisfied that the presentation of things like the table in 3.1 is sufficiently descriptive that's fine with me (though I'd prefer at least an explicit reference for some of the shorthand). =20 =20 I have no other items to add to security considerations, your proposed changes sound good. =20 From: Sandeep Sharma [mailto:S.Sharma@CableLabs.com]=20 Sent: Sunday, June 27, 2010 5:17 PM To: Carl Wallace; secdir@ietf.org Cc: iesg@ietf.org; rkumar@cisco.com; joestone@cisco.com; 'Flemming Andreasen (fandreas)'; Sumanth Channabasappa Subject: RE: secdir review of draft-stone-mgcp-vbd-07 =20 Carl, =20 Thanks for the review comments. I consulted with the co-authors and Flemming and our responses are indicated below. =20 -----Original Message----- From: Carl Wallace [mailto:CWallace@cygnacom.com]=20 Sent: Wednesday, June 23, 2010 9:03 AM To: secdir@ietf.org Cc: iesg@ietf.org; rkumar@cisco.com; joestone@cisco.com; Sandeep Sharma Subject: secdir review of draft-stone-mgcp-vbd-07 =20 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. =20 This document defines new MGCP packages. This document is pretty far outside my sandbox, but I did have a couple of questions and comments. =20 - Why is this an Informational document instead of Standards track? It seems to be defining new packages that are not already defined elsewhere. =20 SJS> MGCP (RFC 3435) and other MGCP packages are Informational RFCs, so it seems consistent to have this one being informational as well. =20 - I struggled with the presentation a bit and found myself reading references to understand some of the shorthand in this document. For example, in section 3.1 the column headers are not described in this draft.=20 =20 SJS> This is a standard MGCP package format as defined in RFC 3435 (Section 6, and in this case Section 6.6 in particular) =20 - The security considerations section is brief and primarily references RFC 3435, which essentially has two security considerations: use IPSec and use SDP encryption keys. The latter is not recommended in the current SDP draft. This section should directly state the security considerations it wants to assert. =20 =20 SJS> We agree with your comments about SDP encryption keys (RFC 3435 Section 5.1). We will call out IPsec specifically and then add a few paragraphs about ways to more adequately protect RTP media streams these days (SRTP which should probably have at least a "SHOULD" recommendation here) as well as some of the specific issues that may arise if an attacker is able to modify/inject VBD data in the RTP media stream. We would also greatly appreciate if you can provide additional guidance/considerations (if any) that you believe should be addressed. ------_=_NextPart_001_01CB16BE.3C4E4E19 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Informational track is fine, I was just asking why it was = chosen. 

 

If you and the ADs are satisfied that the presentation of = things like the table in 3.1 is sufficiently descriptive that’s fine with = me (though I’d prefer at least an explicit reference for some of the shorthand).  =

 

I have no other items to add to security considerations, = your proposed changes sound good.

 

From:= Sandeep = Sharma [mailto:S.Sharma@CableLabs.com]
Sent: Sunday, June 27, 2010 5:17 PM
To: Carl Wallace; secdir@ietf.org
Cc: iesg@ietf.org; rkumar@cisco.com; joestone@cisco.com; = 'Flemming Andreasen (fandreas)'; Sumanth Channabasappa
Subject: RE: secdir review of = draft-stone-mgcp-vbd-07

 

Carl,

 

Thanks for the review comments. I consulted with = the co-authors and Flemming and our responses are indicated = below.

 

-----Original Message-----
From: Carl Wallace [mailto:CWallace@cygnacom.com]
Sent: Wednesday, June 23, 2010 9:03 AM
To: secdir@ietf.org
Cc: iesg@ietf.org; rkumar@cisco.com; joestone@cisco.com; Sandeep = Sharma
Subject: secdir review of draft-stone-mgcp-vbd-07

 

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 new MGCP packages.  = This document is pretty far

outside my sandbox, but I did have a couple of = questions and comments.

 

- Why is this an Informational document instead = of Standards track?  It

seems to be defining new packages that are not = already defined

elsewhere.

 

SJS> MGCP (RFC = 3435) and other MGCP packages are Informational RFCs, so it seems consistent to = have this one being informational as well.

 

- I struggled with the presentation a bit and = found myself reading

references to understand some of the shorthand = in this document.  For

example, in section 3.1 the column headers are = not described in this

draft.

 

SJS> This is a = standard MGCP package format as defined in RFC 3435 (Section 6, and in this case = Section 6.6 in particular)

 

- The security considerations section is brief = and primarily references

RFC 3435, which essentially has two security considerations: use IPSec

and use SDP encryption keys.  The latter is = not recommended in the

current SDP draft.  This section should = directly state the security

considerations it wants to assert.  =

 

SJS> We agree with = your comments about SDP encryption keys (RFC 3435 Section 5.1). We will call = out IPsec specifically and then add a few paragraphs about ways to more = adequately protect RTP media streams these days (SRTP which should probably have at = least a "SHOULD" recommendation here) as well as some of the = specific issues that may arise if an attacker is able to modify/inject VBD data = in the RTP media stream. We would also greatly appreciate if you can provide = additional guidance/considerations (if any) that you believe should be = addressed.

------_=_NextPart_001_01CB16BE.3C4E4E19-- From hilarie@purplestreak.com Mon Jun 28 09:06:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB463A67A3 for ; Mon, 28 Jun 2010 09:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.042 X-Spam-Level: X-Spam-Status: No, score=0.042 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AObxMKjoZJpe for ; Mon, 28 Jun 2010 09:06:15 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id 62CEC28C0D9 for ; Mon, 28 Jun 2010 09:06:15 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OTGqm-0001A1-I2; Mon, 28 Jun 2010 10:06:24 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OTGqk-0008SY-0l; Mon, 28 Jun 2010 10:06:23 -0600 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o5SG8KD8013335; Mon, 28 Jun 2010 10:08:20 -0600 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o5SG8Je8013327; Mon, 28 Jun 2010 10:08:19 -0600 Date: Mon, 28 Jun 2010 10:08:19 -0600 Message-Id: <201006281608.o5SG8Je8013327@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: john.elwell@siemens-enterprise.com In-reply-to: Yourmessage X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.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; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;john.elwell@siemens-enterprise.com X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Cc: secdir@ietf.org, Bernard_Aboba@hotmail.com, Gonzalo.Camarillo@ericsson.com, spencer@wonderhamster.org, hkaplan@acmepacket.com, rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 16:06:16 -0000 I did respond to you --- I asked that for the security issues that I raised and you said were already addressed in other documents, that you reference those documents in the sections were you require transport security and mutual authentication. Hilarie From secdir-bounces@mit.edu Sat Jun 26 20:29:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B153A6802 for ; Sat, 26 Jun 2010 20:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 313tIqTugiVy for ; Sat, 26 Jun 2010 20:29:23 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E6C5D3A67C2 for ; Sat, 26 Jun 2010 20:29:22 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5R3TVmQ005690 for ; Sat, 26 Jun 2010 23:29:31 -0400 Received: from mailhub-dmz-3.mit.edu (MAILHUB-DMZ-3.MIT.EDU [18.9.21.42]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5R3TRBS005687 for ; Sat, 26 Jun 2010 23:29:27 -0400 Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id o5R3TNee013512 for ; Sat, 26 Jun 2010 23:29:26 -0400 X-AuditID: 12074423-b7be0ae000000a83-8d-4c26c5959c53 Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 9E.23.02691.595C62C4; Sat, 26 Jun 2010 23:29:26 -0400 (EDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.3/8.14.3) with SMTP id o5R3Pt2E030163; Sat, 26 Jun 2010 20:29:20 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.8]) by mx0b-000f0801.pphosted.com with ESMTP id pn2mqrgcv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 26 Jun 2010 20:29:20 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.72.231) by BRM-EXEDGE-2.corp.brocade.com (172.16.72.249) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 26 Jun 2010 21:29:17 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.2.126]) by brm-excashub-2.corp.brocade.com ([172.16.72.231]) with mapi; Sat, 26 Jun 2010 21:29:18 -0600 From: Jaehoon Jeong To: Jari Arkko , Vincent Roca Date: Sat, 26 Jun 2010 21:29:03 -0600 Thread-Topic: SecDir review of draft-ietf-6man-dns-options-bis-03 Thread-Index: AcsVEwkoQT0bOfMGRemzrTBs/bZExgAlN+qQ Message-ID: <5A6980BCAE9E6D438D4D8A05540F6FB70113658855@BRM-EXCH-3.corp.brocade.com> References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> <4C25CA06.1080809@piuha.net> In-Reply-To: <4C25CA06.1080809@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-26_01:2010-02-06, 2010-06-26, 2010-06-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1006260186 X-Brightmail-Tracker: AAAAAhTf0JkU4LMb X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o5R3TRBS005687 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 28 Jun 2010 09:50:30 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "secdir@mit.edu" , "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" , IESG Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 03:29:24 -0000 Hi Vincent, I updated the security considerations section with Jari's suggest text as follows. Also, this attack can send redirects that tell the hosts to send their traffic somewhere else. The malicious node can send unsolicited RA or Neighbor Advertisement (NA) replies, answer RS or Neighbor Solicitation (NS) requests, etc. Also, an attacker could send an RA with a fraudulent RDNSS address, which is presumably an easier avenue of attack than becoming a rogue router and having to process all traffic for the subnet. This attack is similar to Neighbor Discovery attacks that use Redirect or Neighbor Advertisement messages to redirect traffic to individual addresses to malicious parties. In general, the attacks related to RDNSS and DNSSL are similar to both Neighbor Discovery attacks and attacks against unauthenticated DHCP, as both can be used for both "wholesale" traffic redirection and more specific attacks. The revised I-D is located at the following link: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-04.txt The difference between 03-version and 04-version is located: http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-03_txt%20draft-ietf-6man-dns-options-bis-04_txt.htm I believe that Jari addressed your questions and comments. Could you confirm whether this update is fine with you? Thanks. Best Regards, Paul -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Saturday, June 26, 2010 4:36 AM To: Vincent Roca Cc: Jaehoon Jeong; draft-ietf-6man-dns-options-bis.all@tools.ietf.org; secdir@mit.edu; IESG; 6man Chairs Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03 Vincent, Thank you for your review! I have some comments on the issues that you raise below as well as some suggested new text: > ** Section 7 "Security considerations" > I don't share all the ideas of the authors. If I understand the point > of view, the authors say that the situation is not worse than before, > without these DNS options. > "...learning DNS information via the RA options cannot be worse than > learning bad router information via the RA options." > > Well, it depends on the security level we consider... > >From the point of view of the ND protocol itself, I agree. But from > the end user point of view, the situation is quite different, since > sending forged packets (for instance) and controlling which DNS server > is trusted by the client opens the way to, for instance, fishing > attacks. This attack enables an attacker to make a client use a > compromised DNS server that behaves perfectly except for one particular > DNS query. If the attacker can send an email to this client, then many > things can happen. This attack could be launched e.g. during next IETF > plenary ;-). The attacker knows the email off all participants, so if > he can control their DNS configuration as well, many things may > happen... IMHO a serious threat is introduced by this document that > needs to be seriously discussed. > I agree that in general the ability to redirect specific traffic instead of all traffic is an interesting attack. However, in this case the specific attack already exists in plain ND. If you want to redirect DNS server traffic to a malicious node, this can be done not just with RA DNS options, but also with ICMP Redirects or unsolicited Neighbor Advertisements. > ** Section 7: > Another point... the authors explain than network devices like > switches can be configured in such a way to disable ND/DHCP from > some ports. That's great and I agree it helps preventing attacks. > However this is limited to wired networks. Nothing is said concerning > ND configurations in wireless networks. The situation is rather > different since any host can issue ND/DHCP traffic as if it were a > legitimate server if I understand correctly. The document MUST > include this kind of discussion. > But this is generic issue with spoofing RAs and I am not sure it is the task of this document to specify the solutions. One solution exists in SEND (RFC 3791). > ** Section 7: > Yet another remark: SEND is listed as one potential solution to > add signatures in ND packets issued from servers. > I don't know SEND at all, so may be my remarks are flawed (but in > that case the text should be at least clarified). > - Shouldn't the use of SEND be RECOMMENDED as a solution to > mitigate attacks? Current document is not clear. > - Does SEND enable an authentication of the sender (the document > only mentions integrity protection)? If there's no sender > authentication, then I agree that the added value of SEND would be > limited. I'd like the authors to clarify this as well. > The details are in RFC 3791 and its companion documents. SEND does enable a host to verify that the sender of an RA is actually a router authorized to act as a router. All this being said I also re-read the Security Considerations section, and was not super happy with it myself. I would suggest the following change: OLD: Also, an attacker could configure a host to send out an RA with a fraudulent RDNSS address, which is presumably an easier avenue of attack than becoming a rogue router and having to process all traffic for the subnet. It is necessary to disable the RA RDNSS option or DNSSL option in both routers and clients administratively to avoid this problem. All of this can be done independently of implementing ND. Therefore, it can be claimed that the RA options for RDNSS and DNSSL has vulnerabilities similar to those existing in unauthenticated DHCPv6. NEW: Also, an attacker could send an RA with a fraudulent RDNSS address, which is presumably an easier avenue of attack than becoming a rogue router and having to process all traffic for the subnet. This attack is similar to Neighbor Discovery attacks that use Redirect or Neighbor Advertisement messages to redirect traffic to individual addresses to malicious parties. In general, the attacks related to RDNS and DNSSL are similar to both Neighbor Discovery attacks and attacks against unauthenticated DHCP, as both can be used for both "wholesale" traffic redirection and more specific attacks. Jari _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From S.Sharma@CableLabs.com Sun Jun 27 14:16:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347183A6957; Sun, 27 Jun 2010 14:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.583 X-Spam-Level: * X-Spam-Status: No, score=1.583 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ0ocIZwk0Tl; Sun, 27 Jun 2010 14:16:42 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 055D93A69F0; Sun, 27 Jun 2010 14:16:41 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o5RLGmC8003790; Sun, 27 Jun 2010 15:16:49 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Sun, 27 Jun 2010 15:16:48 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Sun, 27 Jun 2010 15:16:48 -0600 From: Sandeep Sharma To: "'Carl Wallace'" , "secdir@ietf.org" Date: Sun, 27 Jun 2010 15:16:48 -0600 Thread-Topic: secdir review of draft-stone-mgcp-vbd-07 Thread-Index: AcsS5SiAzRrqHLOYRH+RyifUiUWN1gDVoMPQ Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF4A7B323@srvxchg> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7CF4A7B323srvxchg_" MIME-Version: 1.0 X-Approved: ondar X-Mailman-Approved-At: Mon, 28 Jun 2010 09:50:30 -0700 Cc: "'Flemming Andreasen \(fandreas\)'" , "rkumar@cisco.com" , "joestone@cisco.com" , "iesg@ietf.org" , Sumanth Channabasappa Subject: Re: [secdir] secdir review of draft-stone-mgcp-vbd-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 21:19:38 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CF4A7B323srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Carl, Thanks for the review comments. I consulted with the co-authors and Flemmin= g and our responses are indicated below. -----Original Message----- From: Carl Wallace [mailto:CWallace@cygnacom.com] Sent: Wednesday, June 23, 2010 9:03 AM To: secdir@ietf.org Cc: iesg@ietf.org; rkumar@cisco.com; joestone@cisco.com; Sandeep Sharma Subject: secdir review of draft-stone-mgcp-vbd-07 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 new MGCP packages. This document is pretty far outside my sandbox, but I did have a couple of questions and comments. - Why is this an Informational document instead of Standards track? It seems to be defining new packages that are not already defined elsewhere. SJS> MGCP (RFC 3435) and other MGCP packages are Informational RFCs, so it = seems consistent to have this one being informational as well. - I struggled with the presentation a bit and found myself reading references to understand some of the shorthand in this document. For example, in section 3.1 the column headers are not described in this draft. SJS> This is a standard MGCP package format as defined in RFC 3435 (Section= 6, and in this case Section 6.6 in particular) - The security considerations section is brief and primarily references RFC 3435, which essentially has two security considerations: use IPSec and use SDP encryption keys. The latter is not recommended in the current SDP draft. This section should directly state the security considerations it wants to assert. SJS> We agree with your comments about SDP encryption keys (RFC 3435 Sectio= n 5.1). We will call out IPsec specifically and then add a few paragraphs a= bout ways to more adequately protect RTP media streams these days (SRTP whi= ch should probably have at least a "SHOULD" recommendation here) as well as= some of the specific issues that may arise if an attacker is able to modif= y/inject VBD data in the RTP media stream. We would also greatly appreciate= if you can provide additional guidance/considerations (if any) that you be= lieve should be addressed. --_000_76AC5FEF83F1E64491446437EA81A61F7CF4A7B323srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Carl,

 

Thanks for the review comments. I consulted with the co-authors and Flemming and our responses are indicated below.

 

-----Original Message-----
From: Carl Wallace [mailto:CWallace@cygnacom.com]
Sent: Wednesday, June 23, 2010 9:03 AM
To: secdir@ietf.org
Cc: iesg@ietf.org; rkumar@cisco.com; joestone@cisco.com; Sandeep Sharma
Subject: secdir review of draft-stone-mgcp-vbd-07

 

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 securi= ty

area directors. Document editors and WG chairs should treat these

comments just like any other last call comments.<= /font>

 

This document defines new MGCP packages.  This document is pre= tty far

outside my sandbox, but I did have a couple of questions and commen= ts.

 

- Why is this an Informational document instead of Standards track?  It

seems to be defining new packages that are not already defined=

elsewhere.

<= span style=3D'font-size:10.0pt;color:black'> 

SJS> MGCP (RFC 3435) and other MGC= P packages are Informational RFCs, so it seems consistent to have this one be= ing informational as well.

<= span style=3D'font-size:10.0pt;color:black'> 

- I struggled with the presentation a bit and found myself reading<= o:p>

references to understand some of the shorthand in this document.&nb= sp; For

example, in section 3.1 the column headers are not described in thi= s

draft.

<= span style=3D'font-size:10.0pt;color:black'> 

SJS> This is a standard MGCP packa= ge format as defined in RFC 3435 (Section 6, and in this case Section 6.6 in particular)

<= span style=3D'font-size:10.0pt;color:black'> 

- The security considerations section is brief and primarily refere= nces

RFC 3435, which essentially has two security considerations: use IP= Sec

and use SDP encryption keys.  The latter is not recommended in= the

current SDP draft.  This section should directly state the security

considerations it wants to assert.  <= /p>

<= span style=3D'font-size:10.0pt;color:black'> 

SJS> We agree with your comments a= bout SDP encryption keys (RFC 3435 Section 5.1). We will call out IPsec specific= ally and then add a few paragraphs about ways to more adequately protect RTP med= ia streams these days (SRTP which should probably have at least a "SHOULD" recommendation here) as well as some of the specific iss= ues that may arise if an attacker is able to modify/inject VBD data in the RTP media stream. We would also greatly appreciate if you can provide additiona= l guidance/considerations (if any) that you believe should be addressed.

--_000_76AC5FEF83F1E64491446437EA81A61F7CF4A7B323srvxchg_-- From secdir-bounces@mit.edu Sat Jun 26 03:02:44 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097853A6900 for ; Sat, 26 Jun 2010 03:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.855 X-Spam-Level: X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn4nbOlXOy4f for ; Sat, 26 Jun 2010 03:02:42 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 05DB13A67EB for ; Sat, 26 Jun 2010 03:02:41 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5QA2p3T021084 for ; Sat, 26 Jun 2010 06:02:51 -0400 Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o5QA2lHo021081 for ; Sat, 26 Jun 2010 06:02:47 -0400 Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id o5QA0337011687 for ; Sat, 26 Jun 2010 06:02:47 -0400 X-AuditID: 1209190e-b7b33ae000000a01-24-4c25d046a9a3 Received: from mail-ww0-f49.google.com (mail-ww0-f49.google.com [74.125.82.49]) by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with SMTP id 5B.EE.02561.740D52C4; Sat, 26 Jun 2010 06:02:47 -0400 (EDT) Received: by wwa36 with SMTP id 36so2269874wwa.36 for ; Sat, 26 Jun 2010 03:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=x359I3w+Lo8pG/yVqqBmrs2qfDPbtGaJKaZTCXNHfkY=; b=nmvFIHNpGwy/NRoF1Da7PcahibZ2EToYsS0YFE5qRxMrKk8FfcK48gb+nJTbOUvQXB E7ySw0RAlDdCrxdkkOIChJgISuqYFD48AMr7u9uZujVO63wJ20pveWrILsFF/HrOg+nW o3v6cPjTnViX8NXgCtCDwSVkEc8gdIISAhJW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=hSHmWnNgJFYZM/qfJFtQVR6aLhkNJ4wjDhDe+VbTNujaWbJH9VWoJPlnXC8P5H0zQn Pswhc2P4ovUmNU7D9uYHYfoeG17f8ZaF8OcEtuqYmo/RDbl2cyJS6tGFmBaZhOU+IB/7 nL2InOz903VBjMDyMSycyhVI1bvlx7j2ZItAk= Received: by 10.216.172.80 with SMTP id s58mr6009529wel.60.1277546566545; Sat, 26 Jun 2010 03:02:46 -0700 (PDT) Received: from [10.243.44.238] (m2b5a36d0.tmodns.net [208.54.90.43]) by mx.google.com with ESMTPS id l70sm2012419weq.0.2010.06.26.03.02.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Jun 2010 03:02:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) From: Bob Hinden In-Reply-To: <4C25CA06.1080809@piuha.net> Date: Sat, 26 Jun 2010 06:02:40 -0400 Message-Id: References: <4C248D9A.5080508@inrialpes.fr> <5A6980BCAE9E6D438D4D8A05540F6FB70113043B9B@BRM-EXCH-3.corp.brocade.com> <4C25CA06.1080809@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAxTf0JkU4KD1FOCzGw== X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id o5QA2lHo021081 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 28 Jun 2010 09:50:31 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, "secdir@mit.edu" , Bob Hinden , IESG , Jaehoon Jeong , "draft-ietf-6man-dns-options-bis.all@tools.ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 10:02:44 -0000 Jari, Your suggested text looks good to me. Thanks, Bob On Jun 26, 2010, at 5:36 AM, Jari Arkko wrote: > Vincent, > > Thank you for your review! > > I have some comments on the issues that you raise below as well as some suggested new text: > >> ** Section 7 "Security considerations" >> I don't share all the ideas of the authors. If I understand the point >> of view, the authors say that the situation is not worse than before, >> without these DNS options. >> "...learning DNS information via the RA options cannot be worse than >> learning bad router information via the RA options." >> >> Well, it depends on the security level we consider... >> >From the point of view of the ND protocol itself, I agree. But from >> the end user point of view, the situation is quite different, since >> sending forged packets (for instance) and controlling which DNS server >> is trusted by the client opens the way to, for instance, fishing >> attacks. This attack enables an attacker to make a client use a >> compromised DNS server that behaves perfectly except for one particular >> DNS query. If the attacker can send an email to this client, then many >> things can happen. This attack could be launched e.g. during next IETF >> plenary ;-). The attacker knows the email off all participants, so if >> he can control their DNS configuration as well, many things may >> happen... IMHO a serious threat is introduced by this document that >> needs to be seriously discussed. >> > > I agree that in general the ability to redirect specific traffic instead of all traffic is an interesting attack. However, in this case the specific attack already exists in plain ND. If you want to redirect DNS server traffic to a malicious node, this can be done not just with RA DNS options, but also with ICMP Redirects or unsolicited Neighbor Advertisements. > >> ** Section 7: >> Another point... the authors explain than network devices like >> switches can be configured in such a way to disable ND/DHCP from >> some ports. That's great and I agree it helps preventing attacks. >> However this is limited to wired networks. Nothing is said concerning >> ND configurations in wireless networks. The situation is rather >> different since any host can issue ND/DHCP traffic as if it were a >> legitimate server if I understand correctly. The document MUST >> include this kind of discussion. >> > > But this is generic issue with spoofing RAs and I am not sure it is the task of this document to specify the solutions. One solution exists in SEND (RFC 3791). > >> ** Section 7: >> Yet another remark: SEND is listed as one potential solution to >> add signatures in ND packets issued from servers. >> I don't know SEND at all, so may be my remarks are flawed (but in >> that case the text should be at least clarified). >> - Shouldn't the use of SEND be RECOMMENDED as a solution to >> mitigate attacks? Current document is not clear. >> - Does SEND enable an authentication of the sender (the document >> only mentions integrity protection)? If there's no sender >> authentication, then I agree that the added value of SEND would be >> limited. I'd like the authors to clarify this as well. >> > > The details are in RFC 3791 and its companion documents. SEND does enable a host to verify that the sender of an RA is actually a router authorized to act as a router. > > All this being said I also re-read the Security Considerations section, and was not super happy with it myself. I would suggest the following change: > > OLD: > Also, an attacker could configure a host to send out > an RA with a fraudulent RDNSS address, which is presumably an easier > avenue of attack than becoming a rogue router and having to process > all traffic for the subnet. It is necessary to disable the RA RDNSS > option or DNSSL option in both routers and clients administratively > to avoid this problem. All of this can be done independently of > implementing ND. Therefore, it can be claimed that the RA options > for RDNSS and DNSSL has vulnerabilities similar to those existing in > unauthenticated DHCPv6. > NEW: > Also, an attacker could send > an RA with a fraudulent RDNSS address, which is presumably an easier > avenue of attack than becoming a rogue router and having to process > all traffic for the subnet. This attack is similar to Neighbor Discovery > attacks that use Redirect or Neighbor Advertisement messages to redirect > traffic to individual addresses to malicious parties. In general, the > attacks related to RDNS and DNSSL are similar to both Neighbor Discovery > attacks and attacks against unauthenticated DHCP, as both can be used > for both "wholesale" traffic redirection and more specific attacks. > > Jari > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From john.elwell@siemens-enterprise.com Mon Jun 28 00:27:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7CB3A6989 for ; Mon, 28 Jun 2010 00:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isWcsFijQ1YN for ; Mon, 28 Jun 2010 00:27:27 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 154803A6988 for ; Mon, 28 Jun 2010 00:27:26 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-649358; Mon, 28 Jun 2010 09:27:35 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 1AE461EB82AB; Mon, 28 Jun 2010 09:27:35 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 28 Jun 2010 09:27:35 +0200 From: "Elwell, John" To: Gonzalo Camarillo Date: Mon, 28 Jun 2010 09:27:33 +0200 Thread-Topic: review of draft-ietf-martini-reqs-07.txt Thread-Index: AcsVTWlr+/jPrAVaT2686G+Xk89yOwBRWcGw Message-ID: References: <201006220148.o5M1mdgA006857@fermat.rhmr.com> <4C262A09.5070008@ericsson.com> In-Reply-To: <4C262A09.5070008@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_A444A0F8084434499206E78C106220CAE7E7E61BMCHP058Aglobala_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 28 Jun 2010 09:50:31 -0700 Cc: "secdir@ietf.org" , "Bernard_Aboba@hotmail.com" , "hkaplan@acmepacket.com" , "spencer@wonderhamster.org" , "rjsparks@nostrum.com" Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 07:27:29 -0000 --_002_A444A0F8084434499206E78C106220CAE7E7E61BMCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe Hilary and I are in agreement - I received no further response (s= ee my most recent mail attached). So I will go ahead and produce -08 right = now. John=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: 26 June 2010 17:26 > To: Elwell, John > Cc: Hilarie Orman; secdir@ietf.org;=20 > Bernard_Aboba@hotmail.com; spencer@wonderhamster.org;=20 > rjsparks@nostrum.com; hkaplan@acmepacket.com > Subject: Re: review of draft-ietf-martini-reqs-07.txt >=20 > Hi John, >=20 > please, agree with Hilarie on how to address these comments=20 > and submit a > new revision of the draft. Please, also include any other IETF LC > comments you have received. >=20 > I have updated the draft's state in the tracker to Revised ID Needed. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 22/06/2010 9:43 AM, Elwell, John wrote: > > Hilarie, > >=20 > > Thanks for your review. See responses below:=20 > >=20 > >> -----Original Message----- > >> From: hilarie@purplestreak.com=20 > >> [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman > >> Sent: 22 June 2010 02:49 > >> To: secdir@ietf.org > >> Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org;=20 > >> gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; Elwell,=20 > >> John; hkaplan@acmepacket.com > >> Subject: review of draft-ietf-martini-reqs-07.txt > >> > >> Security review of draft-ietf-martini-reqs-07.txt, > >> Multiple AOR reachability in SIP=20 > >> > >> 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=20 > editors and > >> WG chairs should treat these comments just like any other last call > >> comments. > >> > >> The abstract: > >> This document states requirements for a standardized SIP=20 > registration > >> mechanism for multiple addresses of record, the mechanism being > >> suitable for deployment by SIP service providers on a=20 > large scale in > >> support of small to medium sized Private Branch Exchanges (PBXs). > >> The requirements are for a solution that can, as a=20 > minimum, support > >> AORs based on E.164 numbers. > >> > >> There are 21 requirements, and two of them address security. > >> > >> I think requirement 14 leaves out a couple of things: > >> REQ14 - The mechanism MUST be able to operate over a=20 > transport that > >> provides integrity protection and confidentiality. > >> It should probably require "end-to-end" integrity protection and > >> confidentiality between the two entities (SIP-PBX and the SSP). > > [JRE] In the next version I will change it to: > > "The mechanism MUST be able to operate over a transport=20 > that provides end-to-end integrity protection and=20 > confidentiality between the SIP-PBX and the SSP." > >=20 > >> > >> And I think requirement 15 should say something about how the two > >> entites are expected to agree on an authentication method, and that > >> the authentication should apply to every registration message > >> exchanged by the entities. That is, once they have authenticated, > >> then that information should be tied to requirement 14 and=20 > ensure that > >> the integrity and/or confidentiality is defined between the two > >> entities (by use of, for example, an authenticated key exchange > >> protocol) on all subsequent messages between the two. =20 > > [JRE] I am reluctant to make any changes here. We don't=20 > anticipate any new security mechanism, and indeed the=20 > solution that is moving forward in the WG allows use of TLS,=20 > which is already allowed for in SIP. For authentication it=20 > allows both TLS mutual authentication or SIP digest=20 > authentication + TLS server authentication, again, in line=20 > with what is already allowed in SIP. SIP has a wealth of=20 > material in this area, including aspects of RFC 3263 and RFC=20 > 3329. I don't think it worthwhile adding a bunch of=20 > requirements that in the end will not lead to any new=20 > mechanisms or influence use of existing mechanisms. REQ14 and=20 > REQ15 I think are sufficient pointers to needs in this area. > >=20 > >> REQ15 - The mechanism MUST support authentication of=20 > the SIP-PBX by > >> the SSP and vice versa. > >> I'd also add that it MUST support termination of authenticaton and > >> re-authentication. > > [JRE] I am not sure exactly what you are looking for here.=20 > Is this referring to what happens when a certificate expires,=20 > say? Again, I would doubt we really need to add anything=20 > here, since we don't anticipate new security mechanisms. > >=20 > >> > >> Minor non-security things: > >> > >> Requirement 4 has a triple negative ("not" "prevent"=20 > "without"), and > >> I'm not sure what the heck it means. > > [JRE] Yes, in the next version I will change it to: > > "The mechanism MUST allow UAs attached to a SIP-PBX to=20 > register with the SIP-PBX for AORs based on assigned=20 > telephone numbers, in order to receive requests targeted at=20 > those telephone numbers, without needing to involve the SSP=20 > in the registration process." > >=20 > >> > >> Requirement 5 has a typo, probably "internally" for "internal". > > [JRE] It intentionally says "internally" at present - an=20 > adverb modifying the verb "handle". I am not sure how to=20 > reword it to prevent misinterpretation. > >=20 > > John > >=20 > >=20 > >> > >> Hilarie >=20 > = --_002_A444A0F8084434499206E78C106220CAE7E7E61BMCHP058Aglobala_ Content-Type: message/rfc822 From: "Elwell, John" To: Hilarie Orman Date: Wed, 23 Jun 2010 08:24:30 +0200 Subject: RE: [secdir] review of draft-ietf-martini-reqs-07.txt Thread-Topic: [secdir] review of draft-ietf-martini-reqs-07.txt Thread-Index: AcsSMx6bYY3VJfK0QeWdVfHO0d4N+AAaVAxg References: <363157371.1144204.1277228904761.JavaMail.root@zms03.zcs> Keywords: MARTINI In-Reply-To: <363157371.1144204.1277228904761.JavaMail.root@zms03.zcs> X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 =20 > -----Original Message----- > From: Hilarie Orman [mailto:hilarie@purplestreak.com]=20 > Sent: 22 June 2010 18:48 > To: Elwell, John > Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt >=20 > OK, but maybe you reference existing security documents in=20 > the security requirements? [JRE] I could add to REQ14 "e.g., using TLS as specified in " and to REQ15 "e.g., using SIP digest authentication plus TLS s= erver authentication as specified in ". Personall= y I don't think it is needed, but if you think it would help I could do tha= t. >=20 > Just delete the word "internally" -- it's not doing anything useful. [JRE] Will do. John >=20 > Hilarie >=20 >=20 > ----- Original Message ----- > From: John Elwell > To: Hilarie Orman , secdir@ietf.org > Cc: Bernard Aboba ,=20 > hkaplan@acmepacket.com, gonzalo camarillo=20 > , spencer@wonderhamster.org,=20 > rjsparks@nostrum.com > Sent: Tue, 22 Jun 2010 00:43:44 -0600 (MDT) > Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt > Hilarie, > Thanks for your review. See responses below:=20 > > -----Original Message----- > > From: hilarie@purplestreak.com=20 > > [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman > > Sent: 22 June 2010 02:49 > > To: secdir@ietf.org > > Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org;=20 > > gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; Elwell,=20 > > John; hkaplan@acmepacket.com > > Subject: review of draft-ietf-martini-reqs-07.txt > >=20 > > Security review of draft-ietf-martini-reqs-07.txt, > > Multiple AOR reachability in SIP=20 > >=20 > > Do not be alarmed. I have reviewed this document as part of the > > security directorate's ongoing effort to review all IETF documents > > being processed by the IESG. These comments were written primarily > > for the benefit of the security area directors. Document editors and > > WG chairs should treat these comments just like any other last call > > comments. > >=20 > > The abstract: > > This document states requirements for a standardized SIP=20 > registration > > mechanism for multiple addresses of record, the mechanism being > > suitable for deployment by SIP service providers on a large scale in > > support of small to medium sized Private Branch Exchanges (PBXs). > > The requirements are for a solution that can, as a minimum, support > > AORs based on E.164 numbers. > >=20 > > There are 21 requirements, and two of them address security. > >=20 > > I think requirement 14 leaves out a couple of things: > > REQ14 - The mechanism MUST be able to operate over a transport that > > provides integrity protection and confidentiality. > > It should probably require "end-to-end" integrity protection and > > confidentiality between the two entities (SIP-PBX and the SSP). > [JRE] In the next version I will change it to: > "The mechanism MUST be able to operate over a transport that=20 > provides end-to-end integrity protection and confidentiality=20 > between the SIP-PBX and the SSP." > >=20 > > And I think requirement 15 should say something about how the two > > entites are expected to agree on an authentication method, and that > > the authentication should apply to every registration message > > exchanged by the entities. That is, once they have authenticated, > > then that information should be tied to requirement 14 and=20 > ensure that > > the integrity and/or confidentiality is defined between the two > > entities (by use of, for example, an authenticated key exchange > > protocol) on all subsequent messages between the two.=20 > [JRE] I am reluctant to make any changes here. We don't=20 > anticipate any new security mechanism, and indeed the=20 > solution that is moving forward in the WG allows use of TLS,=20 > which is already allowed for in SIP. For authentication it=20 > allows both TLS mutual authentication or SIP digest=20 > authentication + TLS server authentication, again, in line=20 > with what is already allowed in SIP. SIP has a wealth of=20 > material in this area, including aspects of RFC 3263 and RFC=20 > 3329. I don't think it worthwhile adding a bunch of=20 > requirements that in the end will not lead to any new=20 > mechanisms or influence use of existing mechanisms. REQ14 and=20 > REQ15 I think are sufficient pointers to needs in this area. > > REQ15 - The mechanism MUST support authentication of the SIP-PBX by > > the SSP and vice versa. > > I'd also add that it MUST support termination of authenticaton and > > re-authentication. > [JRE] I am not sure exactly what you are looking for here. Is=20 > this referring to what happens when a certificate expires,=20 > say? Again, I would doubt we really need to add anything=20 > here, since we don't anticipate new security mechanisms. > >=20 > > Minor non-security things: > >=20 > > Requirement 4 has a triple negative ("not" "prevent" "without"), and > > I'm not sure what the heck it means. > [JRE] Yes, in the next version I will change it to: > "The mechanism MUST allow UAs attached to a SIP-PBX to=20 > register with the SIP-PBX for AORs based on assigned=20 > telephone numbers, in order to receive requests targeted at=20 > those telephone numbers, without needing to involve the SSP=20 > in the registration process." > >=20 > > Requirement 5 has a typo, probably "internally" for "internal". > [JRE] It intentionally says "internally" at present - an=20 > adverb modifying the verb "handle". I am not sure how to=20 > reword it to prevent misinterpretation. > John > >=20 > > Hilarie > >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > = --_002_A444A0F8084434499206E78C106220CAE7E7E61BMCHP058Aglobala_-- From john.elwell@siemens-enterprise.com Mon Jun 28 09:23:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1B83A6813 for ; Mon, 28 Jun 2010 09:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ua7NNcxjGpT for ; Mon, 28 Jun 2010 09:23:22 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B81EB3A6918 for ; Mon, 28 Jun 2010 09:23:21 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-666230; Mon, 28 Jun 2010 18:23:30 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6D34623F028E; Mon, 28 Jun 2010 18:23:30 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 28 Jun 2010 18:23:30 +0200 From: "Elwell, John" To: Hilarie Orman Date: Mon, 28 Jun 2010 18:23:29 +0200 Thread-Topic: review of draft-ietf-martini-reqs-07.txt Thread-Index: AcsW290yxLdz2WExQ2GExJ1n+TVjwAAAdBhQ Message-ID: References: Yourmessage <201006281608.o5SG8Je8013327@fermat.rhmr.com> In-Reply-To: <201006281608.o5SG8Je8013327@fermat.rhmr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 28 Jun 2010 09:50:32 -0700 Cc: "secdir@ietf.org" , "Bernard_Aboba@hotmail.com" , "Gonzalo.Camarillo@ericsson.com" , "spencer@wonderhamster.org" , "hkaplan@acmepacket.com" , "rjsparks@nostrum.com" Subject: Re: [secdir] review of draft-ietf-martini-reqs-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 16:23:22 -0000 Hilarie, What I meant was that I did not get a further response, so I assumed you we= re happy with my later response sent on 2010-06-23. Anyway, if you have any concerns with -08 as posted today, please let me kn= ow. John=20 > -----Original Message----- > From: Hilarie Orman [mailto:hilarie@purplestreak.com]=20 > Sent: 28 June 2010 17:08 > To: Elwell, John > Cc: Gonzalo.Camarillo@ericsson.com; hkaplan@acmepacket.com;=20 > rjsparks@nostrum.com; spencer@wonderhamster.org;=20 > Bernard_Aboba@hotmail.com; secdir@ietf.org > Subject: RE: review of draft-ietf-martini-reqs-07.txt >=20 > I did respond to you --- I asked that for the security issues that > I raised and you said were already addressed in other documents, that > you reference those documents in the sections were you=20 > require transport > security and mutual authentication. >=20 > Hilarie > = From julienl@qualcomm.com Mon Jun 28 14:09:35 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9C328C121; Mon, 28 Jun 2010 14:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.489 X-Spam-Level: X-Spam-Status: No, score=-104.489 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk4pc6LLFZJB; Mon, 28 Jun 2010 14:09:34 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A634C28C115; Mon, 28 Jun 2010 14:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1277759383; x=1309295383; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"secdir@ietf.org"=20,=20"iesg@iet f.org"=20|CC:=20"draft-ietf-behave-v6v4-xl ate-stateful@tools.ietf.org"=0D=0A=09,=0D=0A=09"behave-chair s@tools.ietf.org"=20|Date: =20Mon,=2028=20Jun=202010=2014:09:41=20-0700|Subject:=20s ecdir=20review=20of=20draft-ietf-behave-v6v4-xlate-statef ul-11|Thread-Topic:=20secdir=20review=20of=20draft-ietf-b ehave-v6v4-xlate-stateful-11|Thread-Index:=20AcsXBjnihORq h1ckQ3SEf8aol2I7fQ=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=g+ufuVUltCoBtgB0sgR1fDlfAwN0ZMsk5M0PQEO1Oio=; b=J8OQniaFwlFHw78FgQ/yd+IqR+7Ulhw3aEbBc4rlpaNAJhFtpF/YSyT6 r0e4glYA0wWZSzM5WGEiyA8HCNX961TzXP4alknqluc8yu6ht0BCNiwkD RmEpC+C0cv/UiZrZantF7FQQfX6JhtmU46M0NnCSM0L/uBkSovliVzAxN s=; X-IronPort-AV: E=McAfee;i="5400,1158,6027"; a="45683672" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 28 Jun 2010 14:09:42 -0700 X-IronPort-AV: E=Sophos;i="4.53,497,1272870000"; d="scan'208";a="80423705" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Jun 2010 14:09:42 -0700 Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Jun 2010 14:09:44 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.0.694.0; Mon, 28 Jun 2010 14:09:44 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 28 Jun 2010 14:09:44 -0700 From: "Laganier, Julien" To: "secdir@ietf.org" , "iesg@ietf.org" Date: Mon, 28 Jun 2010 14:09:41 -0700 Thread-Topic: secdir review of draft-ietf-behave-v6v4-xlate-stateful-11 Thread-Index: AcsXBjnihORqh1ckQ3SEf8aol2I7fQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-v6v4-xlate-stateful@tools.ietf.org" , "behave-chairs@tools.ietf.org" Subject: [secdir] secdir review of draft-ietf-behave-v6v4-xlate-stateful-11 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, 28 Jun 2010 21:09:35 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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. Document abstract: This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. The public IPv4 address can be shared among several IPv6-only clients. When the stateful NAT64 is used in conjunction with DNS64 no changes are usually required in the IPv6 client or the IPv4 server. Comments: The document is a nice read and in a good shape. I have a few comments belo= w: Section 1.2. "Overview": Repeated use of the term "transport address" but i= t is only defined later in the Terminology section 2. Suggest moving "1.2 O= verview" in its own standalone section numbered 3, just after terminology. Section 2 describes Hairpinning and Section 3.8 specifies NAT64 support for= Hairpinning. The document states that "Hairpinning support is important fo= r peer-to-peer applications, as there are cases when two different hosts on= the same side of a NAT can only communicate using sessions that hairpin th= rough the NAT." I understand that it is important for NAT44 because only RF= C1918 ambiguous address space is available for hosts behind NAT44 which can= make it impossible for host to communicate. I however do not understand wh= y it is needed with NAT64 where non-ambiguous IPv6 address space is availab= le to hosts behind the NAT64. Why would the host be able to communicate onl= y through a NAT64? It seems that putting an IPv6 router next to the NAT64 w= ould avoid the need for hairpinning NAT64. Maybe I am missing something... = If there's a easy explanation, suggest extending the terminology with it. Section 5.2.: "To avoid this type of abuse, a NAT64 MAY keep track of the s= equence number of TCP packets in order to verify that proper sequencing of = exchanged segments, in particular, the SYNs and the FINs." =3D> I think you= mean "in particular, those of the SYNs and the FINs." Also, it seems to me= that you want to keep track of is the whole TCP state rather than the only= the sequence numbers, i.e., whether the connection is opened, half-closed,= by watching at SYNs, RSTs and FINs. --julien From christer.holmberg@ericsson.com Tue Jun 29 08:41:52 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CBD3A6781; Tue, 29 Jun 2010 08:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.892 X-Spam-Level: X-Spam-Status: No, score=-3.892 tagged_above=-999 required=5 tests=[AWL=1.218, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z44zhYMrVmzD; Tue, 29 Jun 2010 08:41:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id F116A3A684C; Tue, 29 Jun 2010 08:41:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-1f-4c2a1443842d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CD.6F.10125.3441A2C4; Tue, 29 Jun 2010 17:41:55 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 29 Jun 2010 17:41:54 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 29 Jun 2010 17:41:54 +0200 From: Christer Holmberg To: Ted Hardie , "Richard L. Barnes" Date: Tue, 29 Jun 2010 17:41:52 +0200 Thread-Topic: secdir review of draft-ietf-simple-msrp-sessmatch Thread-Index: AcsL8r0LZjksOTxKTeGXeVDdNcTaagLrY1cw Message-ID: References: <5A638DC0-41CF-4C0C-B00D-6793C43FB708@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , The, IETF , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 15:41:52 -0000 Hi Ted, >I join Richard in believing that this document makes changes=20 >beyond that which could be understood as "updating" the MSRP=20 >URI scheme processing. >=20 >To highlight one particular aspect, RFC 4975 does not require=20 >session-ids to be present, a fact noted both in the ABNF and=20 >in this text: >=20 >4. The session-id part is compared as case sensitive. A URI without > a session-id part is never equivalent to one that includes one. >=20 >A matching scheme which relies on a URI section which is not=20 >guaranteed to be present has some interesting problems ahead=20 >of it. If this effectively makes their use mandatory, that=20 >requires a change to the fundamental ABNF and text. An MSRP URI in an SDP offer or answer for an MSRP session MUST include a se= ssion-id part, so I believe the comment is based on incorrect assumptions. Section 6 of RFC 4975 says: "The session-id part identifies a particular session of the participant.= The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to= a particular session at that device." >I also note that the security considerations, in addition to=20 >having some fairly disingenuous language about the impact of=20 >this change, seems to fail to mention MSRPS URIs and what, if=20 >any, impact this would have on them. There are no impacts to MSRPS URIs. I assumed it would be implicitly unders= tood since MSRPS URIs are not mentioned in the draft. However, we could explicitly make it clear by modifying the first sentences= of section 5: =09 "The change of session matching procedure does not impact the format = of MSRP URIs,=20 disregarding if the "msrp" scheme or the "msrps" scheme is used. However, MSRP endpoints can only check that the session-id part of the MSR= P URI..." Regards, Christer > On Mon, Jun 14, 2010 at 10:21 AM, Richard L. Barnes=20 > wrote: > > I have reviewed this document as part of the security directorate's=20 > > ongoing effort to review all IETF documents being processed by the=20 > > IESG. =A0These comments were written primarily for the benefit of the=20 > > security area directors. =A0Document editors and WG chairs=20 > should treat=20 > > these comments just like any other last call comments. > > > > This document changes the URI matching algorithm used in=20 > MSRP. =A0MSRP=20 > > sessions are typically initiated using SDP bodies in SIP. =A0 > These SDP=20 > > bodies contain MSRP URIs that the peers use to contact each other. =A0 > > When one peer receives a request to initiate a session, he verifies=20 > > that the URI being requested is one that he initiated in=20 > SDP, thereby=20 > > using the URI as a shared secret to authenticate that the=20 > originator=20 > > of the session actually received the SDP body in question. > > > > According to the current SDP specification, this comparison is=20 > > performed over the whole URI; this document restricts the=20 > comparison=20 > > to the "session-id" component, omitting the host, port, and=20 > transport components. > > =A0The goal of the document is to facilitate a certain class of=20 > > man-in-the-middle attack, namely to allow a signaling=20 > intermediary to=20 > > insert a media intermediary. =A0The restriction on the URI=20 > comparison is=20 > > needed in order for the media intermediary not to have to=20 > modify URIs=20 > > in MSRP packets to reflect the modifications to URIs in SDP bodies=20 > > performed to redirect traffic through the media intermediary. > > > > I have a few significant reservations about this document: > > > > This extension makes it more difficult for MSRP entities to secure=20 > > their communications against attackers in the signaling path. =A0The=20 > > current model provides a basic integrity protection, in=20 > that signaling=20 > > intermediaries cannot redirect traffic to an arbitrary third party;=20 > > they must at least advise the third party about how to modify MSRP=20 > > packets. =A0The proposed modification would remove even this cost. =A0 > > Moreover, it raises the cost of providing integrity protection to=20 > > messages, since Alice must now employ both integrity and=20 > > confidentiality protections on an end-to-end basis; if her messages=20 > > are only integrity-protected, then a proxy can remove the=20 > integrity protection and redirect traffic without it being=20 > observable to Alice. > > > > The document needs to clarify what the impacts are for=20 > authentication=20 > > in secure modes of MSRP. =A0In particular: > > -- The distinction between "self-signed" and "public"=20 > certificates is=20 > > inappropriate. =A0The proper distinction is between the name-based=20 > > authentication in Section 14.2 of RFC 4975 and the=20 > fingerprint-based=20 > > authentication in Section 14.4. -- In either case, changing=20 > the host=20 > > name need not result in an authentication failure, since the media=20 > > intermediary can simply authenticate as itself to both endpoints,=20 > > having changed the respective MSRP URIs appropriately. > > -- There is currently no requirement that a endpoint=20 > identity in the=20 > > To-Path URI matches the endpoint identity authenticated at the TLS=20 > > layer, because these two are required to be the same. =A0This=20 > document=20 > > changes that assumption, and should note that these two=20 > identities can differ. > > The document also precludes any name-based multiplexing, where a=20 > > single MSRP process (single IP address and port) directs=20 > requests to=20 > > different virtual recipients based on the domain name in=20 > the To-Path=20 > > header. =A0(In analogy to Host-based multiplexing in HTTP,=20 > which is very=20 > > widely deployed.) =A0Since with this extension, the domain in the=20 > > To-Path is completely unpredictable from the recipient's=20 > perspective, it is useless to the recipient. > > > > The document has no backward-compatibility. =A0MSRP=20 > implementations that=20 > > do not support this extension will not be able to receive MSRP=20 > > sessions from implementations that do. =A0 In that regard, =A0this=20 > > document seems more like an new version of MSRP rather than=20 > an update. > > > > > > > > > > > > > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > = From rbarnes@bbn.com Tue Jun 29 09:42:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BE03A6860; Tue, 29 Jun 2010 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.923, 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 MchnrXpTIPXL; Tue, 29 Jun 2010 09:42:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2EC9F3A6868; Tue, 29 Jun 2010 09:42:40 -0700 (PDT) Received: from ros-dhcp192-1-51-71.bbn.com ([192.1.51.71]:54895) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OTdta-000Jwk-FR; Tue, 29 Jun 2010 12:42:50 -0400 Message-Id: From: "Richard L. Barnes" To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 29 Jun 2010 12:42:48 -0400 References: <5A638DC0-41CF-4C0C-B00D-6793C43FB708@bbn.com> X-Mailer: Apple Mail (2.936) Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , Ted Hardie , The IETF , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 16:42:41 -0000 >> I also note that the security considerations, in addition to >> having some fairly disingenuous language about the impact of >> this change, seems to fail to mention MSRPS URIs and what, if >> any, impact this would have on them. > > There are no impacts to MSRPS URIs. I assumed it would be implicitly > understood since MSRPS URIs are not mentioned in the draft. > > However, we could explicitly make it clear by modifying the first > sentences of section 5: > > "The change of session matching procedure does not impact the > format of MSRP URIs, > disregarding if the "msrp" scheme or the "msrps" scheme is used. > However, MSRP endpoints can only check that the session-id part of > the MSRP URI..." The conflict here is that with MRSPS authentication, the name in the certificate is checked against the domain name in the URI, which was OK when the URI in the message was required to be the same. By allowing the domain name in the message to change, this draft removes man-in-the-middle protection from MSRPS. The document notes that a SIP MitM can already direct the user to another destination. However, if the peers use MSRPS with the current authentication scheme, the MitM will not be able to be a part of the resulting MSRPS session, since he can't authenticate as one of the endpoints. If only the session ID is used in comparisons, the MitM can patch himself in by changing the domain in the MSRPS URI. (Which actually seems to be the intended use case for this draft.) So the current document does introduce a new MitM vulnerability to MSRPS. --Richard From avy@fdos.ca Mon Jun 28 10:31:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79033A6873; Mon, 28 Jun 2010 10:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfxJg9G-Kcei; Mon, 28 Jun 2010 10:31:40 -0700 (PDT) Received: from kirk.fdos.ca (www.naedra.org [206.75.201.253]) by core3.amsl.com (Postfix) with ESMTP id 0A9353A68F6; Mon, 28 Jun 2010 10:31:14 -0700 (PDT) Received: from PAN (dyna23.fdos.com [192.168.1.23] (may be forged)) by kirk.fdos.ca (8.14.2/8.14.2) with SMTP id o5SHV7hH009768; Mon, 28 Jun 2010 11:31:07 -0600 Message-ID: From: "Avygdor Moise" To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= , , , , "Paul Hoffman" References: Date: Mon, 28 Jun 2010 11:31:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailman-Approved-At: Wed, 30 Jun 2010 08:31:42 -0700 Cc: Jonathan Brodkin Subject: Re: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 17:31:42 -0000 Without going into too much detail I will try and explain what is meant by "only to enhance and preserve [and] ... not be a substitute for ... ANSI C12.22 ... security provisions." ANSI C12.22 / IEEE 1703 / MC12.22 can use any network transport protocol to carry a C12.22 Message. Because of the above expectation the protocol can not assume that the underlying transport is secure, although it may be. A C12.22 Message is composed of three core components: 1) Connectionless-mode ACSE APDU wrapper 2) EPSEM service/response indication 3) ANSI C12.19 / IEEE 1377 / MC12.19 Table Data (for EPSEM Read/Write services) ANSI C12.22 / IEEE 1703 / MC12.22 supports the transmission of the ACSE PDU using one of thee "standard modes" 1) Mode 0 -- The C12.22 Message is transmitted in clear text without encryption and without authentication. 2) Mode 1 -- The C12.22 Message is transmitted in plain text without encryption, but with authentication. 3) Mode 2 -- The C12.22 Message is transmitted encrypted and authenticated. The default (build-in) mechanism is EAX' (based on AES-128). In addition the protocol implements duplicate APDU rejection, playback rejection and message associations. The "built-in" C12.22 Security Mechanism is registered as Module C12.22-Security-Mechanism {iso(1) member-body(2) us(840) c1219-standard(10066) mechanism(12) c1222(1) version(1)} Other encryption/authentication protocols may be registered by providing an algorithm and an OID. In addition EPSEM security service together with ANSI C12.19 / IEEE 1377 / MC12.19 passwords and roles tables role-base accessed to data and services. When authentication and/or encryption is used then the ENTIRE ACSE APDU is authenticated including all source/destination elements. If a network manager wishes to introduce additional security (e.g. TLS, Firewalls etc.) then this should not act to replace the security cited above, because the C12.22 Message "contract" is an end-to-end. i.e. a C12.22 Message may enter and leave an IP network, but when it does then the C12.22 Message integrity, security, privacy and authenticity should not be affected by the presence or absence of an IP network or the presence or absence of IP network security. If the IP security introduces additional opacity (privacy) then it may be necessary to install additional C12.22 Relays/Gateways at the perimeter of the secured IP network, when the network attaches to a global AMI network. I hope this clarifies things Avygdor Moise ----- Original Message ----- From: "Paul Hoffman" To: "Magnus Nyström" ; ; ; Sent: Sunday, June 27, 2010 3:44 PM Subject: Re: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10 Given that I have made this same copy-and-paste error in the past: this review is for draft-c1222-transport-over-ip, not the one in the Subject: line. At 10:31 AM -0700 6/27/10, Magnus Nyström wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >This document defines a framework for transporting ANSI C12.22 >advanced metering infrastructure (AMI) messages on IP networks. > >AMI is intended for interaction with various types of utility meters; >as such, it is clear that security services such as data authenticity, >integrity and confidentiality will be quite important. This draft >defers to ANSI C12.22 for application-layer security and states that >any transport (or IP) network layer security security functionality >shall act "only to enhance and preserve [and] ... not be a substitute >for ... ANSI C12.22 ... security provisions." This is all good but I >have not had access to C12.22 for this review and so cannot comment >further on it. It seems to me, however, that the layering of C12.22 >on top of IP networks may warrant a discussion about potential methods >to enhance C12.22 security? For example, could privacy be enhanced >beyond what C12.22 offers through use of a transport network's >confidentiality services? > >Other than this I have no particular comments on this draft; it reads >good to me. >-- Magnus >_______________________________________________ >secdir mailing list >secdir@ietf.org >https://www.ietf.org/mailman/listinfo/secdir From ted.ietf@gmail.com Tue Jun 29 10:37:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166133A699C; Tue, 29 Jun 2010 10:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=1.641, 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 HwDhQTXrZYq5; Tue, 29 Jun 2010 10:37:14 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B852E3A6817; Tue, 29 Jun 2010 10:37:14 -0700 (PDT) Received: by pwj2 with SMTP id 2so241615pwj.31 for ; Tue, 29 Jun 2010 10:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cFfjERd7VbMuwkNp9PpYKjhXOIAuROOQhAnjmwTg6h8=; b=Y6qKSFNQEeFE7b1lxOk0Ven/PD6Zq233jPOXWscN74AK0HL5+vs8+qb5+4W/jIf2Lk 34ADn+yx2Fa9juXsLe/CNzpZkK5HPvKxtoTXYFYtxbMUs9eGWNYWPpROpfCrdaQ5EaM3 /PVHfZl570Xf+m3UCO32sF4ryLnk0QjJzRrcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XjXKX5l5AyS5JeyD6bogqFw4gZty05yu7L9fYL5cjltsAGOhRGkV0PLS48WnyPvxmu 4zCNQNrNGxtAKBovVPiOPc272d8DhCSqHfSS60+CAneeJJioP51PuhpD/kWGKO5fkNot MYyQHrC6BnUeXs5vO3W6Asc35HV3YGzzllZBI= MIME-Version: 1.0 Received: by 10.142.2.22 with SMTP id 22mr8570352wfb.13.1277833041903; Tue, 29 Jun 2010 10:37:21 -0700 (PDT) Received: by 10.142.254.11 with HTTP; Tue, 29 Jun 2010 10:37:21 -0700 (PDT) In-Reply-To: References: <5A638DC0-41CF-4C0C-B00D-6793C43FB708@bbn.com> Date: Tue, 29 Jun 2010 10:37:21 -0700 Message-ID: From: Ted Hardie To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 30 Jun 2010 08:31:41 -0700 Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , The IETF , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 17:37:17 -0000 In-line. On Tue, Jun 29, 2010 at 8:41 AM, Christer Holmberg wrote: > > Hi Ted, > >>I join Richard in believing that this document makes changes >>beyond that which could be understood as "updating" the MSRP >>URI scheme processing. >> >>To highlight one particular aspect, RFC 4975 does not require >>session-ids to be present, a fact noted both in the ABNF and >>in this text: >> >>4. The session-id part is compared as case sensitive. =A0A URI without >> =A0 a session-id part is never equivalent to one that includes one. >> >>A matching scheme which relies on a URI section which is not >>guaranteed to be present has some interesting problems ahead >>of it. If this effectively makes their use mandatory, that >>requires a change to the fundamental ABNF and text. > > An MSRP URI in an SDP offer or answer for an MSRP session MUST include a = session-id part, so I believe the comment is >based on incorrect assumption= s. This is not indicated in the URI matching sectio > > Section 6 of RFC 4975 says: > > =A0 "The session-id part identifies a particular session of the participa= nt. The absence of the session-id > =A0 part indicates a reference to an MSRP host device, but does not refer= to a particular session at that device." > The full section from which that quote is taken is: The MSRP URI authority field identifies a participant in a particular MSRP session. If the authority field contains a numeric IP address, it MUST also contain a port. The session-id part identifies a particular session of the participant. The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to a particular session at that device. A particular value of session-id is only meaningful in the context of the associated authority; thus, the authority component can be thought of as identifying the "authority" governing a namespace for the session-id. This proposal changes the concept of a namespace authority present in the URI matching section of RFC 4975. I am sorry if my wry reference to this in my previous message was hard to follow; I should have known bett= er. To be more plain, this proposal fundamentally changes the matching semantic= s of the URI set out in RFC 4975, by requiring a match on only a portion of t= he URI. At a bare minimum, this would require noting a normative update to section 6 and 6.1 of RFC 4975, which this draft does not do. In reality, this is unlikely to be sufficient, as URI matching semantics do not generally have the conce= pt of ignoring the authority in providing a match (at least in my reading of the RFC 3986 "ladder of comparison" text). That means you'd have to special case the MSRP matching semantics, rather than have the URI be parsed and compare= d using a standard library. Creating a new URI scheme without re-using authority may be a better approa= ch; this would require more work, but it is cleaner than this appears to be. > >>I also note that the security considerations, in addition to >>having some fairly disingenuous language about the impact of >>this change, seems to fail to mention MSRPS URIs and what, if >>any, impact this would have on them. > > There are no impacts to MSRPS URIs. I assumed it would be implicitly unde= rstood since MSRPS URIs are not mentioned in the draft. > > However, we could explicitly make it clear by modifying the first sentenc= es of section 5: > > =A0 =A0 =A0"The change of session matching procedure does not impact the = format of MSRP URIs, > =A0 =A0 =A0 =A0disregarding if the "msrp" scheme or the "msrps" scheme is= used. > =A0 =A0 =A0 =A0However, MSRP endpoints can only check that the session-id= part of the MSRP URI..." > This doesn't seem to me to actually work, based on Richard's comments, unless what you mean to say is "if MSRPS is in use, nothing in this draft can be used". That gives you different matching semantics for MSRPS (authority must be present and must be matched using TLS semantics) vs MSRP (only session-id is checked) which is at the very least a violation of the principle of least surprise (no other foo over TLS protocol works that way that I know of ). regards, Ted > > Regards, > > Christer > > > >> On Mon, Jun 14, 2010 at 10:21 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. =A0These comments were written primarily for the benefit of the >> > security area directors. =A0Document editors and WG chairs >> should treat >> > these comments just like any other last call comments. >> > >> > This document changes the URI matching algorithm used in >> MSRP. =A0MSRP >> > sessions are typically initiated using SDP bodies in SIP. >> These SDP >> > bodies contain MSRP URIs that the peers use to contact each other. >> > When one peer receives a request to initiate a session, he verifies >> > that the URI being requested is one that he initiated in >> SDP, thereby >> > using the URI as a shared secret to authenticate that the >> originator >> > of the session actually received the SDP body in question. >> > >> > According to the current SDP specification, this comparison is >> > performed over the whole URI; this document restricts the >> comparison >> > to the "session-id" component, omitting the host, port, and >> transport components. >> > =A0The goal of the document is to facilitate a certain class of >> > man-in-the-middle attack, namely to allow a signaling >> intermediary to >> > insert a media intermediary. =A0The restriction on the URI >> comparison is >> > needed in order for the media intermediary not to have to >> modify URIs >> > in MSRP packets to reflect the modifications to URIs in SDP bodies >> > performed to redirect traffic through the media intermediary. >> > >> > I have a few significant reservations about this document: >> > >> > This extension makes it more difficult for MSRP entities to secure >> > their communications against attackers in the signaling path. =A0The >> > current model provides a basic integrity protection, in >> that signaling >> > intermediaries cannot redirect traffic to an arbitrary third party; >> > they must at least advise the third party about how to modify MSRP >> > packets. =A0The proposed modification would remove even this cost. >> > Moreover, it raises the cost of providing integrity protection to >> > messages, since Alice must now employ both integrity and >> > confidentiality protections on an end-to-end basis; if her messages >> > are only integrity-protected, then a proxy can remove the >> integrity protection and redirect traffic without it being >> observable to Alice. >> > >> > The document needs to clarify what the impacts are for >> authentication >> > in secure modes of MSRP. =A0In particular: >> > -- The distinction between "self-signed" and "public" >> certificates is >> > inappropriate. =A0The proper distinction is between the name-based >> > authentication in Section 14.2 of RFC 4975 and the >> fingerprint-based >> > authentication in Section 14.4. -- In either case, changing >> the host >> > name need not result in an authentication failure, since the media >> > intermediary can simply authenticate as itself to both endpoints, >> > having changed the respective MSRP URIs appropriately. >> > -- There is currently no requirement that a endpoint >> identity in the >> > To-Path URI matches the endpoint identity authenticated at the TLS >> > layer, because these two are required to be the same. =A0This >> document >> > changes that assumption, and should note that these two >> identities can differ. >> > The document also precludes any name-based multiplexing, where a >> > single MSRP process (single IP address and port) directs >> requests to >> > different virtual recipients based on the domain name in >> the To-Path >> > header. =A0(In analogy to Host-based multiplexing in HTTP, >> which is very >> > widely deployed.) =A0Since with this extension, the domain in the >> > To-Path is completely unpredictable from the recipient's >> perspective, it is useless to the recipient. >> > >> > The document has no backward-compatibility. =A0MSRP >> implementations that >> > do not support this extension will not be able to receive MSRP >> > sessions from implementations that do. =A0 In that regard, =A0this >> > document seems more like an new version of MSRP rather than >> an update. >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Ietf mailing list >> > Ietf@ietf.org >> > https://www.ietf.org/mailman/listinfo/ietf >> > >>