review of draft-ietf-v6ops-3177bis-end-sites-00.txt

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: ,