From CWallace@cygnacom.com Wed Dec 1 04:34: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 584CF3A6C6B; Wed, 1 Dec 2010 04:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imgOQmb9FDLD; Wed, 1 Dec 2010 04:34:54 -0800 (PST) Received: from sottexchE2.entrust.com (sottexche2.entrust.com [216.191.252.22]) by core3.amsl.com (Postfix) with ESMTP id 98DF83A69ED; Wed, 1 Dec 2010 04:34:54 -0800 (PST) Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 1 Dec 2010 07:35:51 -0500 Received: from scygexch1.cygnacom.com (10.60.50.8) by scygexch7.cygnacom.com (10.4.60.22) with Microsoft SMTP Server id 8.3.106.1; Wed, 1 Dec 2010 07:36:07 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9154.3A0D0863" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 1 Dec 2010 07:35:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-stone-mgcp-vbd-08.txt Thread-Index: AcuRU6b/7VIg6RDFTPSE5MacEo0z4Q== From: Carl Wallace To: , , Cc: s.sharma@cablelabs.com, rkumar@cisco.com, joestone@cisco.com Subject: [secdir] secdir review of draft-stone-mgcp-vbd-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: Wed, 01 Dec 2010 12:34:58 -0000 ------_=_NextPart_001_01CB9154.3A0D0863 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. =20 This is a re-review. Following the last review, changes were made to the security considerations section to highlight a disconnect with the referenced security considerations in RFC 3435. This seems sufficient to me (though there is a typo in the new text - "securuty"). ------_=_NextPart_001_01CB9154.3A0D0863 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This is a = re-review.  Following the last review, changes were made to the = security considerations section to highlight a disconnect with the = referenced security considerations in RFC 3435.  This seems = sufficient to me (though there is a typo in the new text – = “securuty”).

------_=_NextPart_001_01CB9154.3A0D0863-- From cheshire@apple.com Wed Dec 1 08:53: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 346823A6AAC; Wed, 1 Dec 2010 08:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB2SbikBpaws; Wed, 1 Dec 2010 08:53:23 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 36A6F3A69C5; Wed, 1 Dec 2010 08:53:23 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 3A3DBBC2BFA5; Wed, 1 Dec 2010 08:54:37 -0800 (PST) X-AuditID: 11807134-b7c8bae0000031f0-cc-4cf67dcd44d5 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id 6E.5F.12784.DCD76FC4; Wed, 1 Dec 2010 08:54:37 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.24] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LCR005WMDN0O530@elliott.apple.com>; Wed, 01 Dec 2010 08:54:37 -0800 (PST) From: Stuart Cheshire In-reply-to: <20101101094624.GC29846@elstar.local> Date: Wed, 01 Dec 2010 08:54:36 -0800 Message-id: <22E7725B-417F-4944-A0B4-844A237385EF@apple.com> References: <20101101094624.GC29846@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 01 Dec 2010 08:57:21 -0800 Cc: IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-cheshire-dnsext-nbp-09.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, 01 Dec 2010 16:53:24 -0000 On 1 Nov 2010, at 2:46, Juergen Schoenwaelder wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The informational draft discusses requirements for a IP replacement of > AppleTalk's Name Binding Protocol (NBP). As an individual submission, > there is likely little value in commenting on the content. However, I > would have appreciated if the authors would have discussed security as > a requirement for an NBP replacement. I know that flexible discovery > is often pretty much as odd with security, having "security measures > appropriate to the environment in which" an NBP replacement "will be > used" could have been an explicit requirement. Can you propose some specific text you would like to see in the document? > Editorial nit: > > On page 9, the DNS name "printer1.ietf.org" should probably changed to > "printer1.example.com". Fixed. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From derek@ihtfp.com Wed Dec 1 12:55: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 132673A6407; Wed, 1 Dec 2010 12:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTxYtj7tjuUs; Wed, 1 Dec 2010 12:55:27 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 223163A6359; Wed, 1 Dec 2010 12:55:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 95F4B2602AB; Wed, 1 Dec 2010 15:56:37 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06031-05; Wed, 1 Dec 2010 15:56:34 -0500 (EST) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 31513260245; Wed, 1 Dec 2010 15:56:34 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id oB1KuQlL011523; Wed, 1 Dec 2010 15:56:26 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Wed, 01 Dec 2010 15:56:25 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: robinsgv@gmail.com, barryleiba@computer.org, sieve-chairs@tools.ietf.org, Alexey.Melnikov@isode.com Subject: [secdir] sec-dir review of draft-ietf-sieve-autoreply-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, 01 Dec 2010 20:55:28 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient. The security considerations section details many potential issues with automated responders. One attack that it does not mention is the potential for using the auto-responder as an oracle, in particular if the system is using any public key cryptographic methods. An attacker could, theoretically, use the auto-responder to perform timing attacks. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From barryleiba@gmail.com Wed Dec 1 13:07: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 E1D653A67A7; Wed, 1 Dec 2010 13:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B52IaoBASjqQ; Wed, 1 Dec 2010 13:07:59 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id DFDF43A6768; Wed, 1 Dec 2010 13:07:58 -0800 (PST) Received: by ywe9 with SMTP id 9so143095ywe.31 for ; Wed, 01 Dec 2010 13:09:12 -0800 (PST) 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=DpEpkaFcODOcdY451zer5SMRKwjJbTQa+pzeC7NZ278=; b=oNUPmlEszfpfXbnO9nCxdEQ7JXqnM6//nDdMDJmzNU1ueCsR7sbqUNkAPJ/8xyjBJo xx1mGmvr4xX6rUbJ3jEa1J/2/xlaJ9zsim0G0G8PlnEFvCEKHHVusqqzoaRv0nNm8jUG U7prhTc7HKJPivXdIOpZrZntmLzc95ceP/gL0= 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=MmE9RjrlyIsA4DDSHm+i8+d37nl22QbfQc0+WWt7bXvaVkOJ+dwdF4CfBDyWciSXPv YaBHgq/bwkbftHiT0SQ91IhtQduuaLrwFgHQQb0I3X2nApIXgUqpNC/MZbU9zaAIlCHh taCMNtFaCmUY5HHCt/lAcHXkMrkhY5LstjL6U= MIME-Version: 1.0 Received: by 10.231.152.83 with SMTP id f19mr9551774ibw.9.1291237752747; Wed, 01 Dec 2010 13:09:12 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Wed, 1 Dec 2010 13:09:12 -0800 (PST) In-Reply-To: References: Date: Wed, 1 Dec 2010 16:09:12 -0500 X-Google-Sender-Auth: CSGRo9DtM27inNXCNinsaoUWrNk Message-ID: From: Barry Leiba To: Derek Atkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: robinsgv@gmail.com, Alexey.Melnikov@isode.com, sieve-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-sieve-autoreply-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, 01 Dec 2010 21:08:00 -0000 Hi, Derek, and thanks for the review. > The security considerations section details many potential issues with > automated responders. =A0One attack that it does not mention is the > potential for using the auto-responder as an oracle, in particular if > the system is using any public key cryptographic methods. =A0An attacker > could, theoretically, use the auto-responder to perform timing attacks. You mean, as a covert channel? The "probing" paragraph isn't sufficient to cover that as well? (It doesn't focus on covert channels, but does talk about probing for presence changes.) Barry From mundy@sparta.com Wed Dec 1 16:26: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 EBA413A6830; Wed, 1 Dec 2010 16:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpPT8JyhBKrx; Wed, 1 Dec 2010 16:26:52 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B60723A6812; Wed, 1 Dec 2010 16:26:51 -0800 (PST) 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 oB20S38W014701; Wed, 1 Dec 2010 18:28:03 -0600 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 oB20S37u006880; Wed, 1 Dec 2010 18:28:03 -0600 Received: from socks1.tislabs.com ([192.94.214.32]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Dec 2010 19:28:03 -0500 From: Russ Mundy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 1 Dec 2010 19:28:02 -0500 Message-Id: <74C2196A-9DEA-40FF-860B-BDD47857F1CE@sparta.com> To: secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 02 Dec 2010 00:28:03.0275 (UTC) FILETIME=[C81FA1B0:01CB91B7] Cc: draft-ietf-emu-eaptunnel-req.all@tools.ietf.org, iesg@ietf.org, Russ Mundy Subject: [secdir] Review of draft-ietf-emu-eaptunnel-req-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 00:26:55 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I need to start my comments by saying that I do not have a background in the details EAP, tunnels and TLS so I approached the document review as someone who was a potential designer of a solution that the document might provide. The broad problem that I encountered with the document is that it is unclear how it relates to other EAP, TLS and other tunnel specifications. Since there are essentially no illustrations or text describing the various parts and how they are related nor was I able to locate any other document providing architectural descriptions, my conclusion is that the document seems to be for people that already are very familiar with other specifications/documents related to the multiple technology pieces described in the document. In short, there is not sufficient architectural context for the document to be widely useful. - Publication of the current document (without the architectural context) might provide some value to the Internet community but I would recommend that the IESG sees that more architectural context gets put in some document in the near future. Without such architectural direction, documents such as this one will not be used as expected either because they won't be found or won't be understood. A couple of more specific comments: - In section 2., the redifinition of MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY for _this_ document does not seem appropriate. The document should use the standard definitions for these terms or find different words for the definitions (conventions). - Section 4.4 has a normative reference to an I-D which expired in May of 2009. This needs to be corrected prior to publications. Russ Mundy From weiler@watson.org Wed Dec 1 19:28: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 A86033A6843; Wed, 1 Dec 2010 19:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 yD6UFoMgW1IP; Wed, 1 Dec 2010 19:28:47 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id ED7403A67AE; Wed, 1 Dec 2010 19:28:44 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oB23TvjY070033; Wed, 1 Dec 2010 22:29:57 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oB23Tv3n070030; Wed, 1 Dec 2010 22:29:57 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 1 Dec 2010 22:29:56 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org, iesg@ietf.org, draft-ietf-dhc-leasequery-by-remote-id.all@tools.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, 01 Dec 2010 22:29:57 -0500 (EST) Subject: [secdir] secdir review of draft-ietf-dhc-leasequery-by-remote-id-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 03:28:50 -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. Sorry for getting this out so late. I'm a bit confused by this doc -- in particular, I'm not understanding how the Remote ID field is being set so that querying based on it gives a complete set of relevant leases. I'm also wondering if the use case envisioned (filtering spoofed source addresses based on the assumption that you can collect a complete list of leases using this method) is dangerous -- at the very least, it suggests that authentication of the queries here is every more important than in 4388. Furthermore, what risks are there if answers to these queries are spoofed away? In this model, could a relay agent be induced to filter out a legitimate client for want of an answer to a DHCPLEASEQUERY? Also, I'm not a fan of referral Security Considerations sections -- I'd rather see a repeat of the text than a reference. -- Sam From kivinen@iki.fi Thu Dec 2 05:14:51 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 3EA853A693F; Thu, 2 Dec 2010 05:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bzyDDzQ5Lwf; Thu, 2 Dec 2010 05:14:50 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 09A5B3A693C; Thu, 2 Dec 2010 05:14:49 -0800 (PST) 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 oB2DG1Ma012199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Dec 2010 15:16:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id oB2DG0qr024069; Thu, 2 Dec 2010 15:16:00 +0200 (EET) 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: <19703.39952.702085.728298@fireball.kivinen.iki.fi> Date: Thu, 2 Dec 2010 15:16:00 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 20 min Cc: draft-ietf-v6ops-incremental-cgn.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-v6ops-incremental-cgn-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, 02 Dec 2010 13:14:51 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to use Carrier Grade NAT with IPv6 over IPv4 tunneling feature to provide incremental Carrier Grade NAT approach. It seems to mostly describe overall architecture, leaving specific protocols out (or listing multiple protocols). As such this is not really anything that can be implemented, but might provide information when someone selects the suitable protocols for different pieces, and what kind of features to include in different devices. The security consideration section refers to RFC2663 and RFC2993 for NAT security issues. The tunnel security issues are considered relatevely simple as the tunnel is entirely within a single ISP network. One nit: In section 2: ISPs facing only one pressure out of two could adopt either CGN (for shortage of IPv6 addresses) or 6rd (to provide IPv6 connectivity services). I do not think there is shortage of IPv6 addresses... I assume it is meaning shortage of IPv4 addresses. -- kivinen@iki.fi From kurapati@juniper.net Thu Dec 2 08:03: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 42FFA28C125; Thu, 2 Dec 2010 08:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRLuA5EKSMdZ; Thu, 2 Dec 2010 08:03:19 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id A609128C0CE; Thu, 2 Dec 2010 08:03:14 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTPfDjhAiYl5dwY58HBaTrFMvsSlEeqNz@postini.com; Thu, 02 Dec 2010 08:04:35 PST Received: from p-emfe01-bng.jnpr.net (10.211.204.19) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 2 Dec 2010 08:03:47 -0800 Received: from EMBX02-BNG.jnpr.net ([fe80::8ce3:7a6:9990:3c6e]) by p-emfe01-bng.jnpr.net ([::1]) with mapi; Thu, 2 Dec 2010 21:33:35 +0530 From: Pavan Kurapati To: Samuel Weiler , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-dhc-leasequery-by-remote-id.all@tools.ietf.org" Date: Thu, 2 Dec 2010 21:33:32 +0530 Thread-Topic: secdir review of draft-ietf-dhc-leasequery-by-remote-id-07 Thread-Index: AcuR0TuaOEFf+oqzTdmHH2RH//pnmAAaP3Mw Message-ID: <408677E9A8F78149B5DC29F87FBF27A94507290217@EMBX02-BNG.jnpr.net> 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Dec 2010 08:39:39 -0800 Subject: Re: [secdir] secdir review of draft-ietf-dhc-leasequery-by-remote-id-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 16:03:20 -0000 Hi Sam, Thanks for the review. Please find my comments tagged with "" Thanks, Pavan -----Original Message----- From: Samuel Weiler [mailto:weiler@watson.org]=20 Sent: Thursday, December 02, 2010 9:00 AM To: secdir@ietf.org; iesg@ietf.org; draft-ietf-dhc-leasequery-by-remote-id.= all@tools.ietf.org Subject: secdir review of draft-ietf-dhc-leasequery-by-remote-id-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 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 any= other last call comments. Sorry for getting this out so late. I'm a bit confused by this doc -- in particular, I'm not understanding how = the Remote ID field is being set so that querying based on it gives a compl= ete set of relevant leases. The Remote ID is pre-provisioned in the access concentrator per cir= cuit/connection and hence the same will remain available to the access conc= entrator after reboot. Since the servers index the lease binding informatio= n based on remote ID, it can reply complete set of information based on rem= ote ID field. I'm also wondering if the use case envisioned (filtering spoofed source add= resses based on the assumption that you can collect a complete list of leas= es using this method) is dangerous -- at the very least, it suggests that a= uthentication of the queries here is every more important than in 4388. Fur= thermore, what risks are there if answers to these queries are spoofed away= ?=20 The chance of spoofing has not increased with introducing this quer= y type. In fact, it will be difficult to spoof a remote ID compared to spoo= fing an IP address. Like RFC 4388, employing authentication techniques given in RFC 3118 will h= elp preventing such attacks In this model, could a relay agent be induced to filter out a legitimate cl= ient for want of an answer to a DHCPLEASEQUERY? Actually, a query by remote ID will reduce such instances of filter= ing out a legitimate client when compared to earlier query types. Since we = obtain the consolidated lease information, filtering out a legitimate clien= t is less likely. Whereas, in a query by IP or MAC, until the query for spe= cific IP is resolved, the relay agent may filter out the packets. Also, I'm not a fan of referral Security Considerations sections -- I'd rat= her see a repeat of the text than a reference. Yes, Tim Polk had also suggested the same. We will implement it in = our next revision -- Sam From Kurt.Zeilenga@Isode.com Thu Dec 2 19:25:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DAC428C121; Thu, 2 Dec 2010 19:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHuL-zYw+Bez; Thu, 2 Dec 2010 19:25:20 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2F8C43A6A51; Thu, 2 Dec 2010 19:25:18 -0800 (PST) Received: from [192.168.42.8] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 3 Dec 2010 03:26:34 +0000 From: Kurt Zeilenga Date: Thu, 2 Dec 2010 19:26:29 -0800 Message-Id: <9BF7FFED-3F2C-4260-910F-89D461AD0719@Isode.com> To: iesg@ietf.org X-Mailer: Apple Mail (2.1082) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-httpstate-cookie@tools.ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-httpstate-cookie 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, 03 Dec 2010 03:25:21 -0000 I have reviewed this document (v19) 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 find the document discusses well the security considerations = associated with HTTP "cookies". -- Kurt= From derek@ihtfp.com Fri Dec 3 05:46: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 AC51F28C0E9; Fri, 3 Dec 2010 05:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-8mJrvob3vt; Fri, 3 Dec 2010 05:46:43 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 8771528C0ED; Fri, 3 Dec 2010 05:46:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5FB8C2602AB; Fri, 3 Dec 2010 08:47:56 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27377-03; Fri, 3 Dec 2010 08:47:51 -0500 (EST) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id A4B6B260245; Fri, 3 Dec 2010 08:47:51 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id oB3DlYUD020322; Fri, 3 Dec 2010 08:47:34 -0500 From: Derek Atkins To: Barry Leiba References: Date: Fri, 03 Dec 2010 08:47:34 -0500 In-Reply-To: (Barry Leiba's message of "Wed, 1 Dec 2010 16:09:12 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: robinsgv@gmail.com, Alexey.Melnikov@isode.com, sieve-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-sieve-autoreply-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 13:46:44 -0000 Hi, Barry Leiba writes: > Hi, Derek, and thanks for the review. > >> The security considerations section details many potential issues with >> automated responders. =C2=A0One attack that it does not mention is the >> potential for using the auto-responder as an oracle, in particular if >> the system is using any public key cryptographic methods. =C2=A0An attac= ker >> could, theoretically, use the auto-responder to perform timing attacks. > > You mean, as a covert channel? > > The "probing" paragraph isn't sufficient to cover that as well? (It > doesn't focus on covert channels, but does talk about probing for > presence changes.) I wasn't specifically thinking about covert channels. I was more thinking about cases where the autoresponder could perform some operation on behalf of an attacker and return the results. For example, I would be concerned if the auto-responder returned the result of a DKIM verification, or perhaps an OpenPGP or S/MIME decryption. I'm thinking about this more as a cryptographic oracle, not necessarily an IMPP oracle. > Barry -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From barryleiba@gmail.com Fri Dec 3 07:38: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 11FAC28C120; Fri, 3 Dec 2010 07:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0CnoShzK48b; Fri, 3 Dec 2010 07:38:30 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 70D5B28C11D; Fri, 3 Dec 2010 07:38:29 -0800 (PST) Received: by iwn40 with SMTP id 40so11844335iwn.31 for ; Fri, 03 Dec 2010 07:39:47 -0800 (PST) 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; bh=BQlOOXQiupU2jtO680o6A8IYH82uWNv9TpW9OqgTSPI=; b=P7c7titBpXiUw1oNjZ9babwMevJQv8KcPqG9AzU1fjbVop2IUthuN+E351DPLLdnJt D1aPHe+Ljga2lQfAiENVEY4TtxqjDe3erdc8m+NAkSY87BOiXgJdKnVgggUhbs0CBudc qWeixm8AVqKAey5M1NZc05kO4YiMLu8L1C4No= 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; b=Sgne9pswVmvsHLUU7fh1PCp437hlhfvXQRKRckmYLehWFKJxNKoNTQ6Ksa0Id+D58O PCu2qviOxoK8eX5G0O+HF/H+2QewSqkdprT/lsrBNOnLKgjpSJEeE6JgM5Vx4QgU30ti CP/5a3EsppcJAlWrV/JJqICsSlkyVJsQZ/GQA= MIME-Version: 1.0 Received: by 10.231.13.196 with SMTP id d4mr1959126iba.134.1291390786911; Fri, 03 Dec 2010 07:39:46 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Fri, 3 Dec 2010 07:39:46 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Dec 2010 10:39:46 -0500 X-Google-Sender-Auth: JUmQu9EdjLE6ZHfc3v6d9MmxjPc Message-ID: From: Barry Leiba To: Derek Atkins Content-Type: text/plain; charset=ISO-8859-1 Cc: robinsgv@gmail.com, Alexey.Melnikov@isode.com, sieve-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-sieve-autoreply-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 15:38:31 -0000 Off list, Derek and I had a couple of exchanges, and Derek suggested the following text, which I think is fine, and which I will add to my working version of the document: ---------------------- An autoresponder can cause leaks of other pieces of information, including potentially providing the ability to attack cryptographic keying material. For example, using the time it takes to perform an cryptographic operation an attacker may obtain information about the secret key. An autoresponder that doesn't take timing into account could accidentally leak this kind of information. Moreover, if an autoresponder script returns the results of a cryptographic operation that could also provide an attack vector. For example, if a script returns the results of a decryption operation, an attacker can send an arbitrarily encrypted message and use the results as a chosen cyphertext attack to decode the encryption key. Authors of scripts should be careful in what information they return to senders. ---------------------- Barry From j.schoenwaelder@jacobs-university.de Fri Dec 3 09:13: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 C441928C188; Fri, 3 Dec 2010 09:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.115 X-Spam-Level: X-Spam-Status: No, score=-103.115 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN11VgepLAmt; Fri, 3 Dec 2010 09:13:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 164B428C104; Fri, 3 Dec 2010 09:13:43 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B62CC0015; Fri, 3 Dec 2010 18:15:00 +0100 (CET) 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 yP++TDHCNA4y; Fri, 3 Dec 2010 18:15:00 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA232C0002; Fri, 3 Dec 2010 18:14:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4D2DB15DD071; Fri, 3 Dec 2010 18:14:49 +0100 (CET) Date: Fri, 3 Dec 2010 18:14:49 +0100 From: Juergen Schoenwaelder To: Stuart Cheshire Message-ID: <20101203171449.GA2863@elstar.local> Mail-Followup-To: Stuart Cheshire , IESG , secdir@ietf.org References: <20101101094624.GC29846@elstar.local> <22E7725B-417F-4944-A0B4-844A237385EF@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22E7725B-417F-4944-A0B4-844A237385EF@apple.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-cheshire-dnsext-nbp-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 17:13:48 -0000 On Wed, Dec 01, 2010 at 08:54:36AM -0800, Stuart Cheshire wrote: > On 1 Nov 2010, at 2:46, Juergen Schoenwaelder wrote: > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > The informational draft discusses requirements for a IP replacement of > > AppleTalk's Name Binding Protocol (NBP). As an individual submission, > > there is likely little value in commenting on the content. However, I > > would have appreciated if the authors would have discussed security as > > a requirement for an NBP replacement. I know that flexible discovery > > is often pretty much as odd with security, having "security measures > > appropriate to the environment in which" an NBP replacement "will be > > used" could have been an explicit requirement. > > Can you propose some specific text you would like to see in the document? My request is essentially to move the text currently in the security considerations into section 3 where requirements for a replacement of NBP are discussed. For example: 3.15 Security Requirements The AppleTalk Name Binding Protocol was developed in an era where little consideration was given to security issues. In today's world this would no longer be appropriate. Any modern replacement for AppleTalk NBP should have security measures appropriate to the environment in which it will be used. The security considerations section then becomes this: 6. Security Considerations Security requirements for a replacement of the AppleTalk Name Binding Protocol are discussed in Section 3.15. Given that this document is a broad historical overview of how AppleTalk NBP worked, and does not specify any new protocol(s), detailed discussion of possible network environments, what protocols would be appropriate in each, and what security measures would be expected of each such protocol, is beyond the scope of this document. Now that I look at this again, I also think that section 5 "IPv6 Considerations" is kind of mis-placed. It seems that section 5 should also be a subsection of section 3 since it is establishing just another requirement. /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+secdir@watson.org Fri Dec 3 10:44:40 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F250C28C137 for ; Fri, 3 Dec 2010 10:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 c5g9crlvtQvo for ; Fri, 3 Dec 2010 10:44:38 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 34A1C28C0D0 for ; Fri, 3 Dec 2010 10:44:38 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oB3IjtkX075901 for ; Fri, 3 Dec 2010 13:45:55 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oB3Ijt53075898 for ; Fri, 3 Dec 2010 13:45:55 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 3 Dec 2010 13:45:55 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 03 Dec 2010 13:45:55 -0500 (EST) 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, 03 Dec 2010 18:44:40 -0000 Several of the newly assigned docs are scheduled for the 16 December telechat. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Russ Mundy is next in the rotation. For telechat 2010-12-16 Shawn Emery T 2010-12-27 draft-arkko-ipv6-transition-guidelines-08 Stephen Farrell T 2010-12-07 draft-ietf-bmwg-reset-02 Paul Hoffman T 2010-12-07 draft-ietf-morg-fuzzy-search-02 Love Hornquist-Astrand T 2010-12-06 draft-ietf-mpls-fastreroute-mib-14 Jeffrey Hutzelman T 2010-12-06 draft-ietf-roll-trickle-04 Stephen Kent T 2010-12-07 draft-ietf-v6ops-3177bis-end-sites-00 Chris Lonvick T 2010-12-15 draft-ietf-morg-list-specialuse-05 Kathleen Moriarty T 2010-12-15 draft-ietf-tls-ssl2-must-not-03 Vincent Roca T 2010-11-22 draft-ietf-mpls-tp-oam-framework-09 Larry Zhu T 2010-11-30 draft-ietf-mpls-ip-options-05 Glen Zorn T 2010-12-03 draft-ietf-opsec-protect-control-plane-04 For telechat 2011-01-06 Charlie Kaufman T 2010-12-14 draft-ietf-tls-rfc4347-bis-04 Julien Laganier T 2010-12-21 draft-loreto-http-bidirectional-05 Barry Leiba T 2010-12-22 draft-turner-md5-seccon-update-06 David McGrew T 2010-12-29 draft-kucherawy-authres-vbr-01 Last calls and special requests: Reviewer LC end Draft Rob Austein 2010-12-15 draft-salowey-secsh-uri- Dave Cridland 2010-12-03 draft-ietf-sipcore-sec-flows-06 Alan DeKok - draft-ohba-pana-relay-02 Donald Eastlake 2010-12-14 draft-ietf-avt-rtcp-port-for-ssm-03 Tobias Gondrom 2010-12-14 draft-ietf-avt-rtp-cnames-01 Phillip Hallam-Baker 2010-12-14 draft-ietf-ecrit-lost-servicelistboundary-04 Steve Hanna 2010-12-08 draft-ietf-ipfix-mediators-framework-09 Dan Harkins 2010-12-14 draft-ietf-isis-layer2-08 Sam Hartman 2010-12-14 draft-ietf-isis-trill-01 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Scott Kelly 2010-12-07 draft-ietf-tcpm-tcp-timestamps-00 Barry Leiba R2010-12-16 draft-saintandre-tls-server-id-check-10 David McGrew - draft-ietf-ecrit-framework-12 Catherine Meadows 2010-12-29 draft-turner-md4-to-historic-08 Brian Weis 2010-12-02 draft-linowski-netmod-yang-abstract-04 Tom Yu 2010-12-09 draft-cdmi-mediatypes-02 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-06 From catherine.meadows@nrl.navy.mil Fri Dec 3 14:36: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 921BF3A69B8; Fri, 3 Dec 2010 14:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQuAucX90naF; Fri, 3 Dec 2010 14:36:40 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id A472F3A6452; Fri, 3 Dec 2010 14:36:31 -0800 (PST) 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 oB3MbYw9005948; Fri, 3 Dec 2010 17:37:35 -0500 (EST) 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 oB3MbWtP023008; Fri, 3 Dec 2010 17:37:32 -0500 (EST) Received: (from [IPv6:::1] [10.0.0.13]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010120317373102830 ; Fri, 03 Dec 2010 17:37:32 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Catherine Meadows Date: Fri, 3 Dec 2010 17:37:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8B1C3F0B-07B7-4B48-A2BA-9E8719A49CF9@nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org X-Mailer: Apple Mail (2.1082) Subject: [secdir] Secdir review of draft-turner-md4-to-historic-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: Fri, 03 Dec 2010 22:36:43 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document recommends that the MD4 hash algorithm be retired and = moved to historic status and gives the rationale for doing this, namely its known vulnerability to = collision and pre-image attacks. The impact is mostly minimal, except for three Microsoft RFCs that are still supported in various versions of = Windows and the RADIUS and EAP RFCs . It would be helpful to learn = what other algorithms these OSs and RFCs support. This would give a better idea of the effect = of dropping MD4; if there are other alternatives supported by the OS's the impact should be minimal here as well. Other than that, I have no problems with the decision or rationale. I = agree, as I am sure that everyone else does, that MD4 should be retired. =20 Some nits: 1. "Section 6 also discussed" should be "Section 6 also discusses" = This occurs in several places. 2. " The RC4-HMAC is supported in Microsoft's Windows 2000 and=20 later for backwards compatibility with Windows 2000. " later supported by what? I assume later versions of Windows, but it is = probably a good idea to make this clear. 3. When you say that with one exception the impact of retiring MD4 would = be minimal, it would be a good idea to mention that exception upfront. It is fairly clear after you read the whole impact section that the = exception is the Microsoft RFCs, but nowhere where is that said = explicitly. 4. I'm not sure wether or not the discussion of MD4's resistance = against key recovery attack really belongs in the impacts section (in = the discussion of RC4-HMAC). It might give the impression that RC4-HMAC is secure = against key recovery, and, given the other attacks found against MD4, it = is reasonable to believe that this security is only temporary. I would suggest = putting this discussion in the security considerations section, and = also, wherever it does end up, adding the appropriate caveats. 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 charliek@microsoft.com Fri Dec 3 17:31: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 A6E683A67B1; Fri, 3 Dec 2010 17:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46Me3zP+8xHJ; Fri, 3 Dec 2010 17:31:05 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6BC053A6850; Fri, 3 Dec 2010 17:31:05 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 3 Dec 2010 17:32:23 -0800 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.6]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Fri, 3 Dec 2010 17:32:23 -0800 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-tls-rfc4347-bis.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-tls-rfc4347-bis-04.txt Thread-Index: AcuTMKCzJvVNgxw/QMKpf+Vurpj1Kg== Date: Sat, 4 Dec 2010 01:32:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-tls-rfc4347-bis-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 01:31:11 -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 spec is a refresh of rfc4347, which specified DTLS v1.0 as a set of de= ltas from TLS v1.1. This spec defines DTLS v1.2 as a set of deltas from TLS= v1.2. The deltas are mostly the same, so this spec is nearly identical to = rfc4347 except that it adds some clarifications, updates the references, an= d changes the version number. It would be nice to have a structure where if= and when TLS v1.3 appears, there would not be a need for a DTLS v1.3 spec.= Unfortunately, since there might at that time be a need for some DTLS spec= ific changes, there appears to be no way to do such a spec in advance. I've= never looked at DTLS in detail before, so this is a review with fresh eyes= . (That means please forgive me if I raise issues that were long debated an= d finally closed on the mailing list). I found what appears to be a minor f= law in the protocol (where it hangs if the wrong packet is lost), and some = suspicious things in the spec. The spec doesn't specify the changes from DTLS v1.0 and DTLS v1.2 and the i= mplications for interoperability. This would be a section that was not need= ed in rfc4347. I assume the transition is smooth, picking up the version nu= mber negotiation from TLS v1.2, but it would be worth mentioning whether th= ere are any known issues. Section 3.2.2. says that DTLS queues up out of order packets for future pro= cessing. The protocol is designed so that it can alternatively drop out of = order packets (since they will be retransmitted). It's a space/bandwidth tr= ade-off (as noted in section 4.2.2). The next-to-last paragraph of section 3.2.1 says that on a timeout, the cli= ent retransmits the unacknowledged handshake message and (if it was the res= ponse that was lost) the server will retransmit its response. It should be = noted that the server's response must be bit-for-bit identical to the respo= nse it previously sent (since otherwise fragmentation could interleave part= s of two responses). The protocol depends on the HelloVerifyRequest being s= hort enough to fit in a single packet because it cannot reliably recover if= that message is fragmented and a fragment is lost. That retransmission strategy does not work on the last message of the proto= col (the client's Finished) in the session-resuming exchange since the clie= nt is not expecting a response. As specified, I believe the protocol is bro= ken in the case where that packet is lost. The obvious way to fix the proto= col would be to add a fourth message to the session-resuming handshake. An = uglier but less disruptive to the wire protocol fix would be for the server= to interpret any properly encrypted data packet in a new epoch as being ev= idence that the ChangeCipherSpec message was lost. It does not need any inf= ormation from it. That works unless in the encapsulated protocol the server= was expected to speak first. That paragraph also says that servers maintain a retransmission timer and = retransmit when that time expires. It notes that retransmission does not ap= ply to HelloVerifyRequest messages. Retransmission is not required or helpf= ul for any of the messages, but it is also harmless. In sections 4.1.2.1 and 4.1.2.7, it says that invalid packets should normal= ly be silently discarded but can alternately cause a fatal alert. I believe= that it's worth noting that logging the discarded packets (or at least a c= ount of them) is included in the definition of "silently discarding" and is= often useful for diagnostic purposes. Implementing sequence numbers correctly in the handshake protocol has some = subtle requirements implied in the phrase "(at least notionally)" in the la= st paragraph of section 4.2.2. Section 4.2.1 says that there can be multipl= e round trips where a server keeps telling a client to use different cookie= s. The spec contains no upper bound on the number of exchanges there could = be, but it also implies that each HelloVerifyRequest should have a new sequ= ence number. Couple that with a stateless server, and the only way a correc= t implementation can work is for the server to accept *any* sequence number= from a client for a ClientHello and use that as an initial sequence number= for its responses. I don't know whether those semantics were intended. Eit= her way the text should probably explain what to do or implementers are lik= ely to do incompatible things. Just as the cookie exchange was added to DTLS because TLS got that benefit = by running over TCP, there is another problem which this protocol does not = appear to address very well. If a connection is broken uncleanly (e.g. an e= ndpoint crashes) and then someone attempts to create a new connection betwe= en the same IP addresses and UDP ports (e.g. an endpoint reboots), there ap= pears to be no way in this protocol to distinguish a plaintext ClientHello = from a malformed encrypted packet on the old connection. Since the best pra= ctice for a server is to silently discard malformed encrypted packets, when= a client reboots and tries to reconnect it is likely that the server will = appear dead. It would have been helpful if in the record header the Type fi= eld distinguished an encrypted handshake message from an unencrypted handsh= ake message in order to identify this case. In the case of a fixed pair of = UDP ports communicating, it would still be tricky to recover (since this co= uld be confused with a DoS attack), but at least the server could figure ou= t what was probably going on. Then it could implement some strategy like ki= lling the DTLS connection if it had not received any messages in the last X= minutes. This problem doesn't come up for TLS because the initialization o= f a TCP connection includes a SYN message that does not appear in the middl= e of a connection and random ISNs that prevent accidental aliasing of conne= ctions. Nits/Typos: Section 4.1 next to last line: "In an other case" -> "In any other case" Section 4.1.2.7 formatting glitch (spacing) from copying text from one docu= ment to another From paul.hoffman@vpnc.org Sun Dec 5 15:46:18 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 8FE8328C161 for ; Sun, 5 Dec 2010 15:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.174 X-Spam-Level: X-Spam-Status: No, score=-100.174 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, 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 2XalxsDOKNhq for ; Sun, 5 Dec 2010 15:46:17 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D09AA28C164 for ; Sun, 5 Dec 2010 15:46:17 -0800 (PST) Received: from [10.20.30.151] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB5NlcO4099439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Dec 2010 16:47:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 5 Dec 2010 15:47:37 -0800 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: draft-ietf-morg-fuzzy-search.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-morg-fuzzy-search-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: Sun, 05 Dec 2010 23:46: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 document describes an IMAP extension for fuzzy search of messages. The extension itself seemed pretty standard for IMAP. The Security Considerations listed were all that I could think of for such an extension. --Paul Hoffman, Director --VPN Consortium From shawn.emery@oracle.com Sun Dec 5 23:51: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 2F8F33A6A0A; Sun, 5 Dec 2010 23:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUFFJYATwL9F; Sun, 5 Dec 2010 23:51:07 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4EC913A69FC; Sun, 5 Dec 2010 23:51:07 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oB67qSlZ023830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Dec 2010 07:52:29 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oB67qQLd024924; Mon, 6 Dec 2010 07:52:27 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 846545871291621887; Sun, 05 Dec 2010 23:51:27 -0800 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Dec 2010 23:51:27 -0800 Message-ID: <4CFC95FD.4060902@oracle.com> Date: Mon, 06 Dec 2010 00:51:25 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.12) Gecko/20101108 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, draft-arkko-ipv6-transition-guidelines.all@tools.ietf.org Subject: [secdir] Review of draft-arkko-ipv6-transition-guidelines-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 07:51:08 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is an informational draft that provides guidance for deploying IPv6 addresses. The security considerations section does exist and states that the draft does not change the security properties of the different models outlined in the draft. Reading the individual model RFCs provides sufficient information for the possible security implications. General comments: None. Editorial comments: s/connectivity not available/connectivity is not available/ s/and are have/and have/ s/IPv6 networks, notably NRENS like Internet II/IPv6 networks; notably NRENS, Internet II/ Expand NRENS. s/easy with to/easy to/ s/establishment native connectivity is not possible/native connectivity can not be established/ s/more like to/more likely to/ Shawn. -- From turners@ieca.com Mon Dec 6 06:04: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 8DE973A67FA for ; Mon, 6 Dec 2010 06:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfHndluETFkK for ; Mon, 6 Dec 2010 06:04:13 -0800 (PST) Received: from nm12.bullet.mail.sp2.yahoo.com (nm12.bullet.mail.sp2.yahoo.com [98.139.91.82]) by core3.amsl.com (Postfix) with SMTP id 464B33A67AF for ; Mon, 6 Dec 2010 06:04:13 -0800 (PST) Received: from [98.139.91.61] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 06 Dec 2010 14:05:34 -0000 Received: from [98.139.91.4] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 06 Dec 2010 14:05:34 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 06 Dec 2010 14:05:34 -0000 X-Yahoo-Newman-Id: 52588.21997.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 25711 invoked from network); 6 Dec 2010 14:05:34 -0000 Received: from thunderfish.local (turners@96.231.120.248 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 06 Dec 2010 06:05:32 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: dFfiCwQVM1luQuLhJzg3pIJJ6ojD5E78_IiHIQVsDcW2VlO DfFzb4lPMc8nnpxP4GxxvMtmWuX4iDWtMdhLBGbsRljqA9GbD9C7.F7cfnDc iOuAkZeFUEIDgB_O7gSqEZwjMmyTCRvRqGLH4w3EschTXwxy3aXTWBG1OCK9 zuNONPCfWxyMuGzD_c38l7CWSKy3lALJeVyccUxnYN5oqlgA1aovmqQ3hsqX 73WGgMX1XLM1IHmiDoF8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4CFCEDAB.9040909@ieca.com> Date: Mon, 06 Dec 2010 09:05:31 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Catherine Meadows References: <8B1C3F0B-07B7-4B48-A2BA-9E8719A49CF9@nrl.navy.mil> In-Reply-To: <8B1C3F0B-07B7-4B48-A2BA-9E8719A49CF9@nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-turner-md4-to-historic-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 14:04:17 -0000 Catherine, Thanks for the review. Responses inline. spt On 12/3/10 5: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 recommends that the MD4 hash algorithm be retired and moved to historic status and gives > the rationale for doing this, namely its known vulnerability to collision and pre-image attacks. The impact is mostly minimal, except > for three Microsoft RFCs that are still supported in various versions of Windows and the RADIUS and EAP RFCs . It would be helpful to learn what other algorithms > these OSs and RFCs support. This would give a better idea of the effect of dropping MD4; if there are other alternatives supported by the OS's > the impact should be minimal here as well. I it might be hard to explain what alternatives are in each of the OS's because it depends a lot on what version/release/path combo is being used. I think RFC 4757 hints pretty strongly that aes256-cts-hmac-sha1-96 is supported because it says to use that alg instread of RC4-HMAC. > Other than that, I have no problems with the decision or rationale. I agree, as I am sure that everyone else does, that MD4 > should be retired. > > Some nits: > > 1. "Section 6 also discussed" should be "Section 6 also discusses" This occurs in several places. Fixed > 2. " The RC4-HMAC is supported in Microsoft's Windows 2000 and > later for backwards compatibility with Windows 2000. " > later supported by what? I assume later versions of Windows, but it is probably a good idea to make this clear. r/later/later versions of Windows > 3. When you say that with one exception the impact of retiring MD4 would be minimal, it would be a good idea to mention that exception upfront. > It is fairly clear after you read the whole impact section that the exception is the Microsoft RFCs, but nowhere where is that said explicitly. How about: The impact of moving MD4 to Historic is minimal with the one exception of Microsoft's use of MD4 as part of RC4-HMAC in Windows, the as described below. > 4. I'm not sure wether or not the discussion of MD4's resistance against key recovery attack really belongs in the impacts section (in the discussion > of RC4-HMAC). It might give the impression that RC4-HMAC is secure against key recovery, and, given the other attacks found against MD4, it is reasonable > to believe that this security is only temporary. I would suggest putting this discussion in the security considerations section, and also, wherever it does end up, adding the appropriate > caveats. I'm hesitant to move the text because it's in there specifically to address a comment by Sam Hartman. My understanding of MD4's use in RC4-HMAC is that MD4 is used to generate a key from a password and then that key is used as input to HMAC-MD5. So I am actually saying that RC4-HMAC is secure against key recovery attacks but this is entirely because HMAC-MD5 is used. In other words, when HMAC-MD5 is broken then RC4-HMAC is broken. From bew@cisco.com Mon Dec 6 11:36:02 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 8F1E63A68CE; Mon, 6 Dec 2010 11:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seRrztnAndSE; Mon, 6 Dec 2010 11:36:01 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 51A743A68CB; Mon, 6 Dec 2010 11:36:01 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHjJ/EyrR7H+/2dsb2JhbACjPHGjRpsrhUkEhF+GDw X-IronPort-AV: E=Sophos;i="4.59,306,1288569600"; d="scan'208";a="250632241" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Dec 2010 19:37:25 +0000 Received: from dhcp-128-107-151-32.cisco.com (dhcp-128-107-151-32.cisco.com [128.107.151.32]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB6JbPaN022867; Mon, 6 Dec 2010 19:37:25 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Dec 2010 11:37:26 -0800 Message-Id: To: secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: netmod-chairs@tools.ietf.org, draft-linowski-netmod-yang-abstract@tools.ietf.org Subject: [secdir] Secdir review of draft-linowski-netmod-yang-abstract-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 19:36:02 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the = IESG. These comments were written primarily for the benefit of the = security area directors. Document editors and WG chairs should treat = these comments just like any other review comments. This document extends the YANG data modeling language. It supports = modeling of a tree of data elements that represent the configuration and = runtime status of network elements. For example, it allows modeling of a = router or switch comprised of blades containing plug-in modules. The security considerations section seems sufficient as written. I do = not see the need for any changes. Brian= From jari.arkko@piuha.net Tue Dec 7 04:57: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 978F23A659C; Tue, 7 Dec 2010 04:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnPiYgfzFuBk; Tue, 7 Dec 2010 04:57:23 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 6E06F3A6774; Tue, 7 Dec 2010 04:57:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B505E2CC3A; Tue, 7 Dec 2010 14:58:47 +0200 (EET) 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 DNXRpSEPxfMp; Tue, 7 Dec 2010 14:58:47 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4DD622CC2E; Tue, 7 Dec 2010 14:58:47 +0200 (EET) Message-ID: <4CFE2F86.8020104@piuha.net> Date: Tue, 07 Dec 2010 14:58:46 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Shawn Emery References: <4CFC95FD.4060902@oracle.com> In-Reply-To: <4CFC95FD.4060902@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-arkko-ipv6-transition-guidelines.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-arkko-ipv6-transition-guidelines-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 12:57:24 -0000 Thanks for your review, Shawn! I have adopted your editorial suggestions in a new version (to be published soon). Jari Shawn Emery kirjoitti: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This is an informational draft that provides guidance for deploying > IPv6 addresses. > > The security considerations section does exist and states that the > draft does not change the security properties of the different models > outlined in the draft. Reading the individual model RFCs provides > sufficient information for the possible security implications. > > General comments: > > None. > > Editorial comments: > > s/connectivity not available/connectivity is not available/ > s/and are have/and have/ > s/IPv6 networks, notably NRENS like Internet II/IPv6 networks; notably > NRENS, Internet II/ > Expand NRENS. > s/easy with to/easy to/ > s/establishment native connectivity is not possible/native > connectivity can not be established/ > s/more like to/more likely to/ > > Shawn. > -- > > From shanna@juniper.net Wed Dec 8 22:22:40 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012373A69F0; Wed, 8 Dec 2010 22:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thBzB5Ntl827; Wed, 8 Dec 2010 22:22:35 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 7E7253A69F5; Wed, 8 Dec 2010 22:22:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTQB1/269RZGPLnPwZfXhZ4c8e+QyPEQ+@postini.com; Wed, 08 Dec 2010 22:24:02 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 8 Dec 2010 22:23:10 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 9 Dec 2010 01:23:09 -0500 From: Stephen Hanna To: "ietf@ietf.org" , "secdir@ietf.org" , "ipfix@ietf.org" Date: Thu, 9 Dec 2010 01:23:06 -0500 Thread-Topic: secdir review of draft-ietf-ipfix-mediators-framework-09.txt Thread-Index: Acth3WZtFoUbk+23ReaFVG39Xm1qzw1iXwtQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-ipfix-mediators-framework-09.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, 09 Dec 2010 06:22:40 -0000 I have reviewed this document as part of the security directorate's =20 ongoing effort to review all IETF documents being processed by the =20 IESG. These comments were written primarily for the benefit of the =20 security area directors. Document editors and WG chairs should treat =20 these comments just like any other last call comments. This document adds a new concept to the IPFIX architecture (RFC 5470): IPFIX Mediation. This concept allows conversion, correlation, selection, and other transformations on IPFIX records. The document is clear and the Security Considerations section seems to adequately cover the issues raised. I don't see any problems from a security perspective. Thanks, Steve From aland@deployingradius.com Thu Dec 9 01:09: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 B35A128C0E1; Thu, 9 Dec 2010 01:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrWvlru-x239; Thu, 9 Dec 2010 01:09:49 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 576F828C0CF; Thu, 9 Dec 2010 01:09:49 -0800 (PST) Message-ID: <4D009D34.1020809@deployingradius.com> Date: Thu, 09 Dec 2010 10:11:16 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: yoshihiro.ohba@toshiba.co.jp, paduffy@cisco.com, 'Alper Yegin' , margaretw42@gmail.com, pana@ietf.org, robert.cragie@gridmerge.com, samitac@ipinfusion.com, Ralph Droms Subject: [secdir] Secdir review of draft-ohba-pana-relay 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, 09 Dec 2010 09:09:50 -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. Margaret Wasserman said: > IMO, there is (at least) one way in which the introduction of a relay > changes the security model for PANA. In the original PANA protocol, > the PANA Authentication Agent (PAA) determines the source IP Address > and source UDP Port number of the PANA Client (PaC) by looking in the > headers of the request, and responds to that IP Address/Port. > However, in the case where a relay is being used, the client IP > Address/Port are included in an option in the relay message. Requests > are sent from the relay and responses are sent to the relay, using the > IP Address/Port in the headers, but the client (using information from > the option) is authenticated. I understand that this changes the > security properties of the PANA exchange, but I am not sure if it > changes them in a way that matters for the PANA protocol. > > So, I could use help here from someone who understands EAP (and > ideally, PANA) well enough to understand how/if a relay can safely be > used in a PANA environment. The proposed document doesn't affect the security of EAP. EAP is already transported over insecure and unauthenticated channels (i.e. EAPoL), so changing the PANA transport requirements should have no effect on EAP. Some questions: Are multiple relays allowed? If so, how do they work? If not, how are they detected, and forbidden by the participants? The Security Considerations section says: Since the PRE does not maintain per-PaC state, the PRE is robust against resource consumption DoS (Deniable of Service) attack. However, the PRE relays packets to the PaC. This means that entities on the PAA network can now send PANA messages to the PaC, when they previously could not. While the PaC is supposed to discard invalid and/or unexpected messages (RFC 5191), the PRE can be used to send messages to *arbitrary* UDP ports on the PaC or any other machine in the PaC network. The same attack applies (but less so) in the inverse direction. A fake PaC can send the PAA arbitrary PANA messages. Since this can already happen today, there is no new issue here. Having a stateful PRE would help address this attack. It would not prevent it, as the PANA messages are unsigned, and anyone can pretend to be the PRE. I would suggest requiring that the PRE enforce the Message Validity checks of RFC 5191, Section 5.5. If this cannot be done in its entirety, this draft should add a new section entitled "Message Validty checks for the PRE". e.g. The PRE MUST relays only well-formed PANA messages to the PAA. And before relaying messages back to the PaC, it ensures that the Relayed-Message AVP contains a well-formed PANA message. All malformed messages MUST be discarded. Since the behavior of the PAA is also changing, it would be good to leverage the PAA session tracking to add a cryptographic token between the PRE and PAA. This token would be added by the PRE prior to relaying a message, and the PAA could echo it back in the response. This ability means that the PRE is still stateless (in terms of tracking packets), but gains a little bit of security by maintaining additional state. The token would be subject to eavesdropping, so it offers small additional security. Adding it is a recommendation, not a requirement of this review. The token could be (for example) a signature of the PaC source IP and port, using a secret known only to the PaC, and generated automatically. The secret would also need to change periodically. Along with Message Validation, this token would increase the bar for attackers sending packets to the PaC. Rather than simply being able to leverage the PRE to send arbitrary traffic to the PaC, the attacker would need to be able to monitor PRE -> PAA traffic, and to then send well-formed PANA messages to the PaC, to the port used by the PaC for receiving PANA messages. That minimizes the attack exposure. There is also some confusion between PRE and PRY, such as: (c) The source IP address and UDP port number of the PRY is stored in a new PANA session attribute "IP address and UDP port number of the PRE". The text should consistently refer to "address of the PRE", or "address carried within the PRY" Alan DeKok. From new-work-bounces@ietf.org Tue Dec 7 12:13:32 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 4E67A28C0E7; Tue, 7 Dec 2010 12:13:32 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE36828C0E7 for ; Tue, 7 Dec 2010 12:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uVyBL7H4lZl for ; Tue, 7 Dec 2010 12:13:31 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id EF3C728C0E1 for ; Tue, 7 Dec 2010 12:13:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1PQ3w8-0006ri-Mm; Tue, 07 Dec 2010 15:14:56 -0500 Message-Id: From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 7 Dec 2010 14:14:56 -0600 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 09 Dec 2010 04:15:57 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: RDF Working Group (until 2011-01-16) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 20:13:32 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to create modify the Semantic Web Activity (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for an RDF Working Group: http://www.w3.org/2010/09/rdf-wg-charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2011-01-16 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Ivan Herman . Thank you, Ian Jacobs, Head of W3C Communications [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From tlyu@mit.edu Thu Dec 9 20:37: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 ADC9228C113; Thu, 9 Dec 2010 20:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.59 X-Spam-Level: X-Spam-Status: No, score=-100.59 tagged_above=-999 required=5 tests=[AWL=2.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVhHWbMPqQpa; Thu, 9 Dec 2010 20:37:56 -0800 (PST) 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 2A96528C108; Thu, 9 Dec 2010 20:37:56 -0800 (PST) X-AuditID: 12074424-b7b0bae000000a05-ea-4d01aefe013c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id B8.8E.02565.EFEA10D4; Thu, 9 Dec 2010 23:39:26 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id oBA4dPBJ013515; Thu, 9 Dec 2010 23:39:26 -0500 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 oBA4dN0O028155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Dec 2010 23:39:24 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id oBA4dMpB001150; Thu, 9 Dec 2010 23:39:22 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-cdmi-mediatypes.all@tools.ietf.org From: Tom Yu Date: Thu, 09 Dec 2010 23:39:22 -0500 Message-ID: Lines: 4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Subject: [secdir] secdir review of draft-cdmi-mediatypes 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, 10 Dec 2010 04:37:58 -0000 This document does not appear to introduce any significant security concerns of its own. I suggest that the Security Considerations section additionally mention the JSON-related security considerations in RFC 4627. From yoshihiro.ohba@toshiba.co.jp Thu Dec 9 23:46: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 DF7DF3A6C67; Thu, 9 Dec 2010 23:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gglVnDcAH1oF; Thu, 9 Dec 2010 23:46:48 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 80FAD3A6A2B; Thu, 9 Dec 2010 23:46:48 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id oBA7lV75009527; Fri, 10 Dec 2010 16:47:31 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id oBA7lV7X015305; Fri, 10 Dec 2010 16:47:31 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id SAA15304; Fri, 10 Dec 2010 16:47:31 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id oBA7lVMm027001; Fri, 10 Dec 2010 16:47:31 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id oBA7ikvh006944; Fri, 10 Dec 2010 16:47:09 +0900 (JST) Received: from [133.196.17.90] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LD7006Y1C91W050@mail.po.toshiba.co.jp>; Fri, 10 Dec 2010 16:46:13 +0900 (JST) Date: Fri, 10 Dec 2010 16:46:07 +0900 From: Yoshihiro Ohba In-reply-to: <4D009D34.1020809@deployingradius.com> To: Alan DeKok Message-id: <4D01DABF.6060604@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <4D009D34.1020809@deployingradius.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 Cc: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, 'Alper Yegin' , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, Ralph Droms Subject: Re: [secdir] Secdir review of draft-ohba-pana-relay 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, 10 Dec 2010 07:46:50 -0000 Thank you very much for reviewing the draft. Please see my comments below. (2010/12/09 18:11), 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. > > Margaret Wasserman said: >> IMO, there is (at least) one way in which the introduction of a relay >> changes the security model for PANA. In the original PANA protocol, >> the PANA Authentication Agent (PAA) determines the source IP Address >> and source UDP Port number of the PANA Client (PaC) by looking in the >> headers of the request, and responds to that IP Address/Port. >> However, in the case where a relay is being used, the client IP >> Address/Port are included in an option in the relay message. Requests >> are sent from the relay and responses are sent to the relay, using the >> IP Address/Port in the headers, but the client (using information from >> the option) is authenticated. I understand that this changes the >> security properties of the PANA exchange, but I am not sure if it >> changes them in a way that matters for the PANA protocol. >> >> So, I could use help here from someone who understands EAP (and >> ideally, PANA) well enough to understand how/if a relay can safely be >> used in a PANA environment. > > The proposed document doesn't affect the security of EAP. EAP is > already transported over insecure and unauthenticated channels (i.e. > EAPoL), so changing the PANA transport requirements should have no > effect on EAP. > > Some questions: > > Are multiple relays allowed? If so, how do they work? If not, how are > they detected, and forbidden by the participants? > Relaying happens only one time for each message belonging to the same PANA session. We can clarify this in the draft. > The Security Considerations section says: > > Since the PRE does not maintain per-PaC state, the PRE is robust > against resource consumption DoS (Deniable of Service) attack. > > However, the PRE relays packets to the PaC. This means that entities > on the PAA network can now send PANA messages to the PaC, when they > previously could not. While the PaC is supposed to discard invalid > and/or unexpected messages (RFC 5191), the PRE can be used to send > messages to *arbitrary* UDP ports on the PaC or any other machine in the > PaC network. > > The same attack applies (but less so) in the inverse direction. A > fake PaC can send the PAA arbitrary PANA messages. Since this can > already happen today, there is no new issue here. > > Having a stateful PRE would help address this attack. It would not > prevent it, as the PANA messages are unsigned, and anyone can pretend to > be the PRE. > > I would suggest requiring that the PRE enforce the Message Validity > checks of RFC 5191, Section 5.5. If this cannot be done in its > entirety, this draft should add a new section entitled "Message Validty > checks for the PRE". > > e.g. The PRE MUST relays only well-formed PANA messages to the PAA. > And before relaying messages back to the PaC, it ensures that the > Relayed-Message AVP contains a well-formed PANA message. All malformed > messages MUST be discarded. > I agree that some message validity check at the PRE can help address issues you mentioned above. In my analysis: (1) Some check requires the PRE to be stateful (e.g., sequence number check on relayed PANA message requires the PRE to keep track of sequence numbers for each session), (2) some check does not require the PRE to be stateful (e.g., message length check), and (3) some check is impossible unless security is compromised (e.g., AUTH AVP check of relayed PANA message using the PANA SA between the PaC and the PAA). Let's discuss (1) and (2). There are several design choices here: (a) (1) and (2) are mandatory (b) (1) is optional, (2) is mandatory (c) (1) and (2) are optional I listed these choices because ZigBee has chosen pana-relay mainly because of the stateless nature of PRE in its current design and I think that making PRE stateful can be a too strong requirement for ZigBee. (Just to clarify, "stateless" here means that per-PaC state does not need to be maintained by PRE.) > Since the behavior of the PAA is also changing, it would be good to > leverage the PAA session tracking to add a cryptographic token between > the PRE and PAA. This token would be added by the PRE prior to relaying > a message, and the PAA could echo it back in the response. This > ability means that the PRE is still stateless (in terms of tracking > packets), but gains a little bit of security by maintaining additional > state. > > The token would be subject to eavesdropping, so it offers small > additional security. Adding it is a recommendation, not a requirement > of this review. > > The token could be (for example) a signature of the PaC source IP and > port, using a secret known only to the PaC, and generated automatically. > The secret would also need to change periodically. > > Along with Message Validation, this token would increase the bar for > attackers sending packets to the PaC. Rather than simply being able to > leverage the PRE to send arbitrary traffic to the PaC, the attacker > would need to be able to monitor PRE -> PAA traffic, and to then send > well-formed PANA messages to the PaC, to the port used by the PaC for > receiving PANA messages. That minimizes the attack exposure. > To address Margaret's security comment, we (co-authors) are currently discussing whether we can recommend use of DTLS to protect PRY message between PRE and PAA for less-trusted environment. Your suggested token-based approaches (PRE-generated and PaC-generated tokens) can be another recommendation for similar environment. I think we need to consider tradeoff between the level of improvement in security and the required cost for each alternative. > > There is also some confusion between PRE and PRY, such as: > > (c) The source IP address and UDP port number of the PRY is stored in > a new PANA session attribute "IP address and UDP port number of the > PRE". > > The text should consistently refer to "address of the PRE", or > "address carried within the PRY" We will improve the consistency about referring to addresses. Thank you, Yoshihiro Ohba > > > Alan DeKok. > > From aland@deployingradius.com Fri Dec 10 00:40: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 DDD903A6C83; Fri, 10 Dec 2010 00:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efxo+RoLGCvi; Fri, 10 Dec 2010 00:40:02 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 673DE3A6C82; Fri, 10 Dec 2010 00:40:02 -0800 (PST) Message-ID: <4D01E7BB.50605@deployingradius.com> Date: Fri, 10 Dec 2010 09:41:31 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yoshihiro Ohba References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> In-Reply-To: <4D01DABF.6060604@toshiba.co.jp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, 'Alper Yegin' , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, Ralph Droms Subject: Re: [secdir] Secdir review of draft-ohba-pana-relay 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, 10 Dec 2010 08:40:04 -0000 Yoshihiro Ohba wrote: > Relaying happens only one time for each message belonging to the same > PANA session. We can clarify this in the draft. Yes. The draft does not forbid a message passing through multiple relays. > I agree that some message validity check at the PRE can help address > issues you mentioned above. In my analysis: (1) Some check requires > the PRE to be stateful (e.g., sequence number check on relayed PANA > message requires the PRE to keep track of sequence numbers for each > session), (2) some check does not require the PRE to be stateful > (e.g., message length check), and (3) some check is impossible unless > security is compromised (e.g., AUTH AVP check of relayed PANA message > using the PANA SA between the PaC and the PAA). Let's discuss (1) and > (2). There are several design choices here: > > (a) (1) and (2) are mandatory > (b) (1) is optional, (2) is mandatory > (c) (1) and (2) are optional > > I listed these choices because ZigBee has chosen pana-relay mainly > because of the stateless nature of PRE in its current design and I > think that making PRE stateful can be a too strong requirement for ZigBee. A cryptographic token can help with this. The token can contain information about the sequence number, signed by a secret known only to the PRE. > To address Margaret's security comment, we (co-authors) are currently > discussing whether we can recommend use of DTLS to protect PRY message > between PRE and PAA for less-trusted environment. Your suggested > token-based approaches (PRE-generated and PaC-generated tokens) can be > another recommendation for similar environment. I think we need to > consider tradeoff between the level of improvement in security and the > required cost for each alternative. Yes. Adding a token is simple, and requires minimal changes to the PAA (echo the token), and some small work on the PRE (generate / verify the token). In contrast, DTLS takes much more work. Alan DeKok. From kent@bbn.com Fri Dec 10 08:01: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 48BB03A6B52 for ; Fri, 10 Dec 2010 08:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKzM73SXpeAE for ; Fri, 10 Dec 2010 08:01:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 136413A6AA4 for ; Fri, 10 Dec 2010 08:01:14 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:47202 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PR0kU-000KAs-W8 for secdir@ietf.org; Fri, 10 Dec 2010 06:02:51 -0500 Mime-Version: 1.0 Message-Id: Date: Fri, 10 Dec 2010 11:02:42 -0500 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-920125532==_ma============" Subject: [secdir] review of draft-ietf-v6ops-3177bis-end-sites-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 16:01:15 -0000 --============_-920125532==_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. Draft-ietf-v6ops-3177bis-end-sites-00.txt is a very short (9 page) document that revises a policy on the default size of an IPv6 address block that should be assigned to an end site. It updates RFC 3177. The original recommendation (developed by the RIRs) was for each end site to be assigned a /48. Since the publication of RFC 3177, three of the RIRs (APNIC, RIOPE, and ARIN) have revised their policies to encourage assignment of /56 blocks to end sites. This document updates 3177 in two significant ways - It deprecates /128 assignments - It moves away from the "one size fits all" suggestion of end site address block assignments There is no text in the security considerations section. Given the narrow focus of this document, I concur. One might note that moving away from /48, /64, and /128 boundaries may make life a tiny bit harder for address scanning by malware that it not very sophisticated, but I don't think this is a major concern. Steve --============_-920125532==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-v6ops-3177bis-end-sites-00.txt
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.
Draft-ietf-v6ops-3177bis-end-sites-00.txt is a very short (9 page) document that revises a policy on the default size of an IPv6 address block that should be assigned to an end site.  It updates RFC 3177. The original recommendation (developed by the RIRs) was for each end site to be assigned a /48. Since the publication of RFC 3177, three of the RIRs (APNIC, RIOPE, and ARIN) have revised their policies to encourage assignment of /56 blocks to end sites.
This document updates 3177 in two significant ways
        - It deprecates /128 assignments
        - It moves away from the "one size fits all" suggestion of end site address block assignments

There is no text in the security considerations section. Given the narrow focus of this document, I concur.  One might note that moving away from /48, /64, and /128 boundaries may make life a tiny bit harder for address scanning by malware that it not very sophisticated, but I don't think this is a major concern.

Steve
--============_-920125532==_ma============-- From ksankar@cisco.com Thu Dec 9 21: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 7E83F28C13E; Thu, 9 Dec 2010 21:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svTUZvaBmyQo; Thu, 9 Dec 2010 21:03:02 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C2A5228C113; Thu, 9 Dec 2010 21:03:02 -0800 (PST) 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: AvsEABZDAU2rR7H+/2dsb2JhbACkAHikPpsdhUoEhGSJL4gK X-IronPort-AV: E=Sophos;i="4.59,322,1288569600"; d="scan'208";a="300225217" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Dec 2010 05:04:32 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oBA54URO028966; Fri, 10 Dec 2010 05:04:30 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Dec 2010 21:04:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Dec 2010 21:04:52 -0800 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A0C9AFD44@xmb-sjc-219.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-cdmi-mediatypes Thread-Index: AcuYJErAFym7wI/xQTSC5q5//DS/TAAA0CQg References: From: "Krishna Sankar (ksankar)" To: "Tom Yu" , , , X-OriginalArrivalTime: 10 Dec 2010 05:04:30.0585 (UTC) FILETIME=[BA3C4690:01CB9827] X-Mailman-Approved-At: Fri, 10 Dec 2010 08:20:53 -0800 Subject: Re: [secdir] secdir review of draft-cdmi-mediatypes 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, 10 Dec 2010 05:03:04 -0000 Tom, The security considerations in RFC 4627 pertains to JavaScript and security pertaining to scripting languages. We are not using JavaScript in CDMI and so that section is not relevant here. Cheers -----Original Message----- From: Tom Yu [mailto:tlyu@MIT.EDU]=20 Sent: Thursday, December 09, 2010 8:39 PM To: iesg@ietf.org; secdir@ietf.org; draft-cdmi-mediatypes.all@tools.ietf.org Subject: secdir review of draft-cdmi-mediatypes This document does not appear to introduce any significant security concerns of its own. I suggest that the Security Considerations section additionally mention the JSON-related security considerations in RFC 4627. From tlyu@mit.edu Fri Dec 10 10:32: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 3260728C10A; Fri, 10 Dec 2010 10:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.758 X-Spam-Level: X-Spam-Status: No, score=-100.758 tagged_above=-999 required=5 tests=[AWL=1.841, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URElBssXxsVx; Fri, 10 Dec 2010 10:32:15 -0800 (PST) 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 A436128C100; Fri, 10 Dec 2010 10:32:15 -0800 (PST) X-AuditID: 12074424-b7b0bae000000a05-7c-4d02728b553a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 07.8A.02565.B82720D4; Fri, 10 Dec 2010 13:33:47 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id oBAIXk0G029284; Fri, 10 Dec 2010 13:33:46 -0500 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 oBAIXjgk028872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Dec 2010 13:33:46 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id oBAIXjKk003286; Fri, 10 Dec 2010 13:33:45 -0500 (EST) To: "Krishna Sankar (ksankar)" References: <9FA16888AD1BF64ABCE6C2532CCEB98A0C9AFD44@xmb-sjc-219.amer.cisco.com> From: Tom Yu Date: Fri, 10 Dec 2010 13:33:44 -0500 In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A0C9AFD44@xmb-sjc-219.amer.cisco.com> (Krishna Sankar's message of "Thu, 9 Dec 2010 21:04:52 -0800") Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Cc: draft-cdmi-mediatypes.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-cdmi-mediatypes 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, 10 Dec 2010 18:32:17 -0000 "Krishna Sankar (ksankar)" writes: > Tom, > The security considerations in RFC 4627 pertains to JavaScript > and security pertaining to scripting languages. We are not using > JavaScript in CDMI and so that section is not relevant here. > Cheers > Section 3.1 of your document says that the CDMI interface represents CDMI objects in JSON format. If some element of some CDMI implementation is written (perhaps ill-advisedly) in JavaScript and chooses to use eval() to parse the JSON encoding, then I believe the Security Considerations of RFC 4627 would apply. From alper.yegin@yegin.org Mon Dec 13 00:27: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 DF2183A6CE7; Mon, 13 Dec 2010 00:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.85 X-Spam-Level: X-Spam-Status: No, score=-99.85 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449, 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 JwArK6QBJUDi; Mon, 13 Dec 2010 00:27:08 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id E4AC23A6900; Mon, 13 Dec 2010 00:27:07 -0800 (PST) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Mhi4R-1PoFTi0U7f-00N5LG; Mon, 13 Dec 2010 03:28:26 -0500 From: "Alper Yegin" To: "'Yoshihiro Ohba'" , "'Alan DeKok'" References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> In-Reply-To: <4D01DABF.6060604@toshiba.co.jp> Date: Mon, 13 Dec 2010 10:28:10 +0200 Message-ID: <001001cb9a9f$b697a460$23c6ed20$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuYPqjxXV+rcKfeSK63xsDrVdaSlACYEgOg Content-Language: en-us X-Provags-ID: V02:K0:DS3Zt2Q9nWRGOeGpCSsrLF65VBjLLyIeU3yaz/kT8re j8wUbTKLaD37OX3FaoMylOXCApEtFJAmMxw3tH1uKhlB/aXeic O99Sf7Ykr/P1TPCj2Nxug9xknRBj9ukAMD/QQEvsIazh156YnZ 6rg7n7ClYpnmh+yk79XQ5XjFDXqTKKgZKfRtSmR8qhSqgxCPJg LV25riH5MaKMeezwa7xVwbwCihWV50PfZwtP7LIkqE= Cc: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: [secdir] PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay) 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, 13 Dec 2010 08:27:09 -0000 Hi Alan, Thank you for the review. > > The Security Considerations section says: > > > > Since the PRE does not maintain per-PaC state, the PRE is robust > > against resource consumption DoS (Deniable of Service) attack. > > > > However, the PRE relays packets to the PaC. This means that > entities > > on the PAA network can now send PANA messages to the PaC, when they > > previously could not. While the PaC is supposed to discard invalid > > and/or unexpected messages (RFC 5191), the PRE can be used to send > > messages to *arbitrary* UDP ports on the PaC or any other machine in > the > > PaC network. Is the concern that a rogue PRE injecting bogus PANA messages towards the PaC, or a legitimate PRE relaying bogus PANA messages injected by some rogue PAA? > > > > The same attack applies (but less so) in the inverse direction. A > > fake PaC can send the PAA arbitrary PANA messages. Since this can > > already happen today, there is no new issue here. > > > > Having a stateful PRE would help address this attack. It would > not > > prevent it, as the PANA messages are unsigned, and anyone can pretend > to > > be the PRE. > > > > I would suggest requiring that the PRE enforce the Message > Validity > > checks of RFC 5191, Section 5.5. If this cannot be done in its > > entirety, this draft should add a new section entitled "Message > Validty > > checks for the PRE". > > > > e.g. The PRE MUST relays only well-formed PANA messages to the > PAA. > > And before relaying messages back to the PaC, it ensures that the > > Relayed-Message AVP contains a well-formed PANA message. All > malformed > > messages MUST be discarded. Why not let the PaC deal with this? It already performs such checks. Alper From alper.yegin@yegin.org Mon Dec 13 00:30:25 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 D11DD3A6CE7; Mon, 13 Dec 2010 00:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.59 X-Spam-Level: X-Spam-Status: No, score=-99.59 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449, 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 YDXGfSN34+5R; Mon, 13 Dec 2010 00:30:25 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id E4C783A6CDE; Mon, 13 Dec 2010 00:30:24 -0800 (PST) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M1FVw-1QKqEd3fTs-00t71D; Mon, 13 Dec 2010 03:32:00 -0500 From: "Alper Yegin" To: "'Yoshihiro Ohba'" , "'Alan DeKok'" References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> In-Reply-To: <4D01DABF.6060604@toshiba.co.jp> Date: Mon, 13 Dec 2010 10:31:45 +0200 Message-ID: <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuYPqjxXV+rcKfeSK63xsDrVdaSlACYQXfA Content-Language: en-us X-Provags-ID: V02:K0:ziwkryUESO3ycLQz805SxrCb840R42bq8QBvjTYIkGI q2bUQ9YF/f1ruZ9+ysadYlm/kVBVsB8qduj7eQgeu9rhsMGqua kOAZcAPJvTTmYqHVug1D0jjcHw2B40UJx1mU51c8P/dQc4BHXd hmxIwlkvqta/1gCp1UMVWBg6WZNT4JmBLU269ESCAxo5K7Jwzg HwS9Sv/qQZw74OEKWNPYb8oN1XajQsHNVFvHddoYVQ= Cc: secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) 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, 13 Dec 2010 08:30:25 -0000 Alan, > > Since the behavior of the PAA is also changing, it would be good > to > > leverage the PAA session tracking to add a cryptographic token > between > > the PRE and PAA. This token would be added by the PRE prior to > relaying > > a message, and the PAA could echo it back in the response. This > > ability means that the PRE is still stateless (in terms of tracking > > packets), but gains a little bit of security by maintaining > additional > > state. > > > > The token would be subject to eavesdropping, so it offers small > > additional security. Adding it is a recommendation, not a > requirement > > of this review. > > > > The token could be (for example) a signature of the PaC source IP > and > > port, using a secret known only to the PaC, and generated > automatically. > > The secret would also need to change periodically. > > > > Along with Message Validation, this token would increase the bar > for > > attackers sending packets to the PaC. Rather than simply being able > to > > leverage the PRE to send arbitrary traffic to the PaC, the attacker > > would need to be able to monitor PRE -> PAA traffic, and to then > send > > well-formed PANA messages to the PaC, to the port used by the PaC for > > receiving PANA messages. That minimizes the attack exposure. Arbitrary traffic cannot pass the validation on the PaC, as the sequence numbers need to match. And there is also state machine match needed. PaC's is in certain state and would not react to any arbitrary message unless the message is expected in the current state. Alper From aland@deployingradius.com Mon Dec 13 08:10: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 A002928C0E2; Mon, 13 Dec 2010 08:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKBOd9AqeYMX; Mon, 13 Dec 2010 08:10:10 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id BE8793A6DDA; Mon, 13 Dec 2010 08:10:10 -0800 (PST) Message-ID: <4D0645C3.7060406@deployingradius.com> Date: Mon, 13 Dec 2010 17:11:47 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alper Yegin References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001001cb9a9f$b697a460$23c6ed20$@yegin@yegin.org> In-Reply-To: <001001cb9a9f$b697a460$23c6ed20$@yegin@yegin.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay) 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, 13 Dec 2010 16:10:11 -0000 Alper Yegin wrote: >>> While the PaC is supposed to discard invalid >>> and/or unexpected messages (RFC 5191), the PRE can be used to send >>> messages to *arbitrary* UDP ports on the PaC or any other machine in >> the >>> PaC network. > > Is the concern that a rogue PRE injecting bogus PANA messages towards the > PaC, or a legitimate PRE relaying bogus PANA messages injected by some rogue > PAA? A legitimate PRE relaying bogus PANA messages. Or even non-PANA messages. From my reading of the draft, the reply from the PAA is a PANA message with a PANA message carried as a TLV. But there is *no* requirement that the TLV actually carries a real PANA message. So it can be anything. >>> e.g. The PRE MUST relays only well-formed PANA messages to the >> PAA. >>> And before relaying messages back to the PaC, it ensures that the >>> Relayed-Message AVP contains a well-formed PANA message. All >> malformed >>> messages MUST be discarded. > > Why not let the PaC deal with this? It already performs such checks. The PaC discards invalid PANA messages sent to the port from which it sent PANA messages. Since the PRE is stateless, it can be coerced into sending messages to *any* port on the PaC. Since the PRE has no requirement to verify the relayed message, it doesn't even have to be PANA. The PRE can be convinced to relay arbitrary data to arbitrary UDP ports on the PaC. This can't be a good thing. Alan DeKok. From aland@deployingradius.com Mon Dec 13 08:13: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 4DF0A3A6DDA; Mon, 13 Dec 2010 08:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW53gkZ0O4-K; Mon, 13 Dec 2010 08:13:22 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 7A8B53A6DD2; Mon, 13 Dec 2010 08:13:22 -0800 (PST) Message-ID: <4D064683.30009@deployingradius.com> Date: Mon, 13 Dec 2010 17:14:59 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alper Yegin References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> In-Reply-To: <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) 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, 13 Dec 2010 16:13:23 -0000 Alper Yegin wrote: > Arbitrary traffic cannot pass the validation on the PaC, as the sequence > numbers need to match. And there is also state machine match needed. PaC's > is in certain state and would not react to any arbitrary message unless the > message is expected in the current state. If the traffic is sent to the PANA port used by the PaC. The traffic *can* be sent to other ports. As it stands today, the draft doesn't appear to prevent this. The idea of the token is to add limited state to the PRE. It will only send messages that are (a) valid PANA messages, (b) to the IP of a PaC, and (c) to the port used by the PaC used to send PANA messages. Using DTLS in between the PRE and PAA would achieve the same effect. The possibility of a rogue PAA is removed, so no token is required. Alan DeKok. From clonvick@cisco.com Mon Dec 13 14:51: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 AE9243A6E16; Mon, 13 Dec 2010 14:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uR9lxwi1VL4; Mon, 13 Dec 2010 14:51:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ECB553A6D0C; Mon, 13 Dec 2010 14:50:59 -0800 (PST) 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: Av8EAJsyBk2rR7Hu/2dsb2JhbACVYAGOKninJ5tahUoEhGQ X-IronPort-AV: E=Sophos;i="4.59,338,1288569600"; d="scan'208";a="635486614" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 13 Dec 2010 22:52:38 +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 oBDMqc7r017122; Mon, 13 Dec 2010 22:52:38 GMT Date: Mon, 13 Dec 2010 14:52:38 -0800 (PST) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-morg-list-specialuse.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-morg-list-specialuse-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 22:51:00 -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 am not altogether familiar with the placement of IMAP mailboxes to have a solid grasp on the subject. Please take my comments with a grain of salt. :) You mention at the end of Section 2 that users may configure shared mailboxes. Does that imply that mailboxes are not normally shared, and would then mean that another user would not have any access to any of the mailboxes identified by IMAP unless they were specifically given a common, shared mailbox? An example of my concern is that the \Junk mailbox may be configured to be common to all the users. In some cases, a legitimate piece of mail may be incorrectly marked as spam by a filter and then placed into the Junk bin. If that were to happen, anyone who had access to that mailbox would be able to see the contents of that email. If this could happen, then a line or two in the Security Considerations section to alert the reader to this potential threat would address my concern. Other than that, I find the document to be of good quality and ready to be discussed by the IESG. Thanks, Chris From catherine.meadows@nrl.navy.mil Mon Dec 13 15:12:18 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 E4DA628C112; Mon, 13 Dec 2010 15:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h6NxL9i9AwF; Mon, 13 Dec 2010 15:12:17 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 33BCA3A6E17; Mon, 13 Dec 2010 15:12:17 -0800 (PST) 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 oBDNDsj5021399; Mon, 13 Dec 2010 18:13:54 -0500 (EST) 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 oBDNDqGJ011871; Mon, 13 Dec 2010 18:13:52 -0500 (EST) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010121318135108118 ; Mon, 13 Dec 2010 18:13:51 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-6-442658475 From: Catherine Meadows In-Reply-To: <4CFCEDAB.9040909@ieca.com> Date: Mon, 13 Dec 2010 18:21:10 -0500 Message-Id: References: <8B1C3F0B-07B7-4B48-A2BA-9E8719A49CF9@nrl.navy.mil> <4CFCEDAB.9040909@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-turner-md4-to-historic-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 23:12:19 -0000 --Apple-Mail-6-442658475 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sean: My apologies for my late response. I've been doing a lot of traveling = and, due to an accident with my laptop, not checking my email as much as I should have. My response are also inline. Cathy On Dec 6, 2010, at 9:05 AM, Sean Turner wrote: > Catherine, >=20 > Thanks for the review. Responses inline. >=20 > spt >=20 > On 12/3/10 5: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. >>=20 >>=20 >> This document recommends that the MD4 hash algorithm be retired and = moved to historic status and gives >> the rationale for doing this, namely its known vulnerability to = collision and pre-image attacks. The impact is mostly minimal, except >> for three Microsoft RFCs that are still supported in various versions = of Windows and the RADIUS and EAP RFCs . It would be helpful to learn = what other algorithms >> these OSs and RFCs support. This would give a better idea of the = effect of dropping MD4; if there are other alternatives supported by the = OS's >> the impact should be minimal here as well. >=20 > I it might be hard to explain what alternatives are in each of the = OS's because it depends a lot on what version/release/path combo is = being used. I think RFC 4757 hints pretty strongly that = aes256-cts-hmac-sha1-96 is supported because it says to use that alg = instread of RC4-HMAC. OK. >=20 >> Other than that, I have no problems with the decision or rationale. = I agree, as I am sure that everyone else does, that MD4 >> should be retired. >>=20 >> Some nits: >>=20 >> 1. "Section 6 also discussed" should be "Section 6 also discusses" = This occurs in several places. >=20 > Fixed >=20 >> 2. " The RC4-HMAC is supported in Microsoft's Windows 2000 and >> later for backwards compatibility with Windows 2000. " >> later supported by what? I assume later versions of Windows, but it = is probably a good idea to make this clear. >=20 > r/later/later versions of Windows >=20 >> 3. When you say that with one exception the impact of retiring MD4 = would be minimal, it would be a good idea to mention that exception = upfront. >> It is fairly clear after you read the whole impact section that the = exception is the Microsoft RFCs, but nowhere where is that said = explicitly. >=20 > How about: >=20 > The impact of moving MD4 to Historic is minimal with the one exception = of Microsoft's use of MD4 as part of RC4-HMAC in Windows, the as = described below. Sounds good. =20 >=20 >> 4. I'm not sure wether or not the discussion of MD4's resistance = against key recovery attack really belongs in the impacts section (in = the discussion >> of RC4-HMAC). It might give the impression that RC4-HMAC is secure = against key recovery, and, given the other attacks found against MD4, it = is reasonable >> to believe that this security is only temporary. I would suggest = putting this discussion in the security considerations section, and = also, wherever it does end up, adding the appropriate >> caveats. >=20 > I'm hesitant to move the text because it's in there specifically to = address a comment by Sam Hartman. OK, the location of the text is not that big a deal. >=20 > My understanding of MD4's use in RC4-HMAC is that MD4 is used to = generate a key from a password and then that key is used as input to = HMAC-MD5. So I am actually saying that RC4-HMAC is secure against key = recovery attacks but this is entirely because HMAC-MD5 is used. In = other words, when HMAC-MD5 is broken then RC4-HMAC is broken. OK, I misunderstood. If I'd read the text a little more carefully I = might have figured it out, but the text is a little ambiguous at first = glance. It could be interpreted to mean that RC4-HMAC uses MD4 for key protection, but relies on some other = property than collision resistance, which perhaps eventually also be = broken. Here is my suggestion for a clarification, based on what you said: The RC4-HMAC is supported in Microsoft's Windows 2000 and later for backwards compatibility with Windows 2000. As [RFC4757] stated, RC4-HMAC doesn't rely on the collision resistance property of MD4, but uses it to generate a key = from a password, which is then used as input to HMAC-MD5. For an attacker to recover the password from RC4-HMAC, the attacker first needs to recover the key that is used with HMAC-MD5. As noted in [ID.turner-md5-seccon-update], key recovery attacks on HMAC- MD5 are not yet practical. 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-6-442658475 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Sean:

My apologies for my late response.  I've = been doing a lot of traveling and, due to an accident with my = laptop,
not checking my email as much as I should = have.

My response are also = inline.

Cathy

On Dec 6, = 2010, at 9:05 AM, Sean Turner wrote:

Catherine,

Thanks for the review. =  Responses inline.

spt

On 12/3/10 5: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 = recommends that the MD4 hash algorithm be retired and moved to historic = status and gives
the rationale = for doing this, namely its known vulnerability to collision and = pre-image attacks. The impact is mostly minimal, = except
for three Microsoft = RFCs that are still supported in various versions of  Windows and = the RADIUS and EAP RFCs .  It would be helpful to learn what other = algorithms
these OSs and RFCs = support.  This would give a better idea of the effect of dropping = MD4; if there are other alternatives supported by the = OS's
the impact should be = minimal here as well.

I it might be hard to explain = what alternatives are in each of the OS's because it depends a lot on = what version/release/path combo is being used.  I think RFC 4757 = hints pretty strongly that aes256-cts-hmac-sha1-96 is supported because = it says to use that alg instread of = RC4-HMAC.

OK.

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

Some = nits:

1. =  "Section 6 also discussed" should be "Section 6 also discusses" =   This occurs in several = places.

Fixed

2. " = The RC4-HMAC is supported in Microsoft's Windows 2000 = and
=            later = for backwards compatibility with Windows 2000. = "
later supported by what? =  I assume later versions of Windows, but it is probably a good idea = to make this clear.

r/later/later versions of = Windows

3. When you say that with one = exception the impact of retiring MD4 would be minimal, it would be a = good idea to mention that exception upfront.
It is fairly clear after you read the whole impact section =  that the exception is the Microsoft RFCs, but nowhere where is = that  said explicitly.

How about:

The = impact of moving MD4 to Historic is minimal with the one exception of = Microsoft's use of MD4 as part of RC4-HMAC in Windows, the as described = below.

Sounds good. =  

4. =  I'm not sure wether or not   the discussion of MD4's = resistance against key recovery attack really belongs in the impacts = section (in the discussion
of = RC4-HMAC).  It might give the impression that RC4-HMAC is secure = against key recovery, and, given the other attacks found against MD4, it = is reasonable
to believe that = this security is only temporary.  I would suggest putting this = discussion in the security considerations section, and also, wherever it = does end up, adding the appropriate
caveats.

I'm hesitant to move the text = because it's in there specifically to address a comment by Sam = Hartman.

OK, the location of the = text is not that big a deal.

My = understanding of MD4's use in RC4-HMAC is that MD4 is used to generate a = key from a password and then that key is used as input to HMAC-MD5. =  So I am actually saying that RC4-HMAC is secure against key = recovery attacks but this is entirely because HMAC-MD5 is used.  In = other words, when HMAC-MD5 is broken then RC4-HMAC is = broken.

OK, I misunderstood. =  If I'd read the text a little more carefully I might  have = figured it out, but the text is a little ambiguous at first glance. =  It could be interpreted to mean
that RC4-HMAC uses MD4 = for key protection, but relies on some other property than collision = resistance, which perhaps eventually also be broken.  Here is my = suggestion for
a clarification, based on what you = said:

The RC4-HMAC is supported in = Microsoft's Windows 2000 and
         =   later for backwards compatibility with Windows 2000. =  As
           [RFC4757] = stated, RC4-HMAC doesn't rely on the collision
   =         resistance property of MD4, but uses it to = generate a key from a password, which is then
   =         used as input to HMAC-MD5.   For an = attacker to recover the
         =   password from RC4-HMAC, the attacker first needs to = recover
           the key that = is used with HMAC-MD5.  As noted in
     =       [ID.turner-md5-seccon-update], key recovery attacks = on HMAC-
           MD5 are not = yet practical.

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-6-442658475-- From turners@ieca.com Mon Dec 13 16:07: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 B397C3A6E19 for ; Mon, 13 Dec 2010 16:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDaIyWQx8RVj for ; Mon, 13 Dec 2010 16:07:23 -0800 (PST) Received: from nm27.bullet.mail.ac4.yahoo.com (nm27.bullet.mail.ac4.yahoo.com [98.139.52.224]) by core3.amsl.com (Postfix) with SMTP id E30DB3A6E0F for ; Mon, 13 Dec 2010 16:07:22 -0800 (PST) Received: from [98.139.52.196] by nm27.bullet.mail.ac4.yahoo.com with NNFMP; 14 Dec 2010 00:08:59 -0000 Received: from [98.139.52.166] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 14 Dec 2010 00:08:59 -0000 Received: from [127.0.0.1] by omp1049.mail.ac4.yahoo.com with NNFMP; 14 Dec 2010 00:08:59 -0000 X-Yahoo-Newman-Id: 307795.85666.bm@omp1049.mail.ac4.yahoo.com Received: (qmail 15152 invoked from network); 14 Dec 2010 00:08:59 -0000 Received: from thunderfish.local (turners@96.231.123.240 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 13 Dec 2010 16:08:58 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 09pqKHMVM1lG9kpcfI7jy6tIdqGydhKJynv66YQGqmkMtOE XgXXm9HMBX7QAh98lMDx7OdFqQnwF8QPXQyzxoYl4QkBHHU3EAY.GqInHA7K 92y9J5_l6feFPpo92iyzxl8RNNjh771xh21GlFT6TpSBZWEqSLK.GEsaHhnx aS4dMoq1LU2edUx7L80fvSPqqz20nTUx1V0i9fsmM_v2LI3X3sqTk3Ad_jVi .eRSEUXaI0dd1DRQvdleN477J_KFGVYWc9yLBgKTBUr7IZFMxbdPg6jmLOiZ wA_q8Q3htnK8weXReQzKVxgz9I4OVR1kKdtXvQdjpVR4atnkgci8tWX2WSsu xyjJD3iPideX8tMrDADUJY76SzO0UEda1IXuBDlZVwivW5k5M2EQDv5a9Q6G fDpYfbVnoyUkyPym2XyhxQWzcxiKvKPuXwQ.YCU.E X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D06B59A.4040700@ieca.com> Date: Mon, 13 Dec 2010 19:08:58 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Catherine Meadows References: <8B1C3F0B-07B7-4B48-A2BA-9E8719A49CF9@nrl.navy.mil> <4CFCEDAB.9040909@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-turner-md4-to-historic-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 00:07:24 -0000 On 12/13/10 6:21 PM, Catherine Meadows wrote: > Hi Sean: > > My apologies for my late response. I've been doing a lot of traveling > and, due to an accident with my laptop, > not checking my email as much as I should have. No worries. We still got time ;) Hope you've been backing up all along. > My response are also inline. I'll make the modifications to the paragraph as you suggest. Cheers, spt > Cathy > > On Dec 6, 2010, at 9:05 AM, Sean Turner wrote: > >> Catherine, >> >> Thanks for the review. Responses inline. >> >> spt >> >> On 12/3/10 5: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 recommends that the MD4 hash algorithm be retired and >>> moved to historic status and gives >>> the rationale for doing this, namely its known vulnerability to >>> collision and pre-image attacks. The impact is mostly minimal, except >>> for three Microsoft RFCs that are still supported in various versions >>> of Windows and the RADIUS and EAP RFCs . It would be helpful to learn >>> what other algorithms >>> these OSs and RFCs support. This would give a better idea of the >>> effect of dropping MD4; if there are other alternatives supported by >>> the OS's >>> the impact should be minimal here as well. >> >> I it might be hard to explain what alternatives are in each of the >> OS's because it depends a lot on what version/release/path combo is >> being used. I think RFC 4757 hints pretty strongly that >> aes256-cts-hmac-sha1-96 is supported because it says to use that alg >> instread of RC4-HMAC. > > OK. >> >>> Other than that, I have no problems with the decision or rationale. I >>> agree, as I am sure that everyone else does, that MD4 >>> should be retired. >>> >>> Some nits: >>> >>> 1. "Section 6 also discussed" should be "Section 6 also discusses" >>> This occurs in several places. >> >> Fixed >> >>> 2. " The RC4-HMAC is supported in Microsoft's Windows 2000 and >>> later for backwards compatibility with Windows 2000. " >>> later supported by what? I assume later versions of Windows, but it >>> is probably a good idea to make this clear. >> >> r/later/later versions of Windows >> >>> 3. When you say that with one exception the impact of retiring MD4 >>> would be minimal, it would be a good idea to mention that exception >>> upfront. >>> It is fairly clear after you read the whole impact section that the >>> exception is the Microsoft RFCs, but nowhere where is that said >>> explicitly. >> >> How about: >> >> The impact of moving MD4 to Historic is minimal with the one exception >> of Microsoft's use of MD4 as part of RC4-HMAC in Windows, the as >> described below. > > Sounds good. >> >>> 4. I'm not sure wether or not the discussion of MD4's resistance >>> against key recovery attack really belongs in the impacts section (in >>> the discussion >>> of RC4-HMAC). It might give the impression that RC4-HMAC is secure >>> against key recovery, and, given the other attacks found against MD4, >>> it is reasonable >>> to believe that this security is only temporary. I would suggest >>> putting this discussion in the security considerations section, and >>> also, wherever it does end up, adding the appropriate >>> caveats. >> >> I'm hesitant to move the text because it's in there specifically to >> address a comment by Sam Hartman. > > OK, the location of the text is not that big a deal. >> >> My understanding of MD4's use in RC4-HMAC is that MD4 is used to >> generate a key from a password and then that key is used as input to >> HMAC-MD5. So I am actually saying that RC4-HMAC is secure against key >> recovery attacks but this is entirely because HMAC-MD5 is used. In >> other words, when HMAC-MD5 is broken then RC4-HMAC is broken. > > OK, I misunderstood. If I'd read the text a little more carefully I > might have figured it out, but the text is a little ambiguous at first > glance. It could be interpreted to mean > that RC4-HMAC uses MD4 for key protection, but relies on some other > property than collision resistance, which perhaps eventually also be > broken. Here is my suggestion for > a clarification, based on what you said: > > The RC4-HMAC is supported in Microsoft's Windows 2000 and > later for backwards compatibility with Windows 2000. As > [RFC4757] stated, RC4-HMAC doesn't rely on the collision > resistance property of MD4, but uses it to generate a key from a > password, which is then > used as input to HMAC-MD5. For an attacker to recover the > password from RC4-HMAC, the attacker first needs to recover > the key that is used with HMAC-MD5. As noted in > [ID.turner-md5-seccon-update], key recovery attacks on HMAC- > MD5 are not yet practical. > > 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 tobias.gondrom@gondrom.org Mon Dec 13 16:39:25 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 DA4BD3A6D5C for ; Mon, 13 Dec 2010 16:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.143 X-Spam-Level: X-Spam-Status: No, score=-95.143 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6pGRa-jmk+1 for ; Mon, 13 Dec 2010 16:39:25 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 8617A3A6D4F for ; Mon, 13 Dec 2010 16:39:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=o/NE3GvV9iW+tpVYKK1N4yMpKNMILHY1odRes70SBK81PXN68aNUCeuHcSzdDHkSXBeThHIoXaCpuz/k/a7a8qLIgVvC1X8b/MZVcO83L/26pCLdt4rsF+6SU2slFkNt; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 26279 invoked from network); 14 Dec 2010 01:40:29 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Dec 2010 01:40:29 +0100 Message-ID: <4D06BD5F.5040807@gondrom.org> Date: Tue, 14 Dec 2010 00:42:07 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-avt-rtp-cnames.all@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: keith.drage@alcatel-lucent.com, even.roni@huawei.com, abegen@cisco.com, dwing@cisco.com, csp@csperkins.org, rjsparks@nostrum.com Subject: [secdir] secdir review of draft-ietf-avt-rtp-cnames-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 00:39:26 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The Security Considerations section is ok and the draft does not add further security aspects beyond it. However there are a number of issues with the draft, including use of rfc2119 language and hash agility: 1. section 4.2 first bullet point: spelling: s/"and endpoint MUST generate and store a Universally"/"an endpoint MUST generate and store a Universally" 2. COMMENTS/DISCUSS: section 4.2: the draft makes the distinction between 4 cases: a) long-term persistent b) short-term persistent with IPv6 c) short-term persistent with IPv4 d) per-session RTCP CNAME all use MUST to specify the generated CNAME with _different_ methods. This raises a number of potential issues: 2.1. The boundary between the definition of long-term and short-term with persistence across several related RTP sessions (see 4.1) is not well defined, thus different MUST clauses for how to treat these two cases seem problematic. As it can be hard for an application to determine the difference between across several sessions and long-term. 2.2. Though I understand why a system may not want to use UUID in all four cases, it is unclear to me why it should be forbidden to use UUID for scenarios b, c and d. (which is implied by using "MUST" with the defined method). 2.3. in section 4.2. next to last paragraph it states: (other methods) "beyond the three methods listed above, are not compliant with this specification and SHOULD NOT be used." If the document is std track and updates 3550 and uses "MUST" for the methods it would be inconsistent to frame it here as "SHOULD NOT". 2.4. Question: which leads to another question: are there upgrade issues with 3550-applications with this update or is there an upgrade path for RTP from 3550 to draft-ietf-avt-rtp-cnames? 2.5. case b (IPv6): I understand that one reason for different handling of IPv4 is NAT and private address spaces. And although NAT with IPv6 should not make sense, in theory this could still happen, so I am not sure whether these two cases (b and c) can be and need to be handled differently. Overall: a solution could be that UUID be allowed for all methods (e.g. frame it as "MUST use one of the here described methods") and maybe the unification of case b (short-term IPv6) and c (short-term IPv4) - either allowing both methods for both and indicating preferred approaches with "SHOULD" for each of them (e.g. SHOULD use MAC for scenarios of possible NAT) - unless the authors can explain why we really need to mandate these two different scenarios and why IPv6 has not at least in theory NAT issues? 3. hash agility: in section 4.2 last paragraph the draft mandates for case d (per-session RTCP CNAMEs ) to use SHA1-HMAC and truncate the value to 96bit 3.1. DISCUSS: The drafts should not be tied to SHA1 and actually allow use of other algorithms (e.g. SHA2/SHA-256/-512) as well. 3.2. Question: maybe obvious, but why do you need to truncate the output to 96bit? 3.3. Clarification: it also states at the end of this paragraph that the "user@" part of the CNAME "is omitted". Does this mean "MAY be omitted on single-user systems, and MAY be replaced by an opaque token on multiuser systems" like for cases a-c or is this intentionally different and mandatory in d? Kind regards, Tobias Tobias Gondrom email: tobias.gondrom@gondrom.org From barryleiba@gmail.com Mon Dec 13 18:04: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 2AD0828C124; Mon, 13 Dec 2010 18:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVExeuU0gEXR; Mon, 13 Dec 2010 18:03:58 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 925AE28C122; Mon, 13 Dec 2010 18:03:58 -0800 (PST) Received: by iwn40 with SMTP id 40so172318iwn.31 for ; Mon, 13 Dec 2010 18:05:37 -0800 (PST) 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=OmQ2JAtgnY/0uadqfOn9tICcvJ5pAa8iXNR2oUu/9Lk=; b=Q7u2LxttNDbraYmC5Z2tS4NRPHPDVq8HPh4O8U1uR0PFhnHORa25edmDqE7zKmZOOQ +BudfseoITe0GIe276LGnM2wf2KamRG7OnDqYV0B4R0Z9OKSTLs9ktzELgG+Ziv/kf6K uOdBn7aK5vjoesU94zf4VjNrrdJZiIIhA2+1g= 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=SQKVFZJ2A0dm2YNHjWb06pQqM/s9lNBVLSxkPVY3HepfvLibFmlrK8CeqtUlb4GD8v 6QSILpPRslZ8Rj9BjXdE6nbdQXeZy0c52r9G+8Az+mz+xxP1qzz5wejZCMfoFwPgsYwN AIOO1QBHPDxqbz4czkdfZE36fLItuz5wpg6yc= MIME-Version: 1.0 Received: by 10.231.11.204 with SMTP id u12mr2648046ibu.109.1292292337569; Mon, 13 Dec 2010 18:05:37 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Mon, 13 Dec 2010 18:05:37 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Dec 2010 21:05:37 -0500 X-Google-Sender-Auth: ChQ7-_yQbYXjd25_Ur2wvnq1OZw Message-ID: From: Barry Leiba To: Chris Lonvick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-morg-list-specialuse.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-morg-list-specialuse-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 02:04:00 -0000 Hi, Chris, and thanks for the review. > I am not altogether familiar with the placement of IMAP mailboxes to have= a > solid grasp on the subject. =A0Please take my comments with a grain of sa= lt. > =A0:) Noted. > You mention at the end of Section 2 that users may configure shared > mailboxes. =A0Does that imply that mailboxes are not normally shared, and > would then mean that another user would not have any access to any of the > mailboxes identified by IMAP unless they were specifically given a common= , > shared mailbox? > > An example of my concern is that the \Junk mailbox may be configured to b= e > common to all the users. =A0In some cases, a legitimate piece of mail may= be > incorrectly marked as spam by a filter and then placed into the Junk bin.= If > that were to happen, anyone who had access to that mailbox would be able = to > see the contents of that email. Personal IMAP mailboxes are normally private. Users may also have access to public mailboxes (say, archives of mailing lists, or netnews collections), to group mailboxes (our department's "to-do" folder), or to personal mailboxes of others that have been explicitly shared. These are usually presented in a separate namespace from the personal mailboxes. Your concern is reflected in the second paragraph in the Security Considerations: CREATE command "USE" parameter: In some server implementations, some special uses may imply automatic action by the server. For example, creation of a "\Junk" mailbox might cause the server to start placing messages that have been evaluated as spam into the mailbox. Implementors SHOULD consider the consequences of allowing a user (or client program) to designate the target of such automatic action. I can make this more explicit, if you think that's important, by adding another paragraph: Example: If a user is allowed to give the "\Junk" attribute to a shared mailbox, legitimate mail that's misclassified as junk (false positives) will be put into that shared mailbox, exposing the user's private mail to others. The server = might warn a user of that possibility, or might refuse to allow the specification to be made on a shared mailbox. (Note that this problem exists independent of= this specification, if the server allows a user to share a mailbox that's already in use for such a function.) Does that help, do you think? Barry From gwz@net-zen.net Mon Dec 13 22:38: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 344AA3A6E4F for ; Mon, 13 Dec 2010 22:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXrMJUrhoHgC for ; Mon, 13 Dec 2010 22:37:59 -0800 (PST) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id 4EBB23A6E4B for ; Mon, 13 Dec 2010 22:37:58 -0800 (PST) Received: (qmail 3323 invoked from network); 14 Dec 2010 06:39:38 -0000 Received: from unknown (124.122.110.184) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 14 Dec 2010 06:39:37 -0000 From: "Glen Zorn" To: , , , Date: Tue, 14 Dec 2010 13:39:31 +0700 Organization: Network Zen Message-ID: <001201cb9b59$acd02d70$06708850$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcubWamob5YqS29CS2ujzWXZeKAbbg== Content-Language: en-us Subject: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 06:38: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. Section 3.1 says: o Permit RADIUS authentication and accounting replies from RADIUS servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: DB8:100::10 that are listening on UDP ports 1645 and 1646. Note that this doesn't account for a server using Internet Assigned Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. So, in other words, RADIUS traffic on the ports (officially assigned for more than ten years now) will be blocked. This seems like a very poor example. From ksankar@cisco.com Sat Dec 11 20:58:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC0D3A683E; Sat, 11 Dec 2010 20:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG8EsEjfPzM3; Sat, 11 Dec 2010 20:57:59 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 301253A683B; Sat, 11 Dec 2010 20:57:59 -0800 (PST) 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: AvsEAOrkA02rRN+K/2dsb2JhbACkDnilMZoChUoEhGSJL4gK X-IronPort-AV: E=Sophos;i="4.59,331,1288569600"; d="scan'208";a="301019370" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 12 Dec 2010 04:59:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oBC4xYHu013994; Sun, 12 Dec 2010 04:59:34 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Dec 2010 20:59:34 -0800 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: Sat, 11 Dec 2010 20:59:56 -0800 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A0C9B0154@xmb-sjc-219.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-cdmi-mediatypes Thread-Index: AcuYmMsEnuydau+PT+mFFm6VecjprABIJCtA References: <9FA16888AD1BF64ABCE6C2532CCEB98A0C9AFD44@xmb-sjc-219.amer.cisco.com> From: "Krishna Sankar (ksankar)" To: "Tom Yu" X-OriginalArrivalTime: 12 Dec 2010 04:59:34.0028 (UTC) FILETIME=[5E4CC4C0:01CB99B9] X-Mailman-Approved-At: Tue, 14 Dec 2010 00:42:30 -0800 Cc: draft-cdmi-mediatypes.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-cdmi-mediatypes 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, 12 Dec 2010 04:58:00 -0000 New version posted http://www.ietf.org/id/draft-cdmi-mediatypes-04.txt Cheers & thanks -----Original Message----- From: Tom Yu [mailto:tlyu@MIT.EDU]=20 Sent: Friday, December 10, 2010 10:34 AM To: Krishna Sankar (ksankar) Cc: iesg@ietf.org; secdir@ietf.org; draft-cdmi-mediatypes.all@tools.ietf.org Subject: Re: secdir review of draft-cdmi-mediatypes "Krishna Sankar (ksankar)" writes: > Tom, > The security considerations in RFC 4627 pertains to JavaScript > and security pertaining to scripting languages. We are not using > JavaScript in CDMI and so that section is not relevant here. > Cheers > Section 3.1 of your document says that the CDMI interface represents CDMI objects in JSON format. If some element of some CDMI implementation is written (perhaps ill-advisedly) in JavaScript and chooses to use eval() to parse the JSON encoding, then I believe the Security Considerations of RFC 4627 would apply. From kathleen.moriarty@emc.com Mon Dec 13 18:46: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 D045128C137; Mon, 13 Dec 2010 18:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrOCVrfGedSV; Mon, 13 Dec 2010 18:46:41 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 5F90928C0CF; Mon, 13 Dec 2010 18:46:41 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBE2mJWm022899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2010 21:48:19 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 13 Dec 2010 21:48:13 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.221.46.113]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBE2lEwf020730; Mon, 13 Dec 2010 21:47:14 -0500 Received: from mx06a.corp.emc.com ([169.254.1.172]) by mxhub05.corp.emc.com ([128.221.46.113]) with mapi; Mon, 13 Dec 2010 21:47:13 -0500 From: To: , , Date: Mon, 13 Dec 2010 21:47:12 -0500 Thread-Topic: draft-ietf-tls-ssl2-must-not-03 Thread-Index: AcubOTU4L7w32XawTbC9rA16pwoFHg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Tue, 14 Dec 2010 00:42:30 -0800 Cc: tim.polk@nist.gov Subject: [secdir] draft-ietf-tls-ssl2-must-not-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 02:46:43 -0000 Hello, draft-ietf-tls-ssl2-must-not-03 looks good from a security perspective. M= y only question is to ask if the document should list out any previously pu= blished RFCs that contain references to use TLS or at least those that cont= ain TLS v2? I reviewed a similar one for Sean last month and it did contain references. Thanks, Kathleen From vincent.roca@inrialpes.fr Tue Dec 14 03:09: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 E80023A6F8C; Tue, 14 Dec 2010 03:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in9WDU2fvgmn; Tue, 14 Dec 2010 03:09:18 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 46D263A6F7F; Tue, 14 Dec 2010 03:09:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,341,1288566000"; d="scan'208";a="82585792" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 14 Dec 2010 12:10:57 +0100 Message-ID: <4D0750C1.5090304@inrialpes.fr> Date: Tue, 14 Dec 2010 12:10:57 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mpls-tp-oam-framework.all@tools.ietf.org Subject: [secdir] SecDir review of draft-ietf-mpls-tp-oam-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: Tue, 14 Dec 2010 11:09:20 -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. The Security Considerations section of this I-D is fairly strange. The authors first highlight that OAM traffic contains sensitive data (like passwords), and then quickly conclude that securing this traffic is impossible and therefore they require that the network be physically secured. The reason provided is the fact that there are too many entities that are likely to communicate to establish and maintain SAs between them. Well, I don't know the specificities of MPLS networks, nor the OAM operations in MPLS networks, however: 1- I need more information to be convinced that there is indeed no other solution than requiring that the whole physical network be totally secured; 2- I need more information to be convinced that fully securing such a physical network is feasible; Honestly speaking I'm not convinced by 1-. What about solutions based on temporary SA? Are the OAM exchanges so frequent to require that each secure connection be maintained all the time? Would a solution that establishes those connections on-the-fly, when needed, be realistic? Another direction could be to use shared keys between the entities of a group. Or perhaps using a per-packet signature approach is feasible, using some public key infrastructure, if the exchanges are infrequent. There are probably other IETF protocols that have similar requirements. What about the KARP WG that focuses on secure routing protocols? May some ideas be borrowed and applied here (that's a fully open question)? Concerning 2-, a quick search on "MPLS attacks" on the web provides a small number of references. There's also a book on the subject ("Analyzing MPLS VPN Security", M. H. Behringer, M. Morrow, Cisco Press, 2005). I don't known the domain at all but I'd like to be convinced that 2- is feasible. A minor comment. I have the feeling that the authors use the term "man-in-the-middle attack" to denote any attack where the attacker takes control of the physical infrastructure. That's not an appropriate use and this term refers to a very specific attack (e.g. see http://en.wikipedia.org/wiki/Man-in-the-middle_attack). I hope these comments are useful. Regards, Vincent From turners@ieca.com Tue Dec 14 07:49: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 D7CF93A6FA1 for ; Tue, 14 Dec 2010 07:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIp0vjIIh+MD for ; Tue, 14 Dec 2010 07:49:30 -0800 (PST) Received: from nm1-vm0.bullet.mail.sp2.yahoo.com (nm1-vm0.bullet.mail.sp2.yahoo.com [98.139.91.202]) by core3.amsl.com (Postfix) with SMTP id C98B93A6FAE for ; Tue, 14 Dec 2010 07:49:30 -0800 (PST) Received: from [98.139.91.64] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 14 Dec 2010 15:51:08 -0000 Received: from [98.139.91.12] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 14 Dec 2010 15:51:08 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 14 Dec 2010 15:51:08 -0000 X-Yahoo-Newman-Id: 817948.65972.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 34349 invoked from network); 14 Dec 2010 15:51:08 -0000 Received: from thunderfish.local (turners@96.231.115.248 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 14 Dec 2010 07:51:08 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: FL.KufYVM1mweYQT5DmeOL9h6nCaR8HMrofU4ZBpHuAPUPb SceDQ6l_COOS5NeSNuJS_kpTdG0Qt7XrgiGu_eunfIzWvg9ytc.NIqE.UYtu Z2Mb_o3RRtxXwNE6kEznPeDh7sjBaVG52KqgiQR_86SarKIu_qYhaEzfMfuJ pBbF88xtWuarRthKVPIK4Y6xkzt4EHng_ghSwG1eRmX9ptaS8fDufePih3MP q9uxyX6nmVYkhJyjYkV5PIvA_5sAUP5p4_3m03vpJ1yzQnKB_o8P247Z4HjF WPOzEnXn5LConf6H5ezCVLybGHXalk.dRdQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D07926A.9030007@ieca.com> Date: Tue, 14 Dec 2010 10:51:06 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Glen Zorn , draft-ietf-opsec-protect-control-plane@tools.ietf.org References: <001201cb9b59$acd02d70$06708850$@net> In-Reply-To: <001201cb9b59$acd02d70$06708850$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: opsec-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 15:49:32 -0000 I hoping that this was a typo. I pulled out all the registered RADIUS ports from http://www.iana.org/assignments/port-numbers and 1645/1646: sightline 1645/tcp SightLine sightline 1645/udp SightLine # admin sa-msg-port 1646/tcp sa-msg-port sa-msg-port 1646/udp sa-msg-port # Eric Whitehill radius 1812/tcp RADIUS radius 1812/udp RADIUS # [RFC2865] radius-acct 1813/tcp RADIUS Accounting radius-acct 1813/udp RADIUS Accounting # [RFC2866] radsec 2083/tcp Secure Radius Service radsec 2083/udp Secure Radius Service # Mike McCauley May 2005 radius-dynauth 3799/tcp RADIUS Dynamic Authorization radius-dynauth 3799/udp RADIUS Dynamic Authorization # RFC 3576 - July 2003 Should 1812 & 1813 be listed or also 2083 & 3799? spt On 12/14/10 1:39 AM, Glen Zorn 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. > > Section 3.1 says: > > o Permit RADIUS authentication and accounting replies from RADIUS > servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: > DB8:100::10 that are listening on UDP ports 1645 and 1646. Note > that this doesn't account for a server using Internet Assigned > Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. > > So, in other words, RADIUS traffic on the ports (officially assigned for > more than ten years now) will be blocked. This seems like a very poor > example. > > > > From hartmans@mit.edu Tue Dec 14 08:07:51 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 1F7D03A6FA7; Tue, 14 Dec 2010 08:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybyt97M-OmWz; Tue, 14 Dec 2010 08:07:50 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4A7243A6F9B; Tue, 14 Dec 2010 08:07:50 -0800 (PST) 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 4E9862013D; Tue, 14 Dec 2010 11:08:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C01224060; Tue, 14 Dec 2010 11:09:20 -0500 (EST) From: Sam Hartman To: draft-ietf-isis-trill-@tools.ietf.org,ietf@ietf.org,secdir@ietf.org Date: Tue, 14 Dec 2010 11:09:20 -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 Subject: [secdir] Secdir review of draft-ietf-isis-trill 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, 14 Dec 2010 16:07:51 -0000 Please treat these as normal last call comments. I found the introduction to draft-ietf-isis-trill inadequate. I'm familiar with the base concepts behind TRILL, roughly understand what was going on and followed the chartering discussions of the WG fairly closely. I have read the requirements document but have not read the protocol document. In an ideal world this document would be significantly easier to follow; I suspect that after reading the protocol document I'd still find this a bit choppy. However, I understand that sometimes you can only spend so much time on a spec and sometimes you reach the point where if someone isn't willing to jump in and volunteer a lot of hours to add clarity, good enough is good enough. This document claims that it adds no new security considerations to IS-IS. That's true. However, TRILL is a new protocol--completely new. It re-uses IS-IS as a building block, but if I were a security AD I'd still insist that TRILL meet our current standards for security, including a strong mandatory-to-implement security mechanism and (where appropriate) automated key management. I definitely think that this specification should at least document how IS-IS+TRILL fall short of standards we'd require for a new protocol today. The big area I can think of is replay handling for hello packets, which I suspect leads to a DOS. If we had more success with multicast key management we'd probably also require automated key management for a protocol like this. However,we don't, so I think that the RFC 4107 analysis would conclude that manual key management is acceptable under the multicast exception. I suspect the sec ADs will not actually require a solution even though it is a new protocol. I think that's a mistake, but I also don't have a lot of time to spend on TRILL, and I'd definitely rather see it get published than bogged down. I think documenting how IS-IS security interacts with TRILL security and IETF security BCPs should only take a relatively short time. From hartmans@mit.edu Tue Dec 14 08:17: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 E961C3A6EA4; Tue, 14 Dec 2010 08:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzzyLWmdjK47; Tue, 14 Dec 2010 08:17:22 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BD7C83A6DD2; Tue, 14 Dec 2010 08:17:22 -0800 (PST) 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 6E68220220; Tue, 14 Dec 2010 11:17:58 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CF6404060; Tue, 14 Dec 2010 11:18:52 -0500 (EST) From: Sam Hartman To: draft-ietf-isis-trill@tools.ietf.org,ietf@ietf.org,secdir@ietf.org Date: Tue, 14 Dec 2010 11:09:20 -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 Subject: [secdir] Secdir review of draft-ietf-isis-trill 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, 14 Dec 2010 16:17:23 -0000 Please treat these as normal last call comments. I found the introduction to draft-ietf-isis-trill inadequate. I'm familiar with the base concepts behind TRILL, roughly understand what was going on and followed the chartering discussions of the WG fairly closely. I have read the requirements document but have not read the protocol document. In an ideal world this document would be significantly easier to follow; I suspect that after reading the protocol document I'd still find this a bit choppy. However, I understand that sometimes you can only spend so much time on a spec and sometimes you reach the point where if someone isn't willing to jump in and volunteer a lot of hours to add clarity, good enough is good enough. This document claims that it adds no new security considerations to IS-IS. That's true. However, TRILL is a new protocol--completely new. It re-uses IS-IS as a building block, but if I were a security AD I'd still insist that TRILL meet our current standards for security, including a strong mandatory-to-implement security mechanism and (where appropriate) automated key management. I definitely think that this specification should at least document how IS-IS+TRILL fall short of standards we'd require for a new protocol today. The big area I can think of is replay handling for hello packets, which I suspect leads to a DOS. If we had more success with multicast key management we'd probably also require automated key management for a protocol like this. However,we don't, so I think that the RFC 4107 analysis would conclude that manual key management is acceptable under the multicast exception. I suspect the sec ADs will not actually require a solution even though it is a new protocol. I think that's a mistake, but I also don't have a lot of time to spend on TRILL, and I'd definitely rather see it get published than bogged down. I think documenting how IS-IS security interacts with TRILL security and IETF security BCPs should only take a relatively short time. From turners@ieca.com Tue Dec 14 08:18: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 A14383A6FB9 for ; Tue, 14 Dec 2010 08:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evfCxnqkZhsL for ; Tue, 14 Dec 2010 08:18:27 -0800 (PST) Received: from nm28-vm0.bullet.mail.sp2.yahoo.com (nm28-vm0.bullet.mail.sp2.yahoo.com [98.139.91.234]) by core3.amsl.com (Postfix) with SMTP id 98C4F3A6FB6 for ; Tue, 14 Dec 2010 08:18:27 -0800 (PST) Received: from [98.139.91.64] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 14 Dec 2010 16:20:05 -0000 Received: from [98.139.91.57] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 14 Dec 2010 16:20:05 -0000 Received: from [127.0.0.1] by omp1057.mail.sp2.yahoo.com with NNFMP; 14 Dec 2010 16:20:05 -0000 X-Yahoo-Newman-Id: 446793.82999.bm@omp1057.mail.sp2.yahoo.com Received: (qmail 77198 invoked from network); 14 Dec 2010 16:20:05 -0000 Received: from thunderfish.local (turners@96.231.115.248 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 14 Dec 2010 08:20:04 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: RbEeS48VM1lgstZYDpTFdmnyJH2oqztmbeK3HIFIrunED3o Jy_tNhMIc6xms5DY3t_MgIZdwKoExJ2WAfGcxF0s.ygsNP8rSrXjVrKgl_Sa XfXYDt2J48jEV_OzvwZ1cGYTObX6h4A16hPABBrUoyifyVO3vKd9YJYlmHFo gMt8kYmDalNVFSn6wZXYLAPu5n8.gFEdwom8YJm5_7TQfqCrqv9zlqy.TxWz fUvx9vdzGxShDn5BEewPy4Xj32.yAHKi1dDQ2g2l6YxANTKvs_HuPNeVM_0s j6XkpNfXROzIc3DwDyLiOdq_N096pwBjAgA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D079933.2080302@ieca.com> Date: Tue, 14 Dec 2010 11:20:03 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ronald Bonica References: <001201cb9b59$acd02d70$06708850$@net> <4D07926A.9030007@ieca.com> <13205C286662DE4387D9AF3AC30EF456B02F2A46AC@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B02F2A46AC@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" , "draft-ietf-opsec-protect-control-plane@tools.ietf.org" , "opsec-chairs@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:18:28 -0000 Note that the example filters in the Appendicies will also need to be fixed. spt On 12/14/10 11:04 AM, Ronald Bonica wrote: > Authors, > > I think that we can correct this problem with an RFC editors note before the telechat on Thursday. Could one of you please provide the updated text? > > Ron > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of >> Sean Turner >> Sent: Tuesday, December 14, 2010 10:51 AM >> To: Glen Zorn; draft-ietf-opsec-protect-control-plane@tools.ietf.org >> Cc: opsec-chairs@tools.ietf.org; iesg@ietf.org; secdir@ietf.org >> Subject: Re: secdir review of draft-ietf-opsec-protect-control-plane-04 >> >> I hoping that this was a typo. I pulled out all the registered RADIUS >> ports from http://www.iana.org/assignments/port-numbers and 1645/1646: >> >> sightline 1645/tcp SightLine >> sightline 1645/udp SightLine >> # admin >> sa-msg-port 1646/tcp sa-msg-port >> sa-msg-port 1646/udp sa-msg-port >> # Eric Whitehill >> >> >> radius 1812/tcp RADIUS >> radius 1812/udp RADIUS >> # [RFC2865] >> radius-acct 1813/tcp RADIUS Accounting >> radius-acct 1813/udp RADIUS Accounting >> # [RFC2866] >> radsec 2083/tcp Secure Radius Service >> radsec 2083/udp Secure Radius Service >> # Mike McCauley May 2005 >> radius-dynauth 3799/tcp RADIUS Dynamic Authorization >> radius-dynauth 3799/udp RADIUS Dynamic Authorization >> # RFC 3576 - July 2003 >> >> Should 1812& 1813 be listed or also 2083& 3799? >> >> spt >> >> On 12/14/10 1:39 AM, Glen Zorn 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. >>> >>> Section 3.1 says: >>> >>> o Permit RADIUS authentication and accounting replies from >> RADIUS >>> servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and >> 2001: >>> DB8:100::10 that are listening on UDP ports 1645 and 1646. >> Note >>> that this doesn't account for a server using Internet Assigned >>> Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. >>> >>> So, in other words, RADIUS traffic on the ports (officially assigned >> for >>> more than ten years now) will be blocked. This seems like a very >> poor >>> example. >>> >>> >>> >>> > From cpignata@cisco.com Tue Dec 14 08:48: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 8EEA63A6FB4; Tue, 14 Dec 2010 08:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.834 X-Spam-Level: X-Spam-Status: No, score=-107.834 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, 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 5E8D+Q7uqshc; Tue, 14 Dec 2010 08:48:03 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 914073A6EA9; Tue, 14 Dec 2010 08:48:03 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYIAMsuB02tJV2a/2dsb2JhbACjImoCeKZHm16DBYJFBIRkhheDHIRx X-IronPort-AV: E=Sophos;i="4.59,343,1288569600"; d="scan'208";a="192931424" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 14 Dec 2010 16:43:21 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oBEGhLq0021377; Tue, 14 Dec 2010 16:43:21 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 10:43:20 -0600 Received: from 128.107.191.87 ([128.107.191.87]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Dec 2010 16:43:20 +0000 References: <001201cb9b59$acd02d70$06708850$@net> Content-Transfer-Encoding: quoted-printable From: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: Thread-Topic: secdir review of draft-ietf-opsec-protect-control-plane-04 Thread-Index: AcubrgP3DUhH6C2aTHao33g2eHp+ew== Message-ID: <9B0EE2FE-9DCB-4F52-8515-F30050DF46F8@cisco.com> Date: Tue, 14 Dec 2010 11:43:09 -0500 To: "Joe Abley" MIME-Version: 1.0 (iPhone Mail 8C148) X-OriginalArrivalTime: 14 Dec 2010 16:43:20.0783 (UTC) FILETIME=[043BBDF0:01CB9BAE] Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, secdir@ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:48:04 -0000 Glen, Thanks much for your review.=20 Please see inline.=20 Thumb typed by Carlos Pignataro. On Dec 14, 2010, at 8:26 AM, "Joe Abley" wrote: >=20 > On 2010-12-14, at 01:39, Glen Zorn wrote: >=20 >> 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. These >> comments were written primarily for the benefit of the security area >> directors. Document editors and WG chairs should treat these comments ju= st >> like any other last call comments. >>=20 >> Section 3.1 says: >>=20 >> o Permit RADIUS authentication and accounting replies from RADIUS >> servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: >> DB8:100::10 that are listening on UDP ports 1645 and 1646. Note >> that this doesn't account for a server using Internet Assigned >> Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. >>=20 >> So, in other words, RADIUS traffic on the ports (officially assigned for >> more than ten years now) will be blocked. This seems like a very poor >> example. Please note that this was intentional, as a doc produced in Opsec we intende= d to make it as close to the operational reality we know as possible. And ou= r perspective was that we see more 1645/1646.=20 We can change it, sure. But just for the record this was discussed and inten= tionally decided. If our argument was "let's write what we see is in use", what's the operatio= nal argument for 1812/1813, or is that you think IANA's assigned is inuse mo= re ubiquitously? >=20 > This is a cisco-ism -- cisco devices use 1645/1646 by default and have to b= e configured explicitly to use 1812/1813. For the record it's not only cisco that defaults to the "tradition" ports. J= uniper listens on both, others also.=20 > I think this should be changed, as you intimate. Ok.=20 Thanks, Carlos.=20 > Good catch. >=20 >=20 > Joe >=20 From dharkins@lounge.org Tue Dec 14 10:16:01 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 BAA883A6FBA; Tue, 14 Dec 2010 10:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWcgmfaGuoqO; Tue, 14 Dec 2010 10:16:00 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id AE7B73A6EBA; Tue, 14 Dec 2010 10:16:00 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 762941022404C; Tue, 14 Dec 2010 10:17:41 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 14 Dec 2010 10:17:41 -0800 (PST) Message-ID: Date: Tue, 14 Dec 2010 10:17:41 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-isis-layer2.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] review of draft-ietf-isis-layer2 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, 14 Dec 2010 18:16:01 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines a couple of TLVs to add layer 2 information to IS-IS. That's really all it does, it's incredibly short and concise. Adding these TLVs to IS-IS do not affect its security and the Security Considerations mentions that. I see no problems with this draft and there's nothing for the Security ADs to take note of. regards, Dan. From aland@deployingradius.com Tue Dec 14 12:14: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 DB94D28C110; Tue, 14 Dec 2010 12:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4+WbxdKpW6O; Tue, 14 Dec 2010 12:14:37 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id E6AC528C104; Tue, 14 Dec 2010 12:14:36 -0800 (PST) Message-ID: <4D07D090.9020407@deployingradius.com> Date: Tue, 14 Dec 2010 21:16:16 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> In-Reply-To: <4D07A874.4010702@gridmerge.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) 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, 14 Dec 2010 20:14:38 -0000 Robert Cragie wrote: > * I agree with the notion of enforcing the relay to only process > valid PANA messages and only send valid PANA messages. The fact it > is a functionally-defined relay (as opposed to a generic IP > tunnel) means that we can do this. Therefore we need to add text > as you suggest. Thanks. > * I am less sure of the need for a token. As far as I can see, the > token would only protect the immutable information in the data > sent from PRE to PAA, i.e. the IP address and the port. This has > some benefit but would not necessarily prevent a rogue PAA sending > a bogus encapsulated frame. It would *authenticate* the data sent from the PAA to the PRE. This authentication would ensure that the PAA could only respond to packets sent by the PRE. As I said earlier, this would ensure that a rogue PAA can only (a) send PANA messages, to (b) the IP of the PaC, and (c) the port of the PaC used to send PANA messages. It would prevent a rogue PAA from sending a non-PANA frame to arbitrary non-PANA IPs and ports. > Using DTLS between PRE and PAA would > provide protection for the whole packet, possibly including > encryption. It's not per-packet protection. It's that the PRE will only accept frames from the PAA that have been authenticated via TLS. > Using a PANA SA would provide better protection than a > PRE-originated token. Using L2 security also provides a 'walled > garden' protection. It seems to me possible for a rogue node to > send any packet to any port on a node which is accessible at the > link layer provided one knows its address and assumes no L2 > security therefore I don't again see this as an additional threat The document clearly states that the PRE is proxying packets because the PAA can not otherwise route traffic to the PaC. Security between the PAA and PRE is *required* to prevent rogue PAAs from causing the PRE to route traffic to the PaC. One view could be that the PaC is already vulnerable to rogue PAAs on the local network. That local network may, however, be limited in the number of systems, and what they're allowed to do. My presumption is that the PRE to PAA network is a fully-connected network capable of routing to arbitrary destinations. So adding a PRE opens the PaC to attacks from arbitrary sources on a wide-area network, which would seem to be a violation of the PANA assumptions. Alan DeKok. From cpignata@cisco.com Tue Dec 14 12:49: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 912F628C115; Tue, 14 Dec 2010 12:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.253 X-Spam-Level: X-Spam-Status: No, score=-110.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1H-p-OYtHav; Tue, 14 Dec 2010 12:49:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F2FD128C0E1; Tue, 14 Dec 2010 12:49:35 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAApnB02tJXG+/2dsb2JhbACkE3imeptChUoEhGSJMw X-IronPort-AV: E=Sophos;i="4.59,344,1288569600"; d="scan'208";a="193052521" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-2.cisco.com with ESMTP; 14 Dec 2010 20:51:16 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id oBEKpG2E017429; Tue, 14 Dec 2010 20:51:16 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 14:51:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Dec 2010 14:51:13 -0600 Message-ID: <960EC8F9A775AB40BF58D8953342D86303756C03@XMB-RCD-206.cisco.com> In-Reply-To: <1958D397-8B8F-4046-A976-46AEC67EA214@hopcount.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-opsec-protect-control-plane-04 Thread-Index: Acubr6LhTxZn+Br0S22P5bVYQS7qmQAIAVjA References: <001201cb9b59$acd02d70$06708850$@net> <9B0EE2FE-9DCB-4F52-8515-F30050DF46F8@cisco.com> <1958D397-8B8F-4046-A976-46AEC67EA214@hopcount.ca> From: "Carlos Pignataro (cpignata)" To: "Joe Abley" X-OriginalArrivalTime: 14 Dec 2010 20:51:16.0017 (UTC) FILETIME=[A6905210:01CB9BD0] Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, secdir@ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 20:49:37 -0000 Joe, Not the most authoritative source, granted, but I believe at the time we discussed this we checked Wikipedia (and not C J as precedence), at , that says "The tradition of using 1645 and 1646 for backwards compatibility continues to this day", and with full context: "However, prior to IANA allocation of ports 1812 and 1813, ports 1645 and 1646 (authentication and accounting, respectively) were used unofficially and became the default ports assigned by many RADIUS Client/Server implementations of the time. The tradition of using 1645 and 1646 for backwards compatibility continues to this day. For this reason many RADIUS Server implementations monitor both sets of UDP ports for RADIUS requests." That said, I think that you can make a strong case for using the "proper" ones. We will make this change. Thanks, Joe and Glen. -- Carlos. -----Original Message----- From: Joe Abley [mailto:jabley@hopcount.ca]=20 Sent: Tuesday, December 14, 2010 11:55 AM To: Carlos Pignataro (cpignata) Cc: Glen Zorn; iesg@ietf.org; secdir@ietf.org; draft-ietf-opsec-protect-control-plane@tools.ietf.org; opsec-chairs@tools.ietf.org Subject: Re: secdir review of draft-ietf-opsec-protect-control-plane-04 On 2010-12-14, at 11:43, Carlos Pignataro (cpignata) wrote: > Please note that this was intentional, as a doc produced in Opsec we intended to make it as close to the operational reality we know as possible. And our perspective was that we see more 1645/1646.=20 I understand that's your perspective, which is entirely understandable given what cisco devices do by default, but I don't think it's necessarily the case that 1645/1646 are universally prevalent (at least, claims that it is ought to be balanced with some balanced, real-world observation). I take your point that juniper devices accommodate the pre-standard ports as well as the IANA-assigned ones. There are more vendors in the world than just C and J, however. I think pointing out that 1645/1646 are also used is perfectly valid, for the reasons of operational reality that you mention, but that the examples should use 1812/1813. Joe From clonvick@cisco.com Tue Dec 14 13:37:27 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AAE028C100; Tue, 14 Dec 2010 13:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JJjTpTsWN5w; Tue, 14 Dec 2010 13:37:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B5B3428C138; Tue, 14 Dec 2010 13:37:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADtzB02rR7H+/2dsb2JhbACkE3imWJs8hUoEhGQ X-IronPort-AV: E=Sophos;i="4.59,344,1288569600"; d="scan'208";a="232645282" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 14 Dec 2010 21:39:07 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oBELd7Ih028152; Tue, 14 Dec 2010 21:39:07 GMT Date: Tue, 14 Dec 2010 13:39:07 -0800 (PST) From: Chris Lonvick To: Barry Leiba In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-2110444415-1292362747=:28052" Cc: draft-ietf-morg-list-specialuse.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-morg-list-specialuse-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 21:37:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-2110444415-1292362747=:28052 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Barry, On Mon, 13 Dec 2010, Barry Leiba wrote: > Hi, Chris, and thanks for the review. > >> I am not altogether familiar with the placement of IMAP mailboxes to hav= e a >> solid grasp on the subject. =A0Please take my comments with a grain of s= alt. >> =A0:) > > Noted. > >> You mention at the end of Section 2 that users may configure shared >> mailboxes. =A0Does that imply that mailboxes are not normally shared, an= d >> would then mean that another user would not have any access to any of th= e >> mailboxes identified by IMAP unless they were specifically given a commo= n, >> shared mailbox? >> >> An example of my concern is that the \Junk mailbox may be configured to = be >> common to all the users. =A0In some cases, a legitimate piece of mail ma= y be >> incorrectly marked as spam by a filter and then placed into the Junk bin= =2E If >> that were to happen, anyone who had access to that mailbox would be able= to >> see the contents of that email. > > Personal IMAP mailboxes are normally private. Users may also have > access to public mailboxes (say, archives of mailing lists, or netnews > collections), to group mailboxes (our department's "to-do" folder), or > to personal mailboxes of others that have been explicitly shared. > These are usually presented in a separate namespace from the personal > mailboxes. > > Your concern is reflected in the second paragraph in the Security > Considerations: > > CREATE command "USE" parameter: In some server implementations, some > special uses may imply automatic action by the server. For example, > creation of a "\Junk" mailbox might cause the server to start placing > messages that have been evaluated as spam into the mailbox. > Implementors SHOULD consider the consequences of allowing a user (or > client program) to designate the target of such automatic action. I didn't see what I was talking about (more-r-less access control) in that= =20 paragraph. It looked more like a warning about automated processes as it= =20 doesn't seem to imply that the \Junk mailbox would be shared. > > I can make this more explicit, if you think that's important, by > adding another paragraph: > > Example: If a user is allowed to give the "\Junk" attribute to a > shared mailbox, > legitimate mail that's misclassified as junk (false positives) will > be put into that > shared mailbox, exposing the user's private mail to others. The server= might > warn a user of that possibility, or might refuse to allow the > specification to be > made on a shared mailbox. (Note that this problem exists independent o= f this > specification, if the server allows a user to share a mailbox > that's already in use > for such a function.) > > Does that help, do you think? Personally, I think being expicit about this helps. Your explanation=20 ebove helps me as well. I'd like to see it in there but if you, or others feel that people=20 familiar enough with IMAP to implement this don't need this extra warning,= =20 then I won't push it. Regards, Chris > > Barry > ---559023410-2110444415-1292362747=:28052-- From cpignata@cisco.com Tue Dec 14 13:51: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 C40F028C130; Tue, 14 Dec 2010 13:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.284 X-Spam-Level: X-Spam-Status: No, score=-110.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1GbToWsU6aO; Tue, 14 Dec 2010 13:51:50 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 10DF028C14A; Tue, 14 Dec 2010 13:51:48 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: draft-ietf-opsec-protect-control-plane-06-from-5.abdiff.txt : 30936 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEd2B02tJXHB/2dsb2JhbACkFnimRZs6gwWCRQSEZIkz X-IronPort-AV: E=Sophos;i="4.59,344,1288569600"; d="txt'?scan'208";a="193083044" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 14 Dec 2010 21:53:29 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id oBELrSvb009753; Tue, 14 Dec 2010 21:53:28 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 15:53:28 -0600 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_01CB9BD9.5729395C" Date: Tue, 14 Dec 2010 15:53:27 -0600 Message-ID: <960EC8F9A775AB40BF58D8953342D86303756C62@XMB-RCD-206.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B02F2A46AC@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-opsec-protect-control-plane-04 Thread-Index: Acubpr/14Cwlsd7NSeGL8pAU0+7LHwAAaimQAAv8C4A= References: <001201cb9b59$acd02d70$06708850$@net> <4D07926A.9030007@ieca.com> <13205C286662DE4387D9AF3AC30EF456B02F2A46AC@EMBX01-WF.jnpr.net> From: "Carlos Pignataro (cpignata)" To: "Ronald Bonica" , "Sean Turner" , "Glen Zorn" , X-OriginalArrivalTime: 14 Dec 2010 21:53:28.0633 (UTC) FILETIME=[57605290:01CB9BD9] Cc: opsec-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 21:51:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB9BD9.5729395C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ron, (Glen, Joe,) Please find attached ABDiffs (RFC-Ed style Diffs) for this change. Please note that because of the actual change in the example filter in the Appendices, the diffs are longer than should (treats big chunks of configs as single para). But my `rfcdiff` marks the line of change with a beginning "|" at least. If you'd rather, we can ship a new revision (it's cheap with the IDST). Thanks ! -- Carlos. -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net]=20 Sent: Tuesday, December 14, 2010 11:04 AM To: Sean Turner; Glen Zorn; draft-ietf-opsec-protect-control-plane@tools.ietf.org Cc: opsec-chairs@tools.ietf.org; iesg@ietf.org; secdir@ietf.org Subject: RE: secdir review of draft-ietf-opsec-protect-control-plane-04 Authors, I think that we can correct this problem with an RFC editors note before the telechat on Thursday. Could one of you please provide the updated text? Ron > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Tuesday, December 14, 2010 10:51 AM > To: Glen Zorn; draft-ietf-opsec-protect-control-plane@tools.ietf.org > Cc: opsec-chairs@tools.ietf.org; iesg@ietf.org; secdir@ietf.org > Subject: Re: secdir review of draft-ietf-opsec-protect-control-plane-04 >=20 > I hoping that this was a typo. I pulled out all the registered RADIUS > ports from http://www.iana.org/assignments/port-numbers and 1645/1646: >=20 > sightline 1645/tcp SightLine > sightline 1645/udp SightLine > # admin > sa-msg-port 1646/tcp sa-msg-port > sa-msg-port 1646/udp sa-msg-port > # Eric Whitehill >=20 >=20 > radius 1812/tcp RADIUS > radius 1812/udp RADIUS > # [RFC2865] > radius-acct 1813/tcp RADIUS Accounting > radius-acct 1813/udp RADIUS Accounting > # [RFC2866] > radsec 2083/tcp Secure Radius Service > radsec 2083/udp Secure Radius Service > # Mike McCauley May 2005 > radius-dynauth 3799/tcp RADIUS Dynamic Authorization > radius-dynauth 3799/udp RADIUS Dynamic Authorization > # RFC 3576 - July 2003 >=20 > Should 1812 & 1813 be listed or also 2083 & 3799? >=20 > spt >=20 > On 12/14/10 1:39 AM, Glen Zorn 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. > > > > Section 3.1 says: > > > > o Permit RADIUS authentication and accounting replies from > RADIUS > > servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and > 2001: > > DB8:100::10 that are listening on UDP ports 1645 and 1646. > Note > > that this doesn't account for a server using Internet Assigned > > Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. > > > > So, in other words, RADIUS traffic on the ports (officially assigned > for > > more than ten years now) will be blocked. This seems like a very > poor > > example. > > > > > > > > ------_=_NextPart_001_01CB9BD9.5729395C Content-Type: text/plain; name="draft-ietf-opsec-protect-control-plane-06-from-5.abdiff.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-opsec-protect-control-plane-06-from-5.abdiff.txt Content-Disposition: attachment; filename="draft-ietf-opsec-protect-control-plane-06-from-5.abdiff.txt" CgpTZWN0aW9uIDMuMS4sIHBhcmFncmFwaCAxMToKRVhQTEFOQVRJT046IAoKT0xEOgoKICAgIG8g IFBlcm1pdCBSQURJVVMgYXV0aGVudGljYXRpb24gYW5kIGFjY291bnRpbmcgcmVwbGllcyBmcm9t IFJBRElVUwogICAgICAgc2VydmVycyAxOTguNTEuMTAwLjksIDE5OC41MS4xMDAuMTAsIDIwMDE6 REI4OjEwMDo6OSwgYW5kIDIwMDE6CnwgICAgICBEQjg6MTAwOjoxMCB0aGF0IGFyZSBsaXN0ZW5p bmcgb24gVURQIHBvcnRzIDE2NDUgYW5kIDE2NDYuICBOb3RlCnwgICAgICB0aGF0IHRoaXMgZG9l c24ndCBhY2NvdW50IGZvciBhIHNlcnZlciB1c2luZyBJbnRlcm5ldCBBc3NpZ25lZAp8ICAgICAg TnVtYmVycyBBdXRob3JpdHkgKElBTkEpIHBvcnRzIDE4MTIgYW5kIDE4MTMgZm9yIFJBRElVUy4K Ck5FVzoKCiAgICBvICBQZXJtaXQgUkFESVVTIGF1dGhlbnRpY2F0aW9uIGFuZCBhY2NvdW50aW5n IHJlcGxpZXMgZnJvbSBSQURJVVMKICAgICAgIHNlcnZlcnMgMTk4LjUxLjEwMC45LCAxOTguNTEu MTAwLjEwLCAyMDAxOkRCODoxMDA6OjksIGFuZCAyMDAxOgp8ICAgICAgREI4OjEwMDo6MTAgdGhh dCBhcmUgbGlzdGVuaW5nIG9uIFVEUCBwb3J0cyAxODEyIGFuZCAxODEzCnwgICAgICAoSW50ZXJu ZXQgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKElBTkEpIFJBRElVUyBwb3J0cykuICBOb3Rl CnwgICAgICB0aGF0IHRoaXMgZG9lcyBub3QgYWNjb21tbW9kYXRlIGEgc2VydmVyIHVzaW5nIHBy ZS1zdGFuZGFyZCBVRFAKfCAgICAgIHBvcnRzIG9mIDE2NDUgYW5kIDE2NDYuCgoKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgoKQXBwZW5kaXggQS4sIHBhcmFncmFwaCA0OgpFWFBMQU5BVElPTjogCgpPTEQ6Cgog ICAgIVN0YXJ0OiBQcm90ZWN0aW5nIFRoZSBSb3V0ZXIgQ29udHJvbCBQbGFuZQogICAgIQogICAg IUNvbnRyb2wgUGxhbmUgUG9saWNpbmcgKENvUFApIENvbmZpZ3VyYXRpb24KICAgICEKICAgICFB Y2Nlc3MgQ29udHJvbCBMaXN0IERlZmluaXRpb25zCiAgICAhCiAgICBpcCBhY2Nlc3MtbGlzdCBl eHRlbmRlZCBJQ01QCiAgICAgcGVybWl0IGljbXAgYW55IGFueQogICAgaXB2NiBhY2Nlc3MtbGlz dCBJQ01QdjYKICAgICBwZXJtaXQgaWNtcCBhbnkgYW55CiAgICBpcCBhY2Nlc3MtbGlzdCBleHRl bmRlZCBPU1BGCiAgICAgcGVybWl0IG9zcGYgMTkyLjAuMi4wIDAuMC4wLjI1NSBhbnkKICAgIGlw djYgYWNjZXNzLWxpc3QgT1NQRnYzCiAgICAgcGVybWl0IDg5IEZFODA6Oi8xMCBhbnkKICAgIGlw IGFjY2Vzcy1saXN0IGV4dGVuZGVkIElCR1AKICAgICBwZXJtaXQgdGNwIDE5Mi4wLjIuMCAwLjAu MC4yNTUgZXEgYmdwIGFueQogICAgIHBlcm1pdCB0Y3AgMTkyLjAuMi4wIDAuMC4wLjI1NSBhbnkg ZXEgYmdwCiAgICBpcHY2IGFjY2Vzcy1saXN0IElCR1B2NgogICAgIHBlcm1pdCB0Y3AgMjAwMTpE Qjg6MTo6LzQ4IGVxIGJncCBhbnkKICAgICBwZXJtaXQgdGNwIDIwMDE6REI4OjE6Oi80OCBhbnkg ZXEgYmdwCiAgICBpcCBhY2Nlc3MtbGlzdCBleHRlbmRlZCBFQkdQCiAgICAgcGVybWl0IHRjcCBo b3N0IDE5OC41MS4xMDAuMjUgZXEgYmdwIGFueQogICAgIHBlcm1pdCB0Y3AgaG9zdCAxOTguNTEu MTAwLjI1IGFueSBlcSBiZ3AKICAgICBwZXJtaXQgdGNwIGhvc3QgMTk4LjUxLjEwMC4yNyBlcSBi Z3AgYW55CiAgICAgcGVybWl0IHRjcCBob3N0IDE5OC41MS4xMDAuMjcgYW55IGVxIGJncAogICAg IHBlcm1pdCB0Y3AgaG9zdCAxOTguNTEuMTAwLjI5IGVxIGJncCBhbnkKICAgICBwZXJtaXQgdGNw IGhvc3QgMTk4LjUxLjEwMC4yOSBhbnkgZXEgYmdwCiAgICAgcGVybWl0IHRjcCBob3N0IDE5OC41 MS4xMDAuMzEgZXEgYmdwIGFueQogICAgIHBlcm1pdCB0Y3AgaG9zdCAxOTguNTEuMTAwLjMxIGFu eSBlcSBiZ3AKICAgIGlwdjYgYWNjZXNzLWxpc3QgRUJHUHY2CiAgICAgcGVybWl0IHRjcCBob3N0 IDIwMDE6REI4OjEwMDo6MjUgZXEgYmdwIGFueQogICAgIHBlcm1pdCB0Y3AgaG9zdCAyMDAxOkRC ODoxMDA6OjI1IGFueSBlcSBiZ3AKICAgICBwZXJtaXQgdGNwIGhvc3QgMjAwMTpEQjg6MTAwOjoy NyBlcSBiZ3AgYW55CiAgICAgcGVybWl0IHRjcCBob3N0IDIwMDE6REI4OjEwMDo6MjcgYW55IGVx IGJncAogICAgIHBlcm1pdCB0Y3AgaG9zdCAyMDAxOkRCODoxMDA6OjI5IGVxIGJncCBhbnkKICAg ICBwZXJtaXQgdGNwIGhvc3QgMjAwMTpEQjg6MTAwOjoyOSBhbnkgZXEgYmdwCiAgICAgcGVybWl0 IHRjcCBob3N0IDIwMDE6REI4OjEwMDo6MzEgZXEgYmdwIGFueQogICAgIHBlcm1pdCB0Y3AgaG9z dCAyMDAxOkRCODoxMDA6OjMxIGFueSBlcSBiZ3AKICAgIGlwIGFjY2Vzcy1saXN0IGV4dGVuZGVk IEROUwogICAgIHBlcm1pdCB1ZHAgMTk4LjUxLjEwMC4wIDAuMC4wLjI1MiBlcSBkb21haW4gYW55 CiAgICBpcHY2IGFjY2Vzcy1saXN0IEROU3Y2CiAgICAgcGVybWl0IHVkcCAyMDAxOkRCODoxMDA6 MTo6LzY0IGVxIGRvbWFpbiBhbnkKICAgICBwZXJtaXQgdGNwIDIwMDE6REI4OjEwMDoxOjovNjQg ZXEgZG9tYWluIGFueQogICAgaXAgYWNjZXNzLWxpc3QgZXh0ZW5kZWQgTlRQCiAgICAgcGVybWl0 IHVkcCAxOTguNTEuMTAwLjQgMjU1LjI1NS4yNTUuMjUyIGFueSBlcSBudHAKICAgIGlwdjYgYWNj ZXNzLWxpc3QgTlRQdjYKICAgICBwZXJtaXQgdWRwIDIwMDE6REI4OjEwMDoyOjovNjQgYW55IGVx IG50cAogICAgaXAgYWNjZXNzLWxpc3QgZXh0ZW5kZWQgU1NICiAgICAgcGVybWl0IHRjcCAxOTgu NTEuMTAwLjEyOCAwLjAuMC4xMjggYW55IGVxIDIyCiAgICBpcHY2IGFjY2Vzcy1saXN0IFNTSHY2 CiAgICAgcGVybWl0IHRjcCAyMDAxOkRCODoxMDA6Mzo6LzY0IGFueSBlcSAyMgogICAgaXAgYWNj ZXNzLWxpc3QgZXh0ZW5kZWQgU05NUAogICAgIHBlcm1pdCB1ZHAgMTk4LjUxLjEwMC4xMjggMC4w LjAuMTI4IGFueSBlcSBzbm1wCiAgICBpcHY2IGFjY2Vzcy1saXN0IFNOTVB2NgogICAgIHBlcm1p dCB1ZHAgMjAwMTpEQjg6MTAwOjM6Oi82NCBhbnkgZXEgc25tcAogICAgaXAgYWNjZXNzLWxpc3Qg ZXh0ZW5kZWQgUkFESVVTCnwgICAgcGVybWl0IHVkcCBob3N0IDE5OC41MS4xMDAuOSBlcSAxNjQ1 IGFueQp8ICAgIHBlcm1pdCB1ZHAgaG9zdCAxOTguNTEuMTAwLjkgZXEgMTY0NiBhbnkKfCAgICBw ZXJtaXQgdWRwIGhvc3QgMTk4LjUxLjEwMC4xMCBlcSAxNjQ1IGFueQp8ICAgIHBlcm1pdCB1ZHAg aG9zdCAxOTguNTEuMTAwLjEwIGVxIDE2NDYgYW55CiAgICBpcHY2IGFjY2Vzcy1saXN0IFJBRElV U3Y2CnwgICAgcGVybWl0IHVkcCBob3N0IDIwMDE6REI4OjEwMDo6OSBlcSAxNjQ1IGFueQp8ICAg IHBlcm1pdCB1ZHAgaG9zdCAyMDAxOkRCODoxMDA6OjkgZXEgMTY0NiBhbnkKfCAgICBwZXJtaXQg dWRwIGhvc3QgMjAwMTpEQjg6MTAwOjoxMCBlcSAxNjQ1IGFueQp8ICAgIHBlcm1pdCB1ZHAgaG9z dCAyMDAxOkRCODoxMDA6OjEwIGVxIDE2NDYgYW55CiAgICBpcCBhY2Nlc3MtbGlzdCBleHRlbmRl ZCBGUkFHTUVOVFMKICAgICBwZXJtaXQgaXAgYW55IGFueSBmcmFnbWVudHMKICAgIGlwdjYgYWNj ZXNzLWxpc3QgRlJBR01FTlRTdjYKICAgICBwZXJtaXQgaXB2NiBhbnkgYW55IGZyYWdtZW50cwog ICAgaXAgYWNjZXNzLWxpc3QgZXh0ZW5kZWQgQUxMT1RIRVJJUAogICAgIHBlcm1pdCBpcCBhbnkg YW55CiAgICBpcHY2IGFjY2Vzcy1saXN0IEFMTE9USEVSSVB2NgogICAgIHBlcm1pdCBpcHY2IGFu eSBhbnkKICAgICEKICAgICFDbGFzcyBEZWZpbml0aW9ucwogICAgIQogICAgY2xhc3MtbWFwIG1h dGNoLWFueSBJQ01QCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgSUNNUAogICAgY2xhc3Mt bWFwIG1hdGNoLWFueSBJQ01QdjYKICAgICBtYXRjaCBhY2Nlc3MtZ3JvdXAgbmFtZSBJQ01QdjYK ICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkgT1NQRgogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1l IE9TUEYKICAgICBtYXRjaCBhY2Nlc3MtZ3JvdXAgbmFtZSBPU1BGdjMKICAgIGNsYXNzLW1hcCBt YXRjaC1hbnkgSUJHUAogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIElCR1AKICAgICBtYXRj aCBhY2Nlc3MtZ3JvdXAgbmFtZSBJQkdQdjYKICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkgRUJHUAog ICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIEVCR1AKICAgICBtYXRjaCBhY2Nlc3MtZ3JvdXAg bmFtZSBFQkdQdjYKICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkgRE5TCiAgICAgbWF0Y2ggYWNjZXNz LWdyb3VwIG5hbWUgRE5TCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgRE5TdjYKICAgIGNs YXNzLW1hcCBtYXRjaC1hbnkgTlRQCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgTlRQCiAg ICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgTlRQdjYKICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkg U1NICiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgU1NICiAgICAgbWF0Y2ggYWNjZXNzLWdy b3VwIG5hbWUgU1NIdjYKICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkgU05NUAogICAgIG1hdGNoIGFj Y2Vzcy1ncm91cCBuYW1lIFNOTVAKICAgICBtYXRjaCBhY2Nlc3MtZ3JvdXAgbmFtZSBTTk1QdjYK ICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkgUkFESVVTCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5h bWUgUkFESVVTCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgUkFESVVTdjYKICAgIGNsYXNz LW1hcCBtYXRjaC1hbnkgRlJBR01FTlRTCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgRlJB R01FTlRTCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgRlJBR01FTlRTdjYKICAgIGNsYXNz LW1hcCBtYXRjaC1hbnkgQUxMT1RIRVJJUAogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIEFM TE9USEVSSVAKICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkgQUxMT1RIRVJJUHY2CiAgICAgbWF0Y2gg YWNjZXNzLWdyb3VwIG5hbWUgQUxMT1RIRVJJUHY2CiAgICAhCiAgICAhUG9saWN5IERlZmluaXRp b24KICAgICEKICAgIHBvbGljeS1tYXAgQ09QUAogICAgIGNsYXNzIEZSQUdNRU5UUwogICAgICBk cm9wCiAgICAgY2xhc3MgSUNNUAogICAgICBwb2xpY2UgNTAwMDAwCiAgICAgICAgIGNvbmZvcm0t YWN0aW9uIHRyYW5zbWl0CiAgICAgICAgIGV4Y2VlZC1hY3Rpb24gZHJvcAogICAgICAgICB2aW9s YXRlLWFjdGlvbiBkcm9wCiAgICAgY2xhc3MgSUNNUHY2CiAgICAgIHBvbGljZSA1MDAwMDAKICAg ICAgICAgY29uZm9ybS1hY3Rpb24gdHJhbnNtaXQKICAgICAgICAgZXhjZWVkLWFjdGlvbiBkcm9w CiAgICAgICAgIHZpb2xhdGUtYWN0aW9uIGRyb3AKICAgICBjbGFzcyBPU1BGCiAgICAgY2xhc3Mg SUJHUAogICAgIGNsYXNzIEVCR1AKICAgICBjbGFzcyBETlMKICAgICBjbGFzcyBOVFAKICAgICBj bGFzcyBTU0gKICAgICBjbGFzcyBTTk1QCiAgICAgY2xhc3MgUkFESVVTCiAgICAgY2xhc3MgQUxM T1RIRVJJUAogICAgICAgcG9saWNlIGNpciA1MDAwMDAKICAgICAgICAgY29uZm9ybS1hY3Rpb24g dHJhbnNtaXQKICAgICAgICAgZXhjZWVkLWFjdGlvbiBkcm9wCiAgICAgICAgIHZpb2xhdGUtYWN0 aW9uIGRyb3AKICAgICBjbGFzcyBBTExPVEhFUklQdjYKICAgICAgIHBvbGljZSBjaXIgNTAwMDAw CiAgICAgICAgIGNvbmZvcm0tYWN0aW9uIHRyYW5zbWl0CiAgICAgICAgIGV4Y2VlZC1hY3Rpb24g ZHJvcAogICAgICAgICB2aW9sYXRlLWFjdGlvbiBkcm9wCiAgICAgY2xhc3MgY2xhc3MtZGVmYXVs dAogICAgICAgcG9saWNlIGNpciAyNTAwMDAKICAgICAgICAgY29uZm9ybS1hY3Rpb24gdHJhbnNt aXQKICAgICAgICAgZXhjZWVkLWFjdGlvbiBkcm9wCiAgICAgICAgIHZpb2xhdGUtYWN0aW9uIGRy b3AKICAgICEKICAgICFDb250cm9sIFBsYW5lIENvbmZpZ3VyYXRpb24KICAgICEKICAgIGNvbnRy b2wtcGxhbmUKICAgICBzZXJ2aWNlLXBvbGljeSBpbnB1dCBDT1BQCiAgICAhCiAgICAhRW5kOiBQ cm90ZWN0aW5nIFRoZSBSb3V0ZXIgQ29udHJvbCBQbGFuZQoKTkVXOgoKICAgICFTdGFydDogUHJv dGVjdGluZyBUaGUgUm91dGVyIENvbnRyb2wgUGxhbmUKICAgICEKICAgICFDb250cm9sIFBsYW5l IFBvbGljaW5nIChDb1BQKSBDb25maWd1cmF0aW9uCiAgICAhCiAgICAhQWNjZXNzIENvbnRyb2wg TGlzdCBEZWZpbml0aW9ucwogICAgIQogICAgaXAgYWNjZXNzLWxpc3QgZXh0ZW5kZWQgSUNNUAog ICAgIHBlcm1pdCBpY21wIGFueSBhbnkKICAgIGlwdjYgYWNjZXNzLWxpc3QgSUNNUHY2CiAgICAg cGVybWl0IGljbXAgYW55IGFueQogICAgaXAgYWNjZXNzLWxpc3QgZXh0ZW5kZWQgT1NQRgogICAg IHBlcm1pdCBvc3BmIDE5Mi4wLjIuMCAwLjAuMC4yNTUgYW55CiAgICBpcHY2IGFjY2Vzcy1saXN0 IE9TUEZ2MwogICAgIHBlcm1pdCA4OSBGRTgwOjovMTAgYW55CiAgICBpcCBhY2Nlc3MtbGlzdCBl eHRlbmRlZCBJQkdQCiAgICAgcGVybWl0IHRjcCAxOTIuMC4yLjAgMC4wLjAuMjU1IGVxIGJncCBh bnkKICAgICBwZXJtaXQgdGNwIDE5Mi4wLjIuMCAwLjAuMC4yNTUgYW55IGVxIGJncAogICAgaXB2 NiBhY2Nlc3MtbGlzdCBJQkdQdjYKICAgICBwZXJtaXQgdGNwIDIwMDE6REI4OjE6Oi80OCBlcSBi Z3AgYW55CiAgICAgcGVybWl0IHRjcCAyMDAxOkRCODoxOjovNDggYW55IGVxIGJncAogICAgaXAg YWNjZXNzLWxpc3QgZXh0ZW5kZWQgRUJHUAogICAgIHBlcm1pdCB0Y3AgaG9zdCAxOTguNTEuMTAw LjI1IGVxIGJncCBhbnkKICAgICBwZXJtaXQgdGNwIGhvc3QgMTk4LjUxLjEwMC4yNSBhbnkgZXEg YmdwCiAgICAgcGVybWl0IHRjcCBob3N0IDE5OC41MS4xMDAuMjcgZXEgYmdwIGFueQogICAgIHBl cm1pdCB0Y3AgaG9zdCAxOTguNTEuMTAwLjI3IGFueSBlcSBiZ3AKICAgICBwZXJtaXQgdGNwIGhv c3QgMTk4LjUxLjEwMC4yOSBlcSBiZ3AgYW55CiAgICAgcGVybWl0IHRjcCBob3N0IDE5OC41MS4x MDAuMjkgYW55IGVxIGJncAogICAgIHBlcm1pdCB0Y3AgaG9zdCAxOTguNTEuMTAwLjMxIGVxIGJn cCBhbnkKICAgICBwZXJtaXQgdGNwIGhvc3QgMTk4LjUxLjEwMC4zMSBhbnkgZXEgYmdwCiAgICBp cHY2IGFjY2Vzcy1saXN0IEVCR1B2NgogICAgIHBlcm1pdCB0Y3AgaG9zdCAyMDAxOkRCODoxMDA6 OjI1IGVxIGJncCBhbnkKICAgICBwZXJtaXQgdGNwIGhvc3QgMjAwMTpEQjg6MTAwOjoyNSBhbnkg ZXEgYmdwCiAgICAgcGVybWl0IHRjcCBob3N0IDIwMDE6REI4OjEwMDo6MjcgZXEgYmdwIGFueQog ICAgIHBlcm1pdCB0Y3AgaG9zdCAyMDAxOkRCODoxMDA6OjI3IGFueSBlcSBiZ3AKICAgICBwZXJt aXQgdGNwIGhvc3QgMjAwMTpEQjg6MTAwOjoyOSBlcSBiZ3AgYW55CiAgICAgcGVybWl0IHRjcCBo b3N0IDIwMDE6REI4OjEwMDo6MjkgYW55IGVxIGJncAogICAgIHBlcm1pdCB0Y3AgaG9zdCAyMDAx OkRCODoxMDA6OjMxIGVxIGJncCBhbnkKICAgICBwZXJtaXQgdGNwIGhvc3QgMjAwMTpEQjg6MTAw OjozMSBhbnkgZXEgYmdwCiAgICBpcCBhY2Nlc3MtbGlzdCBleHRlbmRlZCBETlMKICAgICBwZXJt aXQgdWRwIDE5OC41MS4xMDAuMCAwLjAuMC4yNTIgZXEgZG9tYWluIGFueQogICAgaXB2NiBhY2Nl c3MtbGlzdCBETlN2NgogICAgIHBlcm1pdCB1ZHAgMjAwMTpEQjg6MTAwOjE6Oi82NCBlcSBkb21h aW4gYW55CiAgICAgcGVybWl0IHRjcCAyMDAxOkRCODoxMDA6MTo6LzY0IGVxIGRvbWFpbiBhbnkK ICAgIGlwIGFjY2Vzcy1saXN0IGV4dGVuZGVkIE5UUAogICAgIHBlcm1pdCB1ZHAgMTk4LjUxLjEw MC40IDI1NS4yNTUuMjU1LjI1MiBhbnkgZXEgbnRwCiAgICBpcHY2IGFjY2Vzcy1saXN0IE5UUHY2 CiAgICAgcGVybWl0IHVkcCAyMDAxOkRCODoxMDA6Mjo6LzY0IGFueSBlcSBudHAKICAgIGlwIGFj Y2Vzcy1saXN0IGV4dGVuZGVkIFNTSAogICAgIHBlcm1pdCB0Y3AgMTk4LjUxLjEwMC4xMjggMC4w LjAuMTI4IGFueSBlcSAyMgogICAgaXB2NiBhY2Nlc3MtbGlzdCBTU0h2NgogICAgIHBlcm1pdCB0 Y3AgMjAwMTpEQjg6MTAwOjM6Oi82NCBhbnkgZXEgMjIKICAgIGlwIGFjY2Vzcy1saXN0IGV4dGVu ZGVkIFNOTVAKICAgICBwZXJtaXQgdWRwIDE5OC41MS4xMDAuMTI4IDAuMC4wLjEyOCBhbnkgZXEg c25tcAogICAgaXB2NiBhY2Nlc3MtbGlzdCBTTk1QdjYKICAgICBwZXJtaXQgdWRwIDIwMDE6REI4 OjEwMDozOjovNjQgYW55IGVxIHNubXAKICAgIGlwIGFjY2Vzcy1saXN0IGV4dGVuZGVkIFJBRElV Uwp8ICAgIHBlcm1pdCB1ZHAgaG9zdCAxOTguNTEuMTAwLjkgZXEgMTgxMiBhbnkKfCAgICBwZXJt aXQgdWRwIGhvc3QgMTk4LjUxLjEwMC45IGVxIDE4MTMgYW55CnwgICAgcGVybWl0IHVkcCBob3N0 IDE5OC41MS4xMDAuMTAgZXEgMTgxMiBhbnkKfCAgICBwZXJtaXQgdWRwIGhvc3QgMTk4LjUxLjEw MC4xMCBlcSAxODEzIGFueQogICAgaXB2NiBhY2Nlc3MtbGlzdCBSQURJVVN2Ngp8ICAgIHBlcm1p dCB1ZHAgaG9zdCAyMDAxOkRCODoxMDA6OjkgZXEgMTgxMiBhbnkKfCAgICBwZXJtaXQgdWRwIGhv c3QgMjAwMTpEQjg6MTAwOjo5IGVxIDE4MTMgYW55CnwgICAgcGVybWl0IHVkcCBob3N0IDIwMDE6 REI4OjEwMDo6MTAgZXEgMTgxMiBhbnkKfCAgICBwZXJtaXQgdWRwIGhvc3QgMjAwMTpEQjg6MTAw OjoxMCBlcSAxODEzIGFueQogICAgaXAgYWNjZXNzLWxpc3QgZXh0ZW5kZWQgRlJBR01FTlRTCiAg ICAgcGVybWl0IGlwIGFueSBhbnkgZnJhZ21lbnRzCiAgICBpcHY2IGFjY2Vzcy1saXN0IEZSQUdN RU5UU3Y2CiAgICAgcGVybWl0IGlwdjYgYW55IGFueSBmcmFnbWVudHMKICAgIGlwIGFjY2Vzcy1s aXN0IGV4dGVuZGVkIEFMTE9USEVSSVAKICAgICBwZXJtaXQgaXAgYW55IGFueQogICAgaXB2NiBh Y2Nlc3MtbGlzdCBBTExPVEhFUklQdjYKICAgICBwZXJtaXQgaXB2NiBhbnkgYW55CiAgICAhCiAg ICAhQ2xhc3MgRGVmaW5pdGlvbnMKICAgICEKICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkgSUNNUAog ICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIElDTVAKICAgIGNsYXNzLW1hcCBtYXRjaC1hbnkg SUNNUHY2CiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgSUNNUHY2CiAgICBjbGFzcy1tYXAg bWF0Y2gtYW55IE9TUEYKICAgICBtYXRjaCBhY2Nlc3MtZ3JvdXAgbmFtZSBPU1BGCiAgICAgbWF0 Y2ggYWNjZXNzLWdyb3VwIG5hbWUgT1NQRnYzCiAgICBjbGFzcy1tYXAgbWF0Y2gtYW55IElCR1AK ICAgICBtYXRjaCBhY2Nlc3MtZ3JvdXAgbmFtZSBJQkdQCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3Vw IG5hbWUgSUJHUHY2CiAgICBjbGFzcy1tYXAgbWF0Y2gtYW55IEVCR1AKICAgICBtYXRjaCBhY2Nl c3MtZ3JvdXAgbmFtZSBFQkdQCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgRUJHUHY2CiAg ICBjbGFzcy1tYXAgbWF0Y2gtYW55IEROUwogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIERO UwogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIEROU3Y2CiAgICBjbGFzcy1tYXAgbWF0Y2gt YW55IE5UUAogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIE5UUAogICAgIG1hdGNoIGFjY2Vz cy1ncm91cCBuYW1lIE5UUHY2CiAgICBjbGFzcy1tYXAgbWF0Y2gtYW55IFNTSAogICAgIG1hdGNo IGFjY2Vzcy1ncm91cCBuYW1lIFNTSAogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIFNTSHY2 CiAgICBjbGFzcy1tYXAgbWF0Y2gtYW55IFNOTVAKICAgICBtYXRjaCBhY2Nlc3MtZ3JvdXAgbmFt ZSBTTk1QCiAgICAgbWF0Y2ggYWNjZXNzLWdyb3VwIG5hbWUgU05NUHY2CiAgICBjbGFzcy1tYXAg bWF0Y2gtYW55IFJBRElVUwogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIFJBRElVUwogICAg IG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIFJBRElVU3Y2CiAgICBjbGFzcy1tYXAgbWF0Y2gtYW55 IEZSQUdNRU5UUwogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBuYW1lIEZSQUdNRU5UUwogICAgIG1h dGNoIGFjY2Vzcy1ncm91cCBuYW1lIEZSQUdNRU5UU3Y2CiAgICBjbGFzcy1tYXAgbWF0Y2gtYW55 IEFMTE9USEVSSVAKICAgICBtYXRjaCBhY2Nlc3MtZ3JvdXAgbmFtZSBBTExPVEhFUklQCiAgICBj bGFzcy1tYXAgbWF0Y2gtYW55IEFMTE9USEVSSVB2NgogICAgIG1hdGNoIGFjY2Vzcy1ncm91cCBu YW1lIEFMTE9USEVSSVB2NgogICAgIQogICAgIVBvbGljeSBEZWZpbml0aW9uCiAgICAhCiAgICBw b2xpY3ktbWFwIENPUFAKICAgICBjbGFzcyBGUkFHTUVOVFMKICAgICAgZHJvcAogICAgIGNsYXNz IElDTVAKICAgICAgcG9saWNlIDUwMDAwMAogICAgICAgICBjb25mb3JtLWFjdGlvbiB0cmFuc21p dAogICAgICAgICBleGNlZWQtYWN0aW9uIGRyb3AKICAgICAgICAgdmlvbGF0ZS1hY3Rpb24gZHJv cAogICAgIGNsYXNzIElDTVB2NgogICAgICBwb2xpY2UgNTAwMDAwCiAgICAgICAgIGNvbmZvcm0t YWN0aW9uIHRyYW5zbWl0CiAgICAgICAgIGV4Y2VlZC1hY3Rpb24gZHJvcAogICAgICAgICB2aW9s YXRlLWFjdGlvbiBkcm9wCiAgICAgY2xhc3MgT1NQRgogICAgIGNsYXNzIElCR1AKICAgICBjbGFz cyBFQkdQCiAgICAgY2xhc3MgRE5TCiAgICAgY2xhc3MgTlRQCiAgICAgY2xhc3MgU1NICiAgICAg Y2xhc3MgU05NUAogICAgIGNsYXNzIFJBRElVUwogICAgIGNsYXNzIEFMTE9USEVSSVAKICAgICAg IHBvbGljZSBjaXIgNTAwMDAwCiAgICAgICAgIGNvbmZvcm0tYWN0aW9uIHRyYW5zbWl0CiAgICAg ICAgIGV4Y2VlZC1hY3Rpb24gZHJvcAogICAgICAgICB2aW9sYXRlLWFjdGlvbiBkcm9wCiAgICAg Y2xhc3MgQUxMT1RIRVJJUHY2CiAgICAgICBwb2xpY2UgY2lyIDUwMDAwMAogICAgICAgICBjb25m b3JtLWFjdGlvbiB0cmFuc21pdAogICAgICAgICBleGNlZWQtYWN0aW9uIGRyb3AKICAgICAgICAg dmlvbGF0ZS1hY3Rpb24gZHJvcAogICAgIGNsYXNzIGNsYXNzLWRlZmF1bHQKICAgICAgIHBvbGlj ZSBjaXIgMjUwMDAwCiAgICAgICAgIGNvbmZvcm0tYWN0aW9uIHRyYW5zbWl0CiAgICAgICAgIGV4 Y2VlZC1hY3Rpb24gZHJvcAogICAgICAgICB2aW9sYXRlLWFjdGlvbiBkcm9wCiAgICAhCiAgICAh Q29udHJvbCBQbGFuZSBDb25maWd1cmF0aW9uCiAgICAhCiAgICBjb250cm9sLXBsYW5lCiAgICAg c2VydmljZS1wb2xpY3kgaW5wdXQgQ09QUAogICAgIQogICAgIUVuZDogUHJvdGVjdGluZyBUaGUg Um91dGVyIENvbnRyb2wgUGxhbmUKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCgpBcHBlbmRpeCBBLiwgcGFy YWdyYXBoIDc6CkVYUExBTkFUSU9OOiAKCk9MRDoKCiAgICBwb2xpY3ktb3B0aW9ucyB7CiAgICAg ICAgcHJlZml4LWxpc3QgSUJHUC1ORUlHSEJPUlMgewogICAgICAgICAgICAxOTIuMC4yLjAvMjQ7 CiAgICAgICAgfQogICAgICAgIHByZWZpeC1saXN0IEVCR1AtTkVJR0hCT1JTIHsKICAgICAgICAg ICAgMTk4LjUxLjEwMC4yNS8zMjsKICAgICAgICAgICAgMTk4LjUxLjEwMC4yNy8zMjsKICAgICAg ICAgICAgMTk4LjUxLjEwMC4yOS8zMjsKICAgICAgICAgICAgMTk4LjUxLjEwMC4zMS8zMjsKICAg ICAgICB9CiAgICAgICAgcHJlZml4LWxpc3QgUkFESVVTLVNFUlZFUlMgewogICAgICAgICAgICAx OTguNTEuMTAwLjkvMzI7CiAgICAgICAgICAgIDE5OC41MS4xMDAuMTAvMzI7CiAgICAgICAgfQog ICAgICAgIHByZWZpeC1saXN0IElCR1B2Ni1ORUlHSEJPUlMgewogICAgICAgICAgICAyMDAxOkRC ODoxOjovNDg7CiAgICAgICAgfQogICAgICAgIHByZWZpeC1saXN0IEVCR1B2Ni1ORUlHSEJPUlMg ewogICAgICAgICAgICAyMDAxOkRCODoxMDA6OjI1LzEyODsKICAgICAgICAgICAgMjAwMTpEQjg6 MTAwOjoyNy8xMjg7CiAgICAgICAgICAgIDIwMDE6REI4OjEwMDo6MjkvMTI4OwogICAgICAgICAg ICAyMDAxOkRCODoxMDA6OjMxLzEyODsKICAgICAgICB9CiAgICAgICAgcHJlZml4LWxpc3QgUkFE SVVTdjYtU0VSVkVSUyB7CiAgICAgICAgICAgIDIwMDE6REI4OjEwMDo6OS8xMjg7CiAgICAgICAg ICAgIDIwMDE6REI4OjEwMDo6MTAvMTI4OwogICAgICAgIH0KICAgIH0KICAgIGZpcmV3YWxsIHsK ICAgICAgICBwb2xpY2VyIDUwMGticHMgewogICAgICAgICAgICBpZi1leGNlZWRpbmcgewogICAg ICAgICAgICAgICAgYmFuZHdpZHRoLWxpbWl0IDUwMGs7CiAgICAgICAgICAgICAgICBidXJzdC1z aXplLWxpbWl0IDE1MDA7CiAgICAgICAgICAgIH0KICAgICAgICAgICAgdGhlbiBkaXNjYXJkOwog ICAgICAgIH0KICAgICAgICBwb2xpY2VyIDI1MGticHMgewogICAgICAgICAgICBpZi1leGNlZWRp bmcgewogICAgICAgICAgICAgICAgYmFuZHdpZHRoLWxpbWl0IDI1MGs7CiAgICAgICAgICAgICAg ICBidXJzdC1zaXplLWxpbWl0IDE1MDA7CiAgICAgICAgICAgIH0KICAgICAgICAgICAgdGhlbiBk aXNjYXJkOwogICAgICAgIH0KICAgICAgICBmYW1pbHkgaW5ldCB7CiAgICAgICAgICAgIGZpbHRl ciBwcm90ZWN0LXJvdXRlci1jb250cm9sLXBsYW5lIHsKICAgICAgICAgICAgICAgIHRlcm0gZmly c3QtZnJhZyB7CiAgICAgICAgICAgICAgICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAg ICAgIGZpcnN0LWZyYWdtZW50OwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAg ICAgICB0aGVuIHsKICAgICAgICAgICAgICAgICAgICAgICAgY291bnQgZnJhZy1kaXNjYXJkczsK ICAgICAgICAgICAgICAgICAgICAgICAgbG9nOwogICAgICAgICAgICAgICAgICAgICAgICBkaXNj YXJkOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg ICAgIHRlcm0gbmV4dC1mcmFnIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAg ICAgICAgICAgICAgICAgaXMtZnJhZ21lbnQ7CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAg ICAgICAgICAgICAgIHRoZW4gewogICAgICAgICAgICAgICAgICAgICAgICBjb3VudCBmcmFnLWRp c2NhcmRzOwogICAgICAgICAgICAgICAgICAgICAgICBsb2c7CiAgICAgICAgICAgICAgICAgICAg ICAgIGRpc2NhcmQ7CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgdGVybSBpY21wIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAg ICAgICAgICAgICAgICAgICAgcHJvdG9jb2wgaWNtcDsKICAgICAgICAgICAgICAgICAgICB9CiAg ICAgICAgICAgICAgICAgICAgdGhlbiB7CiAgICAgICAgICAgICAgICAgICAgICAgIHBvbGljZXIg NTAwa2JwczsKICAgICAgICAgICAgICAgICAgICAgICAgYWNjZXB0OwogICAgICAgICAgICAgICAg ICAgIH0KICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0gb3NwZiB7CiAgICAg ICAgICAgICAgICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1hZGRy ZXNzIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE5Mi4wLjIuMC8yNDsKICAgICAgICAg ICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICBwcm90b2NvbCBvc3BmOwog ICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAg ICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0gaWJncC1jb25uZWN0IHsKICAgICAg ICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAgICAgICAgICAgc291cmNlLXByZWZp eC1saXN0IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIElCR1AtTkVJR0hCT1JTOwogICAg ICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29sIHRj cDsKICAgICAgICAgICAgICAgICAgICAgICAgZGVzdGluYXRpb24tcG9ydCBiZ3A7CiAgICAgICAg ICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAgICAgICAg ICAgICAgfQogICAgICAgICAgICAgICAgdGVybSBpYmdwLXJlcGx5IHsKICAgICAgICAgICAgICAg ICAgICBmcm9tIHsKICAgICAgICAgICAgICAgICAgICAgICAgc291cmNlLXByZWZpeC1saXN0IHsK ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElCR1AtTkVJR0hCT1JTOwogICAgICAgICAgICAg ICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29sIHRjcDsKICAgICAg ICAgICAgICAgICAgICAgICAgcG9ydCBiZ3A7CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAg ICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAgICAgICAgICAgICAgfQogICAgICAgICAgICAg ICAgdGVybSBlYmdwLWNvbm5lY3QgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAgICAg ICAgICAgICAgICAgICAgICBzb3VyY2UtcHJlZml4LWxpc3QgewogICAgICAgICAgICAgICAgICAg ICAgICAgICAgRUJHUC1ORUlHSEJPUlM7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAg ICAgICAgICAgICAgICAgICAgcHJvdG9jb2wgdGNwOwogICAgICAgICAgICAgICAgICAgICAgICBk ZXN0aW5hdGlvbi1wb3J0IGJncDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAg ICAgICAgdGhlbiBhY2NlcHQ7CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJt IGViZ3AtcmVwbHkgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAgICAgICAgICAgICAg ICAgICAgICBzb3VyY2UtcHJlZml4LWxpc3QgewogICAgICAgICAgICAgICAgICAgICAgICAgICAg RUJHUC1ORUlHSEJPUlM7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAg ICAgICAgICAgcHJvdG9jb2wgdGNwOwogICAgICAgICAgICAgICAgICAgICAgICBwb3J0IGJncDsK ICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgdGhlbiBhY2NlcHQ7CiAg ICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIGRucyB7CiAgICAgICAgICAgICAg ICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1hZGRyZXNzIHsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDE5OC41MS4xMDAuMC8zMDsKICAgICAgICAgICAgICAg ICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICBwcm90b2NvbCB1ZHA7CiAgICAgICAg ICAgICAgICAgICAgICAgIHBvcnQgZG9tYWluOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAg ICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg ICAgIHRlcm0gbnRwIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAg ICAgICAgICAgc291cmNlLWFkZHJlc3MgewogICAgICAgICAgICAgICAgICAgICAgICAgICAgMTk4 LjUxLjEwMC40LzMwOwogICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAg ICAgICAgIHByb3RvY29sIHVkcDsKICAgICAgICAgICAgICAgICAgICAgICAgZGVzdGluYXRpb24t cG9ydCBudHA7CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRoZW4g YWNjZXB0OwogICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgdGVybSBzc2ggewogICAg ICAgICAgICAgICAgICAgIGZyb20gewogICAgICAgICAgICAgICAgICAgICAgICBzb3VyY2UtYWRk cmVzcyB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAxOTguNTEuMTAwLjEyOC8yNTsKICAg ICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICBwcm90b2NvbCB0 Y3A7CiAgICAgICAgICAgICAgICAgICAgICAgIGRlc3RpbmF0aW9uLXBvcnQgc3NoOwogICAgICAg ICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAg ICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0gc25tcCB7CiAgICAgICAgICAgICAgICAgICAg ZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1hZGRyZXNzIHsKICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDE5OC41MS4xMDAuMTI4LzI1OwogICAgICAgICAgICAgICAgICAg ICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29sIHVkcDsKICAgICAgICAgICAg ICAgICAgICAgICAgZGVzdGluYXRpb24tcG9ydCBzbm1wOwogICAgICAgICAgICAgICAgICAgIH0K ICAgICAgICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAg ICAgICAgICAgIHRlcm0gcmFkaXVzIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAg ICAgICAgICAgICAgICAgICAgc291cmNlLXByZWZpeC1saXN0IHsKICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJBRElVUy1TRVJWRVJTOwogICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAg ICAgICAgICAgICAgICAgICAgIHByb3RvY29sIHVkcDsKfCAgICAgICAgICAgICAgICAgICAgICAg cG9ydCBbIDE2NDUgMTY0NiBdOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAg ICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0g ZGVmYXVsdC10ZXJtIHsKICAgICAgICAgICAgICAgICAgICB0aGVuIHsKICAgICAgICAgICAgICAg ICAgICAgICAgY291bnQgY29wcC1leGNlcHRpb25zOwogICAgICAgICAgICAgICAgICAgICAgICBs b2c7CiAgICAgICAgICAgICAgICAgICAgICAgIHBvbGljZXIgNTAwa2JwczsKICAgICAgICAgICAg ICAgICAgICAgICAgYWNjZXB0OwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAg IH0KICAgICAgICAgICAgfQogICAgICAgIH0KCk5FVzoKCiAgICBwb2xpY3ktb3B0aW9ucyB7CiAg ICAgICAgcHJlZml4LWxpc3QgSUJHUC1ORUlHSEJPUlMgewogICAgICAgICAgICAxOTIuMC4yLjAv MjQ7CiAgICAgICAgfQogICAgICAgIHByZWZpeC1saXN0IEVCR1AtTkVJR0hCT1JTIHsKICAgICAg ICAgICAgMTk4LjUxLjEwMC4yNS8zMjsKICAgICAgICAgICAgMTk4LjUxLjEwMC4yNy8zMjsKICAg ICAgICAgICAgMTk4LjUxLjEwMC4yOS8zMjsKICAgICAgICAgICAgMTk4LjUxLjEwMC4zMS8zMjsK ICAgICAgICB9CiAgICAgICAgcHJlZml4LWxpc3QgUkFESVVTLVNFUlZFUlMgewogICAgICAgICAg ICAxOTguNTEuMTAwLjkvMzI7CiAgICAgICAgICAgIDE5OC41MS4xMDAuMTAvMzI7CiAgICAgICAg fQogICAgICAgIHByZWZpeC1saXN0IElCR1B2Ni1ORUlHSEJPUlMgewogICAgICAgICAgICAyMDAx OkRCODoxOjovNDg7CiAgICAgICAgfQogICAgICAgIHByZWZpeC1saXN0IEVCR1B2Ni1ORUlHSEJP UlMgewogICAgICAgICAgICAyMDAxOkRCODoxMDA6OjI1LzEyODsKICAgICAgICAgICAgMjAwMTpE Qjg6MTAwOjoyNy8xMjg7CiAgICAgICAgICAgIDIwMDE6REI4OjEwMDo6MjkvMTI4OwogICAgICAg ICAgICAyMDAxOkRCODoxMDA6OjMxLzEyODsKICAgICAgICB9CiAgICAgICAgcHJlZml4LWxpc3Qg UkFESVVTdjYtU0VSVkVSUyB7CiAgICAgICAgICAgIDIwMDE6REI4OjEwMDo6OS8xMjg7CiAgICAg ICAgICAgIDIwMDE6REI4OjEwMDo6MTAvMTI4OwogICAgICAgIH0KICAgIH0KICAgIGZpcmV3YWxs IHsKICAgICAgICBwb2xpY2VyIDUwMGticHMgewogICAgICAgICAgICBpZi1leGNlZWRpbmcgewog ICAgICAgICAgICAgICAgYmFuZHdpZHRoLWxpbWl0IDUwMGs7CiAgICAgICAgICAgICAgICBidXJz dC1zaXplLWxpbWl0IDE1MDA7CiAgICAgICAgICAgIH0KICAgICAgICAgICAgdGhlbiBkaXNjYXJk OwogICAgICAgIH0KICAgICAgICBwb2xpY2VyIDI1MGticHMgewogICAgICAgICAgICBpZi1leGNl ZWRpbmcgewogICAgICAgICAgICAgICAgYmFuZHdpZHRoLWxpbWl0IDI1MGs7CiAgICAgICAgICAg ICAgICBidXJzdC1zaXplLWxpbWl0IDE1MDA7CiAgICAgICAgICAgIH0KICAgICAgICAgICAgdGhl biBkaXNjYXJkOwogICAgICAgIH0KICAgICAgICBmYW1pbHkgaW5ldCB7CiAgICAgICAgICAgIGZp bHRlciBwcm90ZWN0LXJvdXRlci1jb250cm9sLXBsYW5lIHsKICAgICAgICAgICAgICAgIHRlcm0g Zmlyc3QtZnJhZyB7CiAgICAgICAgICAgICAgICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAg ICAgICAgIGZpcnN0LWZyYWdtZW50OwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg ICAgICAgICB0aGVuIHsKICAgICAgICAgICAgICAgICAgICAgICAgY291bnQgZnJhZy1kaXNjYXJk czsKICAgICAgICAgICAgICAgICAgICAgICAgbG9nOwogICAgICAgICAgICAgICAgICAgICAgICBk aXNjYXJkOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIH0KICAgICAgICAg ICAgICAgIHRlcm0gbmV4dC1mcmFnIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAg ICAgICAgICAgICAgICAgICAgaXMtZnJhZ21lbnQ7CiAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgICAgIHRoZW4gewogICAgICAgICAgICAgICAgICAgICAgICBjb3VudCBmcmFn LWRpc2NhcmRzOwogICAgICAgICAgICAgICAgICAgICAgICBsb2c7CiAgICAgICAgICAgICAgICAg ICAgICAgIGRpc2NhcmQ7CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgfQog ICAgICAgICAgICAgICAgdGVybSBpY21wIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAg ICAgICAgICAgICAgICAgICAgICAgcHJvdG9jb2wgaWNtcDsKICAgICAgICAgICAgICAgICAgICB9 CiAgICAgICAgICAgICAgICAgICAgdGhlbiB7CiAgICAgICAgICAgICAgICAgICAgICAgIHBvbGlj ZXIgNTAwa2JwczsKICAgICAgICAgICAgICAgICAgICAgICAgYWNjZXB0OwogICAgICAgICAgICAg ICAgICAgIH0KICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0gb3NwZiB7CiAg ICAgICAgICAgICAgICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1h ZGRyZXNzIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE5Mi4wLjIuMC8yNDsKICAgICAg ICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICBwcm90b2NvbCBvc3Bm OwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsK ICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0gaWJncC1jb25uZWN0IHsKICAg ICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAgICAgICAgICAgc291cmNlLXBy ZWZpeC1saXN0IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIElCR1AtTkVJR0hCT1JTOwog ICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29s IHRjcDsKICAgICAgICAgICAgICAgICAgICAgICAgZGVzdGluYXRpb24tcG9ydCBiZ3A7CiAgICAg ICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAgICAg ICAgICAgICAgfQogICAgICAgICAgICAgICAgdGVybSBpYmdwLXJlcGx5IHsKICAgICAgICAgICAg ICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAgICAgICAgICAgc291cmNlLXByZWZpeC1saXN0 IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIElCR1AtTkVJR0hCT1JTOwogICAgICAgICAg ICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29sIHRjcDsKICAg ICAgICAgICAgICAgICAgICAgICAgcG9ydCBiZ3A7CiAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAgICAgICAgICAgICAgfQogICAgICAgICAg ICAgICAgdGVybSBlYmdwLWNvbm5lY3QgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAg ICAgICAgICAgICAgICAgICAgICBzb3VyY2UtcHJlZml4LWxpc3QgewogICAgICAgICAgICAgICAg ICAgICAgICAgICAgRUJHUC1ORUlHSEJPUlM7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAg ICAgICAgICAgICAgICAgICAgICAgcHJvdG9jb2wgdGNwOwogICAgICAgICAgICAgICAgICAgICAg ICBkZXN0aW5hdGlvbi1wb3J0IGJncDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAg ICAgICAgICAgdGhlbiBhY2NlcHQ7CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0 ZXJtIGViZ3AtcmVwbHkgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAgICAgICAgICAg ICAgICAgICAgICBzb3VyY2UtcHJlZml4LWxpc3QgewogICAgICAgICAgICAgICAgICAgICAgICAg ICAgRUJHUC1ORUlHSEJPUlM7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg ICAgICAgICAgICAgcHJvdG9jb2wgdGNwOwogICAgICAgICAgICAgICAgICAgICAgICBwb3J0IGJn cDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgdGhlbiBhY2NlcHQ7 CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIGRucyB7CiAgICAgICAgICAg ICAgICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1hZGRyZXNzIHsK ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDE5OC41MS4xMDAuMC8zMDsKICAgICAgICAgICAg ICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICBwcm90b2NvbCB1ZHA7CiAgICAg ICAgICAgICAgICAgICAgICAgIHBvcnQgZG9tYWluOwogICAgICAgICAgICAgICAgICAgIH0KICAg ICAgICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAg ICAgICAgIHRlcm0gbnRwIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAg ICAgICAgICAgICAgc291cmNlLWFkZHJlc3MgewogICAgICAgICAgICAgICAgICAgICAgICAgICAg MTk4LjUxLjEwMC40LzMwOwogICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAg ICAgICAgICAgIHByb3RvY29sIHVkcDsKICAgICAgICAgICAgICAgICAgICAgICAgZGVzdGluYXRp b24tcG9ydCBudHA7CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRo ZW4gYWNjZXB0OwogICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgdGVybSBzc2ggewog ICAgICAgICAgICAgICAgICAgIGZyb20gewogICAgICAgICAgICAgICAgICAgICAgICBzb3VyY2Ut YWRkcmVzcyB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAxOTguNTEuMTAwLjEyOC8yNTsK ICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICBwcm90b2Nv bCB0Y3A7CiAgICAgICAgICAgICAgICAgICAgICAgIGRlc3RpbmF0aW9uLXBvcnQgc3NoOwogICAg ICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAg ICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0gc25tcCB7CiAgICAgICAgICAgICAgICAg ICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1hZGRyZXNzIHsKICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDE5OC41MS4xMDAuMTI4LzI1OwogICAgICAgICAgICAgICAg ICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29sIHVkcDsKICAgICAgICAg ICAgICAgICAgICAgICAgZGVzdGluYXRpb24tcG9ydCBzbm1wOwogICAgICAgICAgICAgICAgICAg IH0KICAgICAgICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAg ICAgICAgICAgICAgIHRlcm0gcmFkaXVzIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAg ICAgICAgICAgICAgICAgICAgICAgc291cmNlLXByZWZpeC1saXN0IHsKICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFJBRElVUy1TRVJWRVJTOwogICAgICAgICAgICAgICAgICAgICAgICB9CiAg ICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29sIHVkcDsKfCAgICAgICAgICAgICAgICAgICAg ICAgcG9ydCBbIDE4MTIgMTgxMyBdOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg ICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRl cm0gZGVmYXVsdC10ZXJtIHsKICAgICAgICAgICAgICAgICAgICB0aGVuIHsKICAgICAgICAgICAg ICAgICAgICAgICAgY291bnQgY29wcC1leGNlcHRpb25zOwogICAgICAgICAgICAgICAgICAgICAg ICBsb2c7CiAgICAgICAgICAgICAgICAgICAgICAgIHBvbGljZXIgNTAwa2JwczsKICAgICAgICAg ICAgICAgICAgICAgICAgYWNjZXB0OwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg ICAgIH0KICAgICAgICAgICAgfQogICAgICAgIH0KCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCgpBcHBlbmRp eCBBLiwgcGFyYWdyYXBoIDg6CkVYUExBTkFUSU9OOiAKCk9MRDoKCiAgICAgICAgZmFtaWx5IGlu ZXQ2IHsKICAgICAgICAgICAgZmlsdGVyIHByb3RlY3Qtcm91dGVyLWNvbnRyb2wtcGxhbmUtdjYg ewogICAgICAgICAgICAgICAgdGVybSBmcmFndjYgewogICAgICAgICAgICAgICAgICAgIGZyb20g ewogICAgICAgICAgICAgICAgICAgICAgICBuZXh0LWhlYWRlciBmcmFnbWVudDsKICAgICAgICAg ICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgdGhlbiB7CiAgICAgICAgICAgICAgICAg ICAgICAgIGNvdW50IGZyYWctdjYtZGlzY2FyZHM7CiAgICAgICAgICAgICAgICAgICAgICAgIGxv ZzsKICAgICAgICAgICAgICAgICAgICAgICAgZGlzY2FyZDsKICAgICAgICAgICAgICAgICAgICB9 CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIGljbXB2NiB7CiAgICAgICAg ICAgICAgICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAgIG5leHQtaGVhZGVyIGlj bXB2NjsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgdGhlbiB7CiAg ICAgICAgICAgICAgICAgICAgICAgIHBvbGljZXIgNTAwa2JwczsKICAgICAgICAgICAgICAgICAg ICAgICAgYWNjZXB0OwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIH0KICAg ICAgICAgICAgICAgIHRlcm0gb3NwZnYzIHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAg ICAgICAgICAgICAgICAgICAgICAgc291cmNlLWFkZHJlc3MgewogICAgICAgICAgICAgICAgICAg ICAgICAgICAgRkU4MDo6LzEwOwogICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAg ICAgICAgICAgICAgIG5leHQtaGVhZGVyIG9zcGY7CiAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAgICAgICAgICAgICAgfQogICAgICAgICAg ICAgICAgdGVybSBpYmdwdjYtY29ubmVjdCB7CiAgICAgICAgICAgICAgICAgICAgZnJvbSB7CiAg ICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1wcmVmaXgtbGlzdCB7CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJQkdQdjYtTkVJR0hCT1JTOwogICAgICAgICAgICAgICAgICAgICAgICB9 CiAgICAgICAgICAgICAgICAgICAgICAgIG5leHQtaGVhZGVyIHRjcDsKICAgICAgICAgICAgICAg ICAgICAgICAgZGVzdGluYXRpb24tcG9ydCBiZ3A7CiAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAgICAgICAgICAgICAgfQogICAgICAgICAg ICAgICAgdGVybSBpYmdwdjYtcmVwbHkgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAg ICAgICAgICAgICAgICAgICAgICBzb3VyY2UtcHJlZml4LWxpc3QgewogICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJHUHY2LU5FSUdIQk9SUzsKICAgICAgICAgICAgICAgICAgICAgICAgfQog ICAgICAgICAgICAgICAgICAgICAgICBuZXh0LWhlYWRlciB0Y3A7CiAgICAgICAgICAgICAgICAg ICAgICAgIHBvcnQgYmdwOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAg ICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0gZWJn cHY2LWNvbm5lY3QgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAgICAgICAgICAgICAg ICAgICAgICBzb3VyY2UtcHJlZml4LWxpc3QgewogICAgICAgICAgICAgICAgICAgICAgICAgICAg RUJHUHY2LU5FSUdIQk9SUzsKICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAg ICAgICAgICAgICBuZXh0LWhlYWRlciB0Y3A7CiAgICAgICAgICAgICAgICAgICAgICAgIGRlc3Rp bmF0aW9uLXBvcnQgYmdwOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAg ICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRlcm0gZWJn cHY2LXJlcGx5IHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAgICAg ICAgICAgc291cmNlLXByZWZpeC1saXN0IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVC R1B2Ni1ORUlHSEJPUlM7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAg ICAgICAgICAgbmV4dC1oZWFkZXIgdGNwOwogICAgICAgICAgICAgICAgICAgICAgICBwb3J0IGJn cDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgdGhlbiBhY2NlcHQ7 CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIGRuc3Y2IHsKICAgICAgICAg ICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAgICAgICAgICAgc291cmNlLWFkZHJlc3Mg ewogICAgICAgICAgICAgICAgICAgICAgICAgICAyMDAxOkRCODoxMDA6MTo6LzY0OwogICAgICAg ICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIG5leHQtaGVhZGVy IFsgdWRwIHRjcCBdOwogICAgICAgICAgICAgICAgICAgICAgICBwb3J0IGRvbWFpbjsKICAgICAg ICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgdGhlbiBhY2NlcHQ7CiAgICAgICAg ICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIG50cHY2IHsKICAgICAgICAgICAgICAgICAg ICBmcm9tIHsKICAgICAgICAgICAgICAgICAgICAgICAgc291cmNlLWFkZHJlc3MgewogICAgICAg ICAgICAgICAgICAgICAgICAgICAgMjAwMTpEQjg6MTAwOjI6Oi82NDsKICAgICAgICAgICAgICAg ICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICBuZXh0LWhlYWRlciB1ZHA7CiAgICAg ICAgICAgICAgICAgICAgICAgIGRlc3RpbmF0aW9uLXBvcnQgbnRwOwogICAgICAgICAgICAgICAg ICAgIH0KICAgICAgICAgICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0K ICAgICAgICAgICAgICAgIHRlcm0gc3NodjYgewogICAgICAgICAgICAgICAgICAgIGZyb20gewog ICAgICAgICAgICAgICAgICAgICAgICBzb3VyY2UtYWRkcmVzcyB7CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAyMDAxOkRCODoxMDA6Mzo6LzY0OwogICAgICAgICAgICAgICAgICAgICAgICB9 CiAgICAgICAgICAgICAgICAgICAgICAgIG5leHQtaGVhZGVyIHRjcDsKICAgICAgICAgICAgICAg ICAgICAgICAgZGVzdGluYXRpb24tcG9ydCBzc2g7CiAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAgICAgICAgICAgICAgfQogICAgICAgICAg ICAgICAgdGVybSBzbm1wdjYgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAgICAgICAg ICAgICAgICAgICAgICBzb3VyY2UtYWRkcmVzcyB7CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAyMDAxOkRCODoxMDA6Mzo6LzY0OwogICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAg ICAgICAgICAgICAgICAgIG5leHQtaGVhZGVyIHVkcDsKICAgICAgICAgICAgICAgICAgICAgICAg ZGVzdGluYXRpb24tcG9ydCBzbm1wOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg ICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIHRl cm0gcmFkaXVzdjYgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAgICAgICAgICAgICAg ICAgICAgICBzb3VyY2UtcHJlZml4LWxpc3QgewogICAgICAgICAgICAgICAgICAgICAgICAgICAg UkFESVVTdjYtU0VSVkVSUzsKICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAg ICAgICAgICAgICBuZXh0LWhlYWRlciB1ZHA7CnwgICAgICAgICAgICAgICAgICAgICAgIHBvcnQg WyAxNjQ1IDE2NDYgXTsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAg dGhlbiBhY2NlcHQ7CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIGRlZmF1 bHQtdGVybS12NiB7CiAgICAgICAgICAgICAgICAgICAgdGhlbiB7CiAgICAgICAgICAgICAgICAg ICAgICAgIHBvbGljZXIgNTAwa2JwczsKICAgICAgICAgICAgICAgICAgICAgICAgY291bnQgY29w cC1leGNlcHRpb25zLXY2OwogICAgICAgICAgICAgICAgICAgICAgICBsb2c7CiAgICAgICAgICAg ICAgICAgICAgICAgIGFjY2VwdDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAg ICB9CiAgICAgICAgICAgIH0KICAgICAgICB9CgpORVc6CgogICAgICAgIGZhbWlseSBpbmV0NiB7 CiAgICAgICAgICAgIGZpbHRlciBwcm90ZWN0LXJvdXRlci1jb250cm9sLXBsYW5lLXY2IHsKICAg ICAgICAgICAgICAgIHRlcm0gZnJhZ3Y2IHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAg ICAgICAgICAgICAgICAgICAgICAgbmV4dC1oZWFkZXIgZnJhZ21lbnQ7CiAgICAgICAgICAgICAg ICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRoZW4gewogICAgICAgICAgICAgICAgICAgICAg ICBjb3VudCBmcmFnLXY2LWRpc2NhcmRzOwogICAgICAgICAgICAgICAgICAgICAgICBsb2c7CiAg ICAgICAgICAgICAgICAgICAgICAgIGRpc2NhcmQ7CiAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgdGVybSBpY21wdjYgewogICAgICAgICAgICAg ICAgICAgIGZyb20gewogICAgICAgICAgICAgICAgICAgICAgICBuZXh0LWhlYWRlciBpY21wdjY7 CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRoZW4gewogICAgICAg ICAgICAgICAgICAgICAgICBwb2xpY2VyIDUwMGticHM7CiAgICAgICAgICAgICAgICAgICAgICAg IGFjY2VwdDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB9CiAgICAgICAg ICAgICAgICB0ZXJtIG9zcGZ2MyB7CiAgICAgICAgICAgICAgICAgICAgZnJvbSB7CiAgICAgICAg ICAgICAgICAgICAgICAgIHNvdXJjZS1hZGRyZXNzIHsKICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZFODA6Oi8xMDsKICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAg ICAgICAgICBuZXh0LWhlYWRlciBvc3BmOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAg ICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAg IHRlcm0gaWJncHY2LWNvbm5lY3QgewogICAgICAgICAgICAgICAgICAgIGZyb20gewogICAgICAg ICAgICAgICAgICAgICAgICBzb3VyY2UtcHJlZml4LWxpc3QgewogICAgICAgICAgICAgICAgICAg ICAgICAgICAgSUJHUHY2LU5FSUdIQk9SUzsKICAgICAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgICAgICAgICBuZXh0LWhlYWRlciB0Y3A7CiAgICAgICAgICAgICAgICAgICAg ICAgIGRlc3RpbmF0aW9uLXBvcnQgYmdwOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAg ICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAg IHRlcm0gaWJncHY2LXJlcGx5IHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAg ICAgICAgICAgICAgICAgc291cmNlLXByZWZpeC1saXN0IHsKICAgICAgICAgICAgICAgICAgICAg ICAgICAgIElCR1B2Ni1ORUlHSEJPUlM7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAg ICAgICAgICAgICAgICAgICAgbmV4dC1oZWFkZXIgdGNwOwogICAgICAgICAgICAgICAgICAgICAg ICBwb3J0IGJncDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgdGhl biBhY2NlcHQ7CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIGViZ3B2Ni1j b25uZWN0IHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAgICAgICAg ICAgc291cmNlLXByZWZpeC1saXN0IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVCR1B2 Ni1ORUlHSEJPUlM7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAg ICAgICAgbmV4dC1oZWFkZXIgdGNwOwogICAgICAgICAgICAgICAgICAgICAgICBkZXN0aW5hdGlv bi1wb3J0IGJncDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgdGhl biBhY2NlcHQ7CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIGViZ3B2Ni1y ZXBseSB7CiAgICAgICAgICAgICAgICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAg IHNvdXJjZS1wcmVmaXgtbGlzdCB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBFQkdQdjYt TkVJR0hCT1JTOwogICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAg ICAgIG5leHQtaGVhZGVyIHRjcDsKICAgICAgICAgICAgICAgICAgICAgICAgcG9ydCBiZ3A7CiAg ICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAg ICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgdGVybSBkbnN2NiB7CiAgICAgICAgICAgICAg ICAgICAgZnJvbSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1hZGRyZXNzIHsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgMjAwMTpEQjg6MTAwOjE6Oi82NDsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgICBuZXh0LWhlYWRlciBbIHVk cCB0Y3AgXTsKICAgICAgICAgICAgICAgICAgICAgICAgcG9ydCBkb21haW47CiAgICAgICAgICAg ICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRoZW4gYWNjZXB0OwogICAgICAgICAgICAg ICAgfQogICAgICAgICAgICAgICAgdGVybSBudHB2NiB7CiAgICAgICAgICAgICAgICAgICAgZnJv bSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHNvdXJjZS1hZGRyZXNzIHsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDIwMDE6REI4OjEwMDoyOjovNjQ7CiAgICAgICAgICAgICAgICAgICAg ICAgIH0KICAgICAgICAgICAgICAgICAgICAgICAgbmV4dC1oZWFkZXIgdWRwOwogICAgICAgICAg ICAgICAgICAgICAgICBkZXN0aW5hdGlvbi1wb3J0IG50cDsKICAgICAgICAgICAgICAgICAgICB9 CiAgICAgICAgICAgICAgICAgICAgdGhlbiBhY2NlcHQ7CiAgICAgICAgICAgICAgICB9CiAgICAg ICAgICAgICAgICB0ZXJtIHNzaHY2IHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAg ICAgICAgICAgICAgICAgICAgc291cmNlLWFkZHJlc3MgewogICAgICAgICAgICAgICAgICAgICAg ICAgICAgMjAwMTpEQjg6MTAwOjM6Oi82NDsKICAgICAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgICAgICAgICBuZXh0LWhlYWRlciB0Y3A7CiAgICAgICAgICAgICAgICAgICAg ICAgIGRlc3RpbmF0aW9uLXBvcnQgc3NoOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAg ICAgICAgICAgICB0aGVuIGFjY2VwdDsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAg IHRlcm0gc25tcHY2IHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAg ICAgICAgICAgc291cmNlLWFkZHJlc3MgewogICAgICAgICAgICAgICAgICAgICAgICAgICAgMjAw MTpEQjg6MTAwOjM6Oi82NDsKICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAg ICAgICAgICAgICBuZXh0LWhlYWRlciB1ZHA7CiAgICAgICAgICAgICAgICAgICAgICAgIGRlc3Rp bmF0aW9uLXBvcnQgc25tcDsKICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAg ICAgdGhlbiBhY2NlcHQ7CiAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICB0ZXJtIHJh ZGl1c3Y2IHsKICAgICAgICAgICAgICAgICAgICBmcm9tIHsKICAgICAgICAgICAgICAgICAgICAg ICAgc291cmNlLXByZWZpeC1saXN0IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJBRElV U3Y2LVNFUlZFUlM7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAg ICAgICAgbmV4dC1oZWFkZXIgdWRwOwp8ICAgICAgICAgICAgICAgICAgICAgICBwb3J0IFsgMTgx MiAxODEzIF07CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgIHRoZW4g YWNjZXB0OwogICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgdGVybSBkZWZhdWx0LXRl cm0tdjYgewogICAgICAgICAgICAgICAgICAgIHRoZW4gewogICAgICAgICAgICAgICAgICAgICAg ICBwb2xpY2VyIDUwMGticHM7CiAgICAgICAgICAgICAgICAgICAgICAgIGNvdW50IGNvcHAtZXhj ZXB0aW9ucy12NjsKICAgICAgICAgICAgICAgICAgICAgICAgbG9nOwogICAgICAgICAgICAgICAg ICAgICAgICBhY2NlcHQ7CiAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgfQog ICAgICAgICAgICB9CiAgICAgICAgfQoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoK ------_=_NextPart_001_01CB9BD9.5729395C-- From barryleiba@gmail.com Tue Dec 14 14:14: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 E5A1128C115; Tue, 14 Dec 2010 14:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ34O7TdtbLn; Tue, 14 Dec 2010 14:14:09 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D484928C0E6; Tue, 14 Dec 2010 14:14:08 -0800 (PST) Received: by iwn40 with SMTP id 40so1367478iwn.31 for ; Tue, 14 Dec 2010 14:15:49 -0800 (PST) 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=B/l0CgSVoSDFUzsXBMSk89k3J06lEwEp45Xp3uJGKH8=; b=K1vGbHrK38IAXOWMxCuln13YvRrND2r4XYHkXAkOmYSM6joNa0FfyJfdVV7VN1SP2K KRtc0DVqto/H8ANAt0e5Iu485vz/Kl0Fn9Y9B/FZsZPxJJP+ODZt1l7P/7Sx2PRdo13a 0z87x99MJLQQBrgzwRS7hYgurPK8D0vAneUNI= 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=KUeqgQW9qWfOvvZpZFGbALx4EKX6NPsy1F5IjXru5KofE+Czi7RRFdRV63x+3Md1TW nba4T9mbnACHzAl9BtpQZoVaXRGNmrUJWmhDCP0byKGET5AP/YKY/bz8UUPcKKT45iHp IJduvPffq3ZrCLeqHEmY5ti1lWLLb9PAuVKyk= MIME-Version: 1.0 Received: by 10.231.191.129 with SMTP id dm1mr4030560ibb.59.1292364949716; Tue, 14 Dec 2010 14:15:49 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Tue, 14 Dec 2010 14:15:49 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Dec 2010 17:15:49 -0500 X-Google-Sender-Auth: InPuu4M02Zxh7E2IOjrOkqLFqUI Message-ID: From: Barry Leiba To: Chris Lonvick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-morg-list-specialuse.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-morg-list-specialuse-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 22:14:10 -0000 >> I can make this more explicit, if you think that's important, by >> adding another paragraph: >> >> =A0Example: If a user is allowed to give the "\Junk" attribute to a >> shared mailbox, >> =A0legitimate mail that's misclassified as junk (false positives) will >> be put into that >> =A0shared mailbox, exposing the user's private mail to others. =A0The se= rver >> might >> =A0warn a user of that possibility, or might refuse to allow the >> specification to be >> =A0made on a shared mailbox. =A0(Note that this problem exists independe= nt of >> this >> =A0specification, if the server allows a user to share a mailbox >> that's already in use >> =A0for such a function.) >> >> Does that help, do you think? > > Personally, I think being expicit about this helps. =A0Your explanation e= bove > helps me as well. > > I'd like to see it in there but if you, or others feel that people famili= ar > enough with IMAP to implement this don't need this extra warning, then I > won't push it. It's already in my working copy for the next rev. Barry From dwing@cisco.com Tue Dec 14 15:20:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2429228C115; Tue, 14 Dec 2010 15:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.567 X-Spam-Level: X-Spam-Status: No, score=-110.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-jQ+A72+Bpu; Tue, 14 Dec 2010 15:20:19 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BBBF628C148; Tue, 14 Dec 2010 15:20:19 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,345,1288569600"; d="scan'208";a="232696749" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 14 Dec 2010 23:22:01 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBENM0nW025399; Tue, 14 Dec 2010 23:22:00 GMT From: "Dan Wing" To: "'Tobias Gondrom'" , , , References: <4D06BD5F.5040807@gondrom.org> In-Reply-To: <4D06BD5F.5040807@gondrom.org> Date: Tue, 14 Dec 2010 15:21:59 -0800 Message-ID: <220d01cb9be5$b57179c0$20546d40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcubJ4eHjcpZjn6VSrmBjIHzK3CylgAEajAQ Content-Language: en-us Cc: keith.drage@alcatel-lucent.com, abegen@cisco.com, csp@csperkins.org, even.roni@huawei.com, rjsparks@nostrum.com Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-cnames-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 23:20:21 -0000 -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > Sent: Monday, December 13, 2010 4:42 PM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-avt-rtp- > cnames.all@tools.ietf.org > Cc: abegen@cisco.com; csp@csperkins.org; dwing@cisco.com; > keith.drage@alcatel-lucent.com; even.roni@huawei.com; > rjsparks@nostrum.com > Subject: secdir review of draft-ietf-avt-rtp-cnames-02 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. Tobias, Thanks for your review. > The Security Considerations section is ok and the draft does not add > further security aspects beyond it. > However there are a number of issues with the draft, including use of > rfc2119 language and hash agility: > > 1. section 4.2 first bullet point: > spelling: > s/"and endpoint MUST generate and store a Universally"/"an endpoint > MUST > generate and store a Universally" Will be fixed in -03, thanks. > 2. COMMENTS/DISCUSS: > section 4.2: the draft makes the distinction between 4 cases: > a) long-term persistent > b) short-term persistent with IPv6 > c) short-term persistent with IPv4 > d) per-session RTCP CNAME > all use MUST to specify the generated CNAME with _different_ methods. > > This raises a number of potential issues: > 2.1. The boundary between the definition of long-term and short-term > with persistence across several related RTP sessions (see 4.1) is not > well defined, thus different MUST clauses for how to treat these two > cases seem problematic. As it can be hard for an application to > determine the difference between across several sessions and long-term. It is explained in Section 4.1's paragraph 2 and 3, which essentially say that short-term is per each RTP session and necessary for lipsync, while long-term is across several RTP sessions and useful for third- party monitoring of RTP performance. Are those descriptions inadequate for implementers to determine which they want? > 2.2. Though I understand why a system may not want to use UUID in all > four cases, it is unclear to me why it should be forbidden to use UUID > for scenarios b, c and d. (which is implied by using "MUST" with the > defined method). UUID is a persistent and permanent identifier, so can't be used with d (per-session). However, you have a good point that it is equally useful for b (short-term IPv6) and c (short-term IPv4). See more on that below. > 2.3. in section 4.2. next to last paragraph it states: (other methods) > "beyond the three methods listed above, are not compliant with this > specification and SHOULD NOT be used." > If the document is std track and updates 3550 and uses "MUST" for the > methods it would be inconsistent to frame it here as "SHOULD NOT". We will delete the sentence that says: Other methods, beyond the three methods listed above, are not compliant with this specification and SHOULD NOT be used. because it is really saying "if you don't comply with this document's requirements, you aren't in compliance with this document" -- which is a silly thing to say. Based on other reviews, we also added the following new text at the end of that section: It is believed that obtaining uniqueness is an important property that requires careful evaluation of the method. This document provides a number of methods, for which it is believed that at least one of them would meet all deployment scenarios. This document therefore does not provide for the implementor to define and select an alternative method. A future specification might define an alternative method for generating RTCP CNAMEs as long as the proposed method has appropriate uniqueness, and there is consistency between the methods used for multiple RTP sessions that are to be correlated. However, such a specification needs to be reviewed and approved before deployment. > 2.4. Question: which leads to another question: are there upgrade > issues > with 3550-applications with this update or is there an upgrade path for > RTP from 3550 to draft-ietf-avt-rtp-cnames? CNAME values are opaque strings to remote peers, so there is no upgrade problem. > 2.5. case b (IPv6): I understand that one reason for different handling > of IPv4 is NAT and private address spaces. And although NAT with IPv6 > should not make sense, in theory this could still happen, so I am not > sure whether these two cases (b and c) can be and need to be handled > differently. > > Overall: a solution could be that UUID be allowed for all methods (e.g. > frame it as "MUST use one of the here described methods") and maybe the > unification of case b (short-term IPv6) and c (short-term IPv4) - > either > allowing both methods for both and indicating preferred approaches with > "SHOULD" for each of them (e.g. SHOULD use MAC for scenarios of > possible > NAT) - unless the authors can explain why we really need to mandate > these two different scenarios and why IPv6 has not at least in theory > NAT issues? If we expect / fear IPv6 NAPT (IPv6 address sharing), I concur that using an IPv6 address is not safely unique, and we will eliminate the option where an IPv6 address is used as CNAME. Your review highlighted another issue, which had escaped me until now, with two IPv6-only networks using a NAT64 and the well-known prefix 64:ff9b::/96 defined by RFC6052. Those two hosts can't communicate directly with each other over IPv6, but they could communicate with each other using an application-level proxy (Session Border Controller) or a NAT64. And in both cases they would have an RTCP CNAME collision because their IPv6 addresses are not unique. Because of these two problems, we need to remove the option to use the IPv6 address in CNAME. > 3. hash agility: in section 4.2 last paragraph the draft mandates for > case d (per-session RTCP CNAMEs ) to use SHA1-HMAC and truncate the > value to 96bit > 3.1. DISCUSS: The drafts should not be tied to SHA1 and actually allow > use of other algorithms (e.g. SHA2/SHA-256/-512) as well. Would adding the following highlighted text be sufficient to clarify: NEW: To generate a per-session RTCP CNAME, an endpoint MUST perform a Hash-based Message Authentication Code at least as strong as ...^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SHA1-HMAC [RFC2104] on the concatenated values of the RTP endpoint's initial SSRC, > 3.2. Question: maybe obvious, but why do you need to truncate the > output to 96bit? would adding the following text be sufficient to clarify: The output of the hash function is truncated to 96 bits to provides a reasonable compromise between security and packet size. > 3.3. Clarification: it also states at the end of this paragraph that > the > "user@" part of the CNAME "is omitted". Does this mean "MAY be omitted > on single-user systems, and MAY be replaced by an opaque token on > multiuser systems" like for cases a-c or is this intentionally > different > and mandatory in d? For the last sentence of Section 4.2, would adjusting this text be sufficient to clarify: OLD: The "user@" part of the RTCP CNAME is omitted when generating per-session RTCP CNAMEs. NEW: In all cases of single- or multi-user systems, ..^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the "user@" part of the RTCP CNAME is omitted when generating per-session RTCP CNAMEs. -d > Kind regards, Tobias > > > Tobias Gondrom > email: tobias.gondrom@gondrom.org From d3e3e3@gmail.com Tue Dec 14 19:45: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 BC3753A6EC6; Tue, 14 Dec 2010 19:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNLAFonSdAPU; Tue, 14 Dec 2010 19:45:24 -0800 (PST) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by core3.amsl.com (Postfix) with ESMTP id B18013A6E32; Tue, 14 Dec 2010 19:45:23 -0800 (PST) Received: by vws9 with SMTP id 9so654750vws.27 for ; Tue, 14 Dec 2010 19:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=DS19lhLVXQh58nU2ddx/KlpsezBXyaknnb4GMccWdXs=; b=P3VQLWsCXQjqPcwkIQ0W28LJOAzs4aDaULVIVBYQJ5ANxlc1ihGUwIVTEh/IW0hEMZ U47QjwyfBr72/6Hm3Er+1KtYH4yBvH38ROqj+lY2YB9j8/5nlaPj5FEzT4+Z8k/G30fu Kfmh2s0VAjq82/ChwC0w35Lj4QIntLe9XIz+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=B4bLVSPSBm9B+Dk2lCdmGl+yf3pj+uhN4bCxBJcBQAIA4/OS8vnZKNgjT6NZMc8067 EClVOQhkTRT+EXatr0ZDrcjY8WJjo1dieucHxy+B8OiQbaxhyAO3gkYRtDkOahKZyFri OyZnpxnAktdFuyPBOQqsvz1cLaybRni/EKH6U= Received: by 10.220.200.131 with SMTP id ew3mr1946760vcb.66.1292384824861; Tue, 14 Dec 2010 19:47:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.91.197 with HTTP; Tue, 14 Dec 2010 19:46:44 -0800 (PST) From: Donald Eastlake Date: Tue, 14 Dec 2010 22:46:44 -0500 Message-ID: To: secdir@ietf.org, iesg@ietf.org, abegen@cisco.com, Keith Drage , Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] SecDir review of draft-ietf-avt-rtcp-port-for-ssm-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, 15 Dec 2010 03:45:24 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies the addition of a new SDP attribute. This attribute does not appear to present any new type of security vulnerability. I believe the Security Considerations section needs a small addition to avoid being too vague. It currently just says "Therefore, as usual adequate security measures are RECOMMENDED ..." without giving any hint as to what those measures are or where to find any. Admittedly, this draft is an update to RFC 5760 and a reasonable non-exclusive list of such measures occurs in that RFC. Nevertheless, I would be much more comfortable if the Security Considerations section wording was augmented so it said "Therefore, adequate security measures, such as those listed in the Security Considerations section of [RFC5760], are RECOMMENDED...". Trivia: The following sentence: "The formal description of the 'multicast-rtcp' attribute is defined by the following ABNF [RFC5234] syntax:" somehow reads as sort of redundantly redundant. Maybe: "The following ABNF [RFC5234] syntax formally describes the 'multicast-rtcp' attribute:" Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0d3e3e3@gmail.com From gwz@net-zen.net Tue Dec 14 21:17: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 B9EE43A6E01 for ; Tue, 14 Dec 2010 21:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezRnea36I4yx for ; Tue, 14 Dec 2010 21:17:47 -0800 (PST) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id BDC233A6DFC for ; Tue, 14 Dec 2010 21:17:47 -0800 (PST) Received: (qmail 30454 invoked from network); 15 Dec 2010 05:04:00 -0000 Received: from unknown (124.120.200.9) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 15 Dec 2010 05:03:59 -0000 From: "Glen Zorn" To: , "'Joe Abley'" References: <001201cb9b59$acd02d70$06708850$@net> <4D077C47.4010506@cisco.com> In-Reply-To: <4D077C47.4010506@cisco.com> Date: Wed, 15 Dec 2010 12:19:18 +0700 Organization: Network Zen Message-ID: <000e01cb9c17$a19ef080$e4dcd180$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcubmYoipiEUrSd3RTeylvVoGjGxFQAfHGrw Content-Language: en-us Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 05:17:48 -0000 Rodney Dunn [mailto:rodunn@cisco.com] writes: > Thanks Joe/Glen, > > I made the updates to change them to 1812/1813 with a not to the > reference to the 1645/1646 ports. > > "Permit RADIUS authentication and accounting replies from RADIUS servers > 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001:DB8:100::10 that > are listening on UDP ports 1812 and 1813. Note that this doesn't account > for a server using the commonly deployed pre-standard UDP ports of 1812 > and 1813." That's better, except that "pre-standard" isn't exactly accurate: port 1812 was specified in RFC 2058 but it was discovered after the fact that the port was already assigned to the datametrics service (thus the new allocation); furthermore, RADIUS Accounting has _never_ been a standard. I would suggest: OLD: Note that this doesn't account for a server using the commonly deployed pre-standard UDP ports of 1812 and 1813. NEW: Note that this doesn't account for a server using the original UDP ports of 1812 and 1813. ... Hope this helps. ~gwz From gwz@net-zen.net Tue Dec 14 21:19: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 191B83A6E01 for ; Tue, 14 Dec 2010 21:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKc-MorjPfUh for ; Tue, 14 Dec 2010 21:19:13 -0800 (PST) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id 4DF133A6DA6 for ; Tue, 14 Dec 2010 21:19:13 -0800 (PST) Received: (qmail 9416 invoked from network); 15 Dec 2010 05:20:53 -0000 Received: from unknown (124.120.200.9) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 15 Dec 2010 05:20:53 -0000 From: "Glen Zorn" To: "'Joe Abley'" , References: <001201cb9b59$acd02d70$06708850$@net> <4D077C47.4010506@cisco.com> <5C11F4B2-00A9-4C5C-BA19-417756547632@hopcount.ca> In-Reply-To: <5C11F4B2-00A9-4C5C-BA19-417756547632@hopcount.ca> Date: Wed, 15 Dec 2010 12:20:43 +0700 Organization: Network Zen Message-ID: <000f01cb9c17$d48de140$7da9a3c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcubmuPX8ApT8oTvQH25nvfDEry6vAAfM8nw Content-Language: en-us Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 05:19:14 -0000 Joe Abley [mailto:jabley@hopcount.ca] writes: ... > > "Permit RADIUS authentication and accounting replies from RADIUS > servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and > 2001:DB8:100::10 that are listening on UDP ports 1812 and 1813. Note > that this doesn't account for a server using the commonly deployed pre- > standard UDP ports of 1812 and 1813." > > I think you mean "1645 and 1646" in the final sentence. > > I would also drop "commonly deployed" since I think the phrase is > subjective and difficult to qualify, and replace "account for" with > "accommodate" since one of the ports you're opening a hole for is for > accounting and different uses of the same word seems worth avoiding > (e.g. for non-English speakers). Good idea. From gwz@net-zen.net Tue Dec 14 21:27: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 3F8D43A6E3F for ; Tue, 14 Dec 2010 21:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIHsDoQTRDZx for ; Tue, 14 Dec 2010 21:26:59 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 32C883A6FD6 for ; Tue, 14 Dec 2010 21:26:58 -0800 (PST) Received: (qmail 31454 invoked from network); 15 Dec 2010 05:28:40 -0000 Received: from unknown (124.120.200.9) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 15 Dec 2010 05:28:39 -0000 From: "Glen Zorn" To: "'Sean Turner'" , References: <001201cb9b59$acd02d70$06708850$@net> <4D07926A.9030007@ieca.com> In-Reply-To: <4D07926A.9030007@ieca.com> Date: Wed, 15 Dec 2010 12:28:30 +0700 Organization: Network Zen Message-ID: <001001cb9c18$ea998970$bfcc9c50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcubprmL7kvQCK7lSdavRidlJoTNWQAcWvZw Content-Language: en-us Cc: opsec-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 05:27:00 -0000 Sean Turner [mailto:turners@ieca.com] writes: > I hoping that this was a typo. I pulled out all the registered RADIUS > ports from http://www.iana.org/assignments/port-numbers and 1645/1646: > > sightline 1645/tcp SightLine > sightline 1645/udp SightLine > # admin > sa-msg-port 1646/tcp sa-msg-port > sa-msg-port 1646/udp sa-msg-port > # Eric Whitehill > > > radius 1812/tcp RADIUS > radius 1812/udp RADIUS > # [RFC2865] > radius-acct 1813/tcp RADIUS Accounting > radius-acct 1813/udp RADIUS Accounting > # [RFC2866] > radsec 2083/tcp Secure Radius Service > radsec 2083/udp Secure Radius Service > # Mike McCauley May 2005 > radius-dynauth 3799/tcp RADIUS Dynamic Authorization > radius-dynauth 3799/udp RADIUS Dynamic Authorization > # RFC 3576 - July 2003 > > Should 1812 & 1813 be listed or also 2083 & 3799? radsec isn't RADIUS; RFC 3576 isn't a core part of RADIUS, either. I think that 1812 & 1813 are fine in the context of this example. > > spt > > On 12/14/10 1:39 AM, Glen Zorn 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. > > > > Section 3.1 says: > > > > o Permit RADIUS authentication and accounting replies from RADIUS > > servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: > > DB8:100::10 that are listening on UDP ports 1645 and 1646. > Note > > that this doesn't account for a server using Internet Assigned > > Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. > > > > So, in other words, RADIUS traffic on the ports (officially assigned > for > > more than ten years now) will be blocked. This seems like a very poor > > example. > > > > > > > > From gwz@net-zen.net Tue Dec 14 21:40: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 30A533A6DB0 for ; Tue, 14 Dec 2010 21:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ThEaJvVeDed for ; Tue, 14 Dec 2010 21:40:41 -0800 (PST) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id C5A4D3A6E33 for ; Tue, 14 Dec 2010 21:40:41 -0800 (PST) Received: (qmail 22088 invoked from network); 15 Dec 2010 05:26:55 -0000 Received: from unknown (124.120.200.9) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 15 Dec 2010 05:26:54 -0000 From: "Glen Zorn" To: "'Carlos Pignataro \(cpignata\)'" , "'Joe Abley'" References: <001201cb9b59$acd02d70$06708850$@net> <9B0EE2FE-9DCB-4F52-8515-F30050DF46F8@cisco.com> In-Reply-To: <9B0EE2FE-9DCB-4F52-8515-F30050DF46F8@cisco.com> Date: Wed, 15 Dec 2010 12:42:13 +0700 Organization: Network Zen Message-ID: <001201cb9c1a$d52beea0$7f83cbe0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcubrgP3DUhH6C2aTHao33g2eHp+ewAbFIwg Content-Language: en-us Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 05:40:43 -0000 Carlos Pignataro (cpignata) [mailto://cpignata@cisco.com] writes: ... > >> Section 3.1 says: > >> > >> o Permit RADIUS authentication and accounting replies from RADIUS > >> servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: > >> DB8:100::10 that are listening on UDP ports 1645 and 1646. Note > >> that this doesn't account for a server using Internet Assigned > >> Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. > >> > >> So, in other words, RADIUS traffic on the ports (officially assigned > for > >> more than ten years now) will be blocked. This seems like a very > poor > >> example. > > Please note that this was intentional, as a doc produced in Opsec we > intended to make it as close to the operational reality we know as > possible. And our perspective was that we see more 1645/1646. There are lots of non-standard hacks in the wild; I don't think that it's the job of the IETF to document them. ... From d3e3e3@gmail.com Tue Dec 14 22:14: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 8A2853A6FEF; Tue, 14 Dec 2010 22:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsxTae1GU-yn; Tue, 14 Dec 2010 22:14:27 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 1FCF73A7024; Tue, 14 Dec 2010 22:13:28 -0800 (PST) Received: by qyj19 with SMTP id 19so1627290qyj.10 for ; Tue, 14 Dec 2010 22:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=mLsytRt3vfUc/0WR1vMBmMpsDO65gQXsK7sawWKIdfI=; b=jNfIyrPp+NSiVmOKa76rQUPMhElid6ycRuZRdNtc1BXqB1gRZORklhrVtnIFVtRdZZ OGHG+CsyaqyMSQxZuw5rJd2EFuybfLgk+Rw5j2PF71s7/VzvHG6oNYWFfpP83cf3Clrk RYrwwSZOQzp6aPJo4TI8vMi0fifgRePo+4xCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=NdXztDGxiR7fhmRNhQuEK+3ZrVsB5UhjD+4jHiNpHcuVqRjEZIlWoE4HD90vIGU1FH BIuuu605PaGIhkQmhGn7NClkX5QMScufl7Rz4EarT+BtLLQX5T5qdNxWukXmS7xe2rUL gONt/aBiIAGJPbWRxjlf8KLpYqj2SrgwAxjs4= Received: by 10.224.67.147 with SMTP id r19mr5949905qai.324.1292393709689; Tue, 14 Dec 2010 22:15:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.91.197 with HTTP; Tue, 14 Dec 2010 22:14:49 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2E71E@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2E71E@xmb-sjc-215.amer.cisco.com> From: Donald Eastlake Date: Wed, 15 Dec 2010 01:14:49 -0500 Message-ID: To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Drage , iesg@ietf.org, Roni Even , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-avt-rtcp-port-for-ssm-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, 15 Dec 2010 06:14:28 -0000 Thanks, that wording looks good. Donald On Tue, Dec 14, 2010 at 11:52 PM, Ali C. Begen (abegen) wrote: > Hi Donald, > > Thanks for the review. > >> -----Original Message----- >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >> Sent: Tuesday, December 14, 2010 10:47 PM >> To: secdir@ietf.org; iesg@ietf.org; Ali C. Begen (abegen); Keith Drage; = Roni Even >> Subject: SecDir review of draft-ietf-avt-rtcp-port-for-ssm-03 >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. =A0Document editors and WG chairs should treat these comments just >> like any other last call comments. >> >> This draft specifies the addition of a new SDP attribute. This >> attribute does not appear to present any new type of security >> vulnerability. >> >> I believe the Security Considerations section needs a small addition >> to avoid being too vague. It currently just says "Therefore, as usual >> adequate security measures are RECOMMENDED ..." without giving any >> hint as to what those measures are or where to find any. Admittedly, >> this draft is an update to RFC 5760 and a reasonable non-exclusive >> list of such measures occurs in that RFC. Nevertheless, I would be >> much more comfortable if the Security Considerations section wording >> was augmented so it said "Therefore, adequate security measures, such >> as those listed in the Security Considerations section of [RFC5760], >> are RECOMMENDED...". > > Based on other reviews and discussing with the AD, we went one step furth= er and the sentence above is replaced with: > > "In order to avoid attacks of this sort, the SDP description needs to be = integrity protected and provided with source authentication. This can, for = example, be achieved on an end-to-end basis using S/MIME RFC5652 when SDP i= s used in a signaling packet using MIME types (application/sdp). Alternativ= ely, HTTPS RFC2818 or the authentication method in the Session Announcement= Protocol (SAP) RFC2974 could be used as well." > >> Trivia: >> >> The following sentence: >> =A0 =A0"The formal description of the 'multicast-rtcp' attribute is defi= ned >> =A0 =A0by the following ABNF [RFC5234] syntax:" >> somehow reads as sort of redundantly redundant. Maybe: "The following >> ABNF [RFC5234] syntax formally describes the 'multicast-rtcp' >> attribute:" > > Sounds good. > > Cheers, acbegen. > >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) >> =A0d3e3e3@gmail.com > From jabley@hopcount.ca Tue Dec 14 05:24: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 14AA23A6FA3; Tue, 14 Dec 2010 05:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5EBeEmPKVLd; Tue, 14 Dec 2010 05:24:07 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 502563A6FA1; Tue, 14 Dec 2010 05:24:07 -0800 (PST) Received: from [199.212.90.26] (helo=dh26.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PSUwk-000Eag-CC; Tue, 14 Dec 2010 13:29:38 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <001201cb9b59$acd02d70$06708850$@net> Date: Tue, 14 Dec 2010 08:25:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001201cb9b59$acd02d70$06708850$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.26 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 13:24:08 -0000 On 2010-12-14, at 01:39, Glen Zorn 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 > Section 3.1 says: >=20 > o Permit RADIUS authentication and accounting replies from RADIUS > servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: > DB8:100::10 that are listening on UDP ports 1645 and 1646. Note > that this doesn't account for a server using Internet Assigned > Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. >=20 > So, in other words, RADIUS traffic on the ports (officially assigned = for > more than ten years now) will be blocked. This seems like a very poor > example. This is a cisco-ism -- cisco devices use 1645/1646 by default and have = to be configured explicitly to use 1812/1813. I think this should be = changed, as you intimate. Good catch. Joe= From rodunn@cisco.com Tue Dec 14 06:15: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 EB33E3A6E9E; Tue, 14 Dec 2010 06:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXZEwUdhzuRK; Tue, 14 Dec 2010 06:15:03 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id DB68B3A6E94; Tue, 14 Dec 2010 06:15:02 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oBEEGemQ026826; Tue, 14 Dec 2010 09:16:40 -0500 (EST) Received: from dhcp-64-102-157-231.cisco.com (dhcp-64-102-157-231.cisco.com [64.102.157.231]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oBEEGdRt024112; Tue, 14 Dec 2010 09:16:39 -0500 (EST) Message-ID: <4D077C47.4010506@cisco.com> Date: Tue, 14 Dec 2010 06:16:39 -0800 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Abley References: <001201cb9b59$acd02d70$06708850$@net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, secdir@ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 14:15:04 -0000 Thanks Joe/Glen, I made the updates to change them to 1812/1813 with a not to the reference to the 1645/1646 ports. "Permit RADIUS authentication and accounting replies from RADIUS servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001:DB8:100::10 that are listening on UDP ports 1812 and 1813. Note that this doesn't account for a server using the commonly deployed pre-standard UDP ports of 1812 and 1813." Also updated the relevant configurations. Rodney On 12/14/10 5:25 AM, Joe Abley wrote: > > On 2010-12-14, at 01:39, Glen Zorn 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. >> >> Section 3.1 says: >> >> o Permit RADIUS authentication and accounting replies from RADIUS >> servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001: >> DB8:100::10 that are listening on UDP ports 1645 and 1646. Note >> that this doesn't account for a server using Internet Assigned >> Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. >> >> So, in other words, RADIUS traffic on the ports (officially assigned for >> more than ten years now) will be blocked. This seems like a very poor >> example. > > This is a cisco-ism -- cisco devices use 1645/1646 by default and have to be configured explicitly to use 1812/1813. I think this should be changed, as you intimate. Good catch. > > > Joe From jabley@hopcount.ca Tue Dec 14 06:24:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39B43A6FA4; Tue, 14 Dec 2010 06:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUYKXQij9q7F; Tue, 14 Dec 2010 06:24:56 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 08FBE3A6FA0; Tue, 14 Dec 2010 06:24:56 -0800 (PST) Received: from [199.212.90.26] (helo=dh26.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PSVtP-000Gdz-T2; Tue, 14 Dec 2010 14:30:17 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4D077C47.4010506@cisco.com> Date: Tue, 14 Dec 2010 09:26:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5C11F4B2-00A9-4C5C-BA19-417756547632@hopcount.ca> References: <001201cb9b59$acd02d70$06708850$@net> <4D077C47.4010506@cisco.com> To: rodunn@cisco.com X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.26 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, secdir@ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 14:24:56 -0000 On 2010-12-14, at 09:16, Rodney Dunn wrote: > Thanks Joe/Glen, >=20 > I made the updates to change them to 1812/1813 with a not to the = reference to the 1645/1646 ports. >=20 > "Permit RADIUS authentication and accounting replies from RADIUS = servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and = 2001:DB8:100::10 that are listening on UDP ports 1812 and 1813. Note = that this doesn't account for a server using the commonly deployed = pre-standard UDP ports of 1812 and 1813." I think you mean "1645 and 1646" in the final sentence. I would also drop "commonly deployed" since I think the phrase is = subjective and difficult to qualify, and replace "account for" with = "accommodate" since one of the ports you're opening a hole for is for = accounting and different uses of the same word seems worth avoiding = (e.g. for non-English speakers). Joe From rodunn@cisco.com Tue Dec 14 06:42: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 D30BA3A6DA9; Tue, 14 Dec 2010 06:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXqtfMyw9xxl; Tue, 14 Dec 2010 06:42:49 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id E6B1C3A6D9D; Tue, 14 Dec 2010 06:42:48 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oBEEiQv7029591; Tue, 14 Dec 2010 09:44:26 -0500 (EST) Received: from dhcp-64-102-157-231.cisco.com (dhcp-64-102-157-231.cisco.com [64.102.157.231]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oBEEiQW4006927; Tue, 14 Dec 2010 09:44:26 -0500 (EST) Message-ID: <4D0782CA.5080403@cisco.com> Date: Tue, 14 Dec 2010 06:44:26 -0800 From: Rodney Dunn Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Abley References: <001201cb9b59$acd02d70$06708850$@net> <4D077C47.4010506@cisco.com> <5C11F4B2-00A9-4C5C-BA19-417756547632@hopcount.ca> In-Reply-To: <5C11F4B2-00A9-4C5C-BA19-417756547632@hopcount.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, secdir@ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rodunn@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 14:42:49 -0000 Fixed and updated: "Permit RADIUS authentication and accounting replies from RADIUS servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001:DB8:100::10 that are listening on UDP ports 1812 and 1813. Note that this does not accommmodate a server using pre-standard UDP ports of 1645 and 1646." Thanks, Rodney On 12/14/10 6:26 AM, Joe Abley wrote: > > On 2010-12-14, at 09:16, Rodney Dunn wrote: > >> Thanks Joe/Glen, >> >> I made the updates to change them to 1812/1813 with a not to the reference to the 1645/1646 ports. >> >> "Permit RADIUS authentication and accounting replies from RADIUS servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and 2001:DB8:100::10 that are listening on UDP ports 1812 and 1813. Note that this doesn't account for a server using the commonly deployed pre-standard UDP ports of 1812 and 1813." > > I think you mean "1645 and 1646" in the final sentence. > > I would also drop "commonly deployed" since I think the phrase is subjective and difficult to qualify, and replace "account for" with "accommodate" since one of the ports you're opening a hole for is for accounting and different uses of the same word seems worth avoiding (e.g. for non-English speakers). > > > Joe > From rbonica@juniper.net Tue Dec 14 08:05: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 AAC0E3A6FB6; Tue, 14 Dec 2010 08:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.371 X-Spam-Level: X-Spam-Status: No, score=-106.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNMomtGCJQl1; Tue, 14 Dec 2010 08:05:22 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 6CD323A6FB1; Tue, 14 Dec 2010 08:05:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTQeWI2ERhf8cgx5efC5imKjabrj1oyQP@postini.com; Tue, 14 Dec 2010 08:07:03 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 14 Dec 2010 08:04:26 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 14 Dec 2010 11:04:26 -0500 From: Ronald Bonica To: Sean Turner , Glen Zorn , "draft-ietf-opsec-protect-control-plane@tools.ietf.org" Date: Tue, 14 Dec 2010 11:04:25 -0500 Thread-Topic: secdir review of draft-ietf-opsec-protect-control-plane-04 Thread-Index: Acubpr/14Cwlsd7NSeGL8pAU0+7LHwAAaimQ Message-ID: <13205C286662DE4387D9AF3AC30EF456B02F2A46AC@EMBX01-WF.jnpr.net> References: <001201cb9b59$acd02d70$06708850$@net> <4D07926A.9030007@ieca.com> In-Reply-To: <4D07926A.9030007@ieca.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: Wed, 15 Dec 2010 00:36:03 -0800 Cc: "opsec-chairs@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:05:23 -0000 Authors, I think that we can correct this problem with an RFC editors note before th= e telechat on Thursday. Could one of you please provide the updated text? Ron > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Tuesday, December 14, 2010 10:51 AM > To: Glen Zorn; draft-ietf-opsec-protect-control-plane@tools.ietf.org > Cc: opsec-chairs@tools.ietf.org; iesg@ietf.org; secdir@ietf.org > Subject: Re: secdir review of draft-ietf-opsec-protect-control-plane-04 >=20 > I hoping that this was a typo. I pulled out all the registered RADIUS > ports from http://www.iana.org/assignments/port-numbers and 1645/1646: >=20 > sightline 1645/tcp SightLine > sightline 1645/udp SightLine > # admin > sa-msg-port 1646/tcp sa-msg-port > sa-msg-port 1646/udp sa-msg-port > # Eric Whitehill >=20 >=20 > radius 1812/tcp RADIUS > radius 1812/udp RADIUS > # [RFC2865] > radius-acct 1813/tcp RADIUS Accounting > radius-acct 1813/udp RADIUS Accounting > # [RFC2866] > radsec 2083/tcp Secure Radius Service > radsec 2083/udp Secure Radius Service > # Mike McCauley May 2005 > radius-dynauth 3799/tcp RADIUS Dynamic Authorization > radius-dynauth 3799/udp RADIUS Dynamic Authorization > # RFC 3576 - July 2003 >=20 > Should 1812 & 1813 be listed or also 2083 & 3799? >=20 > spt >=20 > On 12/14/10 1:39 AM, Glen Zorn 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. > > > > Section 3.1 says: > > > > o Permit RADIUS authentication and accounting replies from > RADIUS > > servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and > 2001: > > DB8:100::10 that are listening on UDP ports 1645 and 1646. > Note > > that this doesn't account for a server using Internet Assigned > > Numbers Authority (IANA) ports 1812 and 1813 for RADIUS. > > > > So, in other words, RADIUS traffic on the ports (officially assigned > for > > more than ten years now) will be blocked. This seems like a very > poor > > example. > > > > > > > > From jabley@hopcount.ca Tue Dec 14 08:53: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 3D3E128C0F9; Tue, 14 Dec 2010 08:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6tT-mirAnus; Tue, 14 Dec 2010 08:53:09 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 7AD6428B797; Tue, 14 Dec 2010 08:53:09 -0800 (PST) Received: from [199.212.90.26] (helo=dh26.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PSYD0-000LS2-PY; Tue, 14 Dec 2010 16:58:39 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <9B0EE2FE-9DCB-4F52-8515-F30050DF46F8@cisco.com> Date: Tue, 14 Dec 2010 11:54:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1958D397-8B8F-4046-A976-46AEC67EA214@hopcount.ca> References: <001201cb9b59$acd02d70$06708850$@net> <9B0EE2FE-9DCB-4F52-8515-F30050DF46F8@cisco.com> To: Carlos Pignataro (cpignata) X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 199.212.90.26 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, secdir@ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 16:53:10 -0000 On 2010-12-14, at 11:43, Carlos Pignataro (cpignata) wrote: > Please note that this was intentional, as a doc produced in Opsec we = intended to make it as close to the operational reality we know as = possible. And our perspective was that we see more 1645/1646.=20 I understand that's your perspective, which is entirely understandable = given what cisco devices do by default, but I don't think it's = necessarily the case that 1645/1646 are universally prevalent (at least, = claims that it is ought to be balanced with some balanced, real-world = observation). I take your point that juniper devices accommodate the = pre-standard ports as well as the IANA-assigned ones. There are more = vendors in the world than just C and J, however. I think pointing out that 1645/1646 are also used is perfectly valid, = for the reasons of operational reality that you mention, but that the = examples should use 1812/1813. Joe From david.i.allan@ericsson.com Tue Dec 14 09:05: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 C93BA28C0DC; Tue, 14 Dec 2010 09:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 jtvFKla8sfuj; Tue, 14 Dec 2010 09:05:06 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 22C6628C0DB; Tue, 14 Dec 2010 09:05:06 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oBEH6cMt011713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Dec 2010 11:06:44 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 14 Dec 2010 12:06:40 -0500 From: David Allan I To: Vincent Roca , "secdir@ietf.org" , "iesg@ietf.org" Date: Tue, 14 Dec 2010 12:06:39 -0500 Thread-Topic: SecDir review of draft-ietf-mpls-tp-oam-framework-09 Thread-Index: Acubf7u2LtRaZBydSAGC5u99SpErPAAL3XbQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD51CB7F4CE2@EUSAACMS0703.eamcs.ericsson.se> References: <4D0750C1.5090304@inrialpes.fr> In-Reply-To: <4D0750C1.5090304@inrialpes.fr> 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: Wed, 15 Dec 2010 00:36:03 -0800 Cc: "draft-ietf-mpls-tp-oam-framework.all@tools.ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-tp-oam-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: Tue, 14 Dec 2010 17:05:07 -0000 HI Vincent: Thank you for the detailed read of the section and your comments.... There are a couple of problems associated with the volume of SAs required = that IMO there is no obvious way to mitigate... The primary example that comes to mind is fault management... 1) Heartbeats are running between LSP endpoints at a an interval as low as = 3.3msec interval. The number of SAs is bounded but applying some form of cr= ypto per-packet authentication would just about melt any existing implement= ation. This discussion has already come up independently in the BFD WG w.r.= t. the authentication option. 2) Applying authentication to the generation of notification messages from = intermediate nodes in the path means the number of SAs goes up in direct pr= oprotion to the number of hops in the path length of each LSP if the SAs ar= e to be established prior to actually being required in the interest of tim= ely generation of notifications. Negotiating the establishment of each SA o= n the fly would appear to add significant delays in what is supposed to be = an instantaneous network response so does not appear to be a practical opti= on for reducing the scaling impact of maintaining a full set of SAs for all= eventualities... Now we probably overstate the case for crypto in the section (reference to = password exchange) and will edit accordingly. What we are exchanging is sta= te about the operational status of a given entity with a minimum of authent= ication/non-repudiation exclusively on internal links to a network. If a ma= licious party is able to tap into one of those links they would be able to = insert or modify transactions./messages as to mask the true state of the ne= twork.=20 SO on the basis of the above any suggestions as to how the section can be i= mproved would be welcome. BTW thanks for pointing out that man in the middl= e has a more specific context that our usage, we will edit accordingly. Cheers Dave -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]=20 Sent: Tuesday, December 14, 2010 3:11 AM To: secdir@ietf.org; iesg@ietf.org Cc: vincent.roca@inrialpes.fr; draft-ietf-mpls-tp-oam-framework.all@tools.i= etf.org Subject: SecDir review of draft-ietf-mpls-tp-oam-framework-09 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 com= ments 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 Security Considerations section of this I-D is fairly strange. The authors first highlight that OAM traffic contains sensitive data (like = passwords), and then quickly conclude that securing this traffic is impossi= ble and therefore they require that the network be physically secured. The = reason provided is the fact that there are too many entities that are likel= y to communicate to establish and maintain SAs between them. Well, I don't know the specificities of MPLS networks, nor the OAM operatio= ns in MPLS networks, however: 1- I need more information to be convinced that there is indeed no other solution than requiring that the whole physical network be totally secured; 2- I need more information to be convinced that fully securing such a physical network is feasible; Honestly speaking I'm not convinced by 1-. What about solutions based on te= mporary SA? Are the OAM exchanges so frequent to require that each secure c= onnection be maintained all the time? Would a solution that establishes tho= se connections on-the-fly, when needed, be realistic? Another direction cou= ld be to use shared keys between the entities of a group. Or perhaps using = a per-packet signature approach is feasible, using some public key infrastr= ucture, if the exchanges are infrequent. There are probably other IETF prot= ocols that have similar requirements. What about the KARP WG that focuses o= n secure routing protocols? May some ideas be borrowed and applied here (th= at's a fully open question)? Concerning 2-, a quick search on "MPLS attacks" on the web provides a small= number of references. There's also a book on the subject ("Analyzing MPLS = VPN Security", M. H. Behringer, M. Morrow, Cisco Press, 2005). I don't know= n the domain at all but I'd like to be convinced that 2- is feasible. A minor comment. I have the feeling that the authors use the term "man-in-the-middle attack"= to denote any attack where the attacker takes control of the physical infr= astructure. That's not an appropriate use and this term refers to a very sp= ecific attack (e.g. see http://en.wikipedia.org/wiki/Man-in-the-middle_atta= ck). I hope these comments are useful. Regards, Vincent From robert.cragie@gridmerge.com Tue Dec 14 09:23: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 023753A6F9B; Tue, 14 Dec 2010 09:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TASmqU9lJpX; Tue, 14 Dec 2010 09:23:48 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 1449E3A6EB8; Tue, 14 Dec 2010 09:23:48 -0800 (PST) Received: from client-86-31-167-78.oxfd.adsl.virginmedia.com ([86.31.167.78] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PSYci-0002XM-Lv; Tue, 14 Dec 2010 17:25:13 +0000 Message-ID: <4D07A874.4010702@gridmerge.com> Date: Tue, 14 Dec 2010 17:25:08 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alan DeKok References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> In-Reply-To: <4D064683.30009@deployingradius.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000407040602030407080206" X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 17:23:50 -0000 This is a cryptographically signed message in MIME format. --------------ms000407040602030407080206 Content-Type: multipart/alternative; boundary="------------060604030107060404050904" This is a multi-part message in MIME format. --------------060604030107060404050904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alan, Thank you for your review of the PANA relay draft. Sorry for the late=20 reply - I was busy last week (actually testing PANA relay). In response=20 to some of your points: * I agree with the notion of enforcing the relay to only process valid PANA messages and only send valid PANA messages. The fact it is a functionally-defined relay (as opposed to a generic IP tunnel) means that we can do this. Therefore we need to add text as you suggest. * I am less sure of the need for a token. As far as I can see, the token would only protect the immutable information in the data sent from PRE to PAA, i.e. the IP address and the port. This has some benefit but would not necessarily prevent a rogue PAA sending a bogus encapsulated frame. Using DTLS between PRE and PAA would provide protection for the whole packet, possibly including encryption. Using a PANA SA would provide better protection than a PRE-originated token. Using L2 security also provides a 'walled garden' protection. It seems to me possible for a rogue node to send any packet to any port on a node which is accessible at the link layer provided one knows its address and assumes no L2 security therefore I don't again see this as an additional threat Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 13/12/2010 4:14 PM, Alan DeKok wrote: > Alper Yegin wrote: >> Arbitrary traffic cannot pass the validation on the PaC, as the sequen= ce >> numbers need to match. And there is also state machine match needed. P= aC's >> is in certain state and would not react to any arbitrary message unles= s the >> message is expected in the current state. > If the traffic is sent to the PANA port used by the PaC. The traffi= c > *can* be sent to other ports. As it stands today, the draft doesn't > appear to prevent this. > > The idea of the token is to add limited state to the PRE. It will > only send messages that are (a) valid PANA messages, (b) to the IP of a= > PaC, and (c) to the port used by the PaC used to send PANA messages. > > Using DTLS in between the PRE and PAA would achieve the same effect.= > The possibility of a rogue PAA is removed, so no token is required. > > Alan DeKok. > --------------060604030107060404050904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alan,

Thank you for your review of the PANA relay draft. Sorry for the late reply - I was busy last week (actually testing PANA relay). In response to some of your points:

  • I agree with the notion of enforcing the relay to only process valid PANA messages and only send valid PANA messages. The fact it is a functionally-defined relay (as opposed to a generic IP tunnel) means that we can do this. Therefore we need to add text as you suggest.
  • I am less sure of the need for a token. As far as I can see, the token would only protect the immutable information in the data sent from PRE to PAA, i.e. the IP address and the port. This has some benefit but would not necessarily prevent a rogue PAA sending a bogus encapsulated frame. Using DTLS between PRE and PAA would provide protection for the whole packet, possibly including encryption. Using a PANA SA would provide better protection than a PRE-originated token. Using L2 security also provides a 'walled garden' protection. It seems to me possible for a rogue node to send any packet to any port on a node which is accessible at the link layer provided one knows its address and assumes no L2 security therefore I don't again see this as an additional threat
Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 13/12/2010 4:14 PM, Alan DeKok wrote:
Alper Yegin wrote:
Arbitrary traffic cannot pass the validation on th=
e PaC, as the sequence
numbers need to match. And there is also state machine match needed. PaC'=
s
is in certain state and would not react to any arbitrary message unless t=
he
message is expected in the current state.
  If the traffic is sent to the PANA port used by th=
e PaC.  The traffic
*can* be sent to other ports.  As it stands today, the draft doesn't
appear to prevent this.

  The idea of the token is to add limited state to the PRE.  It will
only send messages that are (a) valid PANA messages, (b) to the IP of a
PaC, and (c) to the port used by the PaC used to send PANA messages.

  Using DTLS in between the PRE and PAA would achieve the same effect.
The possibility of a rogue PAA is removed, so no token is required.

  Alan DeKok.

--------------060604030107060404050904-- --------------ms000407040602030407080206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMjE0MTcyNTA4WjAjBgkqhkiG9w0BCQQxFgQUW5/E S321ZTAdLQyRMgITDFQ/IOMwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAYx+5PudPLKhaQ4yaY/02yVZmvC/O30VWuJkK HnuWeurHE/z13x1YqQ9yjtFiq9pMyEKxVWV2aK3zTJn0Jg3XqlqwfmtBkpEEZM/TK5YzU/Wy ZwBzdCM1SrMgD9XwMaZ9hVgxdpu7B7FwdU7RyA9KnePdgmy/Sgx6MVOeZSOFNR+2CSRNsNt/ H4Ht0RnFvWaL1YRRdxYAQy5Lpk83xeE8AQHzTgb+LElVGh0RUGH4V7ourcs4Tti7bfbGOS21 NjKWp7mTbn+yex4cUdTx+QKzrwxFVOmAZzcUEgmE8YJc69HV+KKGQh0S3rfj/qP54NUbFgqm obwSLej/ekGV8jLjWwAAAAAAAA== --------------ms000407040602030407080206-- From cheshire@apple.com Tue Dec 14 16:10: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 4A6A83A6E13; Tue, 14 Dec 2010 16:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hw-x0RhUzqfZ; Tue, 14 Dec 2010 16:10:53 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id AE7B83A6E0E; Tue, 14 Dec 2010 16:10:50 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 0BA59C41605A; Tue, 14 Dec 2010 16:12:32 -0800 (PST) X-AuditID: 11807134-b7c51ae000005439-6c-4d0807ef0974 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay14.apple.com (Apple SCV relay) with SMTP id C5.85.21561.FE7080D4; Tue, 14 Dec 2010 16:12:31 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDG00EI10KU8710@gertie.apple.com>; Tue, 14 Dec 2010 16:12:30 -0800 (PST) In-reply-to: <20101101094624.GC29846@elstar.local> References: <20101101094624.GC29846@elstar.local> Message-id: <4EB6E265-450D-41C8-AD98-0665274F7E8C@apple.com> From: Stuart Cheshire Date: Tue, 14 Dec 2010 16:12:37 -0800 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:02 -0800 Cc: draft-cheshire-dnsext-nbp.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-cheshire-dnsext-nbp-09.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, 15 Dec 2010 00:10:59 -0000 On 1 Nov 2010, at 2:46 AM, Juergen Schoenwaelder wrote: > On page 9, the DNS name "printer1.ietf.org" should probably changed > to "printer1.example.com". We'll update the example in the document, but I have a question: RFC 2606 states that names like example.com "can be used as examples". I agree that when writers *want* to use a vendor-neutral example it's useful to have these names available, but are they mandatory? Is there an RFC which states that *all* examples MUST use example.com? I've been seeing this a lot recently. Any time someone uses an example name other than the RFC 2606 example names, people leap on them and tell them this is not allowed and all RFCs have to use only the RFC 2606-sanctioned example names. Is this true? There's a big difference between saying "these names are available for use if you want" and "these names are mandatory and you're not allowed to use any others". Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Tue Dec 14 19:08: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 9B4DF28C0F3; Tue, 14 Dec 2010 19:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.849 X-Spam-Level: X-Spam-Status: No, score=-106.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8rfrKs64hvC; Tue, 14 Dec 2010 19:08:20 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 1833B28C13B; Tue, 14 Dec 2010 19:08:20 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id CABCDBFA61A3; Tue, 14 Dec 2010 19:10:01 -0800 (PST) X-AuditID: 1180711d-b7c30ae0000055b4-48-4d0831899829 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id B8.C5.21940.981380D4; Tue, 14 Dec 2010 19:10:01 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Received: from [10.0.1.201] ([173.164.252.149]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDG00JPJ8SPNW60@elliott.apple.com>; Tue, 14 Dec 2010 19:10:01 -0800 (PST) In-reply-to: References: Message-id: Content-transfer-encoding: quoted-printable From: Stuart Cheshire Date: Tue, 14 Dec 2010 19:10:09 -0800 To: Donald Eastlake X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Cc: IETF Discussion , secdir@ietf.org Subject: Re: [secdir] draft-cheshire-dnsext-multicastdns-12.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, 15 Dec 2010 03:08:22 -0000 On 30 Nov 2010, at 9:13 AM, Donald Eastlake wrote: > I would suggest that the first word of Section 20, currently "The", =20= > should be replaced by "A major" or "One of the" or the like. Agreed. The document now says: Multicast DNS shares, as much as possible, the familiar APIs, naming syntax, resource record types, etc., of Unicast DNS. > For consistency with RFC 5395, all occurrences of "pseudo-RR" =20 > should be replace with "meta-RR" dictionary.reference.com says: > meta > > A prefix meaning one level of description higher. If X is some =20 > concept then meta-X is data about, or processes operating on, X. =20 > For example, a metasyntax is syntax for specifying syntax, =20 > metalanguage is a language used to discuss language, meta-data is =20 > data about data, and meta-reasoning is reasoning about reasoning. Is that what you mean? A "meta resource record" is a "resource record =20= about resource records". The term "pseudo-RR" means: =93false=94, =93pretended=94 or =93unreal=94. In this context the text is referring to any apparent RR in the =20 packet that's not really an RR, not solely to RRs that describe other =20= RRs. > it would not hurt to add a reference to RFC 5395 Where would you like this reference to appear? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From abegen@cisco.com Tue Dec 14 20:51: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 D089E3A6DB0; Tue, 14 Dec 2010 20:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 fWkcT4+q3Bz0; Tue, 14 Dec 2010 20:51:33 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2CF7F3A6DA6; Tue, 14 Dec 2010 20:51:33 -0800 (PST) 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: AvsEAHvYB02rR7Hu/2dsb2JhbACkHHildpspgwyCPgSEZIkzgmw X-IronPort-AV: E=Sophos;i="4.59,346,1288569600"; d="scan'208";a="636141178" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Dec 2010 04:53:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBF4r8qE016055; Wed, 15 Dec 2010 04:53:08 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Dec 2010 20:53:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Dec 2010 20:52:33 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2E71E@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SecDir review of draft-ietf-avt-rtcp-port-for-ssm-03 Thread-Index: AcucCsoHK8IBnbXESLyDlHdrL0fz+AACEB8A References: From: "Ali C. Begen (abegen)" To: "Donald Eastlake" , , , "Keith Drage" , "Roni Even" X-OriginalArrivalTime: 15 Dec 2010 04:53:08.0666 (UTC) FILETIME=[F7D871A0:01CB9C13] X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Subject: Re: [secdir] SecDir review of draft-ietf-avt-rtcp-port-for-ssm-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, 15 Dec 2010 04:51:35 -0000 Hi Donald, Thanks for the review. > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Tuesday, December 14, 2010 10:47 PM > To: secdir@ietf.org; iesg@ietf.org; Ali C. Begen (abegen); Keith = Drage; Roni Even > Subject: SecDir review of draft-ietf-avt-rtcp-port-for-ssm-03 >=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. Document editors and WG chairs should treat these comments just > like any other last call comments. >=20 > This draft specifies the addition of a new SDP attribute. This > attribute does not appear to present any new type of security > vulnerability. >=20 > I believe the Security Considerations section needs a small addition > to avoid being too vague. It currently just says "Therefore, as usual > adequate security measures are RECOMMENDED ..." without giving any > hint as to what those measures are or where to find any. Admittedly, > this draft is an update to RFC 5760 and a reasonable non-exclusive > list of such measures occurs in that RFC. Nevertheless, I would be > much more comfortable if the Security Considerations section wording > was augmented so it said "Therefore, adequate security measures, such > as those listed in the Security Considerations section of [RFC5760], > are RECOMMENDED...". Based on other reviews and discussing with the AD, we went one step = further and the sentence above is replaced with: =20 "In order to avoid attacks of this sort, the SDP description needs to be = integrity protected and provided with source authentication. This can, = for example, be achieved on an end-to-end basis using S/MIME RFC5652 = when SDP is used in a signaling packet using MIME types = (application/sdp). Alternatively, HTTPS RFC2818 or the authentication = method in the Session Announcement Protocol (SAP) RFC2974 could be used = as well." > Trivia: >=20 > The following sentence: > "The formal description of the 'multicast-rtcp' attribute is = defined > by the following ABNF [RFC5234] syntax:" > somehow reads as sort of redundantly redundant. Maybe: "The following > ABNF [RFC5234] syntax formally describes the 'multicast-rtcp' > attribute:" Sounds good. Cheers, acbegen. =20 > Thanks, > Donald > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0d3e3e3@gmail.com From robert.cragie@gridmerge.com Wed Dec 15 00:21:27 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42E43A6F61; Wed, 15 Dec 2010 00:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqjlLh3Ov3xe; Wed, 15 Dec 2010 00:21:26 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 653BA3A6E46; Wed, 15 Dec 2010 00:21:24 -0800 (PST) Received: from client-86-31-167-78.oxfd.adsl.virginmedia.com ([86.31.167.78] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PSmdN-0002KP-Is; Wed, 15 Dec 2010 08:22:50 +0000 Message-ID: <4D087AD5.8020901@gridmerge.com> Date: Wed, 15 Dec 2010 08:22:45 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alan DeKok References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> In-Reply-To: <4D07D090.9020407@deployingradius.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010002030800010202000003" X-Mailman-Approved-At: Wed, 15 Dec 2010 00:36:03 -0800 Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 08:21:27 -0000 This is a cryptographically signed message in MIME format. --------------ms010002030800010202000003 Content-Type: multipart/alternative; boundary="------------030102030405030900010307" This is a multi-part message in MIME format. --------------030102030405030900010307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alan, Thanks for your response. Some further comments below, bracketed by=20 . In summary, I think there are two security considerations in addition to = the other text already proposed which need to be addressed: 1. The PRE, as a protocol-aware relay, MUST only relay PRY messages and MUST only accept valid PANA messages 2. The use of a PRE causes additional state at the PAA (IP address and port of PRE) which may need to be stored Whilst the language Alper has used so far is probably sufficient, I do=20 think that it is important to strenuously recommended that the PRE-PAA=20 connection is secured using either DTLS, PANA SA or L2 protection; Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 14/12/2010 8:16 PM, Alan DeKok wrote: > Robert Cragie wrote: >> * I agree with the notion of enforcing the relay to only process >> valid PANA messages and only send valid PANA messages. The fact= it >> is a functionally-defined relay (as opposed to a generic IP >> tunnel) means that we can do this. Therefore we need to add tex= t >> as you suggest. > Thanks. > >> * I am less sure of the need for a token. As far as I can see, th= e >> token would only protect the immutable information in the data >> sent from PRE to PAA, i.e. the IP address and the port. This ha= s >> some benefit but would not necessarily prevent a rogue PAA send= ing >> a bogus encapsulated frame. > It would *authenticate* the data sent from the PAA to the PRE. This= > authentication would ensure that the PAA could only respond to packets > sent by the PRE. Unless I am missing something, a token generated and validated by=20 the PRE could only authenticate the immutable parts of the PRY, i.e. the = PaC-Information AVP. You would need a full security association between=20 PRE and PAA to authenticate different messages in both directions. > As I said earlier, this would ensure that a rogue PAA can only (a) > send PANA messages, to (b) the IP of the PaC, and (c) the port of the > PaC used to send PANA messages. It would prevent a rogue PAA from > sending a non-PANA frame to arbitrary non-PANA IPs and ports. The use of a token doesn't enforce (a) but the PRE can check for=20 (a) in the scope of PANA as a transport. I agree it does enforce (b) and = (c). The question is whether the additional effort is worth it on the=20 basis that considering a PaC-PAA communication, the IP address and port=20 may not be protected either and PANA doesn't require it at the moment. >> Using DTLS between PRE and PAA would >> provide protection for the whole packet, possibly including >> encryption. > It's not per-packet protection. It's that the PRE will only accept= > frames from the PAA that have been authenticated via TLS. Agreed - that's essentially what I meant; perhaps I used the wrong=20 language. >> Using a PANA SA would provide better protection than a >> PRE-originated token. Using L2 security also provides a 'walled= >> garden' protection. It seems to me possible for a rogue node to= >> send any packet to any port on a node which is accessible at th= e >> link layer provided one knows its address and assumes no L2 >> security therefore I don't again see this as an additional thre= at > The document clearly states that the PRE is proxying packets because= > the PAA can not otherwise route traffic to the PaC. Security between > the PAA and PRE is *required* to prevent rogue PAAs from causing the PR= E > to route traffic to the PaC. I agree it is required to prevent rogue PAAs from causing the PRE=20 to route traffic. It would seem the debate is about whether we have to=20 mandate this for PRE-PAA in general as PANA, as a transport, does not=20 require it. > One view could be that the PaC is already vulnerable to rogue PAAs o= n > the local network. That local network may, however, be limited in the > number of systems, and what they're allowed to do. My presumption is > that the PRE to PAA network is a fully-connected network capable of > routing to arbitrary destinations. > > So adding a PRE opens the PaC to attacks from arbitrary sources on a= > wide-area network, which would seem to be a violation of the PANA > assumptions. That is true. However, I think Alper's point is that an equivalent=20 MiTM router on a wider network in the vicinity of the PaC could still be = the target for a rogue PAA and that the PRE model was really no=20 different. So this doesn't necessarily pose an *additional* threat.= > Alan DeKok. > --------------030102030405030900010307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alan,

Thanks for your response. Some further comments below, bracketed by <RCC></RCC>.

In summary, I think there are two security considerations in addition to the other text already proposed which need to be addressed:

  1. The PRE, as a protocol-aware relay, MUST only relay PRY messages and MUST only accept valid PANA messages
  2. The use of a PRE causes additional state at the PAA (IP address and port of PRE) which may need to be stored
Whilst the language Alper has used so far is probably sufficient, I do think that it is important to strenuously recommended that the PRE-PAA connection is secured using either DTLS, PANA SA or L2 protection;

Robert

On 14/12/2010 8:16 PM, Alan DeKok wrote:
Robert Cragie wrote:
    * I agree with the notion of enforcing the rel=
ay to only process
      valid PANA messages and only send valid PANA messages. The fact it
      is a functionally-defined relay (as opposed to a generic IP
      tunnel) means that we can do this. Therefore we need to add text
      as you suggest.
  Thanks.

    * I am less sure of the need for a token. As f=
ar as I can see, the
      token would only protect the immutable information in the data
      sent from PRE to PAA, i.e. the IP address and the port. This has
      some benefit but would not necessarily prevent a rogue PAA sending
      a bogus encapsulated frame.
  It would *authenticate* the data sent from the PAA to the PRE.  This
authentication would ensure that the PAA could only respond to packets
sent by the PRE.
<RCC>Unless I am missing something, a token generated and validated by the PRE could only authenticate the immutable parts of the PRY, i.e. the PaC-Information AVP. You would need a full security association between PRE and PAA to authenticate different messages in both directions.</RCC>
  As I said earlier, this would ensure that a rogue PAA can only (a)
send PANA messages, to (b) the IP of the PaC, and (c) the port of the
PaC used to send PANA messages.  It would prevent a rogue PAA from
sending a non-PANA frame to arbitrary non-PANA IPs and ports.
<RCC>The use of a token doesn't enforce (a) but the PRE can check for (a) in the scope of PANA as a transport. I agree it does enforce (b) and (c). The question is whether the additional effort is worth it on the basis that considering a PaC-PAA communication, the IP address and port may not be protected either and PANA doesn't require it at the moment.</RCC>

      
 Using DTLS between PRE and PAA would
      provide protection for the whole packet, possibly including
      encryption.
   It's not per-packet protection.  It's that the PRE will only accept
frames from the PAA that have been authenticated via TLS.
<RCC>Agreed - that's essentially what I meant; perhaps I used the wrong language.</RCC>

      
Using a PANA SA would provide better protection th=
an a
      PRE-originated token. Using L2 security also provides a 'walled
      garden' protection. It seems to me possible for a rogue node to
      send any packet to any port on a node which is accessible at the
      link layer provided one knows its address and assumes no L2
      security therefore I don't again see this as an additional threat
  The document clearly states that the PRE is proxying packets because
the PAA can not otherwise route traffic to the PaC.  Security between
the PAA and PRE is *required* to prevent rogue PAAs from causing the PRE
to route traffic to the PaC.
<RCC>I agree it is required to prevent rogue PAAs from causing the PRE to route traffic. It would seem the debate is about whether we have to mandate this for PRE-PAA in general as PANA, as a transport, does not require it.</RCC>
  One view could be that the PaC is already vulnerable to rogue PAAs on
the local network.  That local network may, however, be limited in the
number of systems, and what they're allowed to do.  My presumption is
that the PRE to PAA network is a fully-connected network capable of
routing to arbitrary destinations.

  So adding a PRE opens the PaC to attacks from arbitrary sources on a
wide-area network, which would seem to be a violation of the PANA
assumptions.
<RCC>That is true. However, I think Alper's point is that an equivalent MiTM router on a wider network in the vicinity of the PaC could still be the target for a rogue PAA and that the PRE model was really no different. So this doesn't necessarily pose an *additional* threat.</RCC>
  Alan DeKok.

--------------030102030405030900010307-- --------------ms010002030800010202000003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMjE1MDgyMjQ1WjAjBgkqhkiG9w0BCQQxFgQUoKqc EKDAl750YKMzF0EnhDyxxLQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEASq0KRql1fS5y3dkyCcSb2YkgQe2awpczNftt 3gTC3zCIlnU/oHU7nvFP9SX2wMx8zxTn3pRWm97kC+NblbUmTb8IGM4xRD8q99/GdGFJKJpG CBq7cUKqBWq1v9UuGk/IRZEIzEOyISzASeI5x3KCBP9kj3OVHFlhOTxGTq7E1etiYLsVdIP7 xHDslTVTstQ3hu+t6mn+zIih7o1LOPe8gI5QNif7N+aQS3exFi9b0jluZ4TRNfZ+JW/nFaH3 emK9GGgUfxFJ/b1UFCioU+6q8bPAOjXOJZ1lXS/RiNc0YwNjLTyjzFfrNDjBJ+4xJDDpbiXh 7nQRr2VuXJp1H6hvWAAAAAAAAA== --------------ms010002030800010202000003-- From d3e3e3@gmail.com Wed Dec 15 01:01: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 6405B3A6F72; Wed, 15 Dec 2010 01:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.267 X-Spam-Level: X-Spam-Status: No, score=-103.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jljUEjMzdxhX; Wed, 15 Dec 2010 01:01:29 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 235C13A6F55; Wed, 15 Dec 2010 01:01:29 -0800 (PST) Received: by qyj19 with SMTP id 19so1752217qyj.10 for ; Wed, 15 Dec 2010 01:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=8LMatZkftJWgCNQfauPCHS5/ojE+eBEaRJ9FfoYc85M=; b=p91Lkdqitb5E14rQrGcJtibc4X+CXCK8R6X6+eRZi3MGcFhlmjWmWhqxBUAKOIu4C1 wcuUHiYB7T76InzEjPYLmJTWOmlZ0iJVGEw06NqNukSaNwGrYbeblIz9z2PXWDVM6pnA CH1NGo0fhm8NfbB+ewyjDYiknkuAgHEDoco1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=CjZgZccgxennMZ7sEOt+2UXixc2hw6VAGDjwsbFvng2x5gOh+N+AJK+70xsRb6KVX7 wbTpX/Adnc4M7fV4q3OD/yPeYXckttuBmJC6eGPZ6PgmDUEi0TNjgJYZ0fccg38j7ziQ +tYX8sjuOstbTGkG6TmiVE6vZbvPvaBPXmCnw= Received: by 10.224.67.147 with SMTP id r19mr6094760qai.324.1292403789586; Wed, 15 Dec 2010 01:03:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.91.197 with HTTP; Wed, 15 Dec 2010 01:02:49 -0800 (PST) In-Reply-To: <4EB6E265-450D-41C8-AD98-0665274F7E8C@apple.com> References: <20101101094624.GC29846@elstar.local> <4EB6E265-450D-41C8-AD98-0665274F7E8C@apple.com> From: Donald Eastlake Date: Wed, 15 Dec 2010 04:02:49 -0500 Message-ID: To: Stuart Cheshire Content-Type: text/plain; charset=ISO-8859-1 Cc: secdir@ietf.org, draft-cheshire-dnsext-nbp.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-cheshire-dnsext-nbp-09.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, 15 Dec 2010 09:01:30 -0000 As the principle author of 2606, I believe they were intended to be encouraged but not mandatory. For some time there has been an increasingly hardened attitude about this in the IESG and, basically, you won't be allowed to use other names unless there is a good reason a 2606 name won't serve the purpose or possibly if you are doing a minor update version of an existing RFC and don't want to disturb it more than necessary. On Tue, Dec 14, 2010 at 7:12 PM, Stuart Cheshire wrote: > On 1 Nov 2010, at 2:46 AM, Juergen Schoenwaelder wrote: > >> On page 9, the DNS name "printer1.ietf.org" should probably changed to >> "printer1.example.com". Why not make the minimal change and use printer1.example.org? Donald > We'll update the example in the document, but I have a question: > > RFC 2606 states that names like example.com "can be used as examples". I > agree that when writers *want* to use a vendor-neutral example it's useful > to have these names available, but are they mandatory? Is there an RFC which > states that *all* examples MUST use example.com? > > I've been seeing this a lot recently. Any time someone uses an example name > other than the RFC 2606 example names, people leap on them and tell them > this is not allowed and all RFCs have to use only the RFC 2606-sanctioned > example names. Is this true? There's a big difference between saying "these > names are available for use if you want" and "these names are mandatory and > you're not allowed to use any others". > > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org From aland@deployingradius.com Wed Dec 15 02:44: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 EC6C328C15F; Wed, 15 Dec 2010 02:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0prgx1czdcr; Wed, 15 Dec 2010 02:44:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id B96D628C114; Wed, 15 Dec 2010 02:44:30 -0800 (PST) Message-ID: <4D089C73.6050107@deployingradius.com> Date: Wed, 15 Dec 2010 11:46:11 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <4D087AD5.8020901@gridmerge.com> In-Reply-To: <4D087AD5.8020901@gridmerge.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) 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, 15 Dec 2010 10:44:32 -0000 Robert Cragie wrote: > Alan, > > Thanks for your response. Some further comments below, bracketed by > . > > In summary, I think there are two security considerations in addition to > the other text already proposed which need to be addressed: > > 1. The PRE, as a protocol-aware relay, MUST only relay PRY messages > and MUST only accept valid PANA messages > 2. The use of a PRE causes additional state at the PAA (IP address > and port of PRE) which may need to be stored > > Whilst the language Alper has used so far is probably sufficient, I do > think that it is important to strenuously recommended that the PRE-PAA > connection is secured using either DTLS, PANA SA or L2 protection; > Unless I am missing something, a token generated and validated by > the PRE could only authenticate the immutable parts of the PRY, i.e. the > PaC-Information AVP. You would need a full security association between > PRE and PAA to authenticate different messages in both directions. I'm not sure what "different messages" means. My goal was to ensure that rogue PAAs could only send PANA messages to the IP and source port used by a PaC to send PANA messages. I'm not concerned about protecting messages to the PAA. It's already on an open network, and anyone on that network can send any content to any port. So adding PRE to PAA security is useless. i.e. authenticating messages in *both* directions is not the goal of the token. >> So adding a PRE opens the PaC to attacks from arbitrary sources on a >> wide-area network, which would seem to be a violation of the PANA >> assumptions. > That is true. However, I think Alper's point is that an equivalent > MiTM router on a wider network in the vicinity of the PaC could still be > the target for a rogue PAA and that the PRE model was really no > different. So this doesn't necessarily pose an *additional* threat. If the PaC has access to the wider network before it's authenticated, then there is no need for any PRE-PAA token. If the PaC has access to the wider network before it's authenticated, then I'm not really sure why PANA is being used at all. Alan DeKok. From Adrian.Farrel@huawei.com Wed Dec 15 02:50: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 2B54A3A7028; Wed, 15 Dec 2010 02:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CIErephCaIn; Wed, 15 Dec 2010 02:50:12 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 61C553A7021; Wed, 15 Dec 2010 02:50:12 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LDG004LZU6IIP@usaga03-in.huawei.com>; Wed, 15 Dec 2010 04:51:54 -0600 (CST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LDG00DL0U6GRO@usaga03-in.huawei.com>; Wed, 15 Dec 2010 04:51:54 -0600 (CST) Date: Wed, 15 Dec 2010 10:51:49 +0000 From: Adrian Farrel In-reply-to: <4D0750C1.5090304@inrialpes.fr> To: 'Vincent Roca' , secdir@ietf.org, iesg@ietf.org Message-id: <016501cb9c46$171d96d0$4558c470$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQKvZF4Q8QK06FKZ0ufgR+A9rw6arZHZwjKw References: <4D0750C1.5090304@inrialpes.fr> Cc: draft-ietf-mpls-tp-oam-framework.all@tools.ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-mpls-tp-oam-framework-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 10:50:13 -0000 Thanks Vincent, > Document editors and WG chairs should treat > these comments just like any other last call comments. Well, I shall ask the authors to treat them as comments that need to be considered and discussed with possible document changes. Were we to treat them like any other last call comments you would simply get a response saying "thanks for your thoughts which we will examine to see whether they can be useful, but please be aware that the last call completed some weeks ago" :-) Cheers, Adrian From aland@deployingradius.com Wed Dec 15 06:25: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 DE3DD28C0E5; Wed, 15 Dec 2010 06:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY1MqumpRgLs; Wed, 15 Dec 2010 06:25:56 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 680EF28C0DD; Wed, 15 Dec 2010 06:25:56 -0800 (PST) Message-ID: <4D08D059.1090106@deployingradius.com> Date: Wed, 15 Dec 2010 15:27:37 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <4D087AD5.8020901@gridmerge.com> <4D089C73.6050107@deployingradius.com> <4D08CF2A.9080909@gridmerge.com> In-Reply-To: <4D08CF2A.9080909@gridmerge.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) 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, 15 Dec 2010 14:25:58 -0000 Robert Cragie wrote: > Actually, there is one additional consideration - the PRE has to have > prior knowledge of the PAA address. It is not stated how this is > achieved but is state which is stored in the PRE which means not just > any rogue device can masquerade as the PAA as the PRE would check the > source address. A rogue PAA would either have to hijack the PRE-PAA > address resolution phase or somehow obtain the PAA address and spoof it. PANA is carried over UDP, right? Anyone can trivially spoof UDP packets. Checking the PAA source IP is useful, but it adds no security. Alan DeKok. From cpignata@cisco.com Wed Dec 15 09:38: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 30BA628C0F2; Wed, 15 Dec 2010 09:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.31 X-Spam-Level: X-Spam-Status: No, score=-110.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL81ow2bbXeW; Wed, 15 Dec 2010 09:38:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 76F5528C163; Wed, 15 Dec 2010 09:38:23 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,350,1288569600"; d="scan'208";a="193238651" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-1.cisco.com with ESMTP; 15 Dec 2010 17:40:04 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id oBFHe3ps006319; Wed, 15 Dec 2010 17:40:03 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Dec 2010 11:40:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Dec 2010 11:40:01 -0600 Message-ID: <960EC8F9A775AB40BF58D8953342D86303756F52@XMB-RCD-206.cisco.com> In-Reply-To: <000f01cb9c17$d48de140$7da9a3c0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-opsec-protect-control-plane-04 Thread-Index: AcubmuPX8ApT8oTvQH25nvfDEry6vAAfM8nwABnYTqA= References: <001201cb9b59$acd02d70$06708850$@net> <4D077C47.4010506@cisco.com> <5C11F4B2-00A9-4C5C-BA19-417756547632@hopcount.ca> <000f01cb9c17$d48de140$7da9a3c0$@net> From: "Carlos Pignataro (cpignata)" To: "Glen Zorn" , "Joe Abley" , "Rodney Dunn (rodunn)" X-OriginalArrivalTime: 15 Dec 2010 17:40:03.0655 (UTC) FILETIME=[1AEA8D70:01CB9C7F] Cc: draft-ietf-opsec-protect-control-plane@tools.ietf.org, opsec-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-opsec-protect-control-plane-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 17:38:31 -0000 This helps. Thanks ! -----Original Message----- From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Wednesday, December 15, 2010 12:21 AM To: 'Joe Abley'; Rodney Dunn (rodunn) Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-opsec-protect-control-plane@tools.ietf.org; opsec-chairs@tools.ietf.org Subject: RE: secdir review of draft-ietf-opsec-protect-control-plane-04 Joe Abley [mailto:jabley@hopcount.ca] writes: .. > > "Permit RADIUS authentication and accounting replies from RADIUS > servers 198.51.100.9, 198.51.100.10, 2001:DB8:100::9, and > 2001:DB8:100::10 that are listening on UDP ports 1812 and 1813. Note > that this doesn't account for a server using the commonly deployed pre- > standard UDP ports of 1812 and 1813." >=20 > I think you mean "1645 and 1646" in the final sentence. >=20 > I would also drop "commonly deployed" since I think the phrase is > subjective and difficult to qualify, and replace "account for" with > "accommodate" since one of the ports you're opening a hole for is for > accounting and different uses of the same word seems worth avoiding > (e.g. for non-English speakers). Good idea. From scott@hyperthought.com Wed Dec 15 10:30: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 8179B28C1EA for ; Wed, 15 Dec 2010 10:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDys5LlVw2ss for ; Wed, 15 Dec 2010 10:30:33 -0800 (PST) Received: from smtp112.iad.emailsrvr.com (smtp112.iad.emailsrvr.com [207.97.245.112]) by core3.amsl.com (Postfix) with ESMTP id 92D2228C18D for ; Wed, 15 Dec 2010 10:30:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp41.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id BCFF1290CD4; Wed, 15 Dec 2010 13:32:14 -0500 (EST) X-Virus-Scanned: OK Received: from dynamic7.wm-web.iad.mlsrvr.com (dynamic7.wm-web.iad1a.rsapps.net [192.168.2.148]) by smtp41.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1E5B0B81E8; Wed, 15 Dec 2010 13:31:45 -0500 (EST) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic7.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 0BCEE1538081; Wed, 15 Dec 2010 13:31:45 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Wed, 15 Dec 2010 10:31:45 -0800 (PST) Date: Wed, 15 Dec 2010 10:31:45 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-tcpm-tcp-timestamps.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: <1292437905.046510307@192.168.2.229> X-Mailer: webmail8 Subject: [secdir] secdir review of draft-ietf-tcpm-tcp-timestamps-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, 15 Dec 2010 18:30: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 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 modified processin= g steps for SYN segments received for connections in TIME-WAIT state, with = the aim being to allow higher connection rates. The security considerations= section references a comprehensive discussion of the security implications= for TCP timestamps. I see no security issues with this document.=0A=0AMino= r nits:=0A=0AThe last paragraph of section 3 includes this sentence:=0A=0A = "As noted in [Silbersack], such randomization=0A schemes break prevent = the mechanism proposed in this document from=0A recycling connections tha= t are in the TIME-WAIT state."=0A=0AMight want to remove the word "break".= =0A=0AThe security considerations has this paragraph:=0A=0A While the alg= orithm described in this document for processing=0A incoming SYN segments= would benefit from TCP timestamps that are=0A monotonically-increasing a= cross connections, this document does not=0A propose any specific algorit= hm for generating timestamps, nor does it=0A require monotonically-increa= sing timestamps across connections.=0A=0AMaybe I'm just naive, but based on= the information given, I don't understand why this statement is in the sec= urity considerations section. Does the failure to propose any specific algo= rithms have security consideration (that might be more obvious to someone w= ho reads [CPNI-TCP])?=0A From fernando.gont.netbook.win@gmail.com Wed Dec 15 12:56: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 B63A13A706A; Wed, 15 Dec 2010 12:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XG4zNt2GYIh; Wed, 15 Dec 2010 12:56:49 -0800 (PST) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id A133F3A6FB7; Wed, 15 Dec 2010 12:56:49 -0800 (PST) Received: by gyf1 with SMTP id 1so519015gyf.1 for ; Wed, 15 Dec 2010 12:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=IjJpCKAgf0IUIz5O7belmk0IOtE5OV/cTPNoY6Gzagc=; b=XOkKQPlczVc7cmCmycw5fRMJqS/V8mxTQeGZUeHlDW+diks1iiI3ut+E/IYuoFaWRW Hf3+HMbXgxtAA2rK+pgx0jMNSsrmYLEAERTcKqmSh1+nTX7OZup2mQAkgXAbrhyrx/KK tL5LMtaTSBgjDMOOuy9pFtFjnVSRBw2xrxU1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=vD/64/lk/ZNoHAd88d+P6uGxmwK3KM7T7E5KR2LJe7l9nCBFd3T3NiWJt16Dwe2I3Z fWs1F7+q/9BZIyeHh7P5g9Ms/QU84rjjPtpivSchtROvHFJ96z7tXPKYXFuIDH45If02 4f9lwf7TeQ53IQY04O7VAIEvODw28HdCAqA70= Received: by 10.150.138.17 with SMTP id l17mr10887953ybd.82.1292446712403; Wed, 15 Dec 2010 12:58:32 -0800 (PST) Received: from [192.168.2.4] ([186.137.76.188]) by mx.google.com with ESMTPS id q4sm4206173ybe.12.2010.12.15.12.58.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Dec 2010 12:58:31 -0800 (PST) Sender: Fernando Gont Message-ID: <4D092BEC.7090209@gont.com.ar> Date: Wed, 15 Dec 2010 17:58:20 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Scott G. Kelly" References: <1292437905.046510307@192.168.2.229> In-Reply-To: <1292437905.046510307@192.168.2.229> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-tcpm-tcp-timestamps.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcp-timestamps-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, 15 Dec 2010 20:56:50 -0000 Hi, Scott, Thanks so much for your feedback! Please find my comments inline.... On 15/12/2010 03:31 p.m., Scott G. Kelly wrote: > Minor nits: > > The last paragraph of section 3 includes this sentence: > > "As noted in [Silbersack], such randomization schemes break prevent > the mechanism proposed in this document from recycling connections > that are in the TIME-WAIT state." > > Might want to remove the word "break". I'll rephrase to: ---- cut here ---- As noted in [Silbersack], such randomization schemes may prevent the mechanism proposed in this document from recycling connections that are in the TIME-WAIT state. ---- cut here ---- > The security considerations has this paragraph: > > While the algorithm described in this document for processing > incoming SYN segments would benefit from TCP timestamps that are > monotonically-increasing across connections, this document does not > propose any specific algorithm for generating timestamps, nor does > it require monotonically-increasing timestamps across connections. > > Maybe I'm just naive, but based on the information given, I don't > understand why this statement is in the security considerations > section. Does the failure to propose any specific algorithms have > security consideration (that might be more obvious to someone who > reads [CPNI-TCP])? The most obvious implementation of an algorithm that would produce monotonically-increasing timestamps across connections would be to have a global timestamp clock that is initialized to a fixed value (e.g., zero) at systemp boot-strap time, and that is incremented as specified in RFC 1323. Such an algorithm could, e.g., leak information such as system uptime. How about if I re-write the SecCons as follows: ---- cut here ---- While the algorithm described in this document for processing incoming SYN segments would benefit from TCP timestamps that are monotonically-increasing across connections, this document does not propose any specific algorithm for generating timestamps, nor does it require monotonically-increasing timestamps across connections. [CPNI-TCP] contains a detailed discussion of the security implications of TCP timestamps and of different Timestamps generation algorithms. ---- cut here ---- ? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From scott@hyperthought.com Wed Dec 15 20:44: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 33A7728C13A for ; Wed, 15 Dec 2010 20:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J-vd8GNe9+g for ; Wed, 15 Dec 2010 20:44:53 -0800 (PST) Received: from smtp192.dfw.emailsrvr.com (smtp192.dfw.emailsrvr.com [67.192.241.192]) by core3.amsl.com (Postfix) with ESMTP id 514D928C153 for ; Wed, 15 Dec 2010 20:44:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id E3CA13C8374; Wed, 15 Dec 2010 23:46:36 -0500 (EST) X-Virus-Scanned: OK Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 42B623C81B9; Wed, 15 Dec 2010 23:46:36 -0500 (EST) Message-ID: <4D0999AB.7020705@hyperthought.com> Date: Wed, 15 Dec 2010 20:46:35 -0800 From: "Scott G. Kelly" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont References: <1292437905.046510307@192.168.2.229> <4D092BEC.7090209@gont.com.ar> In-Reply-To: <4D092BEC.7090209@gont.com.ar> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-tcpm-tcp-timestamps.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcp-timestamps-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, 16 Dec 2010 04:44:54 -0000 Hi Fernando, Your proposed security considerations text does tie the two statements together better. Thanks, Scott On 12/15/10 12:58 PM, Fernando Gont wrote: > Hi, Scott, > > Thanks so much for your feedback! Please find my comments inline.... > > On 15/12/2010 03:31 p.m., Scott G. Kelly wrote: > >> Minor nits: >> >> The last paragraph of section 3 includes this sentence: >> >> "As noted in [Silbersack], such randomization schemes break prevent >> the mechanism proposed in this document from recycling connections >> that are in the TIME-WAIT state." >> >> Might want to remove the word "break". > I'll rephrase to: > > ---- cut here ---- > As noted in [Silbersack], such randomization schemes may > prevent the mechanism proposed in this document from recycling > connections that are in the TIME-WAIT state. > ---- cut here ---- > > >> The security considerations has this paragraph: >> >> While the algorithm described in this document for processing >> incoming SYN segments would benefit from TCP timestamps that are >> monotonically-increasing across connections, this document does not >> propose any specific algorithm for generating timestamps, nor does >> it require monotonically-increasing timestamps across connections. >> >> Maybe I'm just naive, but based on the information given, I don't >> understand why this statement is in the security considerations >> section. Does the failure to propose any specific algorithms have >> security consideration (that might be more obvious to someone who >> reads [CPNI-TCP])? > The most obvious implementation of an algorithm that would produce > monotonically-increasing timestamps across connections would be to have > a global timestamp clock that is initialized to a fixed value (e.g., > zero) at systemp boot-strap time, and that is incremented as specified > in RFC 1323. Such an algorithm could, e.g., leak information such as > system uptime. > > How about if I re-write the SecCons as follows: > > ---- cut here ---- > While the algorithm described in this document for processing > incoming SYN segments would benefit from TCP timestamps that are > monotonically-increasing across connections, this document does not > propose any specific algorithm for generating timestamps, nor does it > require monotonically-increasing timestamps across connections. > [CPNI-TCP] contains a detailed discussion of the security > implications of TCP timestamps and of different Timestamps > generation algorithms. > ---- cut here ---- > > ? > > Thanks! > > Kind regards, From weiler+secdir@watson.org Thu Dec 16 08:06: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 47E3E3A68DF for ; Thu, 16 Dec 2010 08:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV7zMTkWctE7 for ; Thu, 16 Dec 2010 08:06:56 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 206733A68A8 for ; Thu, 16 Dec 2010 08:06:55 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oBGG8exg074040 for ; Thu, 16 Dec 2010 11:08:40 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oBGG8drq074036 for ; Thu, 16 Dec 2010 11:08:39 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 16 Dec 2010 11:08:39 -0500 (EST) 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, 16 Dec 2010 11:08:40 -0500 (EST) 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, 16 Dec 2010 16:06:57 -0000 I didn't send assignments last week, so we have many (16) new docs this week, as well as some very old drafts coming back from the dead. My apologies to Hilarie, Radia, and Vincent -- my slowness in sending assignments means there's an IETF LC end date rapidly approaching, though the docs aren't on telechat 'til January. Tom Yu is next in the rotation. For telechat 2011-01-06 Reviewer LC end Draft Phillip Hallam-Baker T 2010-12-14 draft-ietf-ecrit-lost-servicelistboundary-05 Jeffrey Hutzelman T 2010-12-06 draft-ietf-roll-trickle-06 Julien Laganier T 2010-12-21 draft-loreto-http-bidirectional-05 Barry Leiba T 2010-12-22 draft-turner-md5-seccon-update-06 David McGrew T 2010-12-29 draft-kucherawy-authres-vbr-01 Hilarie Orman T 2010-12-17 draft-ietf-avt-srtp-big-aes-05 Radia Perlman T 2010-12-23 draft-ietf-mpls-tp-uni-nni-02 Vincent Roca T 2010-12-23 draft-ietf-pim-group-rp-mapping-07 Stefan Santesson T 2010-12-30 draft-ietf-roll-security-framework-03 Sam Weiler T 2011-01-05 draft-ietf-dnsext-5395bis-02 For telechat 2011-01-20 Reviewer LC end Draft Dave Cridland T 2010-12-03 draft-ietf-sipcore-sec-flows-07 Tina TSOU T 2011-01-06 draft-nsri-tls-aria-01 Carl Wallace T 2011-01-03 draft-schaad-smime-algorithm-attribute-03 Brian Weis T 2011-01-03 draft-schaad-smime-hash-experiment-03 Last calls and special requests: Reviewer LC end Draft Rob Austein 2010-12-15 draft-salowey-secsh-uri-00 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Charlie Kaufman R2011-01-05 draft-baker-ietf-core-11 Barry Leiba R2010-12-16 draft-saintandre-tls-server-id-check-12 David McGrew - draft-ietf-ecrit-framework-12 Russ Mundy 2011-01-04 draft-cardona-cablelabs-urn-05 Sandy Murphy 2011-01-03 draft-turner-sha0-sha1-seccon-02 Magnus Nystrom 2011-01-03 draft-ietf-ccamp-gmpls-g-694-lambda-labels-10 Eric Rescorla 2011-01-07 draft-ietf-pce-inter-layer-req-15 Joe Salowey 2011-01-05 draft-ietf-roll-routing-metrics-14 Juergen Schoenwaelder R2011-01-10 draft-ietf-sipping-sip-offeranswer-13 Juergen Schoenwaelder 2011-01-05 draft-ietf-sipcore-keep-10 Yaron Sheffer 2010-12-29 draft-ietf-v6ops-tunnel-loops-01 Nico Williams 2011-01-14 draft-yevstifeyev-http-headers-not-recognized-09 Kurt Zeilenga R2010-12-29 draft-ietf-v6ops-tunnel-security-concerns-04 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-06 From julienl@qualcomm.com Thu Dec 16 08:36:51 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 F0FE53A6911; Thu, 16 Dec 2010 08:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.365 X-Spam-Level: X-Spam-Status: No, score=-106.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oka77V3rCaFn; Thu, 16 Dec 2010 08:36:50 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E55D53A6910; Thu, 16 Dec 2010 08:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1292517515; x=1324053515; 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-loreto-http-bidirec tional.all@tools.ietf.org"=0D=0A=09|Date:=20Thu,=2016=20Dec=20 2010=2008:38:32=20-0800|Subject:=20SecDir=20review=20of =20draft-loreto-http-bidirectional-05|Thread-Topic:=20Sec Dir=20review=20of=20draft-loreto-http-bidirectional-05 |Thread-Index:=20AcudP61PHFCNnvUZQyaEtBtH++x06g=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-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=cFgIMvcvaNC0eLE3VVcFhHkVgYlA1TnhaD5hSwpZh/M=; b=q6/k0+pNkGV5A+KSeHGC//POk2LSImxQwnOlZrVf+X/Whv3ZTfcsBbci JaY19dZkDrjpQOes/0XH24RTI6En9HQ2zbrJRNOe196KjoBKB0CQHDypc 4Uf+/BAHmtmDbjXakMCL5uizQcDolvPVttfWIk23HhBUi3U35PnS5/Ruj w=; X-IronPort-AV: E=McAfee;i="5400,1158,6198"; a="66890541" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 16 Dec 2010 08:38:34 -0800 X-IronPort-AV: E=Sophos;i="4.59,355,1288594800"; d="scan'208";a="19139220" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 16 Dec 2010 08:38:34 -0800 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 16 Dec 2010 08:38:36 -0800 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 16 Dec 2010 08:38:34 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Thu, 16 Dec 2010 08:38:34 -0800 From: "Laganier, Julien" To: "secdir@ietf.org" , "iesg@ietf.org" Date: Thu, 16 Dec 2010 08:38:32 -0800 Thread-Topic: SecDir review of draft-loreto-http-bidirectional-05 Thread-Index: AcudP61PHFCNnvUZQyaEtBtH++x06g== 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-loreto-http-bidirectional.all@tools.ietf.org" Subject: [secdir] SecDir review of draft-loreto-http-bidirectional-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, 16 Dec 2010 16:36:51 -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. The document describes "Known issues and best practices for the Use of Long= Polling and Streaming in Bidirectional HTTP", and it ha= s the following abstract: There is widespread interest in using the Hypertext Transfer Protocol (HTTP) to enable asynchronous or server-initiated communication from a server to a client as well as from a client to a server. This document describes the known issues and the best practices related to the use of HTTP, as it exists today, to enable such "bidirectional HTTP". The two existing mechanisms, called "HTTP long polling" and "HTTP streaming" are described. The document is very clear and articulate and I have not found any security= issues that were not covered appropriately in the Security Considerations = sections. I have two concerns regarding the use of "should", "must" etc.: 1. I have found at least one occurrence where a recommendation is made usin= g lower cases "recommended" and "should". Should upper cases be used instea= d? 2. Similarly, parts of the text describes node behavior using lower cases "= should" and "must". This makes it hard for the reader to differentiate betw= een behavior specified in another standard document from behavior that can = be reasonably expected from a deployed implementation. I would suggest that= upper case requirements key words ("SHOULD", "MUST") be used if the behavi= or thereby enounced is specified within another RFC documents, and that doc= ument be cited next to the statement.=20 =20 Nits: s/DOS attacks\.[RFC4732]/Denial-of-Service (DoS) attacks [RFC4732]/ Hope that helps, --julien=20 From vincent.roca@inrialpes.fr Fri Dec 17 05:53:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4A53A6B40; Fri, 17 Dec 2010 05:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.858 X-Spam-Level: X-Spam-Status: No, score=-9.858 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diptNNy7ylRf; Fri, 17 Dec 2010 05:53:54 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id BCDF13A6B16; Fri, 17 Dec 2010 05:53:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,361,1288566000"; d="scan'208";a="71031564" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 17 Dec 2010 14:55:38 +0100 Message-ID: <4D0B6BDA.4090706@inrialpes.fr> Date: Fri, 17 Dec 2010 14:55:38 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: David Allan I References: <4D0750C1.5090304@inrialpes.fr> <60C093A41B5E45409A19D42CF7786DFD51CB7F4CE2@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51CB7F4CE2@EUSAACMS0703.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-mpls-tp-oam-framework.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-mpls-tp-oam-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: Fri, 17 Dec 2010 13:53:56 -0000 Hello David, Thanks for your answer and for the -10 version. I see there are indeed good reasons not to encumber too much the protocol with security stuff. This was not obvious at first glance for a non specialist like me and a short simplistic security section is often the sign that the authors didn't take time to think about it (or don't have the required knowledge). This is not the case here. However there's a (naive) question which you didn't answer: is it realistic to assume the physical network can be secured? Are there known weaknesses in the MPLS infrastructure? Nothing is said in the I-D. Another point (from -10). It is said: However it should be observed that the combination of the need for timeliness of OAM transaction exchange and all permutations of unique MEP to MEP, MEP to MIP, and intermediate system originated transactions mitigates against the practical establishment and maintenance of a large number of security associations per MEG either in advance or as required. The reasons mentioned here to justify nothing is done is critical. Only two reasons are listed: timeliness and combinatorial motivations. In your answer you also mention the high transmission frequency of heartbeats. This is not mentioned. Something else? Cheers, Vincent On 14/12/10 18:06, David Allan I wrote: > HI Vincent: > > Thank you for the detailed read of the section and your comments.... > > There are a couple of problems associated with the volume of SAs required that IMO there is no obvious way to mitigate... > > The primary example that comes to mind is fault management... > > 1) Heartbeats are running between LSP endpoints at a an interval as low as 3.3msec interval. The number of SAs is bounded but applying some form of crypto per-packet authentication would just about melt any existing implementation. This discussion has already come up independently in the BFD WG w.r.t. the authentication option. > > 2) Applying authentication to the generation of notification messages from intermediate nodes in the path means the number of SAs goes up in direct proprotion to the number of hops in the path length of each LSP if the SAs are to be established prior to actually being required in the interest of timely generation of notifications. Negotiating the establishment of each SA on the fly would appear to add significant delays in what is supposed to be an instantaneous network response so does not appear to be a practical option for reducing the scaling impact of maintaining a full set of SAs for all eventualities... > > Now we probably overstate the case for crypto in the section (reference to password exchange) and will edit accordingly. What we are exchanging is state about the operational status of a given entity with a minimum of authentication/non-repudiation exclusively on internal links to a network. If a malicious party is able to tap into one of those links they would be able to insert or modify transactions./messages as to mask the true state of the network. > > SO on the basis of the above any suggestions as to how the section can be improved would be welcome. BTW thanks for pointing out that man in the middle has a more specific context that our usage, we will edit accordingly. > > Cheers > Dave > > > > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Tuesday, December 14, 2010 3:11 AM > To: secdir@ietf.org; iesg@ietf.org > Cc: vincent.roca@inrialpes.fr; draft-ietf-mpls-tp-oam-framework.all@tools.ietf.org > Subject: SecDir review of draft-ietf-mpls-tp-oam-framework-09 > > 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. > > The Security Considerations section of this I-D is fairly strange. > The authors first highlight that OAM traffic contains sensitive data (like passwords), and then quickly conclude that securing this traffic is impossible and therefore they require that the network be physically secured. The reason provided is the fact that there are too many entities that are likely to communicate to establish and maintain SAs between them. > > Well, I don't know the specificities of MPLS networks, nor the OAM operations in MPLS networks, however: > 1- I need more information to be convinced that there is indeed no > other solution than requiring that the whole physical network be > totally secured; > 2- I need more information to be convinced that fully securing such > a physical network is feasible; > > Honestly speaking I'm not convinced by 1-. What about solutions based on temporary SA? Are the OAM exchanges so frequent to require that each secure connection be maintained all the time? Would a solution that establishes those connections on-the-fly, when needed, be realistic? Another direction could be to use shared keys between the entities of a group. Or perhaps using a per-packet signature approach is feasible, using some public key infrastructure, if the exchanges are infrequent. There are probably other IETF protocols that have similar requirements. What about the KARP WG that focuses on secure routing protocols? May some ideas be borrowed and applied here (that's a fully open question)? > > Concerning 2-, a quick search on "MPLS attacks" on the web provides a small number of references. There's also a book on the subject ("Analyzing MPLS VPN Security", M. H. Behringer, M. Morrow, Cisco Press, 2005). I don't known the domain at all but I'd like to be convinced that 2- is feasible. > > > A minor comment. > I have the feeling that the authors use the term "man-in-the-middle attack" to denote any attack where the attacker takes control of the physical infrastructure. That's not an appropriate use and this term refers to a very specific attack (e.g. see http://en.wikipedia.org/wiki/Man-in-the-middle_attack). > > I hope these comments are useful. > Regards, > > Vincent From hartmans@mit.edu Fri Dec 17 12:54: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 97AC53A69C2; Fri, 17 Dec 2010 12:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZaX7XGnXb9A; Fri, 17 Dec 2010 12:54:19 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 928813A6998; Fri, 17 Dec 2010 12:54:19 -0800 (PST) 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 EC778202C9; Fri, 17 Dec 2010 15:54:58 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3E21C4060; Fri, 17 Dec 2010 15:55:51 -0500 (EST) From: Sam Hartman To: Sam Hartman References: Date: Fri, 17 Dec 2010 15:55:51 -0500 In-Reply-To: (Sam Hartman's message of "Tue, 14 Dec 2010 11:09:20 -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-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 17 Dec 2010 20:54:20 -0000 Hi. I've been asked by the trill authors to clarify what I meant by my secdir review. That's certainly fair. I think there are two issues. The first is that I think that draft-ietf-isis-trill does an adequate job of discussing the security implications of IS-IS on trill. I've read the security considerations section of draft-ietf-trill-rbridge-protocol and I think it doesn't do so either. However, it comes very close. If I understand Is-IS security correctly, the only attack that we would expect a routing protocol to deal with that it does not is replays. (IS-Is is no worse than anything else here.) The impact of replays is a denial of service. If I'm understanding section 6.2 of draft-ietf-trill-rbridge-protocol correctly, similar denial of service attacks are also possible with trill-specific messages. If my understanding of the impact of IS-IS security (even with authentication) is sufficient, I think this concern could be addressed by adding a sentence to the security considerations section of draft-ietf-isis-trill saying something like "Even when the IS-IS authentication is used, replays of IS-IS packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." I have a second large issue with the way we've handled trill. First I'd like to compliment the authors of draft-ietf-trill-rbridge-protocol, particularly on the security considerations section, but the document quality of other sections of that document I've looked at is high. They've done a good job of describing what they've done and as far as I can tell delivering what they've said they would deliver. However, something went wrong somewhere. We have some standards that we've agreed to as a community for the security of new work we do. It's my opinion that trill does not meet those standards. The document doesn't claim it does. I think that was wrong, however the mistake was in the review of RFC 5556 (the TRILL problem statement), which clearly sets out what TRILL was going to do. I believe I was on the IESG at a time when that document was reviewed, so I especially don't have room to complain here. So, actually even were I on the IESG, I would not hold up the protocol over this issue. Looking forward to future work, though, I think we should be more consistent about applying our community standards to work we charter. If those standards are wrong, let's revise them. No, TRILL should not have been forced to solve the ethernet control plane security problem. However TRILL should have had a security mechanism that meets current standards so that when the ethernet control plane is updated TRILL never ends up being the weakest link. As best I can tell, TRILL does meet the security goals stated in its problem statement. Also, my comment about document quality was never intended to be blocking. While I don't believe draft-ietf-isis-trill is of as high quality as draft-ietf-trill-rbridge-protocol, I did manage to understand it without the rbridge-protocol document. The authors claim that should not be requried; I think if I had looked at the rbridge-protocol document first I would have concluded that it was more clear than isis-trill, although I think it's also true that I would have been less bothered. Either way, I did manage to follow both documents. --Sam From Adrian.Farrel@huawei.com Fri Dec 17 13:22: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 DE16F3A6C2A; Fri, 17 Dec 2010 13:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.641 X-Spam-Level: X-Spam-Status: No, score=-103.641 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlMzLG2Qc64d; Fri, 17 Dec 2010 13:22:52 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id D44E03A6C1D; Fri, 17 Dec 2010 13:22:52 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LDL00J18CT30P@usaga01-in.huawei.com>; Fri, 17 Dec 2010 13:24:40 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LDL00EHDCT1U5@usaga01-in.huawei.com>; Fri, 17 Dec 2010 13:24:39 -0800 (PST) Date: Fri, 17 Dec 2010 21:24:38 +0000 From: Adrian Farrel In-reply-to: To: 'Sam Hartman' Message-id: <010701cb9e30$d17a1990$746e4cb0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQEnHMNUQZgblglcEzvZ5LOribmVJgIlUz+ilNz8YHA= References: Cc: draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2010 21:22:54 -0000 Sam, Thanks for your work. Can I clarify. You wrote: > The first is that I think that draft-ietf-isis-trill does an adequate > job of discussing the security implications of IS-IS on trill. I've > read the security considerations section of > draft-ietf-trill-rbridge-protocol and I think it doesn't do so either. I you have one positive and one negative statement. I think you meant them to both be negative. Perhaps you could confirm. Cheers, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Sam > Hartman > Sent: 17 December 2010 20:56 > To: Sam Hartman > Cc: draft-ietf-isis-trill@tools.ietf.org; ietf@ietf.org; secdir@ietf.org > Subject: Re: Secdir review of draft-ietf-isis-trill > > Hi. I've been asked by the trill authors to clarify what I meant by my > secdir review. > > That's certainly fair. > > I think there are two issues. > > The first is that I think that draft-ietf-isis-trill does an adequate > job of discussing the security implications of IS-IS on trill. I've > read the security considerations section of > draft-ietf-trill-rbridge-protocol and I think it doesn't do so either. > > However, it comes very close. If I understand Is-IS security correctly, > the only attack that we would expect a routing protocol to deal with > that it does not is replays. (IS-Is is no worse than anything else > here.) The impact of replays is a denial of service. If I'm > understanding section 6.2 of draft-ietf-trill-rbridge-protocol > correctly, similar denial of service attacks are also possible with > trill-specific messages. > > If my understanding of the impact of IS-IS security (even with > authentication) is sufficient, I think this concern could be addressed > by adding a sentence to the security considerations section of > draft-ietf-isis-trill saying something like "Even when the IS-IS > authentication is used, replays of IS-IS packets can create > denial-of-service conditaions; see RFC 6039 for details. These issues > are similar in scope to those discussed in section 6.2 of > draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." > > I have a second large issue with the way we've handled trill. First I'd > like to compliment the authors of draft-ietf-trill-rbridge-protocol, > particularly on the security considerations section, but the document > quality of other sections of that document I've looked at is high. > They've done a good job of describing what they've done and as far as I > can tell delivering what they've said they would deliver. > > However, something went wrong somewhere. We have some standards that > we've agreed to as a community for the security of new work we do. It's > my opinion that trill does not meet those standards. The document > doesn't claim it does. > > I think that was wrong, however the mistake was in the review of RFC > 5556 (the TRILL problem statement), which clearly sets out what TRILL > was going to do. I believe I was on the IESG at a time when that > document was reviewed, so I especially don't have room to complain here. > > So, actually even were I on the IESG, I would not hold up the protocol > over this issue. > > Looking forward to future work, though, I think we should be more > consistent about applying our community standards to work we charter. If > those standards are wrong, let's revise them. No, TRILL should not have > been forced to solve the ethernet control plane security > problem. However TRILL should have had a security mechanism that meets > current standards so that when the ethernet control plane is updated > TRILL never ends up being the weakest link. As best I can tell, TRILL > does meet the security goals stated in its problem statement. > > Also, my comment about document quality was never intended to be > blocking. While I don't believe draft-ietf-isis-trill is of as high > quality as draft-ietf-trill-rbridge-protocol, I did manage to understand > it without the rbridge-protocol document. The authors claim that should > not be requried; I think if I had looked at the rbridge-protocol > document first I would have concluded that it was more clear than > isis-trill, although I think it's also true that I would have been less > bothered. Either way, I did manage to follow both documents. > > --Sam > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From hartmans@mit.edu Fri Dec 17 13:31: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 DE08D3A6C2A; Fri, 17 Dec 2010 13:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzMlGiFUoYXt; Fri, 17 Dec 2010 13:31:57 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3CBBC3A6C1D; Fri, 17 Dec 2010 13:31:57 -0800 (PST) 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 AA0AC2016B; Fri, 17 Dec 2010 16:32:38 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E558F4060; Fri, 17 Dec 2010 16:33:30 -0500 (EST) From: Sam Hartman To: Adrian.Farrel@huawei.com References: <010701cb9e30$d17a1990$746e4cb0$@huawei.com> Date: Fri, 17 Dec 2010 16:33:30 -0500 In-Reply-To: <010701cb9e30$d17a1990$746e4cb0$@huawei.com> (Adrian Farrel's message of "Fri, 17 Dec 2010 21:24:38 +0000") 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-isis-trill@tools.ietf.org, 'Sam Hartman' , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 17 Dec 2010 21:31:58 -0000 >>>>> "Adrian" == Adrian Farrel writes: Adrian> Sam, Thanks for your work. Adrian> Can I clarify. You wrote: > The first is that I think that draft-ietf-isis-trill does an adequate >> job of discussing the security implications of IS-IS on trill. >> I've read the security considerations section of >> draft-ietf-trill-rbridge-protocol and I think it doesn't do so >> either. Adrian> I you have one positive and one negative statement. I think Adrian> you meant them to both be negative. Perhaps you could Adrian> confirm. You are correct. From secdir-bounces@mit.edu Wed Dec 15 04:44: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 5AF983A7045 for ; Wed, 15 Dec 2010 04:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[AWL=2.698, 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 RIzJ1hv+SxDq for ; Wed, 15 Dec 2010 04:44:13 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 3B4053A7046 for ; Wed, 15 Dec 2010 04:43:43 -0800 (PST) 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 oBFCjKdU021037 for ; Wed, 15 Dec 2010 07:45:21 -0500 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 oBFCjJBs021034 for ; Wed, 15 Dec 2010 07:45:19 -0500 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 oBFCiM8b032028 for ; Wed, 15 Dec 2010 07:45:19 -0500 X-AuditID: 12074422-b7c3eae000000a70-88-4d08b85e059b Received: from outbound003.nyc1.bluetie.com ( [206.65.163.13]) by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with SMTP id 0B.E8.02672.E58B80D4; Wed, 15 Dec 2010 07:45:18 -0500 (EST) Received: from web002.nyc1.bluetie.com ([10.102.1.14]) by outbound003.nyc1.bluetie.com with outbound001 id jQlJ1f00D0J7qBN01QlJMv; Wed, 15 Dec 2010 07:45:18 -0500 X-CMAE-OUT-Analysis: v=1.1 cv=Lum0m9ISk0xynrnUzP0Fn8qoGZ5artdnZ15xVlZ6NF4= c=1 sm=1 a=gjDEOWbanngA:10 a=IkcTkHD0fZMA:10 a=eJ0rF5sbAAAA:8 a=_BNyH0__AAAA:8 a=o83nqyVRAAAA:8 a=5JsTALN_WaYF4m3l-F0A:9 a=hO_I5V0ziQZPII4OuW4A:7 a=S3YL_psjdjciSuI7DAaNOYX4QOEA:4 a=QEXdDO2ut3YA:10 a=ka6W5khrMvsA:10 a=-qQHQtLo5NIA:10 a=nLCxcEmZIOGyGd-p:21 a=VAaP8I2JGza0SxhA:21 a=bIpfiZevh8TQWWqcgQ8Vuw==:117 X-CMAE-OUT-Score: 0.00 Received: from web002.nyc1.bluetie.com (localhost.localdomain [127.0.0.1]) by web002.nyc1.bluetie.com (Postfix) with ESMTP id 497A6AB0196 for ; Wed, 15 Dec 2010 07:45:19 -0500 (EST) Message-ID: <20101215073231.15662@web002.nyc1.bluetie.com> X-HTTP-Received: from danms2011.rbp5co9a58 [95.45.199.134] by web002.nyc1.bluetie.com (BlueTie WebMail ); Wed, 15 Dec 2010 07:45:01 -0500 X-Mailer: BlueTie MTA Date: Wed, 15 Dec 2010 07:45:01 -0500 To: danms2011@danms.org From: "danms2011@danms.org" Importance: normal X-Brightmail-Tracker: AAAAAA== X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id oBFCjJBs021034 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Fri, 17 Dec 2010 14:07:10 -0800 Subject: [secdir] Submission deadline extended to 2 Jan 2011 CFP: IFIP/IEEE DANMS 2011 (co-located with IM 2011) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 12:44:24 -0000 KFdlIGFwb2xvZ2l6ZSBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3BpZXMgb2YgdGhpcyBtZXNz YWdlLikKCkNBTEwgRk9SIFBBUEVSUwoKSUZJUC9JRUVFIERBTk1TIDIwMTEKRm9ydGggSW50ZXJu YXRpb25hbCBXb3Jrc2hvcCBvbiBEaXN0cmlidXRlZCBBdXRvbm9tb3VzIE5ldHdvcmsgTWFuYWdl bWVudCBTeXN0ZW1zCkNvLWxvY2F0ZWQgd2l0aCBJTSAyMDExLCBEdWJsaW4sIElyZWxhbmQKd3d3 LmRhbm1zLm9yZwoKSW1wb3J0YW50IERhdGVzClBhcGVyIHN1Ym1pc3Npb24gZGVhZGxpbmU6IDIg SmFuIDIwMTEgKGV4dGVuZGVkKQpOb3RpZmljYXRpb24gb2YgYWNjZXB0YW5jZTogMzAgSmFuIDIw MTEKQ2FtZXJhLXJlYWR5IHBhcGVyOiAxNSBGZWIgMjAxMQoKUGFwZXIgU3VibWlzc2lvbiBVUkwK aHR0cHM6Ly9qZW1zLnNiYy5vcmcuYnIvZGFubXMyMDExCgpUaGUgREFOTVMgMjAxMSB3b3Jrc2hv cCBpcyBwYXJ0IG9mIGEgc2VyaWVzIG9mIHdvcmtzaG9wcyBkZWRpY2F0ZWQgdG8gYWR2YW5jZXMg aW4gbmV0d29yayBtYW5hZ2VtZW50IGFuZCB0aGUgYXBwbGljYXRpb24gb2YgbmV3IG1hbmFnZW1l bnQgcHJpbmNpcGxlcyBpbiBuZXR3b3JrIGRlc2lnbi4KVGhpcyB5ZWFy4oCZcyB3b3Jrc2hvcCBl bXBoYXNpemVzIG9uIOKAnEVmZmljaWVudCBNYW5hZ2VtZW50IG9mIExvb3NlbHkgQ29sbGFib3Jh dGl2ZSBTZXJ2aWNlIE5ldHdvcmtz4oCdIHdoZXJlIG5ldHdvcmsgY29ubmVjdGl2aXR5IHByb3Zp ZGVycywgY29udGVudCBhbmQgc2VydmljZSBwcm92aWRlcnMgY29tZSB0b2dldGhlciB0byBwcm92 aWRlIGhpZ2gtbGV2ZWwgc2VydmljZXMgc3VjaCBhcyBPdmVyLVRoZS1Ub3AgKE9UVCkgc2Vydmlj ZXMgdG8gZW5kLXVzZXJzIGluIGEgbG9vc2VseSBjb2xsYWJvcmF0aXZlIHdheS4KSW4gdGhlIHJl Y2VudCBwYXN0LCBlbmQtdXNlciBzZXJ2aWNlcyBzdWNoIGFzIGhpZ2ggcXVhbGl0eSB2aWRlbyBj YWxscywgd2ViLWJhc2VkIHZpZGVvIGNvbnRlbnQgc2VydmVycywgSEQgdmlkZW8gc3RyZWFtaW5n IGFuZCBWb0Qgc2VydmljZXMgZXRjLiBoYXZlIGRyaXZlbiB0aGUgdGVsZWNvbSBtYXJrZXQuIFRo ZSBhcHBlYXJhbmNlIG9mIHRoZXNlIG5ldyBjb250ZW50L3NlcnZpY2UgcHJvdmlkZXJzLCB3aGlj aCBpbmNsdWRlIHNvIGNhbGxlZCBPdmVyLVRoZS1Ub3AgKE9UVCkgc2VydmljZSBwcm92aWRlcnMs IGhhcyBkcml2ZW4gbmV0d29yayB1c2FnZSwgYnV0IGFsc28gY3JlYXRlZCBodWdlIG5ldHdvcmsg bWFuYWdlbWVudCBwcm9ibGVtcyBmb3IgdGhlIG9wZXJhdG9ycy4gSW4gdGhpcyBjb250ZXh0LCBj b250ZW50L3NlcnZpY2UgcHJvdmlkZXJzIHRvZ2V0aGVyIHdpdGggbmV0d29yayBvcGVyYXRvcnMg cHJvdmlkZSB2YWx1ZSB0byB0aGUgc3Vic2NyaWJlcnMgaW4gYSDigJxsb29zZWx5IGNvbGxhYm9y YXRpdmXigJ0gZmFzaGlvbi4gU2VydmljZSBhc3N1cmFuY2UgaW4gdGhpcyBsb29zZSBjb2xsYWJv cmF0aXZlIGVudmlyb25tZW50IGlzIGNoYWxsZW5naW5nLCBwYXJ0aWN1bGFybHkgaW4gdGhlIHBy ZXNlbmNlIG9mIGEgbmV0d29yayB3aXRoIGxpbWl0ZWQgb3Igbm8gZ3VhcmFudGVlcy4gVGhpcyBu YXNjZW50IGVjby1zeXN0ZW0gaXMgZHJpdmluZyBmdW5kYW1lbnRhbCBjaGFuZ2VzIGluIGhvdyBu ZXR3b3JrcyBhcmUgZGVwbG95ZWQgYW5kIG1hbmFnZWQgYXMgd2VsbCBhcyBob3cgdGhleSBpbnRl cmFjdCB3aXRoIGNvbnRlbnQgYW5kIHNlcnZpY2UgcHJvdmlkZXJzLiBJbiB0aGlzIGNvbnRleHQs IHRvZ2V0aGVyIHdpdGggd2lkZXIgbmV0d29yayBtYW5hZ2VtZW50IGNvbnRyaWJ1dGlvbnMsIHdl IGV4cGVjdCB0byBoYXZlIHRlY2huaWNhbCBjb250cmlidXRpb25zIGluIHRoZSBhcmVhcyBvZiBh dXRvbWF0ZWQgc2VydmljZSBhc3N1cmFuY2UgYW5kIGluIGxvb3NlbHkgY29sbGFib3JhdGl2ZSBz ZXJ2aWNlIG5ldHdvcmtzLgoKVG9waWNzIG9mIGludGVyZXN0IGluY2x1ZGUgKGJ1dCBhcmUgbm90 IGxpbWl0ZWQgdG8pIHRoZSBmb2xsb3dpbmc6CgogKiBGZWRlcmF0ZWQgbmV0d29yayBtYW5hZ2Vt ZW50CiAqIEltcGFjdCBvZiBPdmVyIHRoZSBUb3AgKE9UVCkgc2VydmljZXMgaW4gcmVzb3VyY2Ug bWFuYWdlbWVudAogKiBDYXNlIHN0dWRpZXMgb2Ygc2VydmljZSBhc3N1cmFuY2UKICogRWZmaWNp ZW50IHVzZSBvZiB0ZXJtaW5hbCByZXBvcnRzIGluIHNlcnZpY2UgYXNzdXJhbmNlCiAqIFNMQSBm b3IgT1RUIHNlcnZpY2UgYXNzdXJhbmNlCiAqIFNlcnZpY2UgYW5kIHJlc291cmNlIG1vZGVsbGlu ZyBhcHByb2FjaGVzIGZvciBtYW5hZ2VtZW50CiAqIEJ1c2luZXNzIHJ1bGVzIGFuZCBvcmdhbml6 YXRpb25hbCBtb2RlbGxpbmcKICogVXNlIG9mIHNlbWFudGljcyBpbiBzZXJ2aWNlIGRlcGxveW1l bnQgYW5kIHF1YWxpdHkgYXNzdXJhbmNlCiAqIEV4dGVuc2lvbnMgYW5kIHJlZmluZW1lbnRzIG9m IE5NIHN0YW5kYXJkcwogKiBBc3BlY3RzIG9mIHNlcnZpY2UgbWFuYWdlbWVudCBhbmQgYXNzdXJh bmNlCiAqIEF1dG9tYXRlZCBzZXJ2aWNlIHByb3Zpc2lvbmluZyBhY3Jvc3MgbXVsdGlwbGUgc2Vy dmljZSBwcm92aWRlcnMKICogRmF1bHQgYW5kIHBlcmZvcm1hbmNlIG1hbmFnZW1lbnQsIGRpYWdu b3NpcywgYW5kIHRyb3VibGVzaG9vdGluZwogKiBFbmQtdG8tZW5kIFFvUyBtYW5hZ2VtZW50IGZv ciBlbnRlcnByaXNlIG5ldHdvcmtzCiAqIE1lYXN1cmVtZW50cyBhbmQgaW5zaWdodHMgZnJvbSBu ZXR3b3JrIG9wZXJhdGlvbnMKICogTWV0cmljcywgdGVjaG5pcXVlcywgYW5kIGV4cGVyaW1lbnRz IGZvciBldmFsdWF0aW5nIG5ldHdvcmsKICogQ29udmVyZ2VuY2Ugb2YgZml4ZWQgYW5kIG1vYmls ZSBuZXR3b3JrcwoKU3RlZXJpbmcgQ29tbWl0dGVlCiBOYXppbSBBZ291bG1pbmUsIFVuaXZlcnNp dHkgb2YgRXZyeSBWYWwgZCdFc3Nvbm5lIEZyYW5jZQogUmFvdWYgQm91dGFiYSwgVW5pdmVyc2l0 eSBvZiBXYXRlcmxvbyBDYW5hZGEKIEdhYnJpZWwgSG9nYW4sIE5ldHdvcmsgTWFuYWdlbWVudCBM YWIsIEVyaWNzc29uLCBJcmVsYW5kCgpXb3Jrc2hvcCBDby1DaGFpcnMKIFNpZGF0aCBIYW5kdXJ1 a2FuZGUsIE5ldHdvcmsgTWFuYWdlbWVudCBMYWIsIEVyaWNzc29uIElyZWxhbmQKIEpvc2UgTmV1 bWFuIGRlIFNvdXphLCBGZWRlcmFsIFVuaXZlcnNpdHkgb2YgQ2VhcmEsIEJyYXppbAoKUHVibGlj aXR5IENoYWlyCiBZYW5nY2hlbmcgSHVhbmcsIEVyaWNzc29uIElyZWxhbmQKClRlY2huaWNhbCBQ cm9ncmFtIENvbW1pdHRlZQogQXJvc2hhIEJhbmRhcmEsIE9wZW4gVW5pdmVyc2l0eSwgVUsKIEph dmllciBCYWxpb3NpYW4sIFVuaS4gb2YgdGhlIFJlcHVibGljLCBVcnVndWF5CiBTYWxlZW0gQmhh dHRpLCBVbmkuIG9mIFN0IEFuZHJld3MsIFVLCiBTYW1pIEJoaXJpLCBERVJJLCBJcmVsYW5kCiBB bm5lLU1hcmllIEJvc25lYWcsIEVyaWNzc29uLCBJcmVsYW5kCiBBbmNhIENoYW5kcmEsIElCTSBS ZXNlYXJjaCwgVVNBCiBEYXZlIENsZWFyeSwgRXJpY3Nzb24sIElyZWxhbmQKIFpvcmFuIERlc3Bv dG92aWMsIE5UVCBEb0NvTW8gRXVyby1MYWJzLCBHZXJtYW55CiBEb21pbmlxdWUgRHVka293c2tp LCBORUMsIEdlcm1hbnkKIExpYW0gRmFsbG9uLCBFcmljc3NvbiwgSXJlbGFuZAogSmFtZXMgSG9u ZywgUE9TVEVDSCwgS29yZWEKIEplc3NlIEtpZWx0aHksIFRTU0csIElyZWxhbmQKIEZyYW5jaW5l IEtyaWVmLCBCb3JkZWF1eCAxIFVuaXZlcnNpdHksIEZyYW5jZQogUGV0ciBLdXpuZXRzb3YsIERl dXRzY2hlIFRlbGVrb20gTGFib3JhdG9yaWVzLCBHZXJtYW55CiBCcmlhbiBMZWUsIEFJVCwgSXJl bGFuZAogRGVjbGFuIE8nU3VsbGl2YW4sIFRyaW5pdHkgQ29sbGVnZSBEdWJsaW4sIElyZWxhbmQK IEdlcmFyZCBQYXJyLCBVbml2ZXJzaXR5IG9mIFVsc3RlciwgVUsKIEx1aXMgUm9kcmlndWVzLCBJ TkVTQy1JRC9JU1QsIFBvcnR1Z2FsCiBGbG9yaWFuIFNjaHJlaW5lciwgRnJhdW5ob2ZlciBGT0tV UywgR2VybWFueQogUm9sZiBTdGFkbGVyLCBLVEgsIFN3ZWRlbgogTWFydGluIHZhbiBTdGVlbiwg VnJqZSBVbml2ZXJzaXR5LCBOZXRoZXJsYW5kcwogRmlsaXAgRGUgVHVyY2ssIEdoZW50IFVuaXZl cnNpdHktSUJCVCwgQmVsZ2l1bQogU3RlZmFuIFdhbGxpbiwgTHVsZcOlIFVuaXZlcnNpdHkgb2Yg VGVjaG5vbG9neSwgU3dlZGVuCiBNYXJ0aW4gWmFjaCwgU2llbWVucyBBRyBBdXN0cmlhCgpQYXBl ciBTdWJtaXNzaW9uIEluc3RydWN0aW9ucwoKQXV0aG9ycyBhcmUgaW52aXRlZCB0byBzdWJtaXQg cGFwZXJzIG9mIG1heGltdW0gc2l4IHBhZ2VzIG9yIGV4dGVuZGVkIHBhcGVycyBvZiB1cCB0byBl aWdodCBwYWdlcyAoaW5jbHVkaW5nIGZpZ3VyZXMsIHRhYmxlcywgYW5kIHJlZmVyZW5jZXMpLCBp biB0aGUgc3RhbmRhcmQgdHdvLWNvbHVtbiwgMTEgcHQgZm9udCwgSUVFRSBjb25mZXJlbmNlIHBh cGVyIGZvcm1hdC4gU3RhbmRhcmQgSUVFRSBUcmFuc2FjdGlvbnMgdGVtcGxhdGVzIGZvciBNaWNy b3NvZnQgV29yZCBvciBMYVRlWCBmb3JtYXRzIGNhbiBiZSBmb3VuZCBhdApodHRwOi8vd3d3Lmll ZWUub3JnL3BvcnRhbC9wYWdlcy9wdWJzL3RyYW5zYWN0aW9ucy9zdHlsZXNoZWV0cy5odG1sLgpB bGwgd29yayBzdWJtaXR0ZWQgbXVzdCBiZSBvcmlnaW5hbCwgbm90IHByZXZpb3VzbHkgcHVibGlz aGVkIG9yIHVuZGVyIHN1Ym1pc3Npb24gYXQgb3RoZXIgdmVudWVzLgpBdCBsZWFzdCBvbmUgYXV0 aG9yIG9mIGFjY2VwdGVkIHBhcGVycyBtdXN0IGJlIHByZXNlbnQgYXQgdGhlIHdvcmtzaG9wLCB0 byBwcmVzZW50IHRoZSBwYXBlci4gQWNjZXB0ZWQgcGFwZXJzIHdpbGwgYmUgcHVibGlzaGVkIGJ5 IElFRUUgWHBsb3JlIGFuZCBpbmRleGVkIGFjY29yZGluZ2x5LgpPbmx5IFBERiBmaWxlcyB3aWxs IGJlIGFjY2VwdGVkIGZvciB0aGUgcmV2aWV3IHByb2Nlc3MgYW5kIGFsbCBzdWJtaXNzaW9ucyBt dXN0IGJlIGRvbmUgdGhyb3VnaCBKRU1TIGF0IHRoZSBVUkwgYmVsb3c6Cmh0dHBzOi8vamVtcy5z YmMub3JnLmJyL2Rhbm1zMjAxMQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18Kc2VjZGlyIG1haWxpbmcgbGlzdApzZWNkaXJAbWl0LmVkdQpodHRwczovL21h aWxtYW4ubWl0LmVkdS9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcgo= From robert.cragie@gridmerge.com Wed Dec 15 06:21: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 27C2028C164; Wed, 15 Dec 2010 06:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUy5-0Usc+t7; Wed, 15 Dec 2010 06:21:18 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id A06B73A6E8C; Wed, 15 Dec 2010 06:21:17 -0800 (PST) Received: from client-86-31-167-78.oxfd.adsl.virginmedia.com ([86.31.167.78] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PSsFb-0002pO-2L; Wed, 15 Dec 2010 14:22:41 +0000 Message-ID: <4D08CF2A.9080909@gridmerge.com> Date: Wed, 15 Dec 2010 14:22:34 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alan DeKok References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <4D087AD5.8020901@gridmerge.com> <4D089C73.6050107@deployingradius.com> In-Reply-To: <4D089C73.6050107@deployingradius.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010706090200090107000708" X-Mailman-Approved-At: Fri, 17 Dec 2010 14:07:10 -0800 Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 14:21:20 -0000 This is a cryptographically signed message in MIME format. --------------ms010706090200090107000708 Content-Type: multipart/alternative; boundary="------------040701090404050101060604" This is a multi-part message in MIME format. --------------040701090404050101060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alan, Some further comments below, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 15/12/2010 10:46 AM, Alan DeKok wrote: > Robert Cragie wrote: >> Alan, >> >> Thanks for your response. Some further comments below, bracketed by >> . >> >> In summary, I think there are two security considerations in addition = to >> the other text already proposed which need to be addressed: >> >> 1. The PRE, as a protocol-aware relay, MUST only relay PRY message= s >> and MUST only accept valid PANA messages >> 2. The use of a PRE causes additional state at the PAA (IP address= >> and port of PRE) which may need to be stored >> >> Whilst the language Alper has used so far is probably sufficient, I do= >> think that it is important to strenuously recommended that the PRE-PAA= >> connection is secured using either DTLS, PANA SA or L2 protection; > >> Unless I am missing something, a token generated and validated by= >> the PRE could only authenticate the immutable parts of the PRY, i.e. t= he >> PaC-Information AVP. You would need a full security association betwee= n >> PRE and PAA to authenticate different messages in both directions. > I'm not sure what "different messages" means. My goal was to ensure= > that rogue PAAs could only send PANA messages to the IP and source port= > used by a PaC to send PANA messages. > > I'm not concerned about protecting messages to the PAA. It's alread= y > on an open network, and anyone on that network can send any content to > any port. So adding PRE to PAA security is useless. > > i.e. authenticating messages in *both* directions is not the goal of= > the token. OK, understood, we are talking about the same thing. >>> So adding a PRE opens the PaC to attacks from arbitrary sources on= a >>> wide-area network, which would seem to be a violation of the PANA >>> assumptions. >> That is true. However, I think Alper's point is that an equivalen= t >> MiTM router on a wider network in the vicinity of the PaC could still = be >> the target for a rogue PAA and that the PRE model was really no >> different. So this doesn't necessarily pose an *additional* threat. > If the PaC has access to the wider network before it's authenticated= , > then there is no need for any PRE-PAA token. > > If the PaC has access to the wider network before it's authenticated= , > then I'm not really sure why PANA is being used at all. I was considering the case where the PaC has link-local access to a MiTM = router which has access to the wider network, not the PaC itself. One of = the models we considered prior to the relay was one of simply performing = first-hop access to a router that has access to the PAA. But we=20 dismissed this approach for a number of security reasons in favour of=20 the relay approach. Actually, there is one additional consideration - the PRE has to have=20 prior knowledge of the PAA address. It is not stated how this is=20 achieved but is state which is stored in the PRE which means not just=20 any rogue device can masquerade as the PAA as the PRE would check the=20 source address. A rogue PAA would either have to hijack the PRE-PAA=20 address resolution phase or somehow obtain the PAA address and spoof it. > Alan DeKok. > --------------040701090404050101060604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alan,

Some further comments below, bracketed by <RCC></RCC>
=
Robert

On 15/12/2010 10:46 AM, Alan DeKok wrote:
Robert Cragie wrote:
 Alan,

Thanks for your response. Some further comments below, bracketed by
<RCC></RCC>.

In summary, I think there are two security considerations in addition to
the other text already proposed which need to be addressed:

   1. The PRE, as a protocol-aware relay, MUST only relay PRY messages
      and MUST only accept valid PANA messages
   2. The use of a PRE causes additional state at the PAA (IP address
      and port of PRE) which may need to be stored

Whilst the language Alper has used so far is probably sufficient, I do
think that it is important to strenuously recommended that the PRE-PAA
connection is secured using either DTLS, PANA SA or L2 protection;

<RCC>Unless I am missing something, a token =
generated and validated by
the PRE could only authenticate the immutable parts of the PRY, i.e. the
PaC-Information AVP. You would need a full security association between
PRE and PAA to authenticate different messages in both directions.</RC=
C>
  I'm not sure what "different messages" means.  My goal was to ensure
that rogue PAAs could only send PANA messages to the IP and source port
used by a PaC to send PANA messages.

  I'm not concerned about protecting messages to the PAA.  It's already
on an open network, and anyone on that network can send any content to
any port.  So adding PRE to PAA security is useless.

  i.e. authenticating messages in *both* directions is not the goal of
the token.
<RCC>OK, understood, we are talking about the same thing.</RCC>

      
  So adding a PRE opens the PaC to attacks from =
arbitrary sources on a
wide-area network, which would seem to be a violation of the PANA
assumptions.
<RCC>That is true. However, I think Alper's =
point is that an equivalent
MiTM router on a wider network in the vicinity of the PaC could still be
the target for a rogue PAA and that the PRE model was really no
different. So this doesn't necessarily pose an *additional* threat.</R=
CC>
  If the PaC has access to the wider network before it's authenticated,
then there is no need for any PRE-PAA token.

  If the PaC has access to the wider network before it's authenticated,
then I'm not really sure why PANA is being used at all.
<RCC>
I was considering the case where the PaC has link-local access to a MiTM router which has access to the wider network, not the PaC itself. One of the models we considered prior to the relay was one of simply performing first-hop access to a router that has access to the PAA. But we dismissed this approach for a number of security reasons in favour of the relay approach.

Actually, there is one additional consideration - the PRE has to have prior knowledge of the PAA address. It is not stated how this is achieved but is state which is stored in the PRE which means not just any rogue device can masquerade as the PAA as the PRE would check the source address. A rogue PAA would either have to hijack the PRE-PAA address resolution phase or somehow obtain the PAA address and spoof it.
</RCC>
  Alan DeKok.

--------------040701090404050101060604-- --------------ms010706090200090107000708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMjE1MTQyMjM0WjAjBgkqhkiG9w0BCQQxFgQUI+Cc gxIv6wPD3gsuvok4ajmN+jkwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAXgfaRKboXZYG6tqTmfwCy22hMqpGZQQK2jB8 ICqhT6in7yqzVFcOZ2QE3TIDR95/n+w+hvcwbBn/k6NJifuELaJu8H0hHrKc5DXu1gdwRbss iy1qlHWkAzjSIQtNxwm4ICBrE35AXrkSu6iMI4AINuAmeMQh1bm17wLTmdi1rJw4NAF0h26+ WhsVv8xcNT72odAJEizavXwyP3nXTYOc97LiIVf4oC2T32kJ8w7TsSzMemPfsGhlP7oEhiPu +69a821j5zJ9kjinga9f2nYACsgnXN1OXcZRIYS7YjDNGr4DjZ8u3gavkFyn3cQ8Pya/sbwZ n7jBV48Z/4HOMIzQ9QAAAAAAAA== --------------ms010706090200090107000708-- From robert.cragie@gridmerge.com Wed Dec 15 07:44: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 BD36128C179; Wed, 15 Dec 2010 07:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEGpOqdL9PRr; Wed, 15 Dec 2010 07:44:11 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id BD99B28C17B; Wed, 15 Dec 2010 07:44:09 -0800 (PST) Received: from client-86-31-167-78.oxfd.adsl.virginmedia.com ([86.31.167.78] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1PStXv-0005NH-E9; Wed, 15 Dec 2010 15:45:39 +0000 Message-ID: <4D08E29E.3040509@gridmerge.com> Date: Wed, 15 Dec 2010 15:45:34 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alan DeKok References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> <4D087AD5.8020901@gridmerge.com> <4D089C73.6050107@deployingradius.com> <4D08CF2A.9080909@gridmerge.com> <4D08D059.1090106@deployingradius.com> In-Reply-To: <4D08D059.1090106@deployingradius.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050400080708070806040703" X-Mailman-Approved-At: Fri, 17 Dec 2010 14:07:10 -0800 Cc: 'Yoshihiro Ohba' , secdir@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Alper Yegin , margaretw42@gmail.com, pana@ietf.org, paduffy@cisco.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: Re: [secdir] Token (was RE: Secdir review of draft-ohba-pana-relay) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 15:44:17 -0000 This is a cryptographically signed message in MIME format. --------------ms050400080708070806040703 Content-Type: multipart/alternative; boundary="------------090701010803050801050101" This is a multi-part message in MIME format. --------------090701010803050801050101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Agreed, it just makes the attack more complex. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 15/12/2010 2:27 PM, Alan DeKok wrote: > Robert Cragie wrote: >> Actually, there is one additional consideration - the PRE has to have >> prior knowledge of the PAA address. It is not stated how this is >> achieved but is state which is stored in the PRE which means not just >> any rogue device can masquerade as the PAA as the PRE would check the >> source address. A rogue PAA would either have to hijack the PRE-PAA >> address resolution phase or somehow obtain the PAA address and spoof i= t. > PANA is carried over UDP, right? > > Anyone can trivially spoof UDP packets. Checking the PAA source IP = is > useful, but it adds no security. > > Alan DeKok. > --------------090701010803050801050101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed, it just makes the attack more complex.

Robert

On 15/12/2010 2:27 PM, Alan DeKok wrote:
Robert Cragie wrote:
Actually, there is one additional consideration - =
the PRE has to have
prior knowledge of the PAA address. It is not stated how this is
achieved but is state which is stored in the PRE which means not just
any rogue device can masquerade as the PAA as the PRE would check the
source address. A rogue PAA would either have to hijack the PRE-PAA
address resolution phase or somehow obtain the PAA address and spoof it.
  PANA is carried over UDP, right?

  Anyone can trivially spoof UDP packets.  Checking the PAA source IP is
useful, but it adds no security.

  Alan DeKok.

--------------090701010803050801050101-- --------------ms050400080708070806040703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAxMjE1MTU0NTM0WjAjBgkqhkiG9w0BCQQxFgQUAAbR UQYhyKKS1wECPUXNhpWPoyMwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAGOprH8TsxPD5h0U/v/HPaQF73c3BzuJxffab aH3DOJh048yibhwYYIdkaHxiO2lqQtRZgj85gEuNrE9rCYiXMOjXIzVzEfpBBZsprSrXgoXP a+7GGniZV4uq+iXZt8TkKF7CiG17j45JA/RnLwM3nQBQ8/wWsLm4p+a91oaMtvUA8uRKoutG umz3Us70OJH7Odk2CQNA8kvgr0il8ThicgW9Fblzg1DtlMT4QF6tOHlbGZxqbT02Zz7fbCWj Rwa6ACDbXKtzrhrfI3Pl0rXDmKaQU2ByI+VI0bxso+kd6wLVQrLaUwtdfEuNXXif0gpF+GTD T2nX3Lq7DIdKCz4JeQAAAAAAAA== --------------ms050400080708070806040703-- From nordmark@acm.org Fri Dec 17 13:59:51 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 4FA7B3A69FC; Fri, 17 Dec 2010 13:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcklKfN9geib; Fri, 17 Dec 2010 13:59:50 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by core3.amsl.com (Postfix) with ESMTP id 80DDF3A69FB; Fri, 17 Dec 2010 13:59:50 -0800 (PST) Received: from [10.10.10.103] (70-36-183-22.dsl.dynamic.sonic.net [70.36.183.22]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id oBHM1Xft007102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 14:01:35 -0800 Message-ID: <4D0BDDC0.6060201@acm.org> Date: Fri, 17 Dec 2010 14:01:36 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101025 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 17 Dec 2010 14:07:10 -0800 Cc: draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 17 Dec 2010 21:59:51 -0000 On 12/17/10 12:55 PM, Sam Hartman wrote: > However, it comes very close. If I understand Is-IS security correctly, > the only attack that we would expect a routing protocol to deal with > that it does not is replays. (IS-Is is no worse than anything else > here.) The impact of replays is a denial of service. If I'm > understanding section 6.2 of draft-ietf-trill-rbridge-protocol > correctly, similar denial of service attacks are also possible with > trill-specific messages. > > If my understanding of the impact of IS-IS security (even with > authentication) is sufficient, I think this concern could be addressed > by adding a sentence to the security considerations section of > draft-ietf-isis-trill saying something like "Even when the IS-IS > authentication is used, replays of IS-IS packets can create > denial-of-service conditaions; see RFC 6039 for details. These issues > are similar in scope to those discussed in section 6.2 of > draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." Sam, Adding just this sentence to draft-ietf-isis-trill (the code point document) seems odd. Your comment is really a comment on the security of IS-IS, and not specific to TRILL and unrelated to the code points. If we need to point out this IS-IS issue the right place to do that would have been in draft-ietf-trill-rbridge-protocol; we shouldn't make draft-ietf-isis-trill a random collection of (editorial) corrections against the IS-IS spec or the TRILL spec. I don't know if an RFC-ed note for draft-ietf-trill-rbridge-protocol makes sense at this late date (close to a year after the IESG approved it). But one could add a sentence to the second paragraph in section 6 pointing specifically at replay attacks and RFC 6039. > Looking forward to future work, though, I think we should be more > consistent about applying our community standards to work we charter. If > those standards are wrong, let's revise them. No, TRILL should not have > been forced to solve the ethernet control plane security > problem. However TRILL should have had a security mechanism that meets > current standards so that when the ethernet control plane is updated > TRILL never ends up being the weakest link. As best I can tell, TRILL > does meet the security goals stated in its problem statement. Do you have a concrete case where TRILL would end up being the weakest link? We designed the protocol so that ESADI can have higher learning confidence level that learning from data frames. This was to ensure that if e.g., 802.1x or some future technology is used at the edge to autenticate stations, we can give that higher confidence thus ensure that TRILL benefits from that additional security. I don't understand the implications of your reference to current standards. Are you saying that if TRILL was chartered today, its charter would say that it "MUST NOT reuse IS-IS or OSPF since those are not sufficiently secure"? Such a stance doesn't make sense to me, since we want to leverage existing protocols while we improve the security of those existing protocols, instead of prohibiting re-use. Regards, Erik From hartmans@mit.edu Fri Dec 17 19:44: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 074C63A6A25; Fri, 17 Dec 2010 19:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.819 X-Spam-Level: X-Spam-Status: No, score=-102.819 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je7mDA3J24w6; Fri, 17 Dec 2010 19:44:21 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 571933A699C; Fri, 17 Dec 2010 19:44:20 -0800 (PST) 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 4A37A2013D; Fri, 17 Dec 2010 22:45:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 49D1F4060; Fri, 17 Dec 2010 22:45:54 -0500 (EST) From: Sam Hartman To: Erik Nordmark References: <4D0BDDC0.6060201@acm.org> Date: Fri, 17 Dec 2010 22:45:54 -0500 In-Reply-To: <4D0BDDC0.6060201@acm.org> (Erik Nordmark's message of "Fri, 17 Dec 2010 14:01:36 -0800") 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-isis-trill@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 18 Dec 2010 03:44:22 -0000 >>>>> "Erik" == Erik Nordmark writes: Erik> Adding just this sentence to draft-ietf-isis-trill (the code Erik> point document) seems odd. Your comment is really a comment on Erik> the security of IS-IS, and not specific to TRILL and unrelated Erik> to the code points. I don't care much where the text goes. I'm happy if you provide an rfc editor note for draft-ietf-trill-rbridge-protocol if you like that approach better. However, as I read draft-ietf-isis-trill, it defines the interface between TRILL and IS-IS. In my mind, that's where the security consideration appears. You're re-using a component that isn't up to our current standards--we know that; we're working on it in KARP. However in doing that, you need to document the security considerations for your protocol. Since you have a document that specifically is the interface between your protocol and the component you are re-using,that seems like the best place to do the documentation work. however, in decreasing order of priority, I want to call out my concern that we need to be far more careful about what we expect in terms of security from future work we charter and that we should document the specific interactions between IS-IS and TRILL. While I have expressed an opinion above on where I think that documentation should go, feel free to put it where you think is most correct. From d3e3e3@gmail.com Sun Dec 19 10:15:18 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 1EAB93A6870; Sun, 19 Dec 2010 10:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.154 X-Spam-Level: X-Spam-Status: No, score=-103.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6gy5eUz5IDD; Sun, 19 Dec 2010 10:15:17 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3F8C73A6866; Sun, 19 Dec 2010 10:15:16 -0800 (PST) Received: by wyf23 with SMTP id 23so2182647wyf.31 for ; Sun, 19 Dec 2010 10:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=0DxuJl7/2JjuG+i4bXEM5ULhXwpvvAK+f3LdomLTADU=; b=bB8JNYlUA0ivFTVggVYQii3LTVzVQ9Ptvbe4mBricrT9xyfFR6LPdFbBsg3E6caXZs BrhH8B9UP2olQAZ51k+DJnZFbqH9xi4dCXNB/kRyhhK5ORbeDoeqhcnqjuJCvPkxErIP BATfrpLpeCxYUiv86NUk82FVloldmyj2CpnfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=xIyNwRP38vi6KfvlNUkwIu0Ayv9fJf2MiRBcA1BR8x9DOLVoFC/1GS3OA4oMz80WIx O4wK6uLutBTNn93jKyDduHGPhjne5skLLs8Ahj4FcVrGne1LYToHy13VrdY15SglF3Pf K+CQI4t+GvUwjB54EbhB1oU8lP+o0+4iVS5VI= Received: by 10.227.134.82 with SMTP id i18mr2037827wbt.50.1292782627449; Sun, 19 Dec 2010 10:17:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.196 with HTTP; Sun, 19 Dec 2010 10:16:47 -0800 (PST) In-Reply-To: References: <4D0BDDC0.6060201@acm.org> From: Donald Eastlake Date: Sun, 19 Dec 2010 13:16:47 -0500 Message-ID: To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 19 Dec 2010 18:15:18 -0000 My apologies for responding slowly, I was traveling. If it is tolerable to people, I do not mind adding the two sentences requested by Sam to the isis-trill draft. Thanks, Donald PS: It appears to me that the same considerations apply to draft-ietf-isis-ieee-aq. On Fri, Dec 17, 2010 at 10:45 PM, Sam Hartman wrote= : >>>>>> "Erik" =3D=3D Erik Nordmark writes: > > > =A0 =A0Erik> Adding just this sentence to draft-ietf-isis-trill (the code > =A0 =A0Erik> point document) seems odd. Your comment is really a comment = on > =A0 =A0Erik> the security of IS-IS, and not specific to TRILL and unrelat= ed > =A0 =A0Erik> to the code points. > > I don't care much where the text goes. =A0I'm happy if you provide an rfc > editor note for draft-ietf-trill-rbridge-protocol if you like that > approach better. =A0However, as I read draft-ietf-isis-trill, it defines > the interface between TRILL and IS-IS. =A0In my mind, that's where the > security consideration appears. =A0You're re-using a component that isn't > up to our current standards--we know that; we're working on it in > KARP. However in doing that, you need to document the security > considerations for your protocol. =A0Since you have a document that > specifically is the interface between your protocol and the component > you are re-using,that seems like the best place to do the documentation > work. > > however, in decreasing order of priority, I want to call out my concern > that we need to be far more careful about what we expect in terms of > security from future work we charter and that we should document the > specific interactions between IS-IS and TRILL. =A0While I have expressed > an opinion above on where I think that documentation should go, feel > free to put it where you think is most correct. From radiaperlman@gmail.com Sun Dec 19 11:55: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 B80D03A68BC; Sun, 19 Dec 2010 11:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5k3rvbgX8KR; Sun, 19 Dec 2010 11:55:46 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BC1293A68BB; Sun, 19 Dec 2010 11:55:46 -0800 (PST) Received: by iwn40 with SMTP id 40so2694092iwn.31 for ; Sun, 19 Dec 2010 11:57:38 -0800 (PST) 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=+ZEGy+OgJCGKXblBvElHIhNYeABHXgHyQKtzAcSN/wY=; b=v6stuT8Ly3jMpBT2FMiF7kbmRKuaPPvxYZh9Nk/WODM6k3wYwWF2nQ+V0bRADcwtlY nNpJXvkXdcfA34cCyE3aGk7hjOg87YX25ncHlZOSl6kSWZttjPg5x5+OZFz+HeTc80I9 jTG/NbXonfvLnAkTLy4THOGc3gs0EWQfz3ed4= 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=fByNJUOWRewKtgwFPFrORnNvtFI25kC1z/7tJK3FdYn4+RuykrL7U+oR+tBguPayPa c1e4Ld0WgYdyRUe1XHTHj2cAkil/N2puOnQ61V+wpUJ5AoRXP2j8ucB+6RnkwIJa7iuI XdPiyDdnsSPre6/XmgmzPRJApM2IvHjDqU+s0= MIME-Version: 1.0 Received: by 10.42.175.70 with SMTP id az6mr3284518icb.428.1292788658545; Sun, 19 Dec 2010 11:57:38 -0800 (PST) Received: by 10.42.220.199 with HTTP; Sun, 19 Dec 2010 11:57:38 -0800 (PST) In-Reply-To: References: <4D0BDDC0.6060201@acm.org> Date: Sun, 19 Dec 2010 11:57:38 -0800 Message-ID: From: Radia Perlman To: Donald Eastlake Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , secdir@ietf.org, Sam Hartman , draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 19 Dec 2010 19:55:47 -0000 No objections. Radia On Sun, Dec 19, 2010 at 10:16 AM, Donald Eastlake wrote: > My apologies for responding slowly, I was traveling. > > If it is tolerable to people, I do not mind adding the two sentences > requested by Sam to the isis-trill draft. > > Thanks, > Donald > > PS: It appears to me that the same considerations apply to > draft-ietf-isis-ieee-aq. > > On Fri, Dec 17, 2010 at 10:45 PM, Sam Hartman wro= te: >>>>>>> "Erik" =3D=3D Erik Nordmark writes: >> >> >> =A0 =A0Erik> Adding just this sentence to draft-ietf-isis-trill (the cod= e >> =A0 =A0Erik> point document) seems odd. Your comment is really a comment= on >> =A0 =A0Erik> the security of IS-IS, and not specific to TRILL and unrela= ted >> =A0 =A0Erik> to the code points. >> >> I don't care much where the text goes. =A0I'm happy if you provide an rf= c >> editor note for draft-ietf-trill-rbridge-protocol if you like that >> approach better. =A0However, as I read draft-ietf-isis-trill, it defines >> the interface between TRILL and IS-IS. =A0In my mind, that's where the >> security consideration appears. =A0You're re-using a component that isn'= t >> up to our current standards--we know that; we're working on it in >> KARP. However in doing that, you need to document the security >> considerations for your protocol. =A0Since you have a document that >> specifically is the interface between your protocol and the component >> you are re-using,that seems like the best place to do the documentation >> work. >> >> however, in decreasing order of priority, I want to call out my concern >> that we need to be far more careful about what we expect in terms of >> security from future work we charter and that we should document the >> specific interactions between IS-IS and TRILL. =A0While I have expressed >> an opinion above on where I think that documentation should go, feel >> free to put it where you think is most correct. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From hartmans@mit.edu Mon Dec 20 08:41: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 8D5393A6A63; Mon, 20 Dec 2010 08:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.792 X-Spam-Level: X-Spam-Status: No, score=-102.792 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhuiRXVwF0tn; Mon, 20 Dec 2010 08:41:02 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C2ACC3A6808; Mon, 20 Dec 2010 08:41:02 -0800 (PST) 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 3C4CC20239; Mon, 20 Dec 2010 11:41:43 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C219B4060; Mon, 20 Dec 2010 11:42:32 -0500 (EST) From: Sam Hartman To: Radia Perlman References: <4D0BDDC0.6060201@acm.org> Date: Mon, 20 Dec 2010 11:42:32 -0500 In-Reply-To: (Radia Perlman's message of "Sun, 19 Dec 2010 11:57:38 -0800") 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: ietf@ietf.org, secdir@ietf.org, Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, Sam Hartman Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 20 Dec 2010 16:41:03 -0000 >>>>> "Radia" == Radia Perlman writes: Radia> No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. From d3e3e3@gmail.com Mon Dec 20 10:41: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 C14333A69B2; Mon, 20 Dec 2010 10:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zs0+CgOe9iL; Mon, 20 Dec 2010 10:41:31 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8D2983A6866; Mon, 20 Dec 2010 10:41:30 -0800 (PST) Received: by wyf23 with SMTP id 23so3149111wyf.31 for ; Mon, 20 Dec 2010 10:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=YDpZMdDPYeB74CedfD5uWe6qtrlgeCd0QrW6oQnHFE8=; b=jCIoEIAzW/R86DYQZXTzNvctGdwPPq03SW2l6d+hvtNSm65A/XDGircKWExpefkYPS EO3ykgkvqbq45xMPQ6B8mkgihkU0ZjY1PON4ewrqKVnf16xH7fLNaqfVLr5KButgIcfK ji4i8HjshxIAHueyGTWCFh4y3YJhUVUlKbXuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=vvahxom6GKCw6nqAi1RQ/Js9xYBjibNA5qA1eAzUbNeV0pehrijitZMzegPxh1ndQ4 ctEP0zB4EfR0STtgEFm/kS6DDhyUbl9eN4WAEqQmtff/PJasYwn0CUNwSyIwkHcwNftt 58tKClrTc74TlhCx5j4Ga9uTmQ6uxyzGflF3E= Received: by 10.227.183.71 with SMTP id cf7mr2877594wbb.195.1292870604020; Mon, 20 Dec 2010 10:43:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.196 with HTTP; Mon, 20 Dec 2010 10:43:03 -0800 (PST) In-Reply-To: References: <4D0BDDC0.6060201@acm.org> From: Donald Eastlake Date: Mon, 20 Dec 2010 13:43:03 -0500 Message-ID: To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , secdir@ietf.org, draft-ietf-isis-trill@tools.ietf.org, ietf@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 20 Dec 2010 18:41:31 -0000 Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman wrote= : >>>>>> "Radia" =3D=3D Radia Perlman writes: > > =A0 =A0Radia> No objections. =A0Radia > > > Can I get someone to confirm that the text in the proposed sentences is > substantially true? > I think so but I'm not an IS-IS expert. LSPs have sequences number, etc., and are idempotent. I think only Hellos have the potential replay Denial of Service problem. So I would suggest changing to: "Even when the IS-IS authentication is used, replays of Hello packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." Thanks, Donald From hartmans@mit.edu Mon Dec 20 10:49: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 2F8A73A6A95; Mon, 20 Dec 2010 10:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJGZhOJt19Lc; Mon, 20 Dec 2010 10:49:09 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4DAAF3A687A; Mon, 20 Dec 2010 10:49:08 -0800 (PST) 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 5887420239; Mon, 20 Dec 2010 13:49:51 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F1C254060; Mon, 20 Dec 2010 13:50:38 -0500 (EST) From: Sam Hartman To: Donald Eastlake References: <4D0BDDC0.6060201@acm.org> Date: Mon, 20 Dec 2010 13:50:38 -0500 In-Reply-To: (Donald Eastlake's message of "Mon, 20 Dec 2010 13:43:03 -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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: ietf@ietf.org, secdir@ietf.org, Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, Sam Hartman Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 20 Dec 2010 18:49:10 -0000 >>>>> "Donald" == Donald Eastlake writes: Donald> Hi, Donald> On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman wrote: >>>>>>> "Radia" == Radia Perlman writes: >> >>    Radia> No objections.  Radia >> >> >> Can I get someone to confirm that the text in the proposed >> sentences is substantially true? I think so but I'm not an IS-IS >> expert. Donald> LSPs have sequences number, etc., and are idempotent. I Donald> think only Hellos have the potential replay Denial of Donald> Service problem. So I would suggest changing to: Donald> "Even when the IS-IS authentication is used, replays of Donald> Hello packets can create denial-of-service conditaions; see Donald> RFC 6039 for details. These issues are similar in scope to Donald> those discussed in section 6.2 of Donald> draft-ietf-trill-rbridge-protocol, and the same mitigations Donald> may apply." Based on my understanding your correction is accurate; thanks. From stbryant@cisco.com Mon Dec 20 11:03: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 588E13A6A61; Mon, 20 Dec 2010 11:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfgYH18Qd3Ua; Mon, 20 Dec 2010 11:03:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 398283A6A63; Mon, 20 Dec 2010 11:03:11 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG83D01AZnwM/2dsb2JhbACkF3OjWoJMDgGYWIVJBIsBhgw X-IronPort-AV: E=Sophos;i="4.60,203,1291593600"; d="scan'208";a="195249130" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Dec 2010 19:05:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBKJ54Qt001607; Mon, 20 Dec 2010 19:05:04 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oBKJ51806392; Mon, 20 Dec 2010 19:05:02 GMT Message-ID: <4D0FA8DD.2040704@cisco.com> Date: Mon, 20 Dec 2010 19:05:01 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Donald Eastlake References: <4D0BDDC0.6060201@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, secdir@ietf.org, Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, Sam Hartman Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 19:03:13 -0000 On 20/12/2010 18:43, Donald Eastlake wrote: > Hi, > > On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman wrote: >>>>>>> "Radia" == Radia Perlman writes: >> Radia> No objections. Radia >> >> >> Can I get someone to confirm that the text in the proposed sentences is >> substantially true? >> I think so but I'm not an IS-IS expert. > LSPs have sequences number, etc., and are idempotent. I think only > Hellos have the potential replay Denial of Service problem. So I would > suggest changing to: > > "Even when the IS-IS > authentication is used, replays of Hello packets can create > denial-of-service conditaions; see RFC 6039 for details. These issues > are similar in scope to those discussed in section 6.2 of > draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." > > Thanks, > Donald ... as I recall from discussions with the ISIS WG the changes that were made to ISIS for TRILL make it more vulnerable to a hello attack than vanilla ISIS. This I understand is because there is more work to be done in processing a TRILL hello. Is that correct? - Stewart From bew@cisco.com Mon Dec 20 11:22:18 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 6DA843A6AA6; Mon, 20 Dec 2010 11:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL-8WgxPShKN; Mon, 20 Dec 2010 11:22:17 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 309AC3A6AA2; Mon, 20 Dec 2010 11:22:17 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKc7D02rR7Hu/2dsb2JhbACkGXOjUps6hUkEhGWGHA X-IronPort-AV: E=Sophos;i="4.60,203,1291593600"; d="scan'208";a="252983964" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Dec 2010 19:24:11 +0000 Received: from dhcp-128-107-147-31.cisco.com (dhcp-128-107-147-31.cisco.com [128.107.147.31]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBKJOB0S010309; Mon, 20 Dec 2010 19:24:11 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Dec 2010 11:24:13 -0800 Message-Id: <2B08467E-1263-4B0B-9B9D-0A17762015F8@cisco.com> To: secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: draft-schaad-smime-hash-experiment@tools.ietf.org Subject: [secdir] Secdir review of draft-schaad-smime-hash-experiment-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, 20 Dec 2010 19:22: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 review comments. This document proposes an experiment to detect if there are major = problems in using hash algorithms that include parameters as part of CMS = and S/MIME. To that end, it defines a weak un-keyed hash algorithm that = includes a parameter, and also the ASN.1 definition needed to passed the = parameter within the CMS data structure. Both the hash definition and Security Considerations section make it = clear that the defined hash is not expected to provide a sufficient = level of security, and is not intended for use outside of the = experiment. However, I just wonder if that is a reasonable expectation; = Experimental RFCs do get implemented. Even the presence of the statement = "This hash function MUST NOT be released as shipping code, it is = designed only for use in experimentation." in Section 1 may not be = enough to stop implementation of what might look to naive readers as an = interesting new hash function appeared to be published "by the IETF". It might be helpful to follow this MUST NOT statement with one or more = references to parameterized hash functions that have been published for = a security review and might be good actual candidates in the future. I = am not an expert in this area, but one that seems to fit this criteria = is: Shai Halevi, et. al, "Implementing the Halevi-Krawczyk Randomized = Hashing Scheme", = . Other than one suggestion, I do not see the need for any changes. Brian= From d3e3e3@gmail.com Mon Dec 20 13:57: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 60F9F3A6B04; Mon, 20 Dec 2010 13:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-wK8qOn+0tN; Mon, 20 Dec 2010 13:57:14 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2E3FE3A68F9; Mon, 20 Dec 2010 13:57:14 -0800 (PST) Received: by wwa36 with SMTP id 36so3352786wwa.13 for ; Mon, 20 Dec 2010 13:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Wn0JvXue1UlMetIM2Y/7Ypthqsgg+6aqQ3xMoouhAB4=; b=nva6qpSOkBh+ACc8JpR7JUUX+HCzikgGtxzHQrN9EBZw0OghfgufmFksjcMHpF1Ln+ jlJ8XLzY0i9LecCm1vMYszudxvD5Mo3Xp9/exSQKlwHnLdjjrfrBWzcc9iEigMVPeGKV 5+ctfL/+2HjtNYtRBOKz3SqdYmcBBI+oi/IeY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=LsKzz4nxl47bsXTflBkYNGCHotpnZ/17JtCsEoITTaxWa2mEbJYv/xoQXrebnxQhGt CqTNuatMa9thXYgtDgPvVdKa7VArJ1ccPbBFKCusxQkjNii0/wuGsmX7a5TWwAV81U3D nkdF2ZunrgZRYc46nSMwOTICE0u5mXch0yCk8= Received: by 10.227.59.208 with SMTP id m16mr2883466wbh.224.1292882347982; Mon, 20 Dec 2010 13:59:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.143.196 with HTTP; Mon, 20 Dec 2010 13:58:47 -0800 (PST) In-Reply-To: <4D0FA8DD.2040704@cisco.com> References: <4D0BDDC0.6060201@acm.org> <4D0FA8DD.2040704@cisco.com> From: Donald Eastlake Date: Mon, 20 Dec 2010 16:58:47 -0500 Message-ID: To: stbryant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, secdir@ietf.org, Erik Nordmark , draft-ietf-isis-trill@tools.ietf.org, Sam Hartman Subject: Re: [secdir] Secdir review of draft-ietf-isis-trill 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, 20 Dec 2010 21:57:15 -0000 Hi, On Mon, Dec 20, 2010 at 2:05 PM, Stewart Bryant wrote: > On 20/12/2010 18:43, Donald Eastlake wrote: >> >> Hi, >> >> On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman >> =A0wrote: >>>>>>>> "Radia" =3D=3D Radia Perlman =A0writes: >>> >>> =A0 =A0Radia> =A0No objections. =A0Radia >>> >>> Can I get someone to confirm that the text in the proposed sentences is >>> substantially true? >>> I think so but I'm not an IS-IS expert. >> >> LSPs have sequences number, etc., and are idempotent. I think only >> Hellos have the potential replay Denial of Service problem. So I would >> suggest changing to: >> >> "Even when the IS-IS >> authentication is used, replays of Hello packets can create >> denial-of-service conditaions; see RFC 6039 for details. These issues >> are similar in scope to those discussed in section 6.2 of >> draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." >> >> Thanks, >> Donald > > ... as I recall from discussions with the ISIS WG the changes that were m= ade > to ISIS for TRILL make it more vulnerable to a hello attack than vanilla > ISIS. This I understand is because there is more work to be done in > processing a TRILL hello. Is that correct? I think we are talking about Denial of Service due to replay of old Hellos screwing up the state. This is unrelated to the work required to process a Hello. It is true that some processing is required for IS-IS LAN Hellos. One reason for having a protocol like BFD is that you can send BFD messages more frequently because they take less processing than Hellos. But I don't see why there would be that much difference between the work involved in processing a TRILL LAN Hello and a Layer 3 IS-IS LAN Hello. > - Stewart Thanks, Donald From j.schoenwaelder@jacobs-university.de Tue Dec 21 00:53: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 500E23A680F; Tue, 21 Dec 2010 00:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.107 X-Spam-Level: X-Spam-Status: No, score=-103.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWkXRC-VVAKG; Tue, 21 Dec 2010 00:53:04 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4EC773A67A8; Tue, 21 Dec 2010 00:53:04 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74BC6C0003; Tue, 21 Dec 2010 09:54:59 +0100 (CET) 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 qw646TQqz3-U; Tue, 21 Dec 2010 09:54:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43C56C0016; Tue, 21 Dec 2010 09:54:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 28A6516036BA; Tue, 21 Dec 2010 09:54:47 +0100 (CET) Date: Tue, 21 Dec 2010 09:54:47 +0100 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipcore-keep.all@tools.ietf.org Message-ID: <20101221085447.GA32839@elstar.local> Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipcore-keep.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [secdir] secdir review of draft-ietf-sipcore-keep-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 08:53:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document discusses how to negotiate the usage of keep-alive messages using a new SIP "keep" Via header field. The document appears to be well worked out and the security considerations seem to be adequate. I spotted to mostly editorial nits in the security considerations: a) [...] This specification does not specify a connection reuse mechanism, and it does it address security issues related to connection reuse. [...] s/it does it/it does not/ b) [...] They do not instruct the enity to place a value in a "keep" parameter of any request it forwards. [...] s/enity/entity/ /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 Tue Dec 21 00:59: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 2A5A63A67A8; Tue, 21 Dec 2010 00:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.109 X-Spam-Level: X-Spam-Status: No, score=-103.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OEILcLTTlAA; Tue, 21 Dec 2010 00:59:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1F39C3A6783; Tue, 21 Dec 2010 00:59:42 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CCDCC0016; Tue, 21 Dec 2010 10:01:37 +0100 (CET) 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 70QYqWAW6LMc; Tue, 21 Dec 2010 10:01:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FB86C0009; Tue, 21 Dec 2010 10:01:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F023D1603730; Tue, 21 Dec 2010 10:01:26 +0100 (CET) Date: Tue, 21 Dec 2010 10:01:26 +0100 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org Message-ID: <20101221090126.GB32839@elstar.local> Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [secdir] secdir review of draft-ietf-sipping-sip-offeranswer-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 08:59:43 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I reviewed draft-ietf-sipping-sip-offeranswer-10 back in Feburary 2009 and my comments do not seem to have caused changes to the document as far as I read the diffs. My original comments can be found here: http://www.ietf.org/mail-archive/web/secdir/current/msg00460.html /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From christer.holmberg@ericsson.com Tue Dec 21 02:31: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 BBD893A69D6; Tue, 21 Dec 2010 02:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 lWieKxJk+jlk; Tue, 21 Dec 2010 02:31:46 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 58F953A69C0; Tue, 21 Dec 2010 02:31:46 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-82-4d1082851e3a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0A.95.13987.582801D4; Tue, 21 Dec 2010 11:33:41 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.33]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 21 Dec 2010 11:33:39 +0100 From: Christer Holmberg To: Juergen Schoenwaelder , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-sipcore-keep.all@tools.ietf.org" Date: Tue, 21 Dec 2010 11:33:37 +0100 Thread-Topic: secdir review of draft-ietf-sipcore-keep-10.txt Thread-Index: Acug7MT3MV0JoSI3Tf6SRxZH56700QADaMNA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058503BA4F41@ESESSCMS0356.eemea.ericsson.se> References: <20101221085447.GA32839@elstar.local> In-Reply-To: <20101221085447.GA32839@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [secdir] secdir review of draft-ietf-sipcore-keep-10.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, 21 Dec 2010 10:31:47 -0000 Hi Juergen, Thanks for your comments! I will do the changes as suggested. Regards, Christer =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: 21. joulukuuta 2010 10:55 > To: iesg@ietf.org; secdir@ietf.org;=20 > draft-ietf-sipcore-keep.all@tools.ietf.org > Subject: secdir review of draft-ietf-sipcore-keep-10.txt >=20 > I have reviewed this document as part of the security=20 > directorate's ongoing effort to review all IETF documents=20 > being processed by the IESG. These comments were written=20 > primarily for the benefit of the security area directors. =20 > Document editors and WG chairs should treat these comments=20 > just like any other last call comments. >=20 > This document discusses how to negotiate the usage of=20 > keep-alive messages using a new SIP "keep" Via header field.=20 > The document appears to be well worked out and the security=20 > considerations seem to be adequate. I spotted to mostly=20 > editorial nits in the security > considerations: >=20 > a) [...] This specification does not specify a connection > reuse mechanism, and it does it address security issues related to > connection reuse. [...] >=20 > s/it does it/it does not/ >=20 > b) [...] They do not instruct the enity to > place a value in a "keep" parameter of any request it=20 > forwards. [...] >=20 > s/enity/entity/ >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > = From pkyzivat@cisco.com Tue Dec 21 06:23:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E633A68AE; Tue, 21 Dec 2010 06:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.435 X-Spam-Level: X-Spam-Status: No, score=-110.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3tRv6OjrRNx; Tue, 21 Dec 2010 06:23:20 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B13593A6894; Tue, 21 Dec 2010 06:23:20 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE9HEE2tJV2b/2dsb2JhbACkCHOkRZt+hUkEhGWGHYMY X-IronPort-AV: E=Sophos;i="4.60,208,1291593600"; d="scan'208";a="195300820" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 21 Dec 2010 14:25:16 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBLEPFrT026054; Tue, 21 Dec 2010 14:25:15 GMT Message-ID: <4D10B8CB.8070902@cisco.com> Date: Tue, 21 Dec 2010 09:25:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org References: <20101221090126.GB32839@elstar.local> In-Reply-To: <20101221090126.GB32839@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Dec 2010 07:14:13 -0800 Subject: Re: [secdir] secdir review of draft-ietf-sipping-sip-offeranswer-13.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, 21 Dec 2010 14:23:21 -0000 Juergen, On 12/21/2010 4:01 AM, Juergen Schoenwaelder wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I reviewed draft-ietf-sipping-sip-offeranswer-10 back in Feburary 2009 > and my comments do not seem to have caused changes to the document as > far as I read the diffs. My original comments can be found here: > > http://www.ietf.org/mail-archive/web/secdir/current/msg00460.html I'm sorry - I didn't realize these had not been picked up. (This document has had a long slog.) We will have to discuss, and get back to you with some text. Thanks, Paul From new-work-bounces@ietf.org Tue Dec 21 09:35:56 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 59D673A6B37; Tue, 21 Dec 2010 09:35:56 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AC24D3A6A6F; Tue, 21 Dec 2010 09:35:55 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20101221173555.AC24D3A6A6F@core3.amsl.com> Date: Tue, 21 Dec 2010 09:35:55 -0800 (PST) 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: Wed, 22 Dec 2010 12:25:58 -0800 Subject: [secdir] [new-work] WG Review: ControLling mUltiple streams for TElepresence (clue) 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, 21 Dec 2010 17:35:56 -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, December 28, 2010. ControLling mUltiple streams for TElepresence (clue) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-08 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: TBD Description of Working Group: In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows. The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience. This working group is chartered to specify the following information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams * Usage of the stream, for example whether the stream is presentation, or document camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, syntax, and transport mechanism for communicating the necessary information. It will consider whether existing protocols for signaling, messaging and transport are adequate or need to be extended. Any extensions to IETF protocols will be done in appropriate WGs, for example extensions to SDP in MMUSIC. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as specifying the audio and video streams for defined speakers. Specifying the location of the current speakers relative to display microphones needs to be provided dynamically as speakers move. As part of the receiver telling the sender what it wants dynamically, explicit receiver notification to the sender of the desired video stream and video pause will be considered. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple RTP audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate. Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas (e.g., OPS and SEC), and working groups including AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Goals and Milestones: Jul 2011 Submit informational draft to IESG on use cases Jul 2011 Submit informational draft to IESG on framework and requirements Nov 2011 Submit standards track specification(s) to IESG to support framework and requirements _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Dec 21 11:59: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 D5B473A6A6C; Tue, 21 Dec 2010 11:59:27 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE4A3A6BBA for ; Fri, 17 Dec 2010 10:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.628 X-Spam-Level: X-Spam-Status: No, score=-8.628 tagged_above=-999 required=5 tests=[AWL=1.971, 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 LYxVxZ50mGiR for ; Fri, 17 Dec 2010 10:45:48 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 0E9E73A6993 for ; Fri, 17 Dec 2010 10:45:47 -0800 (PST) Received: from 30-5-33.wireless.csail.mit.edu ([128.30.5.33]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PTfL4-0004DS-0m for new-work@ietf.org; Fri, 17 Dec 2010 13:47:34 -0500 From: Philippe Le Hegaret To: new-work@ietf.org Organization: World Wide Web Consortium Date: Fri, 17 Dec 2010 13:47:28 -0500 Message-ID: <1292611648.8577.41.camel@chacal> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 X-Mailman-Approved-At: Tue, 21 Dec 2010 11:59:26 -0800 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: Wed, 22 Dec 2010 12:25:58 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Performance Interest Group (until 2010-01-28) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 19:59:28 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Performance Interest Group: http://www.w3.org/2010/10/webperf-ig.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2010-01-28 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Philippe Le Hegaret, Interaction Domain Leader . Thank you, Philippe Le Hegaret, Interaction Domain Lead [0] http://www.w3.org/2006/rwc/Activity.html [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Dec 21 11:59: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 E628B3A6B4B; Tue, 21 Dec 2010 11:59:27 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDAC3A6C3F for ; Fri, 17 Dec 2010 13:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poE1bIOcUvby for ; Fri, 17 Dec 2010 13:23:50 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 1750D3A6C3C for ; Fri, 17 Dec 2010 13:23:30 -0800 (PST) Received: from c-67-186-132-15.hsd1.ma.comcast.net ([67.186.132.15] helo=[192.168.0.186]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1PThnh-0005Yx-8V for new-work@ietf.org; Fri, 17 Dec 2010 16:25:17 -0500 From: Matt Womer Date: Fri, 17 Dec 2010 16:25:16 -0500 Message-Id: <2AABCBD5-0396-44A5-B6F5-243C8B1852CA@w3.org> To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 21 Dec 2010 11:59:26 -0800 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: Wed, 22 Dec 2010 12:25:58 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Geolocation Working Group (until 28 January 2011) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 19:59:28 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Ubiquitous Web Applications Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Geolocation Working Group: http://www.w3.org/2008/geolocation/charter/charter-2.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 28 January 2011 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact me, Matt Womer, Ubiquitous Web Applications Activity Lead . Thank you, -Matt Womer Ubiquitous Web Applications Activity Lead [0] http://www.w3.org/2007/uwa/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From keith.drage@alcatel-lucent.com Wed Dec 22 08:00: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 5C9333A6B85; Wed, 22 Dec 2010 08:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.667 X-Spam-Level: X-Spam-Status: No, score=-103.667 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq7+o-mrjKXK; Wed, 22 Dec 2010 08:00:51 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 57E7D3A6B87; Wed, 22 Dec 2010 08:00:51 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oBMG2LTc027406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Dec 2010 17:02:21 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 22 Dec 2010 17:02:21 +0100 From: "DRAGE, Keith (Keith)" To: Dan Wing , "'Tobias Gondrom'" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-avt-rtp-cnames.all@tools.ietf.org" Date: Wed, 22 Dec 2010 17:02:19 +0100 Thread-Topic: secdir review of draft-ietf-avt-rtp-cnames-02 Thread-Index: AcubJ4eHjcpZjn6VSrmBjIHzK3CylgAEajAQAa3NHeA= Message-ID: References: <4D06BD5F.5040807@gondrom.org> <220d01cb9be5$b57179c0$20546d40$@com> In-Reply-To: <220d01cb9be5$b57179c0$20546d40$@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-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 X-Mailman-Approved-At: Wed, 22 Dec 2010 12:25:58 -0800 Cc: "abegen@cisco.com" , "csp@csperkins.org" , "even.roni@huawei.com" , "rjsparks@nostrum.com" Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-cnames-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, 22 Dec 2010 16:00:53 -0000 Just coming back on the following: > > 2.3. in section 4.2. next to last paragraph it states:=20 > (other methods)=20 > > "beyond the three methods listed above, are not compliant with this=20 > > specification and SHOULD NOT be used." > > If the document is std track and updates 3550 and uses=20 > "MUST" for the=20 > > methods it would be inconsistent to frame it here as "SHOULD NOT". >=20 > We will delete the sentence that says: >=20 > Other methods, beyond the=09 > three methods listed above, are not compliant with this=20 > specification=09 > and SHOULD NOT be used. >=20 > because it is really saying "if you don't comply with this=20 > document's requirements, you aren't in compliance with this=20 > document" -- which is a silly thing to say. >=20 This sentence was added as a result of my comment in the document shepherd = review as follows: "1) Section 3 contains the following statement: The recommendation in [RFC3550] is to generate an RTCP CNAME of the form "user@host" for multiuser systems, or "host" if the username is not available. The "host" part is specified to be the fully qualified domain name (FQDN) of the host from which the real-time data originates. While this guidance was appropriate at the time [RFC3550] was written, FQDNs are no longer necessarily unique, and can sometimes be common across several endpoints in large service provider networks. Thus, the use of FQDN as the CNAME is strongly discouraged. Given the statement above, can you point me at the SHOULD requirement that = I would expect to see relating to this in section 4." So if we no longer have that added text in section 4, then we need to go ba= ck and revisit section 3, and particularly the sentence: "Thus, the use of = FQDN as the CNAME is strongly discouraged." because it no longer is discour= aged by this document. An alternative statement in section 3 would be: "This document replaces the= use of FQDN as a CNAME by alternative mechanisms." regards Keith =20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Tuesday, December 14, 2010 11:22 PM > To: 'Tobias Gondrom'; iesg@ietf.org; secdir@ietf.org;=20 > draft-ietf-avt-rtp-cnames.all@tools.ietf.org > Cc: abegen@cisco.com; csp@csperkins.org; DRAGE, Keith=20 > (Keith); even.roni@huawei.com; rjsparks@nostrum.com > Subject: RE: secdir review of draft-ietf-avt-rtp-cnames-02 >=20 > -----Original Message----- > > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > > Sent: Monday, December 13, 2010 4:42 PM > > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-avt-rtp-=20 > > cnames.all@tools.ietf.org > > Cc: abegen@cisco.com; csp@csperkins.org; dwing@cisco.com;=20 > > keith.drage@alcatel-lucent.com; even.roni@huawei.com;=20 > > rjsparks@nostrum.com > > Subject: secdir review of draft-ietf-avt-rtp-cnames-02 > >=20 > > I have reviewed this document as part of the security directorate's=20 > > ongoing effort to review all IETF documents being processed by the=20 > > IESG. These comments were written primarily for the benefit of the=20 > > security area directors. Document editors and WG chairs=20 > should treat=20 > > these comments just like any other last call comments. >=20 > Tobias,=20 >=20 > Thanks for your review. >=20 > > The Security Considerations section is ok and the draft=20 > does not add=20 > > further security aspects beyond it. > > However there are a number of issues with the draft,=20 > including use of > > rfc2119 language and hash agility: > >=20 > > 1. section 4.2 first bullet point: > > spelling: > > s/"and endpoint MUST generate and store a Universally"/"an endpoint=20 > > MUST generate and store a Universally" >=20 > Will be fixed in -03, thanks. >=20 > > 2. COMMENTS/DISCUSS: > > section 4.2: the draft makes the distinction between 4 cases: > > a) long-term persistent > > b) short-term persistent with IPv6 > > c) short-term persistent with IPv4 > > d) per-session RTCP CNAME > > all use MUST to specify the generated CNAME with=20 > _different_ methods. > >=20 > > This raises a number of potential issues: > > 2.1. The boundary between the definition of long-term and=20 > short-term=20 > > with persistence across several related RTP sessions (see=20 > 4.1) is not=20 > > well defined, thus different MUST clauses for how to treat=20 > these two=20 > > cases seem problematic. As it can be hard for an application to=20 > > determine the difference between across several sessions=20 > and long-term. >=20 > It is explained in Section 4.1's paragraph 2 and 3, which=20 > essentially say that short-term is per each RTP session and=20 > necessary for lipsync, while long-term is across several RTP=20 > sessions and useful for third- party monitoring of RTP=20 > performance. Are those descriptions inadequate for=20 > implementers to determine which they want? >=20 > > 2.2. Though I understand why a system may not want to use=20 > UUID in all=20 > > four cases, it is unclear to me why it should be forbidden=20 > to use UUID=20 > > for scenarios b, c and d. (which is implied by using "MUST"=20 > with the=20 > > defined method). >=20 > UUID is a persistent and permanent identifier, so can't be=20 > used with d (per-session). However, you have a good point=20 > that it is equally useful for b (short-term IPv6) and c=20 > (short-term IPv4). See more on that below. >=20 > > 2.3. in section 4.2. next to last paragraph it states:=20 > (other methods)=20 > > "beyond the three methods listed above, are not compliant with this=20 > > specification and SHOULD NOT be used." > > If the document is std track and updates 3550 and uses=20 > "MUST" for the=20 > > methods it would be inconsistent to frame it here as "SHOULD NOT". >=20 > We will delete the sentence that says: >=20 > Other methods, beyond the=09 > three methods listed above, are not compliant with this=20 > specification=09 > and SHOULD NOT be used. >=20 > because it is really saying "if you don't comply with this=20 > document's requirements, you aren't in compliance with this=20 > document" -- which is a silly thing to say. >=20 >=20 > Based on other reviews, we also added the following new text=20 > at the end of that section: > =20 > It is believed that obtaining uniqueness is an important property > that requires careful evaluation of the method. This document > provides a number of methods, for which it is believed=20 > that at least > one of them would meet all deployment scenarios. This document > therefore does not provide for the implementor to define and select > an alternative method. > =20 > A future specification might define an alternative method for > generating RTCP CNAMEs as long as the proposed method has=20 > appropriate > uniqueness, and there is consistency between the methods used for > multiple RTP sessions that are to be correlated. However, such a > specification needs to be reviewed and approved before deployment. >=20 > > 2.4. Question: which leads to another question: are there upgrade=20 > > issues with 3550-applications with this update or is there=20 > an upgrade=20 > > path for RTP from 3550 to draft-ietf-avt-rtp-cnames? >=20 > CNAME values are opaque strings to remote peers, so there is=20 > no upgrade problem. >=20 > > 2.5. case b (IPv6): I understand that one reason for different=20 > > handling of IPv4 is NAT and private address spaces. And=20 > although NAT=20 > > with IPv6 should not make sense, in theory this could still=20 > happen, so=20 > > I am not sure whether these two cases (b and c) can be and=20 > need to be=20 > > handled differently. > >=20 > > Overall: a solution could be that UUID be allowed for all=20 > methods (e.g. > > frame it as "MUST use one of the here described methods") and maybe=20 > > the unification of case b (short-term IPv6) and c=20 > (short-term IPv4) -=20 > > either allowing both methods for both and indicating preferred=20 > > approaches with "SHOULD" for each of them (e.g. SHOULD use MAC for=20 > > scenarios of possible > > NAT) - unless the authors can explain why we really need=20 > to mandate=20 > > these two different scenarios and why IPv6 has not at least=20 > in theory=20 > > NAT issues? >=20 > If we expect / fear IPv6 NAPT (IPv6 address sharing), I=20 > concur that using an IPv6 address is not safely unique, and=20 > we will eliminate the option where an IPv6 address is used as CNAME. >=20 > Your review highlighted another issue, which had escaped me=20 > until now, with two IPv6-only networks using a NAT64 and the=20 > well-known prefix 64:ff9b::/96 defined by RFC6052. Those two=20 > hosts can't communicate directly with each other over IPv6,=20 > but they could communicate with each other using an=20 > application-level proxy (Session Border Controller) or a=20 > NAT64. And in both cases they would have an RTCP CNAME=20 > collision because their IPv6 addresses are not unique. >=20 > Because of these two problems, we need to remove the option=20 > to use the IPv6 address in CNAME. >=20 > > 3. hash agility: in section 4.2 last paragraph the draft=20 > mandates for=20 > > case d (per-session RTCP CNAMEs ) to use SHA1-HMAC and truncate the=20 > > value to 96bit 3.1. DISCUSS: The drafts should not be tied=20 > to SHA1 and=20 > > actually allow use of other algorithms (e.g. SHA2/SHA-256/-512) as=20 > > well. >=20 > Would adding the following highlighted text be sufficient to clarify: >=20 > NEW: > To generate a per-session RTCP CNAME, an endpoint MUST perform=20 > a Hash-based Message Authentication Code at least as=20 > strong as=20 > ...^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > SHA1-HMAC [RFC2104] on the concatenated values of the RTP=20 > endpoint's > initial SSRC,=20 >=20 > > 3.2. Question: maybe obvious, but why do you need to truncate the=20 > > output to 96bit? >=20 > would adding the following text be sufficient to clarify: >=20 > The output of the hash function is truncated to 96 bits to > provides a reasonable compromise between security and packet > size. >=20 > > 3.3. Clarification: it also states at the end of this=20 > paragraph that=20 > > the "user@" part of the CNAME "is omitted". Does this mean "MAY be=20 > > omitted on single-user systems, and MAY be replaced by an=20 > opaque token=20 > > on multiuser systems" like for cases a-c or is this intentionally=20 > > different and mandatory in d? >=20 > For the last sentence of Section 4.2, would adjusting this=20 > text be sufficient to clarify: >=20 > OLD: > The "user@" part of the RTCP CNAME is omitted when generating > per-session RTCP CNAMEs. > NEW: > In all cases of single- or multi-user systems,=20 > ..^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the "user@" part of the RTCP CNAME is omitted when generating > per-session RTCP CNAMEs. >=20 > -d >=20 > > Kind regards, Tobias > >=20 > >=20 > > Tobias Gondrom > > email: tobias.gondrom@gondrom.org >=20 > = From abegen@cisco.com Wed Dec 22 08:07:32 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF583A6ACA; Wed, 22 Dec 2010 08:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.44 X-Spam-Level: X-Spam-Status: No, score=-10.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 bzeadqis+DWq; Wed, 22 Dec 2010 08:07:31 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E7BB23A6A4B; Wed, 22 Dec 2010 08:07:31 -0800 (PST) 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: AvsEAHWxEU2rR7Ht/2dsb2JhbACkFnOnd5tDhUkEhGaJQQ X-IronPort-AV: E=Sophos;i="4.60,214,1291593600"; d="scan'208";a="306357816" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 22 Dec 2010 16:09:30 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oBMG9UmG025942; Wed, 22 Dec 2010 16:09:30 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 08:09:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Dec 2010 08:09:21 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DFAEF2C@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-avt-rtp-cnames-02 Thread-Index: AcubJ4eHjcpZjn6VSrmBjIHzK3CylgAEajAQAa3NHeAAAIcdwA== References: <4D06BD5F.5040807@gondrom.org> <220d01cb9be5$b57179c0$20546d40$@com> From: "Ali C. Begen (abegen)" To: "DRAGE, Keith (Keith)" , "Dan Wing (dwing)" , "Tobias Gondrom" , , , X-OriginalArrivalTime: 22 Dec 2010 16:09:26.0014 (UTC) FILETIME=[9AB8A1E0:01CBA1F2] X-Mailman-Approved-At: Wed, 22 Dec 2010 12:25:58 -0800 Cc: csp@csperkins.org, even.roni@huawei.com, rjsparks@nostrum.com Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-cnames-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, 22 Dec 2010 16:07:32 -0000 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Wednesday, December 22, 2010 11:02 AM > To: Dan Wing (dwing); 'Tobias Gondrom'; iesg@ietf.org; = secdir@ietf.org; draft-ietf-avt-rtp-cnames.all@tools.ietf.org > Cc: Ali C. Begen (abegen); csp@csperkins.org; even.roni@huawei.com; = rjsparks@nostrum.com > Subject: RE: secdir review of draft-ietf-avt-rtp-cnames-02 >=20 > Just coming back on the following: >=20 > > > 2.3. in section 4.2. next to last paragraph it states: > > (other methods) > > > "beyond the three methods listed above, are not compliant with = this > > > specification and SHOULD NOT be used." > > > If the document is std track and updates 3550 and uses > > "MUST" for the > > > methods it would be inconsistent to frame it here as "SHOULD NOT". > > > > We will delete the sentence that says: > > > > Other methods, beyond the > > three methods listed above, are not compliant with this > > specification > > and SHOULD NOT be used. > > > > because it is really saying "if you don't comply with this > > document's requirements, you aren't in compliance with this > > document" -- which is a silly thing to say. > > >=20 > This sentence was added as a result of my comment in the document = shepherd review as follows: >=20 > "1) Section 3 contains the following statement: >=20 > The recommendation in [RFC3550] is to generate an RTCP CNAME of the > form "user@host" for multiuser systems, or "host" if the username = is > not available. The "host" part is specified to be the fully > qualified domain name (FQDN) of the host from which the real-time > data originates. While this guidance was appropriate at the time > [RFC3550] was written, FQDNs are no longer necessarily unique, and > can sometimes be common across several endpoints in large service > provider networks. Thus, the use of FQDN as the CNAME is strongly > discouraged. >=20 > Given the statement above, can you point me at the SHOULD requirement = that I would expect to see relating to this in > section 4." >=20 > So if we no longer have that added text in section 4, then we need to = go back and revisit section 3, and particularly the > sentence: "Thus, the use of FQDN as the CNAME is strongly = discouraged." because it no longer is discouraged by this > document. >=20 > An alternative statement in section 3 would be: "This document = replaces the use of FQDN as a CNAME by alternative > mechanisms." This replacement works. Thanks, acbegen. =20 > regards >=20 > Keith From alper.yegin@yegin.org Fri Dec 24 12:57: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 51F973A686B; Fri, 24 Dec 2010 12:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.825 X-Spam-Level: X-Spam-Status: No, score=-100.825 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 Ut6bpcxSGWWb; Fri, 24 Dec 2010 12:57:23 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 47C6E3A683B; Fri, 24 Dec 2010 12:57:23 -0800 (PST) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MQ4KJ-1PS87u2n1X-0051yh; Fri, 24 Dec 2010 15:59:01 -0500 From: "Alper Yegin" To: "'Alan DeKok'" , References: <4D009D34.1020809@deployingradius.com> <4D01DABF.6060604@toshiba.co.jp> <001101cb9aa0$367b3480$a3719d80$@yegin@yegin.org> <4D064683.30009@deployingradius.com> <4D07A874.4010702@gridmerge.com> <4D07D090.9020407@deployingradius.com> In-Reply-To: <4D07D090.9020407@deployingradius.com> Date: Fri, 24 Dec 2010 22:58:45 +0200 Message-ID: <070601cba3ad$63852150$2a8f63f0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuby82V+EVk4y89Qsim1hbsx9U3iwH4OIZw Content-Language: en-us X-Provags-ID: V02:K0:uGATVOeq0WE9qEefQ6WUdDIzvdbDrjxvfkzyjccSn5b fuDQydRKkokYkSkLNR6BwzBOBi/YzJMqkXOU4zpVhpPuG6Cpz6 gLytTOwXb05R/5hEIN00DwynZg1DUIZWr0IoTjgPvLCZG3c14B y37zgU15QeY8BDUAIwbcKbF9QS7+fdjAbytoMdtIH7SdheSrVB uQ4NDbdIofSMQnxFq9gOz7iYPD6Z2c+buy0QisdLAA= Cc: secdir@ietf.org, paduffy@cisco.com, pana@ietf.org, robert.cragie@gridmerge.com, samitac@ipinfusion.com, 'Ralph Droms' Subject: [secdir] pana-relay security considerations 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, 24 Dec 2010 20:57:24 -0000 Hi Alan, Margaret, Based on the feedback we have received from you, we have enhanced the security considerations section of pana-relay I-D as follows. Please see and let us know your feedback. ------8<---------------------- Security Considerations A PRE's main objective is to assist transport of PANA messages between the PaC and the PAA. Relay operation performed between the PRE and the PAA forms an additional conceptual link for relaying the end-to-end PANA messages between the PaC and the PAA. In that sense, a PRE resembles a bridge or a router that sits between the PaC and the PAA when non-relayed PANA (RFC 5191) is used, however the PRE acts as a protocol-aware relay and thus will only relay valid PANA messages to and from the PaC. A PRE can pose certain threats to the relayed PANA messages. A PRE can delay or drop PANA messages sent by the PaC or the PAA. It can also spoof or modify PANA messages sent towards the PaC or the PAA. These threats are similar to what an on-path bridge/router (i.e., a man-in-the-middle, MitM) can pose to non-relayed PANA. EAP and PANA protocols are designed to operate over unsecure links where aforementioned threats can already exist. Even though these threats cannot be leveraged to gain unauthorized network access, or compromise of cryptographic keys (e.g., MK, MSK, EMSK, etc.), other damages such as preventing authentication to complete, or denial-of service are still possible. Even though the PRE-to-PAA relay path appears to be a separate additional link for transporting the PANA messages, the PRE may pose a few additional risks than traditional on-path bridges and routers. The following explains the risks and mitigations of PRE as a relay device. The PRE inserts PaC-Information AVP as the PaC-generated PANA packet is encapsulated in a PRY packet to the PAA. This AVP carries the IP address and the UDP port number values of the PANA packet as sent by the PAC. These values are already carried inside the IP and UDP headers with non-relayed PANA and they are not necessarily secured. EAP and PANA are designed to work in the absence of their protection. Therefore, no additional PANA-layer security is needed when these values are carried as PANA AVPs between the PRE and the PAA. If a future document defines additional payload AVPs for the PRY messages, there may be a need to define additional security for those messages. A rogue PRE can spoof PANA messages on behalf of a victim PaC and receive the response irrespective of the location of the PRE with respect to the network topology. Achieving the same threat with non-relayed PANA requires the rogue node be a MitM, otherwise the spoofed packets may be dropped by the ingress filtering network elements, or the responses would be directly sent to the victim PaC IP address and may not be received by the rogue node. Nevertheless, such a rogue PRE cannot perform full initial authentication on behalf of the victim PaC unless it also holds the PaC's credentials (including the master key). Furthermore, any spoofed PANA messages after the initial authentication will fail the integrity checks at the PAA when a key-generating EAP method is used. The only state that can change on the PAA upon a rogue PRE sending a spoofed PRY is the IP address and UDP port number of the PRE stored as PANA session attributes, which impacts where the PAA sends the next PANA packet (i.e., to the rogue PRE instead of the legitimate PRE). The PAA also needs to handle the PaC-Information AVP in addition to the PaC-originated PANA message carried in the Relayed-Message AVP, so use of the PRE may impose additional storage requirements on the PAA. As required by this specification, if the relayed PANA packet is invalid, it cannot cause the aforementioned state change. A rogue PRE generating a valid PANA packet requires it be a MitM in order to synch up with the PANA session state and attributes on the PaC. Such a MitM can already disturb the EAP and PANA even without playing the role of a PRE. An unauthorized node pretending as PAA, can spoof the relayed PANA messages to the PRE in order to get them delivered to the PaC. While the harm caused by such spoofed packets are limited (due to the EAP and PANA design with unsecured network operation in mind), processing of bogus packets can cause processing load on the PaC. This specification does not allow the PRE to relay any non-PANA packet (*). Some of the risks stemming from the aforementioned threats are already handled by the EAP and PANA as described. The residual risks shall be mitigated using additional physical or cryptographic security in the network hosting the PREs and the PAAs. Access control lists implemented on the PRE, PAA, or intermediary firewalls supported by cryptographic (e.g., using IPsec, DTLS, L2 security, etc.) or physical authentication/authorization are needed for protecting legitimate PRE and PAAs against rogue ones. Details of exact solutions are outside the scope of this document. PREs do not need to maintain per-PaC state, therefore they are robust against resource consumption DoS (Deniable of Service) attacks. However, PREs may maintain per-PaC state to provide additional security based on the transaction sequence being relayed. (*) need to reflect that to the document body. Will only be checking the UDP port (at least one be 716). From radiaperlman@gmail.com Sun Dec 26 20:02: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 309C93A683E for ; Sun, 26 Dec 2010 20:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZOs+imfZK5l for ; Sun, 26 Dec 2010 20:02:27 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6B9E43A6832 for ; Sun, 26 Dec 2010 20:02:27 -0800 (PST) Received: by iwn40 with SMTP id 40so8895932iwn.31 for ; Sun, 26 Dec 2010 20:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=mS4tQm1TJHx6hvg3c+nsk5HviBNV0XI9rf8EmtHKCSQ=; b=eZNw/xDKOVOH4qZH6sLM+2s1UD7Mf+ApqpVSYZXhEhr1F6O50PX3aTuZFed83FPAHV VMP/ox0iYMmldbiRlSGqWWgAcg13VAIq2GG31b0jqg+UWbGffkOJrb3NatGB9kY2go2X 5s1IpYNgSFsmTRn9U+aX4n6zW791vzQu/F2IE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uhtK1bY4FeKAFEZ1WYBOuY7E9LFpOwbLeHuha5gzLthKnXCEIlWFhfCD4u4S359GJl TR7KPBkdCA50aASyZKLqe7jJpEYzjHViQxYfhg4KDmd9NsXrYfLm0KWDDmNgU85Mewpm uDdGhdGH9TM1572KhjjUf/obRrc0EnatBK4so= MIME-Version: 1.0 Received: by 10.42.170.1 with SMTP id d1mr12033846icz.227.1293422671867; Sun, 26 Dec 2010 20:04:31 -0800 (PST) Received: by 10.42.220.199 with HTTP; Sun, 26 Dec 2010 20:04:31 -0800 (PST) Date: Sun, 26 Dec 2010 20:04:31 -0800 Message-ID: From: Radia Perlman To: draft-ietf-mpls-tp-uni-nni.all@ietf.all, secdir@ietf.org, iest@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] secdir review of draft-ietf-mpls-tp-uni-nni-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, 27 Dec 2010 04:02:28 -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 very short document slightly updates the definitions of the Transport service interfaces from "span" to "reference point", updating RFC 5921. As the authors accurately say in the security considerations section, "the security considerations of [RFC5921] apply. The updated reference models provided by this document introduce no new security considerations." Radia From tlyu@mit.edu Wed Dec 29 19:58: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 AF3363A68F8; Wed, 29 Dec 2010 19:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.335 X-Spam-Level: X-Spam-Status: No, score=-100.335 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_05=-1.11, 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 bWjgjVXjlPWR; Wed, 29 Dec 2010 19:58:28 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by core3.amsl.com (Postfix) with ESMTP id 0FF9A3A63D3; Wed, 29 Dec 2010 19:58:27 -0800 (PST) X-AuditID: 1209190e-b7b3bae000000a71-9a-4d1c03e04d56 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with SMTP id 77.52.02673.0E30C1D4; Wed, 29 Dec 2010 23:00:32 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id oBU40V5i010332; Wed, 29 Dec 2010 23:00:32 -0500 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 oBU40OE7026948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Dec 2010 23:00:28 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id oBU40Os9000640; Wed, 29 Dec 2010 23:00:24 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-v6ops-tunnel-loops.all@tools.ietf.org From: Tom Yu Date: Wed, 29 Dec 2010 23:00:24 -0500 Message-ID: Lines: 27 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Subject: [secdir] secdir review of draft-ietf-v6ops-tunnel-loops-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 03:58:30 -0000 This document describes routing loop vulnerabilities inherent in the existing design of IPv6-in-IPv4 tunneling protocols, and suggests mitigation strategies. While the Security Considerations section of this document claims that the recommended checks do not introduce new security threats, Section 3.1 mentions that the additional processing overhead for checking destination and source addresses may be considerable. It would be useful to have measurements or estimates of how this additional processing overhead compares to the effects of the routing loop attack that it is intended to mitigate. This document makes no mention of the Teredo attacks that are discussed in the USENIX WOOT paper. The authors may wish to mention draft-gont-6man-teredo-loops-00 for the sake of completeness. Editorial: Section 3 lists three categories of mitigation measures but the accompanying text states that they fall under two categories. In Section 3.1, in the sentence "However, this approach has some inherit limitations", replace "inherit" with "inherent". In Section 4, in the sentence "...other mitigation measures may be allowed is specific deployment scenarios", replace "may be allowed is" with "may be feasible in". From fred@cisco.com Wed Dec 29 23:42: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 21B183A67F2; Wed, 29 Dec 2010 23:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.385 X-Spam-Level: X-Spam-Status: No, score=-110.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPGZA1um5122; Wed, 29 Dec 2010 23:42:18 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C16283A6889; Wed, 29 Dec 2010 23:42:18 -0800 (PST) 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: AvsEAA7HG02rRN+J/2dsb2JhbACkOnOkcZodhUoEhGWGH4sy X-IronPort-AV: E=Sophos;i="4.60,248,1291593600"; d="scan'208";a="643025754" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 30 Dec 2010 07:44:24 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oBU7iOkk026516; Thu, 30 Dec 2010 07:44:24 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Wed, 29 Dec 2010 23:44:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <64AE925C-9A79-433C-A3A7-90FF523C0321@cisco.com> References: To: Tom Yu X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Chairs , "iesg@ietf.org IESG" , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-v6ops-tunnel-loops-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 07:42:20 -0000 Question for you. I have left the authors off the paper for the moment. Mr Gont has recently posted a draft: http://tools.ietf.org/html/draft-gont-6man-teredo-loops "Mitigating Teredo Rooting Loop Attacks", Fernando Gont, 7-Sep-10, and is pushing for adoption as a working group draft. When asked to = consider merging his paper with this or another draft, he has been = unwilling. The chairs have basically told him to discuss his draft on = the list "and we'll see where it goes".=20 One of your criticisms of this draft is that it doesn't cover his USENIX = material. Would you prefer that this and Mr Gont's draft be merged?=20 On Dec 29, 2010, at 8:00 PM, Tom Yu wrote: > This document describes routing loop vulnerabilities inherent in the > existing design of IPv6-in-IPv4 tunneling protocols, and suggests > mitigation strategies. >=20 > While the Security Considerations section of this document claims that > the recommended checks do not introduce new security threats, Section > 3.1 mentions that the additional processing overhead for checking > destination and source addresses may be considerable. It would be > useful to have measurements or estimates of how this additional > processing overhead compares to the effects of the routing loop attack > that it is intended to mitigate. >=20 > This document makes no mention of the Teredo attacks that are > discussed in the USENIX WOOT paper. The authors may wish to mention > draft-gont-6man-teredo-loops-00 for the sake of completeness. >=20 > Editorial: >=20 > Section 3 lists three categories of mitigation measures but the > accompanying text states that they fall under two categories. >=20 > In Section 3.1, in the sentence "However, this approach has some > inherit limitations", replace "inherit" with "inherent". >=20 > In Section 4, in the sentence "...other mitigation measures may be > allowed is specific deployment scenarios", replace "may be allowed is" > with "may be feasible in". From magnusn@gmail.com Thu Dec 30 18:00: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 34ECF28C0D7; Thu, 30 Dec 2010 18:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.686 X-Spam-Level: X-Spam-Status: No, score=-3.686 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68-ZwEQulzLm; Thu, 30 Dec 2010 18:00:42 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 01A7228B56A; Thu, 30 Dec 2010 18:00:41 -0800 (PST) Received: by iyi42 with SMTP id 42so11022784iyi.31 for ; Thu, 30 Dec 2010 18:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=i+NUPRrzP/D3TvIKcutK29tD5tWjeOTVUXk/5P4syKs=; b=xL/QFUnSWPUUVl9B7Rbe7Wb3lCvkqdJh2KOOlP1ao0Ixk3VAADVlt1obfGwHZrlqrb +3l6uTt7fFPL5xywJrafQhn4Dg9VCiW/Iw7qUwBne/EmiGePsFPes8i86+eYpWF8fNj5 WM74iFQjfl16ayc8TkN/zkiJM+mMaVh/rLq6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u4tCiOJlQcbw9qIL4wEjmhbevSKjACersGRIT+anh0y4QpY+kxjsHACptQCxC8t4gf smcWze8pIiBL8WBhhBYv+iUIW52q4dGHgrDtyRiIUEnrdmQyNdyFGaT+m8frMK7Zf2ur GRcLh4yHOA2OxVN+zG1GVIEXcSav0mmrl4F1E= MIME-Version: 1.0 Received: by 10.231.149.194 with SMTP id u2mr17067958ibv.32.1293760967596; Thu, 30 Dec 2010 18:02:47 -0800 (PST) Received: by 10.231.33.70 with HTTP; Thu, 30 Dec 2010 18:02:47 -0800 (PST) Date: Thu, 30 Dec 2010 18:02:47 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: draft-ietf-ccamp-gmpls-g-694-lambda-labels@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-ietf-ccamp-gmpls-g-694-lambda-labels-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: Fri, 31 Dec 2010 02:00:43 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a new lambda (wavelength) label format for use in GMPLS signaling and routing. I have no particular security concerns with this document. A few editorial comments: - General: The document seems to be in need of a proof-read; there are several examples where the wordings make the intent behind a sentence unclear - I cite some of them below. - Section 2: "The Label_Set object is made by only one sub channel that must be same as the Upstream_Label object": Suggest changing to something like (if I did not misunderstand the intent with this sentence): "The Label_set object shall contain a single sub-channel that must be the same as the Upstream_Label object" - Section 2, last paragraph is unclear and should preferably be re-written for clarity. - Section 3.1, third paragraph, unclear - Sectoin 3.1, why state that n is a two's complement integer? Seems simpler to state it is just an integer? (it does make sense to state it in 3.2, however) -- Magnus