From weiler@watson.org Fri May 1 17:38:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1B83A67FA for ; Fri, 1 May 2009 17:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 hi4n4z5FCl6B for ; Fri, 1 May 2009 17:38:11 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B2A033A6359 for ; Fri, 1 May 2009 17:38:11 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n420dYfT051159 for ; Fri, 1 May 2009 20:39:34 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n420dY8a051156 for ; Fri, 1 May 2009 20:39:34 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 1 May 2009 20:39:34 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Sat, 02 May 2009 01:39:34 +0100 (BST) Subject: [secdir] assignments for May 5th and 8th 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: Sat, 02 May 2009 00:38:12 -0000 We have a large stack of never-reviewed docs on the telechat agenda next week. Please check for your name. (Mine's there, too; I understand the pain.) Ran Canetti is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-05-07 (please review by Tuesday) Rob Austein T draft-p2pi-cooper-workshop-report-01 Phillip Hallam-Baker TR draft-ietf-radext-design-07 Angelos Keromytis T draft-ietf-isms-secshell-16 Julien Laganier T draft-ietf-isms-tmsm-17 Barry Leiba T draft-ietf-isms-transport-security-model-13 Vidya Narayanan T draft-ncook-urlauth-accessid-02 Magnus Nystrom T draft-ietf-mpls-p2mp-te-mib-09 Eric Rescorla T draft-ietf-isms-radius-usage-06 Sam Weiler T draft-thomson-beep-async-02 Glen Zorn T draft-ietf-roll-indus-routing-reqs-05 For telechat 2009-05-21 Catherine Meadows TR draft-groves-megaco-pkgereg-03 Last calls and special requests: Derek Atkins draft-ietf-roll-building-routing-reqs-05 Derek Atkins draft-ietf-mpls-tp-gach-gal-04 Rob Austein draft-ietf-sip-ua-privacy-07 Richard Barnes draft-ietf-sipping-update-pai-09 Pat Cain R draft-crocker-email-arch-12 Pat Cain draft-levine-rfb-01 Ran Canetti draft-ietf-avt-seed-srtp-11 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Steve Hanna draft-peterson-rai-rfc3427bis-01 David Harrington R draft-ietf-rmt-pi-norm-revised-11 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Vidya Narayanan draft-ietf-sip-saml-06 Joe Salowey draft-ietf-geopriv-lis-discovery-10 Hannes Tschofenig draft-ietf-pce-monitoring-04 Carl Wallace draft-ietf-ltru-4646bis-21 Sam Weiler draft-chown-v6ops-rogue-ra-03 Brian Weis draft-ietf-pce-p2mp-app-01 Nico Williams draft-ietf-v6ops-ra-guard-02 Nico Williams draft-ietf-dkim-overview-11 Tom Yu draft-ietf-dkim-rfc4871-errata-04 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 Glen Zorn draft-ietf-geopriv-sip-lo-retransmission-02 From barryleiba.mailing.lists@gmail.com Sat May 2 13:32:18 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB753A6BAD; Sat, 2 May 2009 13:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bap-gkfA8pKq; Sat, 2 May 2009 13:32:17 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 86B603A695D; Sat, 2 May 2009 13:32:16 -0700 (PDT) Received: by fxm2 with SMTP id 2so2881642fxm.37 for ; Sat, 02 May 2009 13:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fy2uYmSw5rN/Pkf8xt7e0mSigt4cAQWXutHm2qCKnpg=; b=JtsOIL/Vu3SllFQvuERsB4hMdgtE2xwH3vSN2+JDDIQ3QgZkX/5JBkBk5VqcugSMZ/ ye3gp/fLPg1TlQFB9c0sV0R1sXHDrTYRb2RkvXPQWnxR4kLpmLkgTQHeA6qhOkSSJAta zEpNLZ7aDQ2rC+Kh5r3lG1yjBkjUA9tIX/AHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=WfVkeWoNpOxGGx/5RDCnLeYIkgt3GHhDqtMAf9iaIcd/4t1TLq5RjYjy8XthXuaTW2 siP9Clb+KFNDrjMFaWMU+zpzTYqwigei5swnFVwbHOT0CSNlcw4O52RudN09feRZ5IIO vQBpqk0yHp2FwsQoQoRj7V6T+I3P/neui+idI= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.223.108.211 with SMTP id g19mr1508050fap.39.1241296418792; Sat, 02 May 2009 13:33:38 -0700 (PDT) Date: Sat, 2 May 2009 16:33:38 -0400 X-Google-Sender-Auth: 583d759322804ec8 Message-ID: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> From: Barry Leiba To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 20:32: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 defines a type of Security Model, as defined in RFC 3411, designed to go with a Transport Model, as defined in draft-ietf-isms-tmsm. I have no expertise in MIBs, and must presume that people who do have reviewed this. For that matter, I don't have expertise in SNMP, so please take these comments with that in mind. I've briefly gone through the associated documents, and I think I understand how the pieces fit into the architecture, but my understanding isn't thorough. My comments: Section 1.5: bullets 1 & 2 use normative RFC 2119 language. Should bullets 4 & 5 do so also? E.g., "A Security Model SHOULD NOT require changes to the SNMP architecture." Section 2.1.1: I'm confused by this. RFC 3411 section 3.1.1.4.1 says that a Security Model specifies "the security protocols used to provide security services such as authentication and privacy." Yet this section says that the Transport Security Model does NOT provide these things. And if it doesn't provide them, how can the admonition to use it "with a Transport Model that provides appropriate security" be a SHOULD, and not a MUST (noting that "appropriate" security could include no authentication, if that's appropriate to the system in question)? Some component has to take responsibility for the security, even if it's to determine that no authentication or no privacy controls are needed. The same goes for the discussion of this in section 8, Security Considerations. "The security threats and how these threats are mitigated should be covered in detail in the specifications of the Transport Models and the underlying secure transports." It looks like this needs to be stronger than plain-English "should", or RFC 2119 "SHOULD", no? I think this is a key point to make clear, so it's well understood where the responsibility lies for the assurance of "appropriate" security in the Transport Model, and what happens when a system uses multiple Security Models, one of which is this one. Again, my confusion here might simply be due to my understanding of the architecture being only superficial. Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From magnus@rsa.com Sun May 3 14:48:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365653A6F59; Sun, 3 May 2009 14:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoE8nH-c41YB; Sun, 3 May 2009 14:48:05 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id BBFA53A6B60; Sun, 3 May 2009 14:47:53 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n43Ln7pP020856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 May 2009 17:49:07 -0400 (EDT) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Sun, 3 May 2009 17:48:56 -0400 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.10.43]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n43Lmsq6015094; Sun, 3 May 2009 17:48:54 -0400 Received: from CORPUSMX50B.corp.emc.com ([128.221.62.41]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 17:48:53 -0400 Received: from W-JNISBETTEST-1 ([10.4.5.130]) by CORPUSMX50B.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 17:48:19 -0400 Date: Sun, 3 May 2009 23:48:49 +0200 (W. Europe Daylight Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, adrian@olddog.co.uk, s.yasukawa@hco.ntt.co.jp, tom.nadeau@bt.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 03 May 2009 21:48:19.0238 (UTC) FILETIME=[DF3DE460:01C9CC38] X-EMM-EM: Active Cc: swallow@cisco.com, secdir-secretary@ietf.org, martin.vigoureux@alcatel-lucent.com, loa@pi.nu Subject: [secdir] SecDir review of draft-ietf-mpls-p2mp-te-mib-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 21:48:06 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Background ---------- This document describes managed objects for point-to-multipoint MultiProtocol Label Switching based traffic engineering. Comments -------- This draft reads well to me and the examples of use of the managed objects are very helpful. In Section 4.2, several MPLS-TE-STD-MIB objects with changed semantics in the context of MPLS-TE-P2MP-STD-MIB are described, for example mplsTunnelXCPointer. The text states that in the case of P2MP MPLS, the value for several of these objects SHOULD be set to 0 (or 0.0). Should not this be a "SHALL/MUST" rather than a "SHOULD" for P2MP TE systems? This since if a P2MP TE system does not set them to zero but to some other value, it seems as if a legacy P2P MPLS systems reading the same objects could become confused (I realize that not setting these objects' values to zero will not hurt other P2MP TE systems as they ignore these objects anyway). In Section 8, Even though the acronyms VACM and USM are spelled out in -09, it would be helpful for the reader with a reference to the documents specifying these modules (RFC 3415 and RFC 3414, I believe) -- Magnus From adrian@olddog.co.uk Sun May 3 14:57:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F34E3A696C; Sun, 3 May 2009 14:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh4VAvKDG79Q; Sun, 3 May 2009 14:57:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 30B3128C11C; Sun, 3 May 2009 14:56:46 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n43LvU7n025888; Sun, 3 May 2009 22:57:30 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n43LvRAn025879; Sun, 3 May 2009 22:57:29 +0100 Message-ID: From: "Adrian Farrel" To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= , , , , References: Date: Sun, 3 May 2009 22:53:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: swallow@cisco.com, secdir-secretary@ietf.org, martin.vigoureux@alcatel-lucent.com, loa@pi.nu Subject: Re: [secdir] SecDir review of draft-ietf-mpls-p2mp-te-mib-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 21:57:19 -0000 Thanks Magnus, Helpful comments. We'll look at the SHOULD/MUST and add the references. Will probably wait for a respin for other reasons. Cheers, Adrian ----- Original Message ----- From: "Magnus Nyström" To: ; ; ; ; Cc: ; ; ; Sent: Sunday, May 03, 2009 10:48 PM Subject: SecDir review of draft-ietf-mpls-p2mp-te-mib-09 >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. > > Background > ---------- > This document describes managed objects for point-to-multipoint > MultiProtocol Label Switching based traffic engineering. > > Comments > -------- > This draft reads well to me and the examples of use of the managed objects > are very helpful. > > In Section 4.2, several MPLS-TE-STD-MIB objects with changed semantics in > the context of MPLS-TE-P2MP-STD-MIB are described, for example > mplsTunnelXCPointer. The text states that in the case of P2MP MPLS, the > value for several of these objects SHOULD be set to 0 (or 0.0). Should not > this be a "SHALL/MUST" rather than a "SHOULD" for P2MP TE systems? This > since if a P2MP TE system does not set them to zero but to some other > value, it seems as if a legacy P2P MPLS systems reading the same objects > could become confused (I realize that not setting these objects' values to > zero will not hurt other P2MP TE systems as they ignore these objects > anyway). > > In Section 8, Even though the acronyms VACM and USM are spelled out > in -09, it would be helpful for the reader with a reference to the > documents > specifying these modules (RFC 3415 and RFC 3414, I believe) > > -- Magnus > From tim.polk@nist.gov Sun May 3 17:52:08 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF2928C12C; Sun, 3 May 2009 17:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 geBZKPuRL+nC; Sun, 3 May 2009 17:52:07 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id B8FF73A63D3; Sun, 3 May 2009 17:50:39 -0700 (PDT) Received: from h222208.nist.gov (h222208.nist.gov [129.6.222.208]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n440px6F017457; Sun, 3 May 2009 20:52:00 -0400 Message-Id: <8DE8F3AC-23D9-4B14-BCD2-6A7E9DB9ECC0@nist.gov> From: Tim Polk To: saag@ietf.org, secdir@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 3 May 2009 20:51:59 -0400 X-Mailer: Apple Mail (2.930.3) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Subject: [secdir] Recruiting Co-Chairs for msec and hokey X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 00:52:08 -0000 Pasi and I would appreciate nominations for co-chair positions for two working groups within the Security Area. The positions are co-chair for msec and hokey. The msec working group has been chaired by Brian Weis for the last year. While he has performed commendably, a co-chair is needed since Brian is also author of some wg documents. The hokey working group has been chaired by Glen Zorn and Charles Clancy since its inception. Charles has accepted new responsibilities that preclude active participation as chair in the future. If you would like to be considered for one of these position, or wish to nominate someone else, please contact Pasi or me directly. From gwz@net-zen.net Sat May 2 00:48:25 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D63F3A69B3 for ; Sat, 2 May 2009 00:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_20=-0.74, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVnZnYyBFFoi for ; Sat, 2 May 2009 00:48:24 -0700 (PDT) Received: from smtpout04.prod.mesa1.secureserver.net (smtpout04-01.prod.mesa1.secureserver.net [64.202.165.196]) by core3.amsl.com (Postfix) with SMTP id 6DF863A6B1C for ; Sat, 2 May 2009 00:48:24 -0700 (PDT) Received: (qmail 18651 invoked from network); 2 May 2009 07:49:47 -0000 Received: from unknown (210.57.242.59) by smtpout04.prod.mesa1.secureserver.net (64.202.165.196) with ESMTP; 02 May 2009 07:49:47 -0000 From: "Glen Zorn" To: , , , , , Date: Sat, 2 May 2009 16:49:43 +0900 Organization: Network Zen Message-ID: <001301c9cafa$9032c190$b09844b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnK+o4xP8QC66J4SHWIV/nhh+XT0Q== Content-Language: en-us X-Mailman-Approved-At: Sun, 03 May 2009 17:59:11 -0700 Subject: [secdir] secdir review of draft-ietf-roll-indus-routing-reqs-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 07:48:25 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. 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. Grammatical and spelling errors are fairly prevalent; a close check would be beneficial. The page title is hyphenated gobbledygook. The acronym "WSN" is used without previous expansion in section 2.2. In section 2.2.1, s/Form afar/From afar/. There is no "Security Considerations" section. The majority of the references to security have to do with general network or node security, not with the security requirements placed upon the routing protocol itself; this is a serious omission, I think and one that should be rectified before publication. Similarly, a large amount of background information on the operation of industrial plants is given, but little of this information is tied specifically to the routing requirements themselves. In several instances technically extraneous claims are made for the need for some feature, as if these claims were statements of fact. For example, section 8 begins: Various economic factors have contributed to a reduction of trained workers in the plant. The industry as a whole appears to be trying to solve this problem with what is called the "wireless worker". Carrying a PDA or something similar, this worker will be able to accomplish more work in less time than the older, better-trained workers that he or she replaces. There are several other ways in which this could be put (none of them quite as flattering to the corporate bosses) but in any case, irrelevant to the goal of specifying routing requirements. I don't know what an "External Informative Reference" is (section 13.3), nor why one would treat it differently than any other informative reference. ~gwz At one time in the US, in the mid-nineteenth century, working for wage labor was considered not very different from chattel slavery...anyone who thinks it's legitimate to be a wage laborer is internalizing oppression in a way which would have seemed intolerable to people in the mills 150 years ago. -- Noam Chomsky, "Propaganda & the Public Mind" From weiler@watson.org Sun May 3 21:39:45 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1A83A6869; Sun, 3 May 2009 21:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 tGHqs738owUn; Sun, 3 May 2009 21:39:44 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 226D33A6A4F; Sun, 3 May 2009 21:39:43 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n444f8h0063174; Mon, 4 May 2009 00:41:08 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n444f7mV063170; Mon, 4 May 2009 00:41:07 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 4 May 2009 00:41:07 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org, iesg@ietf.org, martin.thomson@andrew.com 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.0.1 (fledge.watson.org [127.0.0.1]); Mon, 04 May 2009 05:41:08 +0100 (BST) Cc: Chris Newman Subject: [secdir] secdir review of draft-thomson-beep-async-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 04:39:45 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a BEEP extension to enable asynchrony. The security considerations section highlights the DOS potential from state accumulation, and I don't think anything more needs to be said. I see no security problems with the document. Process/quality of review: The template for the doc says it was reviewed on the BEEP WG list, but the document doesn't suggest taking discussion there. And BEEP closed in 2002. Typo in section 3.1: s/separate/separated/ I also noticed that there's no list of contributors nor any acknowledgements. Might some be appropriate? -- Sam From Martin.Thomson@andrew.com Sun May 3 23:05:54 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC903A6950; Sun, 3 May 2009 23:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 REOP1jmyl0X2; Sun, 3 May 2009 23:05:53 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 111253A6A68; Sun, 3 May 2009 23:05:22 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_04_01_27_40 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 May 2009 01:27:40 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 01:06:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 4 May 2009 01:06:46 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-thomson-beep-async-02 Thread-Index: AcnMcosTCmzuloQ6Q/67DGQjPonlkQACyQcw References: From: "Thomson, Martin" To: , , X-OriginalArrivalTime: 04 May 2009 06:06:47.0558 (UTC) FILETIME=[81FD5A60:01C9CC7E] X-Mailman-Approved-At: Sun, 03 May 2009 23:12:01 -0700 Cc: Chris Newman Subject: Re: [secdir] secdir review of draft-thomson-beep-async-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 06:05:54 -0000 SGkgU2FtLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuICBJJ2xsIG1ha2Ugc3VyZSB0aGF0IHRo YXQgdHlwbyBpcyBzcXVhc2hlZC4NCg0KPiBJIGFsc28gbm90aWNlZCB0aGF0IHRoZXJlJ3Mgbm8g bGlzdCBvZiBjb250cmlidXRvcnMgbm9yIGFueQ0KPiBhY2tub3dsZWRnZW1lbnRzLiAgTWlnaHQg c29tZSBiZSBhcHByb3ByaWF0ZT8NCg0KTWlzY29uY2VwdGlvbiwgY29uY2VwdGlvbiwgZGVzaWdu LCBhbmQgaW1wbGVtZW50YXRpb24gY2FuIGFsbCBiZSBsYWlkIGF0IG15IGZlZXQuICBUaGUgb25s eSBpbnB1dCBJJ3ZlIHJlY2VpdmVkIG9uIHRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gZWRpdG9yaWFs LiAgUGxlbnR5IG9mIGZlZWRiYWNrLCBidXQgbm90aGluZyBtb3JlIHN1YnN0YW50aXZlIHRoYW4g cXVlc3Rpb25zLiAgSSBndWVzcyB0aGF0J3MgdGhlIG5pY2UgdGhpbmcgd2l0aCBzdWNoIGEgc2lt cGxlIGlkZWEuDQoNCi0tTWFydGluDQoNCiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVu dCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVy d2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRo ZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hp Yml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= From ietfdbh@comcast.net Mon May 4 13:23:38 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFF43A7131 for ; Mon, 4 May 2009 13:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 Vxpy5ghbonUJ for ; Mon, 4 May 2009 13:23:37 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 673CB3A696D for ; Mon, 4 May 2009 13:23:37 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA06.westchester.pa.mail.comcast.net with comcast id nMzY1b0010xGWP856YQvPQ; Mon, 04 May 2009 20:24:55 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id nYR21b00y0UQ6dC3YYR3kV; Mon, 04 May 2009 20:25:04 +0000 From: "David Harrington" To: Date: Mon, 4 May 2009 16:25:01 -0400 Message-ID: <05a401c9ccf6$67ac3550$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnM9ma544Dx/Yr6RNyYA24XSVmxyQ== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'Magnus Westerlund' , tim.polk@nist.gov, Pasi.Eronen@nokia.com, adamson@itd.nrl.navy.mil, M.Handley@cs.ucl.ac.uk, cabo@tzi.org, 'Joe Macker' , 'Lorenzo Vicisano' Subject: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:23:38 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document specifies a protocol (or an update to a protocol) that provides end-to-end reliable transport of bulk data objects or streams over multicast routing and forwarding services. It also provides a congestion control scheme. It is designed to permit different upper layer services to utilize its services in different ways. I previousaly reviewed the -09- revision, where I asked that the specification tighen up requirements, ala RFC2119, especially in the Security Considerations. That was done to a degree. More should be done. There are places with text like "It is expected that ..." that might be better expressed as SHOULDs. There are lower case must/should/may/require uses. Since this is a requested early review, let me also comment on document clarity. I found some of the paragraphs have conditionals in them, often following a statement of MUST or SHOULD compliance. I think the "However ..." conditionals really hurt the clarity of the specification. For example: Large NORM group sizes will necessitate some form of key management that does rely upon shared secrets. The GDOI and GSAKMP protocols mentioned here allow for certificate-based authentication. It is RECOMMENDED these certificates use IP addresses for authentication although it may alternatively possible to have authentication associated with pre-assigned NormNodeId values. However, it is likely that available group key management implementations will not be NORM-specific. Is the information after "RECOMMENDED these certificates use IP addresses for authentication" really needed here? If I alternately have authentication associated with re-assigned NormNodeId values, and do not support IP adresses for authentication, am I still compliant? A pet peeve - "it should be noted that" is almost always not needed. Just make the statement, which effectively notes the point. Nothing "should" about it! The same pet peeve variations: unnecessary introductory phrases or clauses in sentences: s/The principal issue is that configuration and operation of IPsec typically requires privileged user authorization./Configuration and operation of IPsec typically requires privileged user authorization./ s/It is expected that additional specifications may/ Additional specifications MAY/ Some words to look at whether they are really necessary: Additionally However Thus It is expected that As previously noted, Note that also as always as mentioned in section x.x as noted David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From pcain2@mail2.coopercain.com Mon May 4 15:34:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D703A6D26; Mon, 4 May 2009 15:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SmOtJysgGEc; Mon, 4 May 2009 15:34:20 -0700 (PDT) Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id 890443A6822; Mon, 4 May 2009 15:34:20 -0700 (PDT) Received: from Familyroom (reverse.completel.net [212.99.110.242] (may be forged)) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id n44MZeBW012761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 May 2009 17:35:45 -0500 Received: from Familyroom by Familyroom (PGP Universal service); Mon, 04 May 2009 18:35:41 -0500 X-PGP-Universal: processed; by Familyroom on Mon, 04 May 2009 18:35:41 -0500 From: "pat cain" To: , Date: Mon, 4 May 2009 18:35:34 -0400 Message-ID: <014f01c9cd08$a71f7960$f55e6c20$@coopercain.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM2wMY+J1M+FtcRKSUjz1RyAkT4Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-Mailman-Approved-At: Mon, 04 May 2009 22:45:47 -0700 Cc: iesg@ietf.org Subject: [secdir] secdir review of draft-levine-rfb-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:34:21 -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 defines a RFB ("remote framebuffer") protocol for remote access to graphical user interfaces. The security considerations section adequately points out the lack of security in the protocol and suggests ways around this issue. There are a few formatting issues (e.g., the references are not split between normative and informative) that I expect the rfc editor review will point out so I will not. There seems to be lots of 'hidden implications' in this document, for example there is a line that states "Other security types exist but are not publicly documented." What happens when two of these non-public things clash? Or if they are really used, maybe we should document them. :) The IANA considerations asks for none, but then states that "IANA has allocated port 5900 to the RFB protocol; the other port numbers have been used informally and do not match IANA allocations." If only one port was allocated (but has no reference) how can the 'other ports' not follow the allocations? (There weren't any other allocations.) Although it looks like this document is documenting a deployed protocol. There seems to be a bunch of implementor data missing. Pat Cain From Adrian.Farrel@huawei.com Tue May 5 02:40:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9923E3A6D4D; Tue, 5 May 2009 02:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_40=-0.185, SARE_SUB_OBFU_Q1=0.227, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR9KGJFfyM62; Tue, 5 May 2009 02:40:20 -0700 (PDT) Received: from lhrga03-in.huawei.com (lhrga03-in.huawei.com [195.33.106.148]) by core3.amsl.com (Postfix) with ESMTP id B151B3A7160; Tue, 5 May 2009 02:40:20 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ6004SC09LEZ@lhrga03-in.huawei.com>; Tue, 05 May 2009 10:41:46 +0100 (BST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ60093T09CJK@lhrga03-in.huawei.com>; Tue, 05 May 2009 10:41:45 +0100 (BST) Date: Tue, 05 May 2009 10:40:31 +0100 From: Adrian Farrel To: Glen Zorn Message-id: <5BCC1AA9899745EE9A48607847FB27D9@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <001301c9cafa$9032c190$b09844b0$@net> X-Mailman-Approved-At: Tue, 05 May 2009 02:49:53 -0700 Cc: pthubert@cisco.com, kpister@dustnetworks.com, secdir@ietf.org, sicco.dwars@shell.com, tom.phinney@cox.net, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-indus-routing-reqs-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 09:40:21 -0000 Hi Glen, I just wanted to check that it really was the -05 version that you looked at. Some of the issues you report show in -04 but were fixed in -05. Thanks, Adrian ----- Original Message ----- From: "Glen Zorn" To: ; ; ; ; ; Sent: Saturday, May 02, 2009 8:49 AM Subject: secdir review of draft-ietf-roll-indus-routing-reqs-05 >I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Grammatical and spelling errors are fairly prevalent; a close check would > be > beneficial. > > The page title is hyphenated gobbledygook. > > The acronym "WSN" is used without previous expansion in section 2.2. > > In section 2.2.1, s/Form afar/From afar/. > > There is no "Security Considerations" section. > > The majority of the references to security have to do with general network > or node security, not with the security requirements placed upon the > routing > protocol itself; this is a serious omission, I think and one that should > be > rectified before publication. Similarly, a large amount of background > information on the operation of industrial plants is given, but little of > this information is tied specifically to the routing requirements > themselves. > > In several instances technically extraneous claims are made for the need > for > some feature, as if these claims were statements of fact. For example, > section 8 begins: > > Various economic factors have contributed to a reduction of trained > workers in the plant. The industry as a whole appears to be trying > to solve this problem with what is called the "wireless worker". > Carrying a PDA or something similar, this worker will be able to > accomplish more work in less time than the older, better-trained > workers that he or she replaces. > > There are several other ways in which this could be put (none of them > quite > as flattering to the corporate bosses) but in any case, irrelevant to the > goal of specifying routing requirements. > > I don't know what an "External Informative Reference" is (section 13.3), > nor > why one would treat it differently than any other informative reference. > > ~gwz > > At one time in the US, in the mid-nineteenth century, working for wage > labor > was considered not very different from chattel slavery...anyone who thinks > it's legitimate to be a wage laborer is internalizing oppression in a way > which would have seemed intolerable to people in the mills 150 years ago. > -- Noam Chomsky, "Propaganda & the Public Mind" > > > From gwz@net-zen.net Tue May 5 03:22:41 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BDF3A6AEC for ; Tue, 5 May 2009 03:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MMnKLawfxcT for ; Tue, 5 May 2009 03:22:41 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id 5FB8B3A69B0 for ; Tue, 5 May 2009 03:22:41 -0700 (PDT) Received: (qmail 31493 invoked from network); 5 May 2009 10:17:28 -0000 Received: from unknown (210.57.242.40) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 05 May 2009 10:17:27 -0000 From: "Glen Zorn" To: "'Adrian Farrel'" References: <001301c9cafa$9032c190$b09844b0$@net> <5BCC1AA9899745EE9A48607847FB27D9@your029b8cecfe> In-Reply-To: <5BCC1AA9899745EE9A48607847FB27D9@your029b8cecfe> Date: Tue, 5 May 2009 19:17:22 +0900 Organization: Network Zen Message-ID: <010b01c9cd6a$affd2480$0ff76d80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnNZbURF22kmDWsSRS/GvAtXgf09gABM0xg Content-Language: en-us X-Mailman-Approved-At: Tue, 05 May 2009 03:33:10 -0700 Cc: pthubert@cisco.com, kpister@dustnetworks.com, secdir@ietf.org, sicco.dwars@shell.com, 'Glen Zorn' , tom.phinney@cox.net, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-indus-routing-reqs-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 10:22:41 -0000 Adrian Farrel [mailto:Adrian.Farrel@huawei.com] writes: > Hi Glen, > > I just wanted to check that it really was the -05 version that you > looked > at. > > Some of the issues you report show in -04 but were fixed in -05. OK, so just ignore them. > > Thanks, > Adrian > ----- Original Message ----- > From: "Glen Zorn" > To: ; ; ; > ; ; > Sent: Saturday, May 02, 2009 8:49 AM > Subject: secdir review of draft-ietf-roll-indus-routing-reqs-05 > > > >I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > Grammatical and spelling errors are fairly prevalent; a close check > would > > be > > beneficial. > > > > The page title is hyphenated gobbledygook. > > > > The acronym "WSN" is used without previous expansion in section 2.2. > > > > In section 2.2.1, s/Form afar/From afar/. > > > > There is no "Security Considerations" section. > > > > The majority of the references to security have to do with general > network > > or node security, not with the security requirements placed upon the > > routing > > protocol itself; this is a serious omission, I think and one that > should > > be > > rectified before publication. Similarly, a large amount of > background > > information on the operation of industrial plants is given, but > little of > > this information is tied specifically to the routing requirements > > themselves. > > > > In several instances technically extraneous claims are made for the > need > > for > > some feature, as if these claims were statements of fact. For > example, > > section 8 begins: > > > > Various economic factors have contributed to a reduction of trained > > workers in the plant. The industry as a whole appears to be trying > > to solve this problem with what is called the "wireless worker". > > Carrying a PDA or something similar, this worker will be able to > > accomplish more work in less time than the older, better-trained > > workers that he or she replaces. > > > > There are several other ways in which this could be put (none of them > > quite > > as flattering to the corporate bosses) but in any case, irrelevant to > the > > goal of specifying routing requirements. > > > > I don't know what an "External Informative Reference" is (section > 13.3), > > nor > > why one would treat it differently than any other informative > reference. > > > > ~gwz > > > > At one time in the US, in the mid-nineteenth century, working for > wage > > labor > > was considered not very different from chattel slavery...anyone who > thinks > > it's legitimate to be a wage laborer is internalizing oppression in a > way > > which would have seemed intolerable to people in the mills 150 years > ago. > > -- Noam Chomsky, "Propaganda & the Public Mind" > > > > > > > > From ekr@networkresonance.com Tue May 5 10:08:31 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C323A692F; Tue, 5 May 2009 10:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 aruFlzNBwGrw; Tue, 5 May 2009 10:08:30 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 1449F3A6899; Tue, 5 May 2009 10:08:30 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8D40E50822; Tue, 5 May 2009 10:13:06 -0700 (PDT) Date: Tue, 05 May 2009 10:13:06 -0700 From: Eric Rescorla To: secdir@ietf.org, iesg@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090505171306.8D40E50822@romeo.rtfm.com> Cc: isms-chairs@tools.ietf.org, draft-ietf-isms-radius-usage@tools.ietf.org Subject: [secdir] Review of draft-ietf-isms-radius-usage-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:08:31 -0000 $Id: draft-ietf-isms-radius-usage-05-rev.txt,v 1.1 2009/05/05 16:12:55 ekr Exp $ This document is about the use of RADIUS servers with SNMP "transport models" (security protocols such as SSH used with SNMP). As far as I can tell, the idea is to explain how to outsource some of the authorization decisions to RADIUS. I found this document extremely difficult to read. I realize that the intended audience is for people with a lot of RADIUS and SNMP experience, but despite some familiarity with them, I had to work fairly hard to figure out what it was trying to say and I'm still not sure. This document would benefit very greatly from a diagram explaining how the authors think things are supposed to work. My big question is how the user authentication decisions are expected to be split between (e.g., SSH), and RADIUS. For example: - If the user has a password, who checks it the RADIUS server or the NAS? RADIUS certainly can do this. - If the user is authenticating with SSH pubkey auth, who checks that? These seem like important architectural issues but I'm not getting them out of the document, and they should in particular be in the security considerations. IMO, this document would benefit from a rewrite that makes it a lot clearer to someone not enmeshed in the WG. S 2. I don't understand what the difference is between service authorization and access control in this context. S 2.3. I don't get the SHOULDs here. If you're defining how code points are set, why are these optional? From dbharrington@comcast.net Tue May 5 10:49:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607B728C0CF for ; Tue, 5 May 2009 10:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 avUOQIEu8uF9 for ; Tue, 5 May 2009 10:49:21 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id E0E623A71BB for ; Tue, 5 May 2009 10:49:20 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id nmB81b0021HzFnQ53tqYi5; Tue, 05 May 2009 17:50:32 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id ntqm1b00n0UQ6dC3atqnEa; Tue, 05 May 2009 17:50:47 +0000 From: "David B Harrington" To: "'Barry Leiba'" , , References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> Date: Tue, 5 May 2009 13:50:46 -0400 Message-ID: <069801c9cdaa$050fb660$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnLZUwu2W1Vd7VvT4OWm2HjF/zAmACQXncg X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [secdir] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 17:49:22 -0000 Hi, Thanks fo rthe review. I am updating the sources. comments inline David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: secdir-bounces@ietf.org > [mailto:secdir-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Saturday, May 02, 2009 4:34 PM > To: secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-isms-transport-security-model@tools.ietf.org; > isms-chairs@tools.ietf.org > Subject: [secdir] secdir review > ofdraft-ietf-isms-transport-security-model-12 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document defines a type of Security Model, as defined in RFC > 3411, designed to go with a Transport Model, as defined in > draft-ietf-isms-tmsm. I have no expertise in MIBs, and must presume > that people who do have reviewed this. > > For that matter, I don't have expertise in SNMP, so please take these > comments with that in mind. I've briefly gone through the associated > documents, and I think I understand how the pieces fit into the > architecture, but my understanding isn't thorough. > > My comments: > > Section 1.5: bullets 1 & 2 use normative RFC 2119 language. Should > bullets 4 & 5 do so also? E.g., "A Security Model SHOULD NOT require > changes to the SNMP architecture." fixed. > > Section 2.1.1: I'm confused by this. RFC 3411 section 3.1.1.4.1 says > that a Security Model specifies "the security protocols used to > provide security services such as authentication and privacy." Yet > this section says that the Transport Security Model does NOT provide > these things. Hmmm. two parts to this answer: 1) RFC3411 says the security model **specifies**; it does not say it must provide the security services itself. This section says this security model "does not provide security mechanisms such as authentication and encryption itself." So they are consistent. 2) They are slightly inconsistent, because the WG realized that the interface to different security protocols would require much the same thing, so we made the Transport Security Model capable of working with multiple underlying security-providing security protocols, and rather than **specifying** each possible protocol, we specify how an administrator can specify the protocol as a parameter used by the Security Model. > > And if it doesn't provide them, how can the admonition to use it "with > a Transport Model that provides appropriate security" be a SHOULD, and > not a MUST (noting that "appropriate" security could include no > authentication, if that's appropriate to the system in question)? > Some component has to take responsibility for the security, even if > it's to determine that no authentication or no privacy controls are > needed. That is a deployment decision made by an administrator who has an understanding of what is appropriate to the system in question. MUST is for implementers and SHOULD is for deployers. > > The same goes for the discussion of this in section 8, Security > Considerations. "The security threats and how these threats are > mitigated should be covered in detail in the specifications of the > Transport Models and the underlying secure transports." It looks like > this needs to be stronger than plain-English "should", or RFC 2119 > "SHOULD", no? fixed. > > I think this is a key point to make clear, so it's well understood > where the responsibility lies for the assurance of "appropriate" > security in the Transport Model, and what happens when a system uses > multiple Security Models, one of which is this one. > > Again, my confusion here might simply be due to my understanding of > the architecture being only superficial. > > Barry > -- > Barry Leiba (barryleiba@computer.org) > http://internetmessagingtechnology.org/ > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From jhutz@cmu.edu Tue May 5 12:09:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468693A6E38; Tue, 5 May 2009 12:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.612, 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 NYkvilSA9R2D; Tue, 5 May 2009 12:09:18 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 6A4FE3A6CFA; Tue, 5 May 2009 12:09:18 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n45JAH51026910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 15:10:17 -0400 (EDT) Date: Tue, 05 May 2009 15:10:17 -0400 From: Jeffrey Hutzelman To: David B Harrington , "'Barry Leiba'" , secdir@ietf.org, iesg@ietf.org Message-ID: <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> In-Reply-To: <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:09:19 -0000 --On Tuesday, May 05, 2009 01:50:46 PM -0400 David B Harrington wrote: > That is a deployment decision made by an administrator who has an > understanding of what is appropriate to the system in question. MUST > is for implementers and SHOULD is for deployers. Nononono. When we say "MUST is for implementors", we mean that our specifications give requirements for implementations which claim to comply; RFC2119 requirements language is generally inappropriate for deployment advice. It is appropriate to say TSM MUST be use with a TM that provides appropriate security; that is equivalent to saying that implementations MUST NOT use TSM together with an inappropriate TM, such as UDP. That said, selection of transport and security models generally is an operational decision. TSM itself is really architectural glue to allow us to push some of the security infrastructure down into a transport below SNMP, such as SSH or TLS. You'd never say "I want to use TSM, now which transport should I use"; you'd say "I want to use SSH -- oh, for that to work, I have to use it with TSM". -- Jeff From dbharrington@comcast.net Tue May 5 12:27:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEF528C1C7 for ; Tue, 5 May 2009 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 DLcy-l0hF75W for ; Tue, 5 May 2009 12:27:14 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id DA4DF3A71D6 for ; Tue, 5 May 2009 12:27:09 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA10.westchester.pa.mail.comcast.net with comcast id nmBx1b00416LCl05AvUcNN; Tue, 05 May 2009 19:28:36 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id nvUb1b00a0UQ6dC3SvUbcE; Tue, 05 May 2009 19:28:36 +0000 From: "David B Harrington" To: "'Jeffrey Hutzelman'" , "'Barry Leiba'" , , References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> Date: Tue, 5 May 2009 15:28:34 -0400 Message-ID: <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnNtSYsrMOk66M4RPGOpg+msofHJgAAhTKA X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:27:15 -0000 OK, I'll change my answer. That is a deployment decision made by an administrator who has an understanding of what is appropriate to the system in question. What is the correct non-RFC2119 phrase in which to couch our deployment advice? dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Tuesday, May 05, 2009 3:10 PM > To: David B Harrington; 'Barry Leiba'; secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-isms-transport-security-model@tools.ietf.org; > isms@ietf.org; isms-chairs@tools.ietf.org; jhutz@cmu.edu > Subject: Re: [Isms] [secdir] secdir review > ofdraft-ietf-isms-transport-security-model-12 > > --On Tuesday, May 05, 2009 01:50:46 PM -0400 David B Harrington > wrote: > > > That is a deployment decision made by an administrator who has an > > understanding of what is appropriate to the system in question. MUST > > is for implementers and SHOULD is for deployers. > > Nononono. When we say "MUST is for implementors", we mean that our > specifications give requirements for implementations which > claim to comply; > RFC2119 requirements language is generally inappropriate for > deployment > advice. > > It is appropriate to say TSM MUST be use with a TM that provides > appropriate security; that is equivalent to saying that > implementations > MUST NOT use TSM together with an inappropriate TM, such as UDP. > > > That said, selection of transport and security models generally is an > operational decision. TSM itself is really architectural > glue to allow us > to push some of the security infrastructure down into a > transport below > SNMP, such as SSH or TLS. You'd never say "I want to use > TSM, now which > transport should I use"; you'd say "I want to use SSH -- oh, > for that to > work, I have to use it with TSM". > > > -- Jeff > From jhutz@cmu.edu Tue May 5 12:41:42 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70563A71A3; Tue, 5 May 2009 12:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.597, 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 uYlM6RORR87p; Tue, 5 May 2009 12:41:42 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 1FC073A6CBF; Tue, 5 May 2009 12:41:10 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n45Jg5Ov028113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 15:42:05 -0400 (EDT) Date: Tue, 05 May 2009 15:42:05 -0400 From: Jeffrey Hutzelman To: David B Harrington , "'Barry Leiba'" , secdir@ietf.org, iesg@ietf.org Message-ID: In-Reply-To: <200905051928.n45JSkHP009987@mx03.srv.cs.cmu.edu> References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <200905051928.n45JSkHP009987@mx03.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:41:42 -0000 --On Tuesday, May 05, 2009 03:28:34 PM -0400 David B Harrington wrote: > OK, I'll change my answer. > > That is a deployment decision made by an administrator who has an > understanding of what is appropriate to the system in question. > > What is the correct non-RFC2119 phrase in which to couch our > deployment advice? I don't know, but as I said, I don't think it would be inappropriate to simply say TSM MUST be used with a secure transport, placing the onus on implementors to prevent inappropriate combinations from being used. From dbharrington@comcast.net Tue May 5 13:42:34 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454F53A6D91 for ; Tue, 5 May 2009 13:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymBLCW+9sRof for ; Tue, 5 May 2009 13:42:33 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 5142C3A6AFE for ; Tue, 5 May 2009 13:42:33 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA06.westchester.pa.mail.comcast.net with comcast id noxb1b00117dt5G56wjqZ8; Tue, 05 May 2009 20:43:50 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id nwk01b0090UQ6dC3Zwk0w8; Tue, 05 May 2009 20:44:00 +0000 From: "David B Harrington" To: "'Barry Leiba'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> Date: Tue, 5 May 2009 16:43:59 -0400 Message-ID: <06ae01c9cdc2$37bbe4e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnNvYH7CDZJrmj2Tqm7iS1rwxNuTAAAYdyQ X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> Cc: isms@ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:42:34 -0000 Hi Barry, your formulation is "MUST ... use", where "use" is a deployment decision, and MUST is inappropriate for deployment advice. We currently use "SHOULD ... use", but Jeff thinks that in inappropriate as well. How about: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so operators are advised to always use this with a Transport Model that provides appropriate security, where "appropriate" for a particular deployment is an administrative decision. Which threats are addressed and how they are mitigated depends on the Transport Model. dbh > -----Original Message----- > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On > Behalf Of Barry Leiba > Sent: Tuesday, May 05, 2009 4:04 PM > To: David B Harrington > Cc: secdir@ietf.org; iesg@ietf.org; isms@ietf.org; > isms-chairs@tools.ietf.org > Subject: Re: [Isms] [secdir] secdir review > ofdraft-ietf-isms-transport-security-model-12 > > > That is a deployment decision made by an administrator who has an > > understanding of what is appropriate to the system in question. > > > > What is the correct non-RFC2119 phrase in which to couch our > > deployment advice? > > Well, this would make me happy; would it work for you (and others)?: > > OLD: > by the RFC 3411 architecture. However, the Transport > Security Model > does not provide security mechanisms such as authentication and > encryption itself, so it SHOULD always be used with a > Transport Model > that provides appropriate security. Which threats are > addressed and > how they are mitigated depends on the Transport Model. > > NEW: > by the RFC 3411 architecture. However, the Transport > Security Model > does not provide security mechanisms such as authentication and > encryption itself, so it MUST always be used with a Transport Model > that provides appropriate security. What is "appropriate" > for a particular > deployment is an administrative decision. Which threats > are addressed > and how they are mitigated depends on the Transport Model. > > Barry > From barryleiba@gmail.com Tue May 5 13:02:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABC33A67EA; Tue, 5 May 2009 13:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waff0qxjJ8YL; Tue, 5 May 2009 13:02:29 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id E61E728C16E; Tue, 5 May 2009 13:02:28 -0700 (PDT) Received: by ewy24 with SMTP id 24so5347919ewy.37 for ; Tue, 05 May 2009 13:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=sv8oTgEQ8oMuiDWDkPQWplPFflqJ6w8ydcDEHTONgFw=; b=J/7+wVj1L+Onocd0Zc5KbKCizEEO5DmK8Eo8iUyjEckkECv54aMSW1qU3q4rB/4RGZ DSTxNwbtf4HjWyI5Xwis7e7lNcCddR0bUuPhyGDjd+KaNabt8tJtHa8AeX2CQx/OY+WA CbE2ujOUBeMQxQtUgXvFR5xUNKUuS34ku4Lzc= 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=BWbHu/a5dBvf2VYE2eKYD1436ydCCSqJcpN8cW6aqt/7S4SC8LDwviMLJUv2aoqK3k tgd9RYoOoz05cI8fBWhy4z7dlrF8ZnDme3YdyQ7NG84Zth74ov3jV0SEuH2YBqzmlIhQ LUSNUccrsFT1U8PMKAaeCacuxtv/B6fQh7faI= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.211.137.19 with SMTP id p19mr5023185ebn.69.1241553832236; Tue, 05 May 2009 13:03:52 -0700 (PDT) In-Reply-To: <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> Date: Tue, 5 May 2009 16:03:52 -0400 X-Google-Sender-Auth: 8ab2eb4451dce772 Message-ID: <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> From: Barry Leiba To: David B Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 05 May 2009 22:53:27 -0700 Cc: isms@ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:02:30 -0000 > That is a deployment decision made by an administrator who has an > understanding of what is appropriate to the system in question. > > What is the correct non-RFC2119 phrase in which to couch our > deployment advice? Well, this would make me happy; would it work for you (and others)?: OLD: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so it SHOULD always be used with a Transport Model that provides appropriate security. Which threats are addressed and how they are mitigated depends on the Transport Model. NEW: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so it MUST always be used with a Transport Model that provides appropriate security. What is "appropriate" for a particular deployment is an administrative decision. Which threats are addressed and how they are mitigated depends on the Transport Model. Barry From d.b.nelson@comcast.net Tue May 5 20:43:11 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13203A6A3F for ; Tue, 5 May 2009 20:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 4eYBHrYuL-W9 for ; Tue, 5 May 2009 20:43:11 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id E01543A6A03 for ; Tue, 5 May 2009 20:43:10 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id o0ad1b00E17UAYkA13keNr; Wed, 06 May 2009 03:44:38 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id o3kc1b00D4H2mdz8Z3kcgw; Wed, 06 May 2009 03:44:38 +0000 From: "Dave Nelson" To: "'Eric Rescorla'" , , References: <20090505171306.8D40E50822@romeo.rtfm.com> Date: Tue, 5 May 2009 23:44:50 -0400 Message-ID: <28137ED4FBEF49BBB99BCFF561806165@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090505171306.8D40E50822@romeo.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnNpFiBbOOEmKygTYW03uT3GEz8wAAVLHbg X-Mailman-Approved-At: Tue, 05 May 2009 22:53:27 -0700 Cc: isms-chairs@tools.ietf.org, draft-ietf-isms-radius-usage@tools.ietf.org Subject: Re: [secdir] Review of draft-ietf-isms-radius-usage-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 03:43:12 -0000 Eric Rescorla writes... > Subject: Review of draft-ietf-isms-radius-usage-05 Thanks for your review and comments. > IMO, this document would benefit from a rewrite that makes it a > lot clearer to someone not enmeshed in the WG. Umm. OK. That's a bit disheartening to hear, but useful feedback. > As far as I can tell, the idea is to explain how to outsource > some of the authorization decisions to RADIUS. Correct. > I found this document extremely difficult to read. I realize that > the intended audience is for people with a lot of RADIUS and > SNMP experience... That's true. Those are the intended audiences. Additional explanatory material was added to give each group some background information. > ...but despite some familiarity with them, I had > to work fairly hard to figure out what it was trying to say > and I'm still not sure. This document would benefit very greatly > from a diagram explaining how the authors think things are > supposed to work. Diagrams can be useful. We can certainly think about what might be helpful in that regard. > My big question is how the user authentication decisions are > expected to be split between (e.g., SSH), and RADIUS. For > example: > > - If the user has a password, who checks it the RADIUS server > or the NAS? RADIUS certainly can do this. The RADIUS server makes the authentication decision. If the credential is a password, as is the typical use case, the password is sent (hidden) in a RADIUS Access-Request message. > - If the user is authenticating with SSH pubkey auth, who > checks that? The SSH server, i.e. the NAS. SSH is used to create a protected transport session (a tunnel, if you will) and the RADIUS credentials are obtained from the SSH server implementation in the NAS and used by the RADIUS client in the NAS to authenticate the user with the RADIUS server. Of course, it has to be an authentication method that RADIUS supports, and SSH public key is not one of those. > These seem like important architectural issues but I'm not getting > them out of the document, and they should in particular > be in the security considerations. I'll re-read the document with your questions in mind. Of course, as a draft author and a RADIUS expert, I may have overlooked some unstated assumptions. > S 2. > I don't understand what the difference is between service authorization > and access control in this context. Service Authorization means that the user is authorized to (a) manage the NAS and (b) use SNMP in particular as the management mechanism. Access Control Authorization relates to the SNMP Access Control Subsystem and could be thought of as analogous to access control lists or packet filters or any similar fine-granularity access control mechanism. > S 2.3. > I don't get the SHOULDs here. If you're defining how code points are > set, why are these optional? OK, let's look at each one of these: RADIUS servers compliant to this specification SHOULD use RADIUS service provisioning attributes, as described herein, to specify SNMP access over a secure transport. This one could arguably be a MUST. In fact, I tend to think it ought to be a MUST. The following RADIUS attributes SHOULD be used, as hint attributes included in the Access-Request message to signal use of SNMP over a secure transport (i.e. authPriv) to the RADIUS server: RADIUS documents have traditionally held that appropriate "hint" attributes are desirable in an Access-Request message, but that they are optional. This preserves that tradition. I suppose this could be changed to MUST without impacting interoperability with RADIUS servers, which are always free to ignore such hints. From randy_presuhn@mindspring.com Tue May 5 23:34:08 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26DD3A6D99; Tue, 5 May 2009 23:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, 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 APd+vbDPfEl3; Tue, 5 May 2009 23:34:08 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id A26FA28C2A2; Tue, 5 May 2009 23:33:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZCfDUSPI4y2lymIkeFzD/aKt/DGZr6iF2Y71N5UHfaCCQ/DoJ5hjJdEfFnj7Hdo4; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.233] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M1ai3-0007Hq-47; Wed, 06 May 2009 02:34:27 -0400 Message-ID: <005901c9ce15$1f2f5300$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> Date: Tue, 5 May 2009 23:37:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696816e54f1a9a3995a2d36e37862333af29350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.233 X-Mailman-Approved-At: Tue, 05 May 2009 23:35:39 -0700 Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [secdir] [Isms] secdirreview ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 06:34:08 -0000 Hi - > From: "David B Harrington" > To: "'Jeffrey Hutzelman'" ; "'Barry Leiba'" ; ; > Cc: ; ; > Sent: Tuesday, May 05, 2009 12:28 PM > Subject: Re: [Isms] [secdir] secdirreview ofdraft-ietf-isms-transport-security-model-12 ... > What is the correct non-RFC2119 phrase in which to couch our > deployment advice? ... Sounds like what RFC 2026 calls an "Applicability Statement". Randy From glenzorn@comcast.net Wed May 6 01:16:44 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8042A3A6D7C for ; Wed, 6 May 2009 01:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTIBE4vq5stU for ; Wed, 6 May 2009 01:16:37 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id B8C983A6DBD for ; Wed, 6 May 2009 01:15:51 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA01.westchester.pa.mail.comcast.net with comcast id o8Fn1b0020EZKEL518HK4u; Wed, 06 May 2009 08:17:19 +0000 Received: from gwzPC ([210.57.242.40]) by OMTA01.westchester.pa.mail.comcast.net with comcast id o8Gd1b0070t0P5u3M8Ghlo; Wed, 06 May 2009 08:16:58 +0000 From: "Glen Zorn" To: "'David B Harrington'" , "'Barry Leiba'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <06ae01c9cdc2$37bbe4e0$0600a8c0@china.huawei.com> In-Reply-To: <06ae01c9cdc2$37bbe4e0$0600a8c0@china.huawei.com> Date: Wed, 6 May 2009 17:16:53 +0900 Message-ID: <011601c9ce23$10883930$3198ab90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnNvYH7CDZJrmj2Tqm7iS1rwxNuTAAAYdyQABj7Q4A= Content-Language: en-us Cc: secdir@ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 08:16:44 -0000 How about just losing the capitalization? > -----Original Message----- > From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On > Behalf Of David B Harrington > Sent: Wednesday, May 06, 2009 5:44 AM > To: 'Barry Leiba' > Cc: isms@ietf.org; iesg@ietf.org; isms-chairs@tools.ietf.org; > secdir@ietf.org > Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport- > security-model-12 > > Hi Barry, > > your formulation is "MUST ... use", where "use" is a deployment > decision, and MUST is inappropriate for deployment advice. > We currently use "SHOULD ... use", but Jeff thinks that in > inappropriate as well. > > How about: > by the RFC 3411 architecture. However, the Transport Security > Model > does not provide security mechanisms such as authentication and > encryption itself, so operators are advised to always use this > with a Transport Model > that provides appropriate security, where "appropriate" for a > particular > deployment is an administrative decision. Which threats are > addressed > and how they are mitigated depends on the Transport Model. > > dbh > > > -----Original Message----- > > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On > > Behalf Of Barry Leiba > > Sent: Tuesday, May 05, 2009 4:04 PM > > To: David B Harrington > > Cc: secdir@ietf.org; iesg@ietf.org; isms@ietf.org; > > isms-chairs@tools.ietf.org > > Subject: Re: [Isms] [secdir] secdir review > > ofdraft-ietf-isms-transport-security-model-12 > > > > > That is a deployment decision made by an administrator who has an > > > understanding of what is appropriate to the system in question. > > > > > > What is the correct non-RFC2119 phrase in which to couch our > > > deployment advice? > > > > Well, this would make me happy; would it work for you (and others)?: > > > > OLD: > > by the RFC 3411 architecture. However, the Transport > > Security Model > > does not provide security mechanisms such as authentication and > > encryption itself, so it SHOULD always be used with a > > Transport Model > > that provides appropriate security. Which threats are > > addressed and > > how they are mitigated depends on the Transport Model. > > > > NEW: > > by the RFC 3411 architecture. However, the Transport > > Security Model > > does not provide security mechanisms such as authentication and > > encryption itself, so it MUST always be used with a Transport > Model > > that provides appropriate security. What is "appropriate" > > for a particular > > deployment is an administrative decision. Which threats > > are addressed > > and how they are mitigated depends on the Transport Model. > > > > Barry > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From j.schoenwaelder@jacobs-university.de Wed May 6 02:29:33 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D253A68E5; Wed, 6 May 2009 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGclpckzahzX; Wed, 6 May 2009 02:29:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7E0853A6BAD; Wed, 6 May 2009 02:29:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53C0AC0171; Wed, 6 May 2009 11:30:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cDvakrjxEPcC; Wed, 6 May 2009 11:30:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69EC4C0022; Wed, 6 May 2009 11:30:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 97034ADBF3D; Wed, 6 May 2009 11:30:21 +0200 (CEST) Date: Wed, 6 May 2009 11:30:21 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20090506093021.GB21714@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , David B Harrington , 'Barry Leiba' , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-isms-transport-security-model@tools.ietf.org" , "isms@ietf.org" , "isms-chairs@tools.ietf.org" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <200905051928.n45JSkHP009987@mx03.srv.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: David B Harrington , "isms@ietf.org" , "secdir@ietf.org" , "isms-chairs@tools.ietf.org" , "iesg@ietf.org" , 'Barry Leiba' , "draft-ietf-isms-transport-security-model@tools.ietf.org" Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12 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: Wed, 06 May 2009 09:29:33 -0000 On Tue, May 05, 2009 at 09:42:05PM +0200, Jeffrey Hutzelman wrote: > --On Tuesday, May 05, 2009 03:28:34 PM -0400 David B Harrington > wrote: > > > OK, I'll change my answer. > > > > That is a deployment decision made by an administrator who has an > > understanding of what is appropriate to the system in question. > > > > What is the correct non-RFC2119 phrase in which to couch our > > deployment advice? > > I don't know, but as I said, I don't think it would be inappropriate to > simply say TSM MUST be used with a secure transport, placing the onus on > implementors to prevent inappropriate combinations from being used. I think the only interesting case here is the sending of messages where a combination of TSM with say UDP/TCP leads to maybe surprising results. (Note that the existing EoPs take care of dropping incoming messages received by a non-secure transport model that does not provide an appropriate cache entry.) I believe changing to MUST is actually fine and it will be very implementation specific how one prevents a combination such as TSM with UDP - so having this not spelled out in the EoP seems to be fine. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ekr@networkresonance.com Wed May 6 06:22:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3303A6F21; Wed, 6 May 2009 06:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya5sLhUHnQE7; Wed, 6 May 2009 06:22:35 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 250683A6F1C; Wed, 6 May 2009 06:17:39 -0700 (PDT) Received: from kilo.local (unknown [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 614751995AF; Wed, 6 May 2009 06:22:44 -0700 (PDT) Date: Wed, 06 May 2009 06:22:44 -0700 From: Eric Rescorla To: "Dave Nelson" In-Reply-To: <28137ED4FBEF49BBB99BCFF561806165@NEWTON603> References: <20090505171306.8D40E50822@romeo.rtfm.com> <28137ED4FBEF49BBB99BCFF561806165@NEWTON603> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090506132244.614751995AF@kilo.networkresonance.com> Cc: iesg@ietf.org, isms-chairs@tools.ietf.org, draft-ietf-isms-radius-usage@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-isms-radius-usage-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:22:36 -0000 At Tue, 5 May 2009 23:44:50 -0400, Dave Nelson wrote: > > Eric Rescorla writes... > > > Subject: Review of draft-ietf-isms-radius-usage-05 > > Thanks for your review and comments. > > > IMO, this document would benefit from a rewrite that makes it a > > lot clearer to someone not enmeshed in the WG. > > Umm. OK. That's a bit disheartening to hear, but useful feedback. > > > As far as I can tell, the idea is to explain how to outsource > > some of the authorization decisions to RADIUS. > > Correct. > > > I found this document extremely difficult to read. I realize that > > My big question is how the user authentication decisions are > > expected to be split between (e.g., SSH), and RADIUS. For > > example: > > > > - If the user has a password, who checks it the RADIUS server > > or the NAS? RADIUS certainly can do this. > > The RADIUS server makes the authentication decision. If the credential is a > password, as is the typical use case, the password is sent (hidden) in a > RADIUS Access-Request message. > > > - If the user is authenticating with SSH pubkey auth, who > > checks that? > > The SSH server, i.e. the NAS. SSH is used to create a protected transport > session (a tunnel, if you will) and the RADIUS credentials are obtained from > the SSH server implementation in the NAS and used by the RADIUS client in > the NAS to authenticate the user with the RADIUS server. Of course, it has > to be an authentication method that RADIUS supports, and SSH public key is > not one of those. so, this is what concerns me: architecturally these are pretty different--and challenge-response may be different yet. That seems like it deserves some analysis. -Ekr From j.schoenwaelder@jacobs-university.de Wed May 6 06:38:58 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1003A6CFE; Wed, 6 May 2009 06:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3wgn5AufFnx; Wed, 6 May 2009 06:38:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4469C3A6912; Wed, 6 May 2009 06:37:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40D34C017B; Wed, 6 May 2009 15:39:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SBBXuyVuajZ8; Wed, 6 May 2009 15:38:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70B09C017A; Wed, 6 May 2009 15:38:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B2776ADC822; Wed, 6 May 2009 15:38:37 +0200 (CEST) Date: Wed, 6 May 2009 15:38:37 +0200 From: Juergen Schoenwaelder To: Eric Rescorla Message-ID: <20090506133837.GA22610@elstar.local> Mail-Followup-To: Eric Rescorla , "secdir@ietf.org" , "iesg@ietf.org" , "isms-chairs@tools.ietf.org" , "draft-ietf-isms-radius-usage@tools.ietf.org" References: <20090505171306.8D40E50822@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090505171306.8D40E50822@romeo.rtfm.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "draft-ietf-isms-radius-usage@tools.ietf.org" , "iesg@ietf.org" , "isms-chairs@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-isms-radius-usage-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:38:58 -0000 On Tue, May 05, 2009 at 07:13:06PM +0200, Eric Rescorla wrote: > IMO, this document would benefit from a rewrite that makes it a > lot clearer to someone not enmeshed in the WG. This document has been revised several times to make it say the right things in the terminology used and understood by RADIUS folks and SNMP folks and while the result might not be optimal for a more general audience, I believe the target communities had reached concensus that the document does in fact say the right things in a way appropriate for the two main target audiences. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Wed May 6 07:07:08 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9E23A6ED0 for ; Wed, 6 May 2009 07:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 kg9RwaRBAEbO for ; Wed, 6 May 2009 07:07:08 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 68BC03A6CAC for ; Wed, 6 May 2009 07:06:13 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id oChE1b0050vp7WLABE6hnf; Wed, 06 May 2009 14:06:41 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id oE6e1b00P4H2mdz8RE6ffH; Wed, 06 May 2009 14:06:41 +0000 From: "Dave Nelson" To: "'Eric Rescorla'" References: <20090505171306.8D40E50822@romeo.rtfm.com><28137ED4FBEF49BBB99BCFF561806165@NEWTON603> <20090506132244.614751995AF@kilo.networkresonance.com> Date: Wed, 6 May 2009 10:06:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090506132244.614751995AF@kilo.networkresonance.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnOTTyGRS+ySOasTp29YJuMjPwZxwABdjbg Cc: isms-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-isms-radius-usage@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-isms-radius-usage-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:07:08 -0000 Eric Rescorla writes... > so, this is what concerns me: architecturally these are pretty > different--and challenge-response may be different yet. That > seems like it deserves some analysis. Perhaps some additional analysis and explanation of the "don't gets" would be useful. The draft clearly focuses on the "gets" and on describing a particular use case involving SSH and password-based authentication. There are other SSH authentication methods that cannot be integrated with RADIUS. Since they cannot be used, we don't spend any time discussing them. In an operator has an existing deployment using SSH and public key authentication, they may be able to use the transport-based security features of SNMPv3 defined in the companion ISMS WG drafts, but they won't be able to use RADIUS as part of that solution. From aland@deployingradius.com Wed May 6 07:38:01 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2B93A6EC4 for ; Wed, 6 May 2009 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, 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 BBRjpKItAorc for ; Wed, 6 May 2009 07:38:00 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 95FC13A6F28 for ; Wed, 6 May 2009 07:36:30 -0700 (PDT) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 3C6A012343A4; Wed, 6 May 2009 16:37:56 +0200 (CEST) Message-ID: <4A01A0C3.9010807@deployingradius.com> Date: Wed, 06 May 2009 16:37:55 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Phillip Hallam-Baker , 'radext mailing list' References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gdweber@gmail.com, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-radext-design-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 14:38:01 -0000 Phillip Hallam-Baker wrote: > As always with Radius documents it is somewhat hard to do a security > review of a security protocol that admits that the protocol does not > offer security. I agree. However... we are working with a legacy protocol here. > While the security is provided through layering on another protocol > (e.g. IPSEC), the mix and match approach is unsatisfactory. Security > is a property of a system. It is really not possible to analyze the > security of a system when one half of the system is unspecified. While it is not part of this document, the WG is working on RADIUS over TLS / DTLS. These specifications should improve the security of the protocol. > The Security Considerations section is adequate and given the purpose > of this draft it is appropriate to cite external documents where the > security issues are discussed in detail rather than repeat the caveats > here. But the question does have to be asked why we have so many > security caveats in what is a foundational security protocol. Historical practice, and the cost of upgrade. When the new TLS-based documents are approved, we expect that they will be the preferred approach for RADIUS transport. > While IPSEC security is certainly adequate for some applications, I > have a really hard time accepting it as the security layer for a > foundational security protocol. I prefer basic authentication and > authorization protocols to have security built in. In particular I > want to know what happens at the RADIUS protocol level when there is > an error at the IPSEC layer or vice versa. IPSEC is not secure against > active attack unless error conditions are appropriately handled. I agree. However, it's outside of the scope of this document. Alan DeKok. From hartmans@mit.edu Wed May 6 09:06:44 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86083A6C54; Wed, 6 May 2009 09:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvT-gRv1DpQG; Wed, 6 May 2009 09:06:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id E4A723A69B9; Wed, 6 May 2009 09:05:26 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4F9224160; Wed, 6 May 2009 12:06:50 -0400 (EDT) To: "Dave Nelson" References: <20090505171306.8D40E50822@romeo.rtfm.com> <28137ED4FBEF49BBB99BCFF561806165@NEWTON603> From: Sam Hartman Date: Wed, 06 May 2009 12:06:50 -0400 In-Reply-To: <28137ED4FBEF49BBB99BCFF561806165@NEWTON603> (Dave Nelson's message of "Tue\, 5 May 2009 23\:44\:50 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org, draft-ietf-isms-radius-usage@tools.ietf.org, isms-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-isms-radius-usage-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 16:06:44 -0000 >>>>> "Dave" == Dave Nelson writes: >> - If the user is authenticating with SSH pubkey auth, who >> checks that? Dave> The SSH server, i.e. the NAS. SSH is used to create a Dave> protected transport session (a tunnel, if you will) and the Dave> RADIUS credentials are obtained from the SSH server Dave> implementation in the NAS and used by the RADIUS client in Dave> the NAS to authenticate the user with the RADIUS server. Of Dave> course, it has to be an authentication method that RADIUS Dave> supports, and SSH public key is not one of those. I'm sorry, but I didn't understand this answer at all. It seems like you're both saying "you can't do that with RADIUS (what I thought the answer was)," and "the ssh server." I don't understand how to reconcile those. From Sandra.Murphy@cobham.com Wed May 6 11:39:27 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465833A6E64; Wed, 6 May 2009 11:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU2E4YPuDp8B; Wed, 6 May 2009 11:39:26 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 600A13A6ECC; Wed, 6 May 2009 11:31:06 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n46IWRCJ029917; Wed, 6 May 2009 13:32:27 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n46IWRwG012545; Wed, 6 May 2009 13:32:27 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 14:32:26 -0400 Date: Wed, 6 May 2009 14:32:08 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Mitesh Dalal (mdalal)" In-Reply-To: <13D1EAB852BE194C94773A947138483D0749EF90@xmb-sjc-21c.amer.cisco.com> Message-ID: References: <13D1EAB852BE194C94773A947138483D0749EF90@xmb-sjc-21c.amer.cisco.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 06 May 2009 18:32:27.0033 (UTC) FILETIME=[019EF890:01C9CE79] Cc: tcpm-chairs@tools.ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org, "Anantha Ramaiah \(ananth\)" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-tcpm-tcpsecure-11.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, 06 May 2009 18:39:27 -0000 On Tue, 28 Apr 2009 11:31:01 -0700, Mitesh Dalal wrote: Comments below in-line. >Hi Sandra, > >Thank you for taking time to review the draft. Please see inline. > > >---------- Forwarded message ---------- >Date: Thu, 23 Apr 2009 14:19:11 -0400 (Eastern Daylight Time) >From: Sandra Murphy >To: iesg@ietf.org, secdir@ietf.org, >draft-ietf-tcpm-tcpsecure@tools.ietf.org, > tcpm-chairs@tools.ietf.org > >This document is intended to update rfc793. That means that it should >be very explicit about what text it is replacing and what the new text >is. > >Mitesh: The mitigation section of the discussed attack does highlight >the processing "rules" that are >being modified. If you have explicit suggestions to make it better, we >welcome it. Essentially, I'm thinking that you need to indicate OLD: 793 text 793 text 793 text NEW: draft text draft text draft text Your mitigation techniques summarize the various pieces of 793 text scattered over the fsm description. Figuring out which pieces of the fsm text are the ones summarized and which should be changed could be ambiguous in interpretation. As the typical tcp code tries hard to follow the fsm description, being precise about the changes would be good. And very tedious, I'm sure. > > >The dicussions of interactions between TCP peers are always difficult to >phrase, as most terms are relative to viewpoint. The text in some >places is tough to read - who is the sender, who the receiver, etc. The >text also uses a lot of different terms to represent the same entity - >remote peer, remote end sender, remote TCP endpoint, etc. > >Mitesh: We may consider simplifying these terms to remote peer if that >helps. Point noted. OK. Note that I recognize the difficulty of choosing an apporpriate term from among the common ones, which are relative to the point of view. >The term "initial sequence number" has a special meaning in TCP and >should be avoided. > >Mitesh: Can you please elaborate the context? Context in your draft: 2) A sequence number that will be used in the RST. This sequence number will be a starting point for a series of guesses to attempt to present a RST segment to a connection endpoint that would be acceptable to it. Any random value may be used to guess the initial sequence number. ^^^^^^^^^^^^^^^^^^^^^^^ Context in RFC793: [Lots of places in 793 refer to initial sequence number or to ISN. And, of course, lots of literature.] I think the draft means "the first guess", "the starting point", not the TCP "initial sequence number". > >The text says that this mitigation SHOULD be used "in devices" which >typically host apps that are most vulnerable and MIGHT be used >elsewhere. Is there a suggestion that this would be under application >control? Chosen by the OS vendor (or device vendor)? For those who are >using Quagga routers (routing apps on top of intel boxes running some >*ix), would this be a socket option? >What's the vision here? > >Mitesh: This implementation detail is outside the scope of the document. >Although, implementors may >make it a compile time option, application dependent control (as you >hint with socket option) or may >make it mandatory for the stack. The draft discusses issues of interoperability between a TCP stack that implements the new algorithm and one that does not. But I'm wondering about issues of interoperabality between applications and TCP stacks. An vulnerable app that wants the new algorithm on an OS that has decided to leave the decision in the TCP stack, etc. For those systems where TCP stack and application are integrally implemented, i.e., "devices" like routers running BGP, the interoperability will be taken care of. But there are cases where an app that is vulnerable is running on a platform where the OS is a general purpose OS. In that case, you aren't considering just one integrally implemented "device". I'm just having trouble deciding what this all means in light of the recommendation of section 1.1: SHOULD be implemented in devices that regularly need to maintain TCP connections of the kind most vulnerable to the attacks described in this document. Examples of such TCP connections are the ones that tend to be long-lived and where the connection end points can be determined, in cases where no auxiliary anti-spoofing protection mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations MAY be implemented in other cases. I'm having difficulty figuring out how this will work. Maybe this is just the age-old inter-layer feature negotiation problem, and people will deal. > >I don't understand some parts of > > All TCP stacks MAY implement the following mitigation. TCP stacks > which implement this mitigation MUST add an additional input check >to > any incoming segment. The ACK value is considered acceptable only >if > it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= > SND.NXT). All incoming segments whose ACK value doesn't satisfy the > above condition MUST be discarded and an ACK sent back. It needs to > be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is >a > duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK > acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an > ACK, drop the segment, and return." This mitigation makes the ACK > check more stringent since any ACK < SND.UNA wouldn't be accepted, > instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) <= > SEG.ACK <= SND.NXT) gets through. > >Seems that SEG.ACK could fall between the SND.UNA and SND.UNA - >MAX.SND.WND, in which case the new code accepts segments that the >existing text says "it is ignored". I would read the 793 text as the >*ACK* is ignored, which means the new text would accept (and act on) >ACKs that are presently ignored. But looking at existing TCP code, it >looks like people have interpreted "it is ignored" as the *segment* is >ignored, i.e., dropped. In that case, this new text is accepting >segments that in existing implementations would be dropped. >Is that the intent? (Note: I could be easily wrong about the tcp_input >code.) > >Mitesh: I will have to dig and find out, my recollection is hazy but I >think this was raised earlier >and may have been discussed. Note that I have mixed two comments here. The first comment is about the algebra: if MAX.SND.WND > 0, then SND.UNA-MAX.SND.WND < SND.UNA, so if SEG.ACK < SND.UNA,it is possible that (SND.UNA - MAX.SND.WND) <= SEG.ACK and SEG.ACK < SND.UNA. So the statement since any ACK < SND.UNA wouldn't be accepted disagrees with ACKs which are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) gets through. for the SEG.ACK range SND.UNA - MAX.SND.WND <= SEG.ACK < SND.UNA The second comment was about the difference in behavior between existing implementations and the new recommended algorithm. I'm interested in what turns up about that. > > >There are some language errors (missed words, punctuation, all that sort >of boring stuff) that I could point out, or you could rely on the RFC >editor to find. > >Mitesh: Do send us stuff annotated and we can "refine" the document as >we move to the finish line. Working on that. >Thanks for your time and input! >Mitesh From d.b.nelson@comcast.net Wed May 6 20:20:00 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0EE3A6BD8 for ; Wed, 6 May 2009 20:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 M6V4C60t5fAF for ; Wed, 6 May 2009 20:20:00 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id E4FDC3A6834 for ; Wed, 6 May 2009 20:19:59 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id oQEZ1b00C0FhH24A6TMU61; Thu, 07 May 2009 03:21:28 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id oTMR1b00M4H2mdz8UTMSiE; Thu, 07 May 2009 03:21:28 +0000 From: "Dave Nelson" To: "'Sam Hartman'" References: <20090505171306.8D40E50822@romeo.rtfm.com><28137ED4FBEF49BBB99BCFF561806165@NEWTON603> Date: Wed, 6 May 2009 23:21:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnOZKzs1XbU7HBKQZe+rlYU3KOGKwAXEdFw Cc: iesg@ietf.org, draft-ietf-isms-radius-usage@tools.ietf.org, isms-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-isms-radius-usage-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 03:20:00 -0000 Sam Hartman writes... > I'm sorry, but I didn't understand this answer at all. Yeah, I'm afraid I've muddled up what this document is about with what *might* happen outside the scope of the document, in an attempt to answer Eric's questions. > It seems like you're both saying "you can't do that with RADIUS > (what I thought the answer was)," and "the ssh server." I don't > understand how to reconcile those. Let me try again. What's being standardized is the use of RADIUS to outsource user authentication and service authorization for SNMP access. This works with SNMP Transport Models, e.g. with SSHTM. Only those authentication methods that are natively supported in RADIUS, e.g. password, are in scope for this document. In the case of SSH, there are other authentication methods, such as public key. Such methods cannot be use with RADIUS as described in this document. Full stop. I added some confusion when I attempted to indicate that SSH and SSHTM *might* be used with SSH public key authentication, but *not* with RADIUS. In that case the use authentication resides with the local SSH server implementation in the NAS. Presumably the public key(s) of the user(s) has/have been installed in the SSH server's local configuration data store. This has nothing to do with RADIUS. It has no central AAA component, and credentials are provisioned on a device-by-device basis. This is what many deployments of SSH with public key have today. It can be used with SNMP, after a fashion. However, it has nothing to do with the document under review. Sorry to have introduced that confusion. From hallam@gmail.com Wed May 6 06:53:11 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022163A6BAD for ; Wed, 6 May 2009 06:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 bjcYzWLQi9sf for ; Wed, 6 May 2009 06:53:03 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 721A03A67A3 for ; Wed, 6 May 2009 06:52:26 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so99843yxb.49 for ; Wed, 06 May 2009 06:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=OdIiAIo/BY7ivV2kv7IDrosdFyWwGTfGaAniTbDhGX4=; b=EwgStgF/jZcQPQdTGqU4cM5fl/nu4dibwZY5dmgnQv5hbKPO+aWSEeM2PCws2pf9E8 kNWe4WIEZOdgK7NcduDIM4WHn0JgaLkkzKMdFUiQZC+Jm7U88twopg4ief6q1n1EIV/p cq42CUfCf4IDOmNK3BtzdX/LCVKIc481YFMnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=w3eHx3p4ASYk3bACqBXsUJUCCUXu04r8sCnSUKPpyQuPmK2DzZsuKPStgLu7ltGRQr 2oDsVeEQUs8PdEL/uOdfGZiAKeWaSiLbLBvdv4QZb7CDloa5gCXjJGdUheFB0drNHIaj vOt2jIzkIiKAHeZImlrcjeoj/DeARalobG2F0= MIME-Version: 1.0 Received: by 10.100.109.13 with SMTP id h13mr3011308anc.16.1241618031061; Wed, 06 May 2009 06:53:51 -0700 (PDT) Date: Wed, 6 May 2009 09:53:51 -0400 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, gdweber@gmail.com, aland@freeradius.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 May 2009 22:34:53 -0700 Subject: [secdir] Review of draft-ietf-radext-design-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 13:53: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 comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. As always with Radius documents it is somewhat hard to do a security review of a security protocol that admits that the protocol does not offer security. While the security is provided through layering on another protocol (e.g. IPSEC), the mix and match approach is unsatisfactory. Security is a property of a system. It is really not possible to analyze the security of a system when one half of the system is unspecified. The Security Considerations section is adequate and given the purpose of this draft it is appropriate to cite external documents where the security issues are discussed in detail rather than repeat the caveats here. But the question does have to be asked why we have so many security caveats in what is a foundational security protocol. While IPSEC security is certainly adequate for some applications, I have a really hard time accepting it as the security layer for a foundational security protocol. I prefer basic authentication and authorization protocols to have security built in. In particular I want to know what happens at the RADIUS protocol level when there is an error at the IPSEC layer or vice versa. IPSEC is not secure against active attack unless error conditions are appropriately handled. -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From lars.eggert@nokia.com Thu May 7 00:17:51 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CB33A683D for ; Thu, 7 May 2009 00:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRR7nGydTods for ; Thu, 7 May 2009 00:17:50 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 4C6493A70D7 for ; Thu, 7 May 2009 00:17:50 -0700 (PDT) Received: from [10.180.88.11] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n477JBKk063230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 May 2009 10:19:12 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <069366F0-685B-443F-8A1C-6EF4E45E8E21@nokia.com> From: Lars Eggert To: Sandra Murphy In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-46--766942656; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 10:19:05 +0300 References: <13D1EAB852BE194C94773A947138483D0749EF90@xmb-sjc-21c.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Thu, 07 May 2009 10:19:13 +0300 (EEST) Cc: "tcpm-chairs@tools.ietf.org" , "draft-ietf-tcpm-tcpsecure@tools.ietf.org" , "secdir@ietf.org" , "Anantha Ramaiah \(ananth\)" , "iesg@ietf.org" , "Mitesh Dalal \(mdalal\)" Subject: Re: [secdir] review of draft-ietf-tcpm-tcpsecure-11.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, 07 May 2009 07:17:51 -0000 --Apple-Mail-46--766942656 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, note that it is not at all clear whether this document will end up indicating that it is updating 793. In the document writeup (in the tracker) the chairs describe the discussion the WG had around this issue and are asking for the IESG to discuss what is appropriate here. Lars On 2009-5-6, at 21:32, Sandra Murphy wrote: > On Tue, 28 Apr 2009 11:31:01 -0700, Mitesh Dalal wrote: > > Comments below in-line. > >> Hi Sandra, >> >> Thank you for taking time to review the draft. Please see inline. >> >> >> ---------- Forwarded message ---------- >> Date: Thu, 23 Apr 2009 14:19:11 -0400 (Eastern Daylight Time) >> From: Sandra Murphy >> To: iesg@ietf.org, secdir@ietf.org, >> draft-ietf-tcpm-tcpsecure@tools.ietf.org, >> tcpm-chairs@tools.ietf.org > >> > > >> This document is intended to update rfc793. That means that it >> should >> be very explicit about what text it is replacing and what the new >> text >> is. >> >> Mitesh: The mitigation section of the discussed attack does highlight >> the processing "rules" that are >> being modified. If you have explicit suggestions to make it better, >> we >> welcome it. > > Essentially, I'm thinking that you need to indicate > > OLD: > > 793 text > 793 text > 793 text > > NEW: > > draft text > draft text > draft text > > Your mitigation techniques summarize the various pieces of 793 text > scattered over the fsm description. Figuring out which pieces of > the fsm > text are the ones summarized and which should be changed could be > ambiguous > in interpretation. As the typical tcp code tries hard to follow the > fsm > description, being precise about the changes would be good. And very > tedious, I'm sure. > >> >> >> The dicussions of interactions between TCP peers are always >> difficult to >> phrase, as most terms are relative to viewpoint. The text in some >> places is tough to read - who is the sender, who the receiver, >> etc. The >> text also uses a lot of different terms to represent the same >> entity - >> remote peer, remote end sender, remote TCP endpoint, etc. >> >> Mitesh: We may consider simplifying these terms to remote peer if >> that >> helps. Point noted. > > OK. Note that I recognize the difficulty of choosing an apporpriate > term from among the common ones, which are relative to the point of > view. > > >> The term "initial sequence number" has a special meaning in TCP and >> should be avoided. >> >> Mitesh: Can you please elaborate the context? > > Context in your draft: > > 2) A sequence number that will be used in the RST. This sequence > number will be a starting point for a series of guesses to > attempt > to present a RST segment to a connection endpoint that would be > acceptable to it. Any random value may be used to guess the > initial sequence number. > ^^^^^^^^^^^^^^^^^^^^^^^ > > Context in RFC793: > > [Lots of places in 793 refer to initial sequence number or to ISN. > And, of course, lots of literature.] > > I think the draft means "the first guess", "the starting point", not > the > TCP "initial sequence number". > >> >> The text says that this mitigation SHOULD be used "in devices" which >> typically host apps that are most vulnerable and MIGHT be used >> elsewhere. Is there a suggestion that this would be under application >> control? Chosen by the OS vendor (or device vendor)? For those who >> are >> using Quagga routers (routing apps on top of intel boxes running some >> *ix), would this be a socket option? >> What's the vision here? >> >> Mitesh: This implementation detail is outside the scope of the >> document. >> Although, implementors may >> make it a compile time option, application dependent control (as you >> hint with socket option) or may >> make it mandatory for the stack. > > The draft discusses issues of interoperability between a TCP stack > that implements the new algorithm and one that does not. But I'm > wondering about issues of interoperabality between applications and > TCP > stacks. An vulnerable app that wants the new algorithm on an OS that > has decided to leave the decision in the TCP stack, etc. > > For those systems where TCP stack and application are integrally > implemented, i.e., "devices" like routers running BGP, the > interoperability > will be taken care of. But there are cases where an app that is > vulnerable > is running on a platform where the OS is a general purpose OS. In > that > case, you aren't considering just one integrally implemented "device". > > I'm just having trouble deciding what this all means in light of the > recommendation of section 1.1: > > SHOULD be implemented in devices that regularly need to maintain > TCP > connections of the kind most vulnerable to the attacks described in > this document. Examples of such TCP connections are the ones that > tend to be long-lived and where the connection end points can be > determined, in cases where no auxiliary anti-spoofing protection > mechanisms like TCP MD5 [RFC2385] can be deployed. These > mitigations > MAY be implemented in other cases. > > I'm having difficulty figuring out how this will work. Maybe this > is just the age-old inter-layer feature negotiation problem, and > people > will deal. > >> >> I don't understand some parts of >> >> All TCP stacks MAY implement the following mitigation. TCP stacks >> which implement this mitigation MUST add an additional input check >> to >> any incoming segment. The ACK value is considered acceptable only >> if >> it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= >> SND.NXT). All incoming segments whose ACK value doesn't satisfy >> the >> above condition MUST be discarded and an ACK sent back. It needs >> to >> be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is >> a >> duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK >> acknowledges something not yet sent (SEG.ACK > SND.NXT) then send >> an >> ACK, drop the segment, and return." This mitigation makes the ACK >> check more stringent since any ACK < SND.UNA wouldn't be accepted, >> instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) >> <= >> SEG.ACK <= SND.NXT) gets through. >> >> Seems that SEG.ACK could fall between the SND.UNA and SND.UNA - >> MAX.SND.WND, in which case the new code accepts segments that the >> existing text says "it is ignored". I would read the 793 text as the >> *ACK* is ignored, which means the new text would accept (and act on) >> ACKs that are presently ignored. But looking at existing TCP code, >> it >> looks like people have interpreted "it is ignored" as the *segment* >> is >> ignored, i.e., dropped. In that case, this new text is accepting >> segments that in existing implementations would be dropped. >> Is that the intent? (Note: I could be easily wrong about the >> tcp_input >> code.) >> >> Mitesh: I will have to dig and find out, my recollection is hazy >> but I >> think this was raised earlier >> and may have been discussed. > > Note that I have mixed two comments here. The first comment is about > the algebra: > > if MAX.SND.WND > 0, then SND.UNA-MAX.SND.WND < SND.UNA, so if > SEG.ACK < SND.UNA,it is possible that (SND.UNA - MAX.SND.WND) <= > SEG.ACK > and SEG.ACK < SND.UNA. So the statement > since any ACK < SND.UNA wouldn't be accepted > disagrees with > ACKs which are in the range ((SND.UNA - > MAX.SND.WND) <= > SEG.ACK <= SND.NXT) gets through. > for the SEG.ACK range SND.UNA - MAX.SND.WND <= SEG.ACK < SND.UNA > > The second comment was about the difference in behavior between > existing > implementations and the new recommended algorithm. I'm interested > in what > turns up about that. > > >> >> >> There are some language errors (missed words, punctuation, all that >> sort >> of boring stuff) that I could point out, or you could rely on the RFC >> editor to find. >> >> Mitesh: Do send us stuff annotated and we can "refine" the document >> as >> we move to the finish line. > > Working on that. > >> Thanks for your time and input! >> Mitesh > --Apple-Mail-46--766942656 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA1MDcwNzE5MDZaMCMGCSqGSIb3DQEJBDEWBBT26oAha0LsAW0K /c+2wV1aZ4AERTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAlkcXwTSzdCExI9s+OG+mrz/K4n2aQQNYxxc3rLwdDjFT8WewMnXG +9Ke/hnaLg5oSKmh+7KCzyubUuvJTdjhh+wW32lPRr6lMabDDvObQzkrs2uvuoPyXqcc8dG4URxm rfkQj1OhOY/nwf0VKbpYc/04ZE8q6j1ddK8LHNlP/8vBbuzmIoAufLH4+XkBJXb6UQz5ie1FrVGE dl5he4kNRcAO3onq37ey97lzVMA40bHSGVYTp+cHRxSEom6veKASHXzTLhH1JCj9d/IJeBfF1KO3 YvH6ukx3gUo5p0PeonZiXhK36tlDmanPqXkfZ+MkgFTmD4feyZaQyxReEObOGQAAAAAAAA== --Apple-Mail-46--766942656-- From dnelson@elbrysnetworks.com Thu May 7 14:06:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E8B3A6802 for ; Thu, 7 May 2009 14:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dAG+w9-uzF1 for ; Thu, 7 May 2009 14:06:39 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 3D4823A68A0 for ; Thu, 7 May 2009 14:06:21 -0700 (PDT) Received: (qmail 19308 invoked from network); 5 May 2009 16:07:46 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 5 May 2009 16:07:46 -0400 From: "David B. Nelson" To: "'David B Harrington'" , "'Jeffrey Hutzelman'" , "'Barry Leiba'" , , References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> Date: Tue, 5 May 2009 16:07:48 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> Thread-Index: AcnNtSYsrMOk66M4RPGOpg+msofHJgAAhTKAAAFePSA= X-Mailman-Approved-At: Thu, 07 May 2009 14:17:47 -0700 Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [secdir] [Isms] secdir review of draft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2009 21:06:39 -0000 David B Harrington writes... > What is the correct non-RFC2119 phrase in which to > couch our deployment advice? One suitable strategy would be to include any "advice to operators" in a non-normative section or appendix, clearly labeled as non-normative. I don't think the "keyword police" will bother with non-normative text. :-) From hartmans@mit.edu Thu May 7 18:49:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055583A7042; Thu, 7 May 2009 18:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLYc+BBZDXxZ; Thu, 7 May 2009 18:49:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 410C63A7031; Thu, 7 May 2009 18:49:18 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EFB854163; Thu, 7 May 2009 21:50:40 -0400 (EDT) To: "David B. Nelson" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> From: Sam Hartman Date: Thu, 07 May 2009 21:15:47 -0400 In-Reply-To: (David B. Nelson's message of "Tue\, 5 May 2009 16\:07\:48 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'David B Harrington' , isms@ietf.org, secdir@ietf.org, isms-chairs@tools.ietf.org, iesg@ietf.org, 8 'Barry Leiba' , draft-ietf-isms-transport-security-model@tools.ietf.org Subject: Re: [secdir] [Isms] secdir review of draft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 01:49:19 -0000 >>>>> "David" == David B Nelson writes: David> David B Harrington writes... >> What is the correct non-RFC2119 phrase in which to couch our >> deployment advice? David> One suitable strategy would be to include any "advice to David> operators" in a non-normative section or appendix, clearly David> labeled as non-normative. I don't think the "keyword David> police" will bother with non-normative text. :-) 8 David> _______________________________________________ secdir David> mailing list secdir@ietf.org David> https://www.ietf.org/mailman/listinfo/secdir Or just use lower case should. I think the advice is important enough it does not belong in an appendix. From barryleiba@gmail.com Thu May 7 19:09:07 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9663A6FA4; Thu, 7 May 2009 19:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGiIoh-fIV9J; Thu, 7 May 2009 19:09:06 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id B5D493A67FB; Thu, 7 May 2009 19:09:05 -0700 (PDT) Received: by ewy24 with SMTP id 24so1539420ewy.37 for ; Thu, 07 May 2009 19:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eM1Y+1syv701mN0NEXSk+38dINk3YIInWKgYsYKTN44=; b=MRKj4VOlTNPdEKwk9g57Pz9Z2mgXujun7N9pPhuB7aTb2oPtrso+f4N7IgIWp4ZbYk bHr4WxmYkxXcjjZabTddTR5aHuGucn01K//0zYmhWX76xYarCNHVxPzvXDX3fn+WsaR/ YsNq4bSYahFoYxE0Ew8E7mjjqpi8NTb+tzwr4= 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=mPUyleGooZh1a2Mj2ARwlvaL1mUVDGvxqrU549mXls+f63DS1NZ+0glCsE+oSn2HcK HHSpVmKciSLZ3VAx9whcBf/sFmb67xM7cBDA3/2lIaK6Um+M9uNdBU6nYR+q6i/M0d+Z Adxlf2FsebSIYQKVV1+zfHoBhYbVQDghrPxrI= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.130.14 with SMTP id c14mr3848956ebd.17.1241748630564; Thu, 07 May 2009 19:10:30 -0700 (PDT) In-Reply-To: References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> Date: Thu, 7 May 2009 22:10:30 -0400 X-Google-Sender-Auth: df2cf3bcf03b453a Message-ID: <9abf48a60905071910rcf9e321ha0ab92e692a6aeed@mail.gmail.com> From: Barry Leiba To: David B Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org, secdir@ietf.org, "David B. Nelson" , isms-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-isms-transport-security-model@tools.ietf.org Subject: Re: [secdir] [Isms] secdir review of draft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 02:09:07 -0000 Sam says... > Or just use lower case should. =A0I think the advice is important enough > it does not belong in an appendix. Indeed. I didn't mean for my comment to cause a big stir; I think it's easy to sort= out. I like my first suggestion, repeated here: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so it MUST always be used with a Transport Model that provides appropriate security. What is "appropriate" for a particul= ar deployment is an administrative decision. Which threats are addressed and how they are mitigated depends on the Transport Model. ...but I'd also be happy with something like this, if you don't want to use 2119 language: by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself, so deployments should [or "must"] use it with a Transport Model that provides appropriate security. Which threats are addressed and how they are mitigated depends on the Transport Model. In any case, let's not spend any more time on this one. Barry --=20 Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From barryleiba@gmail.com Fri May 8 11:03:50 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CDB3A6A6A; Fri, 8 May 2009 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh7Vs5CytDTP; Fri, 8 May 2009 11:03:49 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 1BACA3A68EE; Fri, 8 May 2009 11:03:48 -0700 (PDT) Received: by ewy24 with SMTP id 24so2003758ewy.37 for ; Fri, 08 May 2009 11:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Xxbp2g/pWwo7wsfjK8ouyVG14qFJJN2OPWa/Cf9cPF4=; b=NaZGuz7Lfy6PIhb6XXhqFOUxKiPSjILsG2wIPMGm3SOI3e1l479V+wP2juGsDVjjO1 uVIGYnrIAG3rN4OeOBzelTQbOZyrJm4GSndz6c0YdgJW6Yz79aaFoBWpRz2MINLLQEIC mXhc3i1D0v0U2rBotIxLv98Dylyr3jTAY3ZQ4= 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=aCDzAUR8J3hlq8jZ3Ncr467cgTwOt9My7E5c9dTl12N+AJEVrvyicLHlg2mYtAnJ8V e+flK2bF2fO3F/cZ0c40YpZUwK+/FtRy3ZsWpWuVdJLxXCpcsKgH+11f7Px8KajLBiUL 2QyFHmRBdS5ucBkez5wanSNSbzz2XdCV784tg= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.17.2 with SMTP id 2mr2065031ebq.35.1241805915886; Fri, 08 May 2009 11:05:15 -0700 (PDT) In-Reply-To: <007f01c9cffe$0aa68da0$0601a8c0@allison> References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> Date: Fri, 8 May 2009 14:05:15 -0400 X-Google-Sender-Auth: cb874c641c4d5cc1 Message-ID: <9abf48a60905081105t49201217o591687187c12dd84@mail.gmail.com> From: Barry Leiba To: "tom.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 18:03:50 -0000 (Top post only...) I get what you're saying, Tom, but I'm not sure where it's going. Are you saying that the text should be changed to allow *less* flexibility? That may be right, but then what text do you suggest instead? Barry >> > That is a deployment decision made by an administrator who has an >> > understanding of what is appropriate to the system in question. >> > >> > What is the correct non-RFC2119 phrase in which to couch our >> > deployment advice? >> >> Well, this would make me happy; would it work for you (and others)?: >> >> OLD: >> =A0 =A0by the RFC 3411 architecture. =A0However, the Transport Security = Model >> =A0 =A0does not provide security mechanisms such as authentication and >> =A0 =A0encryption itself, so it SHOULD always be used with a Transport M= odel >> =A0 =A0that provides appropriate security. =A0Which threats are addresse= d and >> =A0 =A0how they are mitigated depends on the Transport Model. >> >> NEW: >> =A0 =A0by the RFC 3411 architecture. =A0However, the Transport Security = Model >> =A0 =A0does not provide security mechanisms such as authentication and >> =A0 =A0encryption itself, so it MUST always be used with a Transport Mod= el >> =A0 =A0that provides appropriate security. =A0What is "appropriate" for = a particular >> =A0 =A0deployment is an administrative decision. =A0Which threats are ad= dressed >> =A0 =A0and how they are mitigated depends on the Transport Model. > > I have reservations about this, about the optimism that it may generate i= n > readers. > > The idea of Models in SNMP is to be able to mix and match. =A0In practice= , this > has not worked - USM with sshTM will not function, regardless of whether = it is > secure or not. =A0Do not underestimate the labour it has taken to get TSM= working > with sshTM. > > If we have got TSM right, then it will work with eg TLSTM or DTLSTM, an i= dea > that is being mooted now. =A0But it may not. =A0In a similar vein, I am m= indful that > ssh just hit problems with AES-GCM, that the architecture of ssh does not= allow > for this new cryptography or that the discussions leading to TLS 1.2 of h= ow to > introduce (or not) algorithm agility, just as SNMP has problems (and has = given > up) trying to use USM with sshTM. > > Thus TLS has session cache and resumption. Will that work with TSM? I do = not > know - and as it has taken the last two years to come up with an agreed f= orm of > words that allows just TSM to work with just sshTM, so I am not going > to try and work out the ramifications of TLSTM just yet:-( =A0We may find= we got > TSM wrong and that it needs changing. > > Or we may have another secure Transport Model that turns out to be insecu= re with > TSM and needs an xSM to make it secure. =A0The proposed amendment seems t= o me > rather optimistic. > > Tom Petch From j.schoenwaelder@jacobs-university.de Fri May 8 14:42:41 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942843A67FD; Fri, 8 May 2009 14:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcCfKlImNOzp; Fri, 8 May 2009 14:42:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7DE063A6C4F; Fri, 8 May 2009 14:42:40 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7D49C0218; Fri, 8 May 2009 23:44:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XzlQWnAS0c2U; Fri, 8 May 2009 23:44:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FA30C0212; Fri, 8 May 2009 23:44:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F0A20AE404D; Fri, 8 May 2009 23:43:46 +0200 (CEST) Date: Fri, 8 May 2009 23:43:46 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20090508214346.GB28541@elstar.local> Mail-Followup-To: "tom.petch" , Barry Leiba , "isms@ietf.org" , "secdir@ietf.org" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007f01c9cffe$0aa68da0$0601a8c0@allison> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Barry Leiba , "isms@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [Isms] secdir reviewofdraft-ietf-isms-transport-security-model-12 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, 08 May 2009 21:42:41 -0000 On Fri, May 08, 2009 at 06:56:27PM +0200, tom.petch wrote: > The idea of Models in SNMP is to be able to mix and match. In > practice, this has not worked - USM with sshTM will not function, > regardless of whether it is secure or not. Not sure I understand why. Can you explain? > Thus TLS has session cache and resumption. Will that work with TSM? Yes, this will just work fine since it is transparent. You can add session resumption to SSH and it will work just fine with sshtm. Of course, sometimes we design for extensibility and when we need it, we realize the shortcomings of the design. But there are also things that just work fine - you are painting a picture here with black colors. Even though it is difficult to get exensibility right, I think not trying to be extensible is not an alternative. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From tlyu@MIT.EDU Fri May 8 15:01:37 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606323A67FD; Fri, 8 May 2009 15:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[AWL=0.852, 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 X9slVv8BES-b; Fri, 8 May 2009 15:01:36 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id A8BC33A6A1C; Fri, 8 May 2009 15:01:20 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n48M2bmZ011050; Fri, 8 May 2009 18:02:37 -0400 (EDT) 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 n48M2ZXg007204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 May 2009 18:02:36 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n48M2ZOi014033; Fri, 8 May 2009 18:02:35 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, dkim-chairs@tools.ietf.org, dcrocker@bbiw.net From: Tom Yu Date: Fri, 08 May 2009 18:02:35 -0400 Message-ID: Lines: 69 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 Subject: [secdir] secdir review of draft-ietf-dkim-rfc4871-errata-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 22:01:37 -0000 This document updates the DKIM specification to clarify the roles of two DKIM identifier tag values that a consumer of DKIM verification may use. The Security Considerations section states that the clarifications in this document should improve the security characteristics of the protocol. I find this statement to be reasonably accurate. Section 12, which adds a new Section 3.9 to RFC 4871, contains a number of statements giving guidance about assessor policy. A summary of these statements, along with a pointer to the full text, should probably appear in an amendment to the RFC 4871 Security Considerations. The following are editorial comments. In Section 1, delete the spurious "and" following "specifies". old: This update resolves this confusion. It defines new labels for the two values, clarifies their nature, and specifies and their relationship. new: This update resolves this confusion. It defines new labels for the two values, clarifies their nature, and specifies their relationship. In Section 8, the text: The name of the module that consumes DKIM's mandatory payload, the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However this additional activity is outside the scope of the DKIM signature specification. might be better written as: A module that consumes DKIM's mandatory payload, which is the responsible Signing Domain Identifier (SDID). The module is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be delivered to this module as well as to a more general message evaluation filtering engine. However, this additional activity is outside the scope of the DKIM signature specification. in order to align with the form of other definitions added in this document. In Sections 9 and 10, the ABNF in the new text looks misformatted. In Section 10, the sentence: However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a finer grained, stable identifier than the SDID. might be better written as: However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID. From ietfdbh@comcast.net Fri May 8 15:08:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D283A6BEE for ; Fri, 8 May 2009 15:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZu85r5pgR6B for ; Fri, 8 May 2009 15:08:18 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id E8EF03A69BD for ; Fri, 8 May 2009 15:08:17 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA01.westchester.pa.mail.comcast.net with comcast id oxjA1b0060vyq2s51A9n1d; Fri, 08 May 2009 22:09:47 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id pA9n1b00H0UQ6dC3RA9nJ1; Fri, 08 May 2009 22:09:47 +0000 From: "David Harrington" To: "'tom.petch'" , "'Barry Leiba'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu><06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com><9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com><007f01c9cffe$0aa68da0$0601a8c0@allison><9abf48a60905081105t49201217o591687187c12dd84@mail.gmail.com> <002801c9d01c$ab134bc0$0601a8c0@allison> Date: Fri, 8 May 2009 18:09:46 -0400 Message-ID: <096b01c9d029$b2b51c20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnQJUeTxtK0lG2NTU6SeHB0hlUu0QAAycQA X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002801c9d01c$ab134bc0$0601a8c0@allison> Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdirreviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 22:08:19 -0000 Hi, IN sechell-17, its says: "It is expected that an entity implementing this MIB will also support the Transport Security Model [I-D.ietf-isms-transport-security-model], and therefore implement the SNMP-TSM-MIB." " To have SNMP properly utilize the security services provided by SSH, the SSH Transport Model MUST be used with a Security Model that knows how to process a tmStateReference, such as the Transport Security Model for SNMP [I-D.ietf-isms-transport-security-model]." In transport-model-14, it says: " To have SNMP properly utilize the security services coordinated by the Transport Security Model, this Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model [I-D.ietf-isms-secshell]." By keeping the reference to an example using "such as", we avoid hard bindings between the models, and we avoid normative references between the documents, so as to not defeat the goal of the RFC3411 modular architecture of allowing the models to advance on the standards track independently. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Friday, May 08, 2009 4:36 PM > To: Barry Leiba > Cc: isms@ietf.org; secdir@ietf.org > Subject: Re: [Isms] [secdir] > secdirreviewofdraft-ietf-isms-transport-security-model-12 > > ----- Original Message ----- > From: "Barry Leiba" > To: "tom.petch" > Cc: ; > Sent: Friday, May 08, 2009 8:05 PM > > (Top post only...) > I get what you're saying, Tom, but I'm not sure where it's going. Are > you saying that the text should be changed to allow *less* > flexibility? That may be right, but then what text do you suggest > instead? > > Barry > > I would like the idea of 'in conjunction with' to hint at the > co-dependence of > xSM and xTM eg > > "However, the Transport Security Model > does not by itself provide security mechanisms such as > authentication and > encryption, so it MUST always be used in conjunction with a > Transport Model that > together with it provides appropriate security" > > Tom Petch > > Barry > > >> > That is a deployment decision made by an administrator who has an > >> > understanding of what is appropriate to the system in question. > >> > > >> > What is the correct non-RFC2119 phrase in which to couch our > >> > deployment advice? > >> > >> Well, this would make me happy; would it work for you (and > others)?: > >> > >> OLD: > >> by the RFC 3411 architecture. However, the Transport Security Model > >> does not provide security mechanisms such as authentication and > >> encryption itself, so it SHOULD always be used with a > Transport Model > >> that provides appropriate security. Which threats are addressed and > >> how they are mitigated depends on the Transport Model. > >> > >> NEW: > >> by the RFC 3411 architecture. However, the Transport Security Model > >> does not provide security mechanisms such as authentication and > >> encryption itself, so it MUST always be used with a Transport Model > >> that provides appropriate security. What is "appropriate" > for a particular > >> deployment is an administrative decision. Which threats > are addressed > >> and how they are mitigated depends on the Transport Model. > > > > I have reservations about this, about the optimism that it > may generate in > > readers. > > > > The idea of Models in SNMP is to be able to mix and match. > In practice, this > > has not worked - USM with sshTM will not function, > regardless of whether it is > > secure or not. Do not underestimate the labour it has taken > to get TSM working > > with sshTM. > > > > If we have got TSM right, then it will work with eg TLSTM > or DTLSTM, an idea > > that is being mooted now. But it may not. In a similar > vein, I am mindful that > > ssh just hit problems with AES-GCM, that the architecture > of ssh does not > allow > > for this new cryptography or that the discussions leading > to TLS 1.2 of how to > > introduce (or not) algorithm agility, just as SNMP has > problems (and has given > > up) trying to use USM with sshTM. > > > > Thus TLS has session cache and resumption. Will that work > with TSM? I do not > > know - and as it has taken the last two years to come up > with an agreed form > of > > words that allows just TSM to work with just sshTM, so I am > not going > > to try and work out the ramifications of TLSTM just yet:-( > We may find we got > > TSM wrong and that it needs changing. > > > > Or we may have another secure Transport Model that turns > out to be insecure > with > > TSM and needs an xSM to make it secure. The proposed > amendment seems to me > > rather optimistic. > > > > Tom Petch > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Fri May 8 15:22:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0BD3A6CDC for ; Fri, 8 May 2009 15:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8CLAUfHFKEE for ; Fri, 8 May 2009 15:22:39 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 4BF3F3A67FD for ; Fri, 8 May 2009 15:22:39 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA06.westchester.pa.mail.comcast.net with comcast id p3UR1b00G0vyq2s56APuSG; Fri, 08 May 2009 22:23:54 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id pAQ61b00A0UQ6dC3RAQ6Lt; Fri, 08 May 2009 22:24:06 +0000 From: "David Harrington" To: "'tom.petch'" , "'Barry Leiba'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu><06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com><9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com><007f01c9cffe$0aa68da0$0601a8c0@allison><9abf48a60905081105t49201217o591687187c12dd84@mail.gmail.com> <002801c9d01c$ab134bc0$0601a8c0@allison> Date: Fri, 8 May 2009 18:24:05 -0400 Message-ID: <096c01c9d02b$b29db1a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnQJUeTxtK0lG2NTU6SeHB0hlUu0QABPnpQ X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002801c9d01c$ab134bc0$0601a8c0@allison> Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdirreviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 22:22:39 -0000 Hi, transport-security-model-14 says, in the discussion of threats,: " The Transport Security Model is compatible with the RFC3411 architecture, and provides protection against the threats identified by the RFC 3411 architecture. However, the Transport Security Model does not provide security mechanisms such as authentication and encryption itself. Which threats are addressed and how they are mitigated depends on the Transport Model used. To avoid creating potential security vulnerabilities, operators should configure their system so this Security Model is always used with a Transport Model that provides appropriate security, where "appropriate" for a particular deployment is an administrative decision." Whether SSHTM is appropriate in the network being managed is an administrative decision, so we do not cite it specifically at this point. and, under Coexistence with Transport Models, it says: " To have SNMP properly utilize the security services coordinated by the Transport Security Model, this Security Model MUST only be used with Transport Models that know how to process a tmStateReference, such as the Secure Shell Transport Model [I-D.ietf-isms-secshell]." David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Friday, May 08, 2009 4:36 PM > To: Barry Leiba > Cc: isms@ietf.org; secdir@ietf.org > Subject: Re: [Isms] [secdir] > secdirreviewofdraft-ietf-isms-transport-security-model-12 > > ----- Original Message ----- > From: "Barry Leiba" > To: "tom.petch" > Cc: ; > Sent: Friday, May 08, 2009 8:05 PM > > (Top post only...) > I get what you're saying, Tom, but I'm not sure where it's going. Are > you saying that the text should be changed to allow *less* > flexibility? That may be right, but then what text do you suggest > instead? > > Barry > > I would like the idea of 'in conjunction with' to hint at the > co-dependence of > xSM and xTM eg > > "However, the Transport Security Model > does not by itself provide security mechanisms such as > authentication and > encryption, so it MUST always be used in conjunction with a > Transport Model that > together with it provides appropriate security" > > Tom Petch > > Barry > > >> > That is a deployment decision made by an administrator who has an > >> > understanding of what is appropriate to the system in question. > >> > > >> > What is the correct non-RFC2119 phrase in which to couch our > >> > deployment advice? > >> > >> Well, this would make me happy; would it work for you (and > others)?: > >> > >> OLD: > >> by the RFC 3411 architecture. However, the Transport Security Model > >> does not provide security mechanisms such as authentication and > >> encryption itself, so it SHOULD always be used with a > Transport Model > >> that provides appropriate security. Which threats are addressed and > >> how they are mitigated depends on the Transport Model. > >> > >> NEW: > >> by the RFC 3411 architecture. However, the Transport Security Model > >> does not provide security mechanisms such as authentication and > >> encryption itself, so it MUST always be used with a Transport Model > >> that provides appropriate security. What is "appropriate" > for a particular > >> deployment is an administrative decision. Which threats > are addressed > >> and how they are mitigated depends on the Transport Model. > > > > I have reservations about this, about the optimism that it > may generate in > > readers. > > > > The idea of Models in SNMP is to be able to mix and match. > In practice, this > > has not worked - USM with sshTM will not function, > regardless of whether it is > > secure or not. Do not underestimate the labour it has taken > to get TSM working > > with sshTM. > > > > If we have got TSM right, then it will work with eg TLSTM > or DTLSTM, an idea > > that is being mooted now. But it may not. In a similar > vein, I am mindful that > > ssh just hit problems with AES-GCM, that the architecture > of ssh does not > allow > > for this new cryptography or that the discussions leading > to TLS 1.2 of how to > > introduce (or not) algorithm agility, just as SNMP has > problems (and has given > > up) trying to use USM with sshTM. > > > > Thus TLS has session cache and resumption. Will that work > with TSM? I do not > > know - and as it has taken the last two years to come up > with an agreed form > of > > words that allows just TSM to work with just sshTM, so I am > not going > > to try and work out the ramifications of TLSTM just yet:-( > We may find we got > > TSM wrong and that it needs changing. > > > > Or we may have another secure Transport Model that turns > out to be insecure > with > > TSM and needs an xSM to make it secure. The proposed > amendment seems to me > > rather optimistic. > > > > Tom Petch > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From dcrocker@bbiw.net Fri May 8 18:06:48 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE473A68CD; Fri, 8 May 2009 18:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywfYlA0CG35w; Fri, 8 May 2009 18:06:47 -0700 (PDT) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 83C963A6892; Fri, 8 May 2009 18:06:47 -0700 (PDT) Received: from [192.168.0.5] (adsl-67-124-151-74.dsl.pltn13.pacbell.net [67.124.151.74]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4917xM0027978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 18:08:14 -0700 Message-ID: <4A04D769.5040502@bbiw.net> Date: Fri, 08 May 2009 18:07:53 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Tom Yu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 08 May 2009 18:08:15 -0700 (PDT) Cc: dkim-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dkim-rfc4871-errata-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: Sat, 09 May 2009 01:06:48 -0000 Tom, Many thanks for the careful review and comments. My reading of your note is that it suggests language that is cleaner and more consistent, but that the changes do *not* introduce any possibility of being seen as changing meaning. In other words, they should help readability and shouldn't be controversial. d/ Tom Yu wrote: > This document updates the DKIM specification to clarify the roles of > two DKIM identifier tag values that a consumer of DKIM verification > may use. The Security Considerations section states that the > clarifications in this document should improve the security > characteristics of the protocol. I find this statement to be > reasonably accurate. > > Section 12, which adds a new Section 3.9 to RFC 4871, contains a > number of statements giving guidance about assessor policy. A summary > of these statements, along with a pointer to the full text, should > probably appear in an amendment to the RFC 4871 Security > Considerations. > > The following are editorial comments. > > In Section 1, delete the spurious "and" following "specifies". > > old: > > This update resolves this confusion. It defines new labels for the > two values, clarifies their nature, and specifies and their > relationship. > > new: > > This update resolves this confusion. It defines new labels for the > two values, clarifies their nature, and specifies their > relationship. > > In Section 8, the text: > > The name of the module that consumes DKIM's mandatory payload, the > responsible Signing Domain Identifier (SDID). The module is > dedicated to the assessment of the delivered identifier. Other > DKIM (and non-DKIM) values can also be delivered to this module as > well as to a more general message evaluation filtering engine. > However this additional activity is outside the scope of the DKIM > signature specification. > > might be better written as: > > A module that consumes DKIM's mandatory payload, which is the > responsible Signing Domain Identifier (SDID). The module is > dedicated to the assessment of the delivered identifier. Other > DKIM (and non-DKIM) values can also be delivered to this module > as well as to a more general message evaluation filtering > engine. However, this additional activity is outside the scope > of the DKIM signature specification. > > in order to align with the form of other definitions added in this > document. > > In Sections 9 and 10, the ABNF in the new text looks misformatted. > > In Section 10, the sentence: > > However, the signer SHOULD use the same AUID for each message > intended to be evaluated as being within the same sphere of > responsibility, if it wishes to offer receivers the option of > using the AUID as a finer grained, stable identifier than the > SDID. > > might be better written as: > > However, the signer SHOULD use the same AUID for each message > intended to be evaluated as being within the same sphere of > responsibility, if it wishes to offer receivers the option of > using the AUID as a stable identifier that is finer grained > than the SDID. > -- Dave Crocker Brandenburg InternetWorking bbiw.net From ietfdbh@comcast.net Sat May 9 09:30:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C043A6E67 for ; Sat, 9 May 2009 09:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poZ-pnx875pT for ; Sat, 9 May 2009 09:30:11 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 3B3C63A6E50 for ; Sat, 9 May 2009 09:30:10 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA04.westchester.pa.mail.comcast.net with comcast id pPRE1b0040cZkys54UXgAk; Sat, 09 May 2009 16:31:40 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id pUXf1b00n0UQ6dC3WUXgVo; Sat, 09 May 2009 16:31:40 +0000 From: "David Harrington" To: "'Wes Hardaker'" , "'tom.petch'" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu><06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com><9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com><007f01c9cffe$0aa68da0$0601a8c0@allison><20090508214346.GB28541@elstar.local> Date: Sat, 9 May 2009 12:31:38 -0400 Message-ID: <098001c9d0c3$a119ea00$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnQrS0FO4T3PJQ/S7+R9hOXeJvNcQAFTx9g X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: 'Barry Leiba' , isms@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 16:30:12 -0000 Hi, I agree we didn't use the word "MUST" in this text, but we do not seem to allow any alternative approach: "then [...] discard the message and return the error indication in the statusInformation." For compliance to this model, this is a required step. Where we do NOT specify a MUST is in the **architecture** document, because other models might choose to do something other than discard the message. Wes, are you suggestiong we should rwwrite all the elements of procedure to use MUST every place where there is a definite step to be followed? Would this be clearer? > 1. If tmStateReference does not refer to a cache containing values > for tmTransportDomain, tmTransportAddress, tmSecurityName, > tmRequestedSecurityLevel, and tmSameSecurity, then the implementation MUST > increment the > sshtmSessionInvalidCaches counter, MUST discard the message > and MUST return > the error indication in the statusInformation. Processing of > this message MUST stop. is that what you want to see? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Saturday, May 09, 2009 9:51 AM > To: tom.petch > Cc: Barry Leiba; isms@ietf.org; secdir@ietf.org > Subject: Re: [Isms] [secdir]secdir > reviewofdraft-ietf-isms-transport-security-model-12 > > >>>>> On Fri, 8 May 2009 23:43:46 +0200, Juergen > Schoenwaelder said: > > >> The idea of Models in SNMP is to be able to mix and match. In > >> practice, this has not worked - USM with sshTM will not function, > >> regardless of whether it is secure or not. > > JS> Not sure I understand why. Can you explain? > > The way it's worded right now in the SSH document is that > there must be > a tmStateReference for outgoing messages or the SSHTM will drop the > message: > > 1. If tmStateReference does not refer to a cache containing values > for tmTransportDomain, tmTransportAddress, tmSecurityName, > tmRequestedSecurityLevel, and tmSameSecurity, then > increment the > sshtmSessionInvalidCaches counter, discard the message > and return > the error indication in the statusInformation. Processing of > this message stops. > > USM won't generate a tmStateReference so it can't be used as an > upper-level security protocol. This was discussed (I'm > fairly certain) > on the list at some point and it was decided this was ok as doing > something to try and recover at that point would really be > adding words > and complexity for a situation that didn't really need to be > supported. > > [that being said, note that there isn't a MUST drop it in the text] > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From cfinss@dial.pipex.com Fri May 8 10:57:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9123A6DB9; Fri, 8 May 2009 10:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.499, 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 Kvk2KI+YgHvU; Fri, 8 May 2009 10:57:18 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 41AE33A6C68; Fri, 8 May 2009 10:57:18 -0700 (PDT) X-Trace: 101204951/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.61/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.61 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEAP8PBEo+vBM9/2dsb2JhbACDKEyKYsJBB4N2BQ X-IronPort-AV: E=Sophos;i="4.40,318,1238972400"; d="scan'208";a="101204951" X-IP-Direction: IN Received: from 1cust61.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.61]) by smtp.pipex.tiscali.co.uk with SMTP; 08 May 2009 18:57:44 +0100 Message-ID: <007f01c9cffe$0aa68da0$0601a8c0@allison> From: "tom.petch" To: "Barry Leiba" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com><200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu><0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu><06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> Date: Fri, 8 May 2009 18:56:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Mon, 11 May 2009 00:03:35 -0700 Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 17:57:19 -0000 ----- Original Message ----- From: "Barry Leiba" To: "David B Harrington" Cc: ; ; ; Sent: Tuesday, May 05, 2009 10:03 PM > > That is a deployment decision made by an administrator who has an > > understanding of what is appropriate to the system in question. > > > > What is the correct non-RFC2119 phrase in which to couch our > > deployment advice? > > Well, this would make me happy; would it work for you (and others)?: > > OLD: > by the RFC 3411 architecture. However, the Transport Security Model > does not provide security mechanisms such as authentication and > encryption itself, so it SHOULD always be used with a Transport Model > that provides appropriate security. Which threats are addressed and > how they are mitigated depends on the Transport Model. > > NEW: > by the RFC 3411 architecture. However, the Transport Security Model > does not provide security mechanisms such as authentication and > encryption itself, so it MUST always be used with a Transport Model > that provides appropriate security. What is "appropriate" for a particular > deployment is an administrative decision. Which threats are addressed > and how they are mitigated depends on the Transport Model. I have reservations about this, about the optimism that it may generate in readers. The idea of Models in SNMP is to be able to mix and match. In practice, this has not worked - USM with sshTM will not function, regardless of whether it is secure or not. Do not underestimate the labour it has taken to get TSM working with sshTM. If we have got TSM right, then it will work with eg TLSTM or DTLSTM, an idea that is being mooted now. But it may not. In a similar vein, I am mindful that ssh just hit problems with AES-GCM, that the architecture of ssh does not allow for this new cryptography or that the discussions leading to TLS 1.2 of how to introduce (or not) algorithm agility, just as SNMP has problems (and has given up) trying to use USM with sshTM. Thus TLS has session cache and resumption. Will that work with TSM? I do not know - and as it has taken the last two years to come up with an agreed form of words that allows just TSM to work with just sshTM, so I am not going to try and work out the ramifications of TLSTM just yet:-( We may find we got TSM wrong and that it needs changing. Or we may have another secure Transport Model that turns out to be insecure with TSM and needs an xSM to make it secure. The proposed amendment seems to me rather optimistic. Tom Petch > Barry > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From cfinss@dial.pipex.com Fri May 8 14:35:43 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14A03A6B1C; Fri, 8 May 2009 14:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.492, 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 8GD8Patyglo3; Fri, 8 May 2009 14:35:42 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 819AA3A7151; Fri, 8 May 2009 14:35:32 -0700 (PDT) X-Trace: 245559828/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.116/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.116 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEABdDBEo+vBN0/2dsb2JhbACDKEyKYsIbB4N2BQ X-IronPort-AV: E=Sophos;i="4.40,319,1238972400"; d="scan'208";a="245559828" X-IP-Direction: IN Received: from 1cust116.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.116]) by smtp.pipex.tiscali.co.uk with SMTP; 08 May 2009 22:36:57 +0100 Message-ID: <002801c9d01c$ab134bc0$0601a8c0@allison> From: "tom.petch" To: "Barry Leiba" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> <9abf48a60905081105t49201217o591687187c12dd84@mail.gmail.com> Date: Fri, 8 May 2009 22:35:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Mon, 11 May 2009 00:03:35 -0700 Cc: isms@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 21:35:43 -0000 ----- Original Message ----- From: "Barry Leiba" To: "tom.petch" Cc: ; Sent: Friday, May 08, 2009 8:05 PM (Top post only...) I get what you're saying, Tom, but I'm not sure where it's going. Are you saying that the text should be changed to allow *less* flexibility? That may be right, but then what text do you suggest instead? Barry I would like the idea of 'in conjunction with' to hint at the co-dependence of xSM and xTM eg "However, the Transport Security Model does not by itself provide security mechanisms such as authentication and encryption, so it MUST always be used in conjunction with a Transport Model that together with it provides appropriate security" Tom Petch Barry >> > That is a deployment decision made by an administrator who has an >> > understanding of what is appropriate to the system in question. >> > >> > What is the correct non-RFC2119 phrase in which to couch our >> > deployment advice? >> >> Well, this would make me happy; would it work for you (and others)?: >> >> OLD: >> by the RFC 3411 architecture. However, the Transport Security Model >> does not provide security mechanisms such as authentication and >> encryption itself, so it SHOULD always be used with a Transport Model >> that provides appropriate security. Which threats are addressed and >> how they are mitigated depends on the Transport Model. >> >> NEW: >> by the RFC 3411 architecture. However, the Transport Security Model >> does not provide security mechanisms such as authentication and >> encryption itself, so it MUST always be used with a Transport Model >> that provides appropriate security. What is "appropriate" for a particular >> deployment is an administrative decision. Which threats are addressed >> and how they are mitigated depends on the Transport Model. > > I have reservations about this, about the optimism that it may generate in > readers. > > The idea of Models in SNMP is to be able to mix and match. In practice, this > has not worked - USM with sshTM will not function, regardless of whether it is > secure or not. Do not underestimate the labour it has taken to get TSM working > with sshTM. > > If we have got TSM right, then it will work with eg TLSTM or DTLSTM, an idea > that is being mooted now. But it may not. In a similar vein, I am mindful that > ssh just hit problems with AES-GCM, that the architecture of ssh does not allow > for this new cryptography or that the discussions leading to TLS 1.2 of how to > introduce (or not) algorithm agility, just as SNMP has problems (and has given > up) trying to use USM with sshTM. > > Thus TLS has session cache and resumption. Will that work with TSM? I do not > know - and as it has taken the last two years to come up with an agreed form of > words that allows just TSM to work with just sshTM, so I am not going > to try and work out the ramifications of TLSTM just yet:-( We may find we got > TSM wrong and that it needs changing. > > Or we may have another secure Transport Model that turns out to be insecure with > TSM and needs an xSM to make it secure. The proposed amendment seems to me > rather optimistic. > > Tom Petch From wjhns1@hardakers.net Sat May 9 06:49:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBEB3A6E40; Sat, 9 May 2009 06:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgbqtvb5bBNf; Sat, 9 May 2009 06:49:20 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id A210C3A6813; Sat, 9 May 2009 06:49:20 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 19B9139A104; Sat, 9 May 2009 06:50:49 -0700 (PDT) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> <20090508214346.GB28541@elstar.local> Date: Sat, 09 May 2009 06:50:49 -0700 In-Reply-To: <20090508214346.GB28541@elstar.local> (Juergen Schoenwaelder's message of "Fri, 8 May 2009 23:43:46 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 11 May 2009 00:03:35 -0700 Cc: Barry Leiba , "isms@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 13:49:21 -0000 >>>>> On Fri, 8 May 2009 23:43:46 +0200, Juergen Schoenwaelder said: >> The idea of Models in SNMP is to be able to mix and match. In >> practice, this has not worked - USM with sshTM will not function, >> regardless of whether it is secure or not. JS> Not sure I understand why. Can you explain? The way it's worded right now in the SSH document is that there must be a tmStateReference for outgoing messages or the SSHTM will drop the message: 1. If tmStateReference does not refer to a cache containing values for tmTransportDomain, tmTransportAddress, tmSecurityName, tmRequestedSecurityLevel, and tmSameSecurity, then increment the sshtmSessionInvalidCaches counter, discard the message and return the error indication in the statusInformation. Processing of this message stops. USM won't generate a tmStateReference so it can't be used as an upper-level security protocol. This was discussed (I'm fairly certain) on the list at some point and it was decided this was ok as doing something to try and recover at that point would really be adding words and complexity for a situation that didn't really need to be supported. [that being said, note that there isn't a MUST drop it in the text] -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Sat May 9 15:18:48 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A213A6887; Sat, 9 May 2009 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufMJKKgYOMoo; Sat, 9 May 2009 15:18:48 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 3DF4E3A67F7; Sat, 9 May 2009 15:18:48 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 6A22539A0EB; Sat, 9 May 2009 15:20:16 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> <20090508214346.GB28541@elstar.local> <098001c9d0c3$a119ea00$0600a8c0@china.huawei.com> Date: Sat, 09 May 2009 15:20:16 -0700 In-Reply-To: <098001c9d0c3$a119ea00$0600a8c0@china.huawei.com> (David Harrington's message of "Sat, 9 May 2009 12:31:38 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 11 May 2009 00:03:35 -0700 Cc: "'tom.petch'" , 'Barry Leiba' , isms@ietf.org, secdir@ietf.org, 'Wes Hardaker' Subject: Re: [secdir] secdir reviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 22:18:49 -0000 >>>>> On Sat, 9 May 2009 12:31:38 -0400, "David Harrington" said: DH> Wes, are you suggestiong we should rwwrite all the elements of DH> procedure to use MUST every place where there is a definite step to be DH> followed? Would this be clearer? David, stop leaping. -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Mon May 11 10:57:09 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954D53A6899; Mon, 11 May 2009 10:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_50=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hEVay6OuSzI; Mon, 11 May 2009 10:57:08 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7193A67E5; Mon, 11 May 2009 10:57:07 -0700 (PDT) X-Trace: 158041757/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.14/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.14 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQEAMsDCEo+vBEO/2dsb2JhbACDKEyKYbBFCY1mAQaCRoE1BQ X-IronPort-AV: E=Sophos;i="4.40,329,1238972400"; d="scan'208";a="158041757" X-IP-Direction: IN Received: from 1cust14.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.14]) by smtp.pipex.tiscali.co.uk with SMTP; 11 May 2009 18:58:35 +0100 Message-ID: <005301c9d259$a5aefa00$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com> <007f01c9cffe$0aa68da0$0601a8c0@allison> <20090508214346.GB28541@elstar.local> Date: Mon, 11 May 2009 18:49:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Barry Leiba , isms@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Isms] secdirreviewofdraft-ietf-isms-transport-security-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 17:57:09 -0000 Juergen Apologies for the delayed response. Happily, I think that Wes's post last Saturday covered it very well. The text as it stands tells me that with sshTM but without TSM, conformance to the three I-Ds will cause outbound messages to be discarded (although inbound can be received - a potential attack surface?) But again as Wes says, this topic has occurred on the list, more than once I seem to recall. I believe it was Bert who first commented - sadly - that it did not seem possible to use sshTM with eg CSM. But that is what we have come up with. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Barry Leiba" ; ; Sent: Friday, May 08, 2009 11:43 PM Subject: Re: [Isms] [secdir] secdirreviewofdraft-ietf-isms-transport-security-model-12 > On Fri, May 08, 2009 at 06:56:27PM +0200, tom.petch wrote: > > > The idea of Models in SNMP is to be able to mix and match. In > > practice, this has not worked - USM with sshTM will not function, > > regardless of whether it is secure or not. > > Not sure I understand why. Can you explain? > > > Thus TLS has session cache and resumption. Will that work with TSM? > > Yes, this will just work fine since it is transparent. You can add > session resumption to SSH and it will work just fine with sshtm. > > Of course, sometimes we design for extensibility and when we need it, > we realize the shortcomings of the design. But there are also things > that just work fine - you are painting a picture here with black > colors. Even though it is difficult to get exensibility right, I think > not trying to be extensible is not an alternative. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From magnus.westerlund@ericsson.com Wed May 13 05:16:10 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49353A6C16 for ; Wed, 13 May 2009 05:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01w-qzAkUD0P for ; Wed, 13 May 2009 05:16:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5E6C83A6F8D for ; Wed, 13 May 2009 05:15:47 -0700 (PDT) X-AuditID: c1b4fb3c-b7b2bae000003e37-e4-4a0aba43c7e1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8A.D9.15927.34ABA0A4; Wed, 13 May 2009 14:17:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 May 2009 14:17:02 +0200 Received: from [153.88.50.61] ([153.88.50.61]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 May 2009 14:17:02 +0200 Message-ID: <4A0ABA3D.6090803@ericsson.com> Date: Wed, 13 May 2009 14:17:01 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Harrington References: <05a401c9ccf6$67ac3550$0600a8c0@china.huawei.com> In-Reply-To: <05a401c9ccf6$67ac3550$0600a8c0@china.huawei.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 May 2009 12:17:02.0035 (UTC) FILETIME=[B8914A30:01C9D3C4] X-Brightmail-Tracker: AAAAAA== Cc: secdir@ietf.org, tim.polk@nist.gov, Pasi.Eronen@nokia.com, adamson@itd.nrl.navy.mil, M.Handley@cs.ucl.ac.uk, cabo@tzi.org, 'Joe Macker' , 'Lorenzo Vicisano' Subject: Re: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 12:16:10 -0000 Hi David, Thanks for your review. I forwarded your message to the WG. We have other documents with similar security considerations that needs to be clarified. I am taking your feedback serious and tries the WG to provide feedback on your comments. I think there will be a benefit in clarifying the implementation requirements for these solutions. Cheers Magnus David Harrington skrev: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > The document specifies a protocol (or an update to a protocol) that > provides end-to-end reliable transport of bulk data objects or streams > > over multicast routing and forwarding services. It also provides a > congestion control scheme. It is designed to permit different > upper layer services to utilize its services in different ways. > > I previousaly reviewed the -09- revision, where I asked that the > specification tighen up requirements, ala RFC2119, especially in the > Security Considerations. That was done to a degree. > > More should be done. There are places with text like "It is expected > that ..." > that might be better expressed as SHOULDs. There are lower case > must/should/may/require uses. > > Since this is a requested early review, let me also comment on > document clarity. > > I found some of the paragraphs have conditionals in them, often > following a > statement of MUST or SHOULD compliance. I think the "However ..." > conditionals > really hurt the clarity of the specification. For example: > Large NORM group sizes will necessitate some form of key management > that does rely upon shared secrets. The GDOI and GSAKMP protocols > mentioned here allow for certificate-based authentication. It is > RECOMMENDED these certificates use IP addresses for authentication > although it may alternatively possible to have authentication > associated with pre-assigned NormNodeId values. However, it is > likely that available group key management implementations will not > be NORM-specific. > > Is the information after "RECOMMENDED these certificates use IP > addresses for authentication" really needed here? > If I alternately have authentication associated with re-assigned > NormNodeId values, and do not support IP adresses for authentication, > am I still compliant? > > A pet peeve - "it should be noted that" is almost always not needed. > Just make the statement, > which effectively notes the point. Nothing "should" about it! > > The same pet peeve variations: unnecessary introductory phrases or > clauses in sentences: > > s/The principal issue is that configuration > and operation of IPsec typically requires privileged user > authorization./Configuration > and operation of IPsec typically requires privileged user > authorization./ > s/It is expected that additional specifications may/ > Additional specifications MAY/ > > Some words to look at whether they are really necessary: > Additionally > However > Thus > It is expected that > As previously noted, > Note that > also > as always > as mentioned in section x.x > as noted > > > > > > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From weiler@watson.org Wed May 13 12:45:00 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FE528C21F for ; Wed, 13 May 2009 12:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4cImdqAFqNu for ; Wed, 13 May 2009 12:44:59 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 74EE428C21E for ; Wed, 13 May 2009 12:44:59 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n4DJkUbO081637 for ; Wed, 13 May 2009 15:46:30 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n4DJkUC8081634 for ; Wed, 13 May 2009 15:46:30 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 13 May 2009 15:46:30 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Wed, 13 May 2009 20:46:30 +0100 (BST) Subject: [secdir] Assignments for May 19th X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 19:45:00 -0000 I'm on holiday,a dnt he list rbelow generally does NOT reflect reviews received in the last week or so. If you're reviewed the doc recently, there's no need to send me a message -- I'll get it recorded when I get back. Phillip Hallam-Baker is next in the rotation. -- Sam For telechat 2009-05-21 Reviewer Draft Stephen Farrell T draft-ietf-netlmm-pmip6-ipv4-support-12 Catherine Meadows TR draft-groves-megaco-pkgereg-03 Chris Newman TR draft-ietf-dccp-simul-open-08 Nico Williams T draft-ietf-dkim-overview-11 Last calls and special requests: Reviewer Draft Derek Atkins draft-ietf-roll-building-routing-reqs-05 Derek Atkins draft-ietf-mpls-tp-gach-gal-04 Rob Austein draft-ietf-sip-ua-privacy-07 Richard Barnes draft-ietf-sipping-update-pai-09 Pat Cain R draft-crocker-email-arch-12 Pat Cain draft-levine-rfb-01 Ran Canetti draft-ietf-avt-seed-srtp-11 Ran Canetti draft-eronen-enterprise-number-documentation-01 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Dave Cridland draft-housley-aes-key-wrap-with-pad-02 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Alan DeKok draft-ietf-dnsext-dnsproxy-05 Donald Eastlake draft-ietf-ippm-more-twamp-01 Shawn Emery draft-ietf-kitten-gssapi-store-cred-04 Tobias Gondrom draft-sinnreich-sip-tools-06 Steve Hanna draft-peterson-rai-rfc3427bis-01 David Harrington R draft-ietf-rmt-pi-norm-revised-11 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-18 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Alexey Melnikov R draft-ietf-sip-outbound-17 Vidya Narayanan draft-ietf-sip-saml-06 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig draft-ietf-pce-monitoring-04 Carl Wallace draft-ietf-ltru-4646bis-21 Sam Weiler draft-chown-v6ops-rogue-ra-03 Brian Weis draft-ietf-pce-p2mp-app-01 Nico Williams draft-ietf-v6ops-ra-guard-02 Tom Yu draft-ietf-dkim-rfc4871-errata-04 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 Glen Zorn draft-ietf-geopriv-sip-lo-retransmission-02 From secdir-bounces@mit.edu Wed May 13 21:48:27 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC983A6C9C for ; Wed, 13 May 2009 21:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.588 X-Spam-Level: X-Spam-Status: No, score=-4.588 tagged_above=-999 required=5 tests=[AWL=2.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-mnwHDqshsP for ; Wed, 13 May 2009 21:48:26 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 67A2228C0DC for ; Wed, 13 May 2009 21:48:26 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n4E4nwDm019117 for ; Thu, 14 May 2009 00:49:58 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n4E4ntbC019111 for ; Thu, 14 May 2009 00:49:55 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n4E4nm5j016241 for ; Thu, 14 May 2009 00:49:48 -0400 (EDT) Received: from mx3.bbn.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id A12E81B9B349 for ; Thu, 14 May 2009 00:49:47 -0400 (EDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by mit.edu with ESMTP id WS2eDFeN8b1hBJKM (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 14 May 2009 00:49:46 -0400 (EDT) X-Barracuda-Envelope-From: rbarnes@bbn.com Received-SPF: pass (mit.edu: domain of rbarnes@bbn.com designates 128.33.1.81 as permitted sender) receiver=mit.edu; client_ip=128.33.1.81; envelope-from=rbarnes@bbn.com; Received: from [128.89.255.185] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M4St4-0006w2-Cc; Thu, 14 May 2009 00:49:45 -0400 Message-ID: <4A0BA2D7.1030900@bbn.com> Date: Thu, 14 May 2009 00:49:27 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: IESG , SECDIR , IETF Discussion , draft-ietf-sipping-update-pai@tools.ietf.org X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] SECDIR review of draft-ietf-sipping-update-pai-09 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 04:48:27 -0000 Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document extends the applicability of the SIP P-Asserted-ID header (PAID in brief) to include origination by other SIP entities and use in other SIP methods than were specified in RFC 3325. It also provides recommendations for processing of P-Asserted-ID to require recipients to be more generous in what they receive as syntactically valid. (I'm actually not clear on why this document is really necessary, since as I read it, RFC 3325 doesn't actually forbid the use of PAID in the cases addressed by this document except informally in the table rows in Sections 9.1 and 9.2. But if the WG feels this document provides important clarifications, I don't see this redundancy as a problem.) The document does not raise significant security issues, largely because it is specified to be used only within a Trust Domain (as specified in RFC 3324), which provides many assumptions about the security of the underlying environment in which this header is used. The document clearly states this requirement (use within a Trust Domain), so there is little risk that the document will be understood to be applicable in the general Internet. Several comments related to some ambiguities and inconsistencies in the document follow. --Richard ----- General: The problems that this document raises with authentication seem kind of irrelevant, in that requirements for authentication are subject to any given domain's Spec(T). For example, Spec(T) may say that it's sufficient a UAC or UAS can send PAID if they've joined the trust domain by establishing an authenticated TLS connection to their next-hop proxy. The document seems to neglect entirely the possibility that the UAS is part of the trust domain (which might be facilitated, e.g., by sip-outbound), in which case it seems sensible to allow PAID in responses. In any case, the first reverse hop can delete PAID from the response if it doesn't regard the UAS as trusted, e.g., if the UAS hasn't previously authenticated (this is the analogue of the comment paragraph in Section 4.2). So I don't really see a need to exclude PAID from ACK and CANCEL request and from responses based on them not being challenge-able. Suggest changing the relevant paragraphs in the Introduction and Security Considerations to say something like "If the authentication provisions in your Spec(T) rely on Digest authentication, then you should forbid PAID in ACK, CANCEL, and responses". ----- General: This seems to be all about PAID. Don't some of the considerations also apply to PPID? PPID is already specified to be inserted by the UAC, but it seems like the addition of other request methods and considerations about multiple URIs and other schemes could be useful. ----- In Section 4.3: "... the registrar MAY use this as evidence that the registering UA has been authenticated ..." This statement seems kind of weird in the case where the 'node' is the UAC. First, there's an unstated assumption that there's a requirement in Spec(T) that UACs authenticate before becoming part of the domain, or otherwise before using PAID. Second, assuming that's the case, the logic here seems either circular or incomplete, depending on who the UAC authenticated to. If the UAC authenticated to the registrar, then there's no need for further proof. If the UAC authenticated to someone else, then the registrar has no idea whether the node is in the trust domain or not, so it has to disregard the PAID -- that is, the registrar needs some other channel to determine whether the UAC is within the trust domain. Suggest adding a clarification here: "However, if the node transmitting a P-Asserted-ID header to a registrar is the registering UAC itself, the registrar MUST NOT regard the P-Asserted-ID itself as evidence that the UAC has authenticated (some other authentication technique must be used, such as SIP Identity or Digest Authentication)." As an aside, the phrase "the registering UA ... represents the identity asserted" seems awkward. Suggest s/represents/is represented by/ ----- In Section 4.5: This section uses the word[s] "[un]expected" a lot without defining what they mean. Is this about adherence to RFC 3325? Implementation design decisions? Part of Spec(T)? All of the "unless Spec(T)" caveats here imply that implementations SHOULD allow all of these things, if it's possible that they could be specified by some users' Spec(T). ----- Section 6: "When receiving a response from a node outside the Trust Domain, a proxy has no standardised SIP means to authenticate the node." This paragraph seems unnecessary. It seems like the message should be "When receiving any message from a node outside the Trust Domain, a proxy MUST remove any P-Asserted-ID information from the message". (Isn't this the definition of "within a trust domain"?) Perhaps this language should be added to section 4.2, but this all seems covered under the Proxy rules in Section 5 of RFC 3325. See also general comment about authentication and responses. ----- Section 6: "When receiving a REGISTER request containing a P-Asserted-Identity header field ..." What's the point of this paragraph? This is again a restatement of "within a trust domain". Either delete or make it a MUST and put it in section 4.3. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From derek@ihtfp.com Wed May 20 13:45:40 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47853A6ED1; Wed, 20 May 2009 13:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lsz3KotTsVHU; Wed, 20 May 2009 13:45:40 -0700 (PDT) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id DE07C3A6ABE; Wed, 20 May 2009 13:45:39 -0700 (PDT) Received: from pgpdev.ihtfp.org (unknown [64.1.215.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 374E0BD858B; Wed, 20 May 2009 16:47:16 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n4KKlAFr016598; Wed, 20 May 2009 16:47:10 -0400 To: iesg@ietf.org, secdir@ietf.org From: Derek Atkins Date: Wed, 20 May 2009 16:47:09 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pieter.demil@intec.ugent.be, nicolas.riou@fr.schneider-electric.com, jerald.p.martocci@jci.com, wouter@vooruit.be, roll-chairs@tools.ietf.org Subject: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:45:40 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The Routing Over Low power and Lossy network (ROLL) Working Group has been chartered to work on routing solutions for Low Power and Lossy networks (LLN) in various markets: Industrial, Commercial (Building), Home and Urban. Pursuant to this effort, this document defines the routing requirements for building automation. The Security Considerations appear to take into account various requirements for different systems. What seems to be lacking is direction about how or when to apply various requirements and what it means to the deployment. For example, what would it mean to a deployment if it has authentication versus not having authentication? Also, it's unclear how these requirements would apply to an implementor. Variable security policies is a good idea, but it requires more guidance because the end user will never understand the ramifications of choosing one policy over another. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From derek@ihtfp.com Wed May 20 13:46:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F02C3A6EF8; Wed, 20 May 2009 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVsn4X-A3TKU; Wed, 20 May 2009 13:46:20 -0700 (PDT) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id A728F3A6FBF; Wed, 20 May 2009 13:46:00 -0700 (PDT) Received: from pgpdev.ihtfp.org (unknown [64.1.215.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id E980ABD85A2; Wed, 20 May 2009 16:47:37 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n4KKlZug016606; Wed, 20 May 2009 16:47:35 -0400 To: iesg@ietf.org, secdir@ietf.org From: Derek Atkins Date: Wed, 20 May 2009 16:47:35 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: swallow@cisco.com, matthew.bocci@alcatel-lucent.com, rahul@juniper.net, dward@cisco.com, mpls-chairs@tools.ietf.org, martin.vigoureux@alcatel-lucent.com, stbryant@cisco.com Subject: [secdir] sec-dir review of draft-ietf-mpls-tp-gach-gal-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:46:21 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism. This document refers to RFC 4385 and 5085 for security consideration dependencies. I believe this document adds no new security issues. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From Adrian.Farrel@huawei.com Wed May 20 14:23:48 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C513A6ABE; Wed, 20 May 2009 14:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gzk+kNS6Uo91; Wed, 20 May 2009 14:23:47 -0700 (PDT) Received: from lhrga03-in.huawei.com (lhrga03-in.huawei.com [195.33.106.148]) by core3.amsl.com (Postfix) with ESMTP id 64EDB3A67E1; Wed, 20 May 2009 14:23:47 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJY00LN0OUBP9@lhrga03-in.huawei.com>; Wed, 20 May 2009 22:25:24 +0100 (BST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJY0057POU97D@lhrga03-in.huawei.com>; Wed, 20 May 2009 22:25:23 +0100 (BST) Date: Wed, 20 May 2009 22:17:02 +0100 From: Adrian Farrel To: Derek Atkins , iesg@ietf.org, secdir@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: nicolas.riou@fr.schneider-electric.com, jerald.p.martocci@jci.com, pieter.demil@intec.ugent.be, wouter@vooruit.be, roll-chairs@tools.ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 21:23:48 -0000 Derek, I appreciate the review and hope that it will be useful to the authors. Since a new revision is expected, maybe the authors will be able to work with this. Cheers, Adrian ----- Original Message ----- From: "Derek Atkins" To: ; Cc: ; ; ; ; Sent: Wednesday, May 20, 2009 9:47 PM Subject: sec-dir review of draft-ietf-roll-building-routing-reqs-05.txt >I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The Routing Over Low power and Lossy network (ROLL) Working Group has > been chartered to work on routing solutions for Low Power and Lossy > networks (LLN) in various markets: Industrial, Commercial (Building), > Home and Urban. Pursuant to this effort, this document defines the > routing requirements for building automation. > > The Security Considerations appear to take into account various > requirements for different systems. What seems to be lacking is > direction about how or when to apply various requirements and what > it means to the deployment. > > For example, what would it mean to a deployment if it has > authentication versus not having authentication? Also, it's unclear > how these requirements would apply to an implementor. > > Variable security policies is a good idea, but it requires more > guidance because the end user will never understand the ramifications > of choosing one policy over another. > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From ananth@cisco.com Mon May 25 01:05:16 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA8B3A6C48; Mon, 25 May 2009 01:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtLaCagSd9yr; Mon, 25 May 2009 01:05:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5352B3A6B38; Mon, 25 May 2009 01:05:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,243,1241395200"; d="scan'208";a="189801679" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 May 2009 08:06:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4P86pvq024524; Mon, 25 May 2009 01:06:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4P86pUq005319; Mon, 25 May 2009 08:06:51 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 May 2009 01:06:49 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 May 2009 01:06:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <0C53DCFB700D144284A584F54711EC58074EEED8@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <069366F0-685B-443F-8A1C-6EF4E45E8E21@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-tcpm-tcpsecure-11.txt thread-index: AcnO5Cc/nY/KsjrLQp+Si/eIk5nLWQOKpWTw References: <13D1EAB852BE194C94773A947138483D0749EF90@xmb-sjc-21c.amer.cisco.com> <069366F0-685B-443F-8A1C-6EF4E45E8E21@nokia.com> From: "Anantha Ramaiah (ananth)" To: "Lars Eggert" , "Sandra Murphy" X-OriginalArrivalTime: 25 May 2009 08:06:49.0635 (UTC) FILETIME=[C16FD730:01C9DD0F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10052; t=1243238811; x=1244102811; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20review=20of=20draft-ietf-tcpm-tcpsecure -11.txt |Sender:=20; bh=vrdAeKiP9MXigkDz0f/PHEMv5a+Cwbul4ctjaosO/98=; b=L0JPI0mtGT1d1kbpzHEcQpWw5lceEpKmV3PQg16FgBqhYONlztrS4uaNsE TLt/tgFSqv7q7K+dqUSQOAAdeWRaVEt10olgrLYAKQdPMizSnryTnyFJqk7+ 0bdoQ3VhAO; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Mon, 25 May 2009 01:20:19 -0700 Cc: tcpm-chairs@tools.ietf.org, "Mitesh Dalal \(mdalal\)" , draft-ietf-tcpm-tcpsecure@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] review of draft-ietf-tcpm-tcpsecure-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 08:05:17 -0000 I think there is a differentiation between what the draft actually does versus what we want to indicate. The draft DOES update RFC 793, but whether we want to put that upfront or not is left to the collective wisdom of IETF. Sandra's comments are valid and need to be taken care of whether or not we put the keyword "updates " in front of the RFC (draft) Thanks, -Anantha > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Thursday, May 07, 2009 12:19 AM > To: Sandra Murphy > Cc: Mitesh Dalal (mdalal); tcpm-chairs@tools.ietf.org;=20 > draft-ietf-tcpm-tcpsecure@tools.ietf.org; Anantha Ramaiah=20 > (ananth); iesg@ietf.org; secdir@ietf.org > Subject: Re: review of draft-ietf-tcpm-tcpsecure-11.txt >=20 > Hi, >=20 > note that it is not at all clear whether this document will=20 > end up indicating that it is updating 793. In the document=20 > writeup (in the > tracker) the chairs describe the discussion the WG had around=20 > this issue and are asking for the IESG to discuss what is=20 > appropriate here. >=20 > Lars >=20 > On 2009-5-6, at 21:32, Sandra Murphy wrote: >=20 > > On Tue, 28 Apr 2009 11:31:01 -0700, Mitesh Dalal wrote: > > > > Comments below in-line. > > > >> Hi Sandra, > >> > >> Thank you for taking time to review the draft. Please see inline. > >> > >> > >> ---------- Forwarded message ---------- > >> Date: Thu, 23 Apr 2009 14:19:11 -0400 (Eastern Daylight Time) > >> From: Sandra Murphy > >> To: iesg@ietf.org, secdir@ietf.org, > >> draft-ietf-tcpm-tcpsecure@tools.ietf.org, > >> tcpm-chairs@tools.ietf.org > > > >> > > > > > >> This document is intended to update rfc793. That means that it=20 > >> should be very explicit about what text it is replacing=20 > and what the=20 > >> new text is. > >> > >> Mitesh: The mitigation section of the discussed attack=20 > does highlight=20 > >> the processing "rules" that are being modified. If you=20 > have explicit=20 > >> suggestions to make it better, we welcome it. > > > > Essentially, I'm thinking that you need to indicate > > > > OLD: > > > > 793 text > > 793 text > > 793 text > > > > NEW: > > > > draft text > > draft text > > draft text > > > > Your mitigation techniques summarize the various pieces of 793 text=20 > > scattered over the fsm description. Figuring out which=20 > pieces of the=20 > > fsm text are the ones summarized and which should be=20 > changed could be=20 > > ambiguous in interpretation. As the typical tcp code tries hard to=20 > > follow the fsm description, being precise about the changes=20 > would be=20 > > good. And very tedious, I'm sure. > > > >> > >> > >> The dicussions of interactions between TCP peers are=20 > always difficult=20 > >> to phrase, as most terms are relative to viewpoint. The=20 > text in some=20 > >> places is tough to read - who is the sender, who the=20 > receiver, etc. =20 > >> The text also uses a lot of different terms to represent the same=20 > >> entity - remote peer, remote end sender, remote TCP endpoint, etc. > >> > >> Mitesh: We may consider simplifying these terms to remote peer if=20 > >> that helps. Point noted. > > > > OK. Note that I recognize the difficulty of choosing an=20 > apporpriate=20 > > term from among the common ones, which are relative to the point of=20 > > view. > > > > > >> The term "initial sequence number" has a special meaning=20 > in TCP and=20 > >> should be avoided. > >> > >> Mitesh: Can you please elaborate the context? > > > > Context in your draft: > > > > 2) A sequence number that will be used in the RST. This sequence > > number will be a starting point for a series of guesses to=20 > > attempt > > to present a RST segment to a connection endpoint=20 > that would be > > acceptable to it. Any random value may be used to guess the > > initial sequence number. > > ^^^^^^^^^^^^^^^^^^^^^^^ > > > > Context in RFC793: > > > > [Lots of places in 793 refer to initial sequence number=20 > or to ISN. > > And, of course, lots of literature.] > > > > I think the draft means "the first guess", "the starting=20 > point", not=20 > > the TCP "initial sequence number". > > > >> > >> The text says that this mitigation SHOULD be used "in=20 > devices" which > >> typically host apps that are most vulnerable and MIGHT be used > >> elsewhere. Is there a suggestion that this would be under=20 > application > >> control? Chosen by the OS vendor (or device vendor)? For=20 > those who =20 > >> are > >> using Quagga routers (routing apps on top of intel boxes=20 > running some > >> *ix), would this be a socket option? > >> What's the vision here? > >> > >> Mitesh: This implementation detail is outside the scope of the =20 > >> document. > >> Although, implementors may > >> make it a compile time option, application dependent=20 > control (as you > >> hint with socket option) or may > >> make it mandatory for the stack. > > > > The draft discusses issues of interoperability between a TCP stack > > that implements the new algorithm and one that does not. But I'm > > wondering about issues of interoperabality between=20 > applications and =20 > > TCP > > stacks. An vulnerable app that wants the new algorithm on=20 > an OS that > > has decided to leave the decision in the TCP stack, etc. > > > > For those systems where TCP stack and application are integrally > > implemented, i.e., "devices" like routers running BGP, the =20 > > interoperability > > will be taken care of. But there are cases where an app that is =20 > > vulnerable > > is running on a platform where the OS is a general purpose OS. In =20 > > that > > case, you aren't considering just one integrally=20 > implemented "device". > > > > I'm just having trouble deciding what this all means in light of the > > recommendation of section 1.1: > > > > SHOULD be implemented in devices that regularly need to=20 > maintain =20 > > TCP > > connections of the kind most vulnerable to the attacks=20 > described in > > this document. Examples of such TCP connections are the=20 > ones that > > tend to be long-lived and where the connection end points can be > > determined, in cases where no auxiliary anti-spoofing protection > > mechanisms like TCP MD5 [RFC2385] can be deployed. These =20 > > mitigations > > MAY be implemented in other cases. > > > > I'm having difficulty figuring out how this will work. Maybe this > > is just the age-old inter-layer feature negotiation problem, and =20 > > people > > will deal. > > > >> > >> I don't understand some parts of > >> > >> All TCP stacks MAY implement the following mitigation. =20 > TCP stacks > >> which implement this mitigation MUST add an additional=20 > input check > >> to > >> any incoming segment. The ACK value is considered=20 > acceptable only > >> if > >> it is in the range of ((SND.UNA - MAX.SND.WND) <=3D SEG.ACK <=3D > >> SND.NXT). All incoming segments whose ACK value doesn't=20 > satisfy =20 > >> the > >> above condition MUST be discarded and an ACK sent back. =20 > It needs =20 > >> to > >> be noted that RFC 793 on page 72 (fifth check) says: "If=20 > the ACK is > >> a > >> duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK > >> acknowledges something not yet sent (SEG.ACK > SND.NXT)=20 > then send =20 > >> an > >> ACK, drop the segment, and return." This mitigation=20 > makes the ACK > >> check more stringent since any ACK < SND.UNA wouldn't be=20 > accepted, > >> instead only ACKs which are in the range ((SND.UNA -=20 > MAX.SND.WND) =20 > >> <=3D > >> SEG.ACK <=3D SND.NXT) gets through. > >> > >> Seems that SEG.ACK could fall between the SND.UNA and SND.UNA - > >> MAX.SND.WND, in which case the new code accepts segments that the > >> existing text says "it is ignored". I would read the 793=20 > text as the > >> *ACK* is ignored, which means the new text would accept=20 > (and act on) > >> ACKs that are presently ignored. But looking at existing=20 > TCP code, =20 > >> it > >> looks like people have interpreted "it is ignored" as the=20 > *segment* =20 > >> is > >> ignored, i.e., dropped. In that case, this new text is accepting > >> segments that in existing implementations would be dropped. > >> Is that the intent? (Note: I could be easily wrong about the =20 > >> tcp_input > >> code.) > >> > >> Mitesh: I will have to dig and find out, my recollection is hazy =20 > >> but I > >> think this was raised earlier > >> and may have been discussed. > > > > Note that I have mixed two comments here. The first=20 > comment is about > > the algebra: > > > > if MAX.SND.WND > 0, then SND.UNA-MAX.SND.WND < SND.UNA, so if > > SEG.ACK < SND.UNA,it is possible that (SND.UNA - MAX.SND.WND) <=3D =20 > > SEG.ACK > > and SEG.ACK < SND.UNA. So the statement > > since any ACK < SND.UNA wouldn't be accepted > > disagrees with > > ACKs which are in the range ((SND.UNA - =20 > > MAX.SND.WND) <=3D > > SEG.ACK <=3D SND.NXT) gets through. > > for the SEG.ACK range SND.UNA - MAX.SND.WND <=3D SEG.ACK < SND.UNA > > > > The second comment was about the difference in behavior between =20 > > existing > > implementations and the new recommended algorithm. I'm interested =20 > > in what > > turns up about that. > > > > > >> > >> > >> There are some language errors (missed words, punctuation,=20 > all that =20 > >> sort > >> of boring stuff) that I could point out, or you could rely=20 > on the RFC > >> editor to find. > >> > >> Mitesh: Do send us stuff annotated and we can "refine" the=20 > document =20 > >> as > >> we move to the finish line. > > > > Working on that. > > > >> Thanks for your time and input! > >> Mitesh > > >=20 >=20 From weiler+secdir@watson.org Mon May 25 09:53:11 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52EC23A6A68 for ; Mon, 25 May 2009 09:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tseYMhZxFPv2 for ; Mon, 25 May 2009 09:53:10 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 6BDF13A6917 for ; Mon, 25 May 2009 09:53:10 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n4PGsoj9006506 for ; Mon, 25 May 2009 12:54:50 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n4PGsob3006503 for ; Mon, 25 May 2009 12:54:50 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 25 May 2009 12:54:50 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 25 May 2009 17:54:50 +0100 (BST) Subject: [secdir] assignments for June 1st X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 16:53:11 -0000 Many new assignments this week. Vidya Narayanan is next in the rotation. Following my holiday, the below list should reflect all reviews received to date. If something seems amiss, please let me know. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-06-04 Reviewer Draft Rob Austein T draft-ietf-sip-ua-privacy-08 Ran Canetti T draft-ietf-avt-seed-srtp-11 Donald Eastlake T draft-ietf-ippm-more-twamp-02 Stephen Farrell T draft-ietf-netlmm-pmip6-ipv4-support-12 Stephen Kent TR draft-ietf-mmusic-sdp-capability-negotiation-10 Glen Zorn T draft-ietf-geopriv-sip-lo-retransmission-02 Last calls and special requests: Pat Cain R draft-crocker-email-arch-13 Ran Canetti draft-eronen-enterprise-number-documentation-01 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Dave Cridland draft-housley-aes-key-wrap-with-pad-02 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Alan DeKok draft-ietf-dnsext-dnsproxy-05 Shawn Emery draft-ietf-avt-app-rtp-keepalive-05 Tobias Gondrom draft-sinnreich-sip-tools-06 Phillip Hallam-Baker draft-ietf-kitten-gssapi-store-cred-04 Steve Hanna draft-peterson-rai-rfc3427bis-01 Steve Hanna draft-ietf-avt-rtcpssm-18 Dan Harkins draft-ietf-avt-rtp-mps-02 David Harrington draft-dusseault-impl-reports-02 Sam Hartman draft-ietf-opsawg-operations-and-management-07 Paul Hoffman draft-ietf-sip-eku-05 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Love Hornquist-Astrand draft-ietf-smime-3278bis-07 Jeffrey Hutzelman draft-ietf-kitten-extended-mech-inquiry-06 Charlie Kaufman draft-ietf-kitten-rfc2853bis-05 Scott Kelly draft-livingood-woundy-p4p-experiences-07 Stephen Kent draft-ietf-geopriv-l7-lcp-ps-09 Sandy Murphy draft-hollenbeck-rfc4933bis-01 Tero Kivinen draft-ietf-webdav-bind-23 Julien Laganier draft-ietf-sip-certs-07 Julien Laganier draft-hollenbeck-rfc4934bis-01 Barry Leiba draft-hollenbeck-rfc4931bis-01 Chris Lonvick draft-hollenbeck-rfc4932bis-01 Catherine Meadows draft-ietf-speechsc-mrcpv2-18 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Catherine Meadows draft-hollenbeck-rfc4930bis-01 Alexey Melnikov R draft-ietf-sip-outbound-17 Vidya Narayanan draft-ietf-sip-saml-06 Eric Rescorla R draft-ietf-geopriv-http-location-delivery-14 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig draft-ietf-pce-monitoring-04 Carl Wallace draft-ietf-ltru-4646bis-22 Sam Weiler draft-chown-v6ops-rogue-ra-03 Brian Weis draft-ietf-pce-p2mp-app-01 Nico Williams draft-ietf-v6ops-ra-guard-02 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 From kent@bbn.com Mon May 25 10:50:31 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21413A6964 for ; Mon, 25 May 2009 10:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.194, 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 DrYN1YNqye4c for ; Mon, 25 May 2009 10:50:30 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A7F2B3A67B6 for ; Mon, 25 May 2009 10:50:30 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[168.77.196.182]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M8eLK-00028g-FW; Mon, 25 May 2009 13:52:11 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 25 May 2009 13:52:08 -0400 To: secdir@core3.amsl.com From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-968848566==_ma============" Cc: fluffy@cisco.com, tim.polk@nist.gov, fandreas@cisco.com Subject: [secdir] review of draft-ietf-mmusic-sdp-capability-negotiation-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 17:50:31 -0000 --============_-968848566==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I have reviewed this I-D 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 performed this re-review by examining a diff between versions 9 and 10 of the I-D, and by reviewing my comments on version 9. I thank the author for having made a number of changes based on my review comments. He paid closer attention to where the word "only" is placed in sentences. I note that some newly added text repeats the previous placement errors re this word :. He also fixed the IPsec misspelling. There are still a few typos in this version, but I expect the RC Editor will fix them. The author added text to include a DTLS-SRTP example, in addition to the MIKEY examples. (I'm not sure that its appropriate to retain the MIKEY examples at all here, but I defer to the RAI AD's judgment on this matter.) The author revised the discussion of RFC 4474 to indicate that it is still PKI-based, but that the required PKI is less extensive (and thus potentially more viable) than a PKI that must encompass all end users. He also corrected the discussion to note the residual MITM attack potential if TLS or IPsec are used for hop-by-hop protection. The author also revised the advice to implementors re DoS attacks, making the advice a "must" vs. "MUST." The reference to section 3.10 in the security considerations discussion of DoS is still wrong; the reference should be to 3.11. --============_-968848566==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-mmusic-sdp-capability-negotiation-10.
I have reviewed this I-D 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 performed this re-review by examining a diff between versions 9 and 10 of the I-D, and by reviewing my comments on version 9.

I thank the author for having made a number of changes based on my review comments. He paid closer attention to where the word "only" is placed in sentences. I note that some newly added text repeats the previous placement errors re this word :. He also fixed the IPsec misspelling. There are still a few typos in this version, but I expect the RC Editor will fix them.

The author added text to include a DTLS-SRTP example, in addition to the MIKEY examples. (I'm not sure that its appropriate to retain the MIKEY examples at all here, but I defer to the RAI AD's judgment on this matter.)

The author revised the discussion of RFC 4474 to indicate that it is still PKI-based, but that the required PKI is less extensive (and thus potentially more viable) than a PKI that must encompass all end users. He also corrected the discussion to note the residual MITM attack potential if TLS or IPsec are used for hop-by-hop protection.

The author also revised the advice to implementors re DoS attacks, making the advice a "must" vs. "MUST."

The reference to section 3.10 in the security considerations discussion of DoS is still wrong; the reference should be to 3.11.
--============_-968848566==_ma============-- From jhutz@cmu.edu Tue May 26 09:06:20 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AEC3A70F6 for ; Tue, 26 May 2009 09:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=-1.415, 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 GwTIg-pBIHfd for ; Tue, 26 May 2009 09:06:17 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id C1E253A6C7F for ; Tue, 26 May 2009 09:05:58 -0700 (PDT) Received: from [172.16.209.64] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4QG7cN4009522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 12:07:38 -0400 (EDT) Date: Tue, 26 May 2009 12:07:37 -0400 From: Jeffrey Hutzelman To: secdir-secretary@mit.edu, secdir@ietf.org Message-ID: <2261498C9C14B92B8FFE14B6@atlantis.pc.cs.cmu.edu> In-Reply-To: <200905251654.n4PGst2X028996@mx02.srv.cs.cmu.edu> References: <200905251654.n4PGst2X028996@mx02.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Subject: Re: [secdir] assignments for June 1st X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 16:06:21 -0000 --On Monday, May 25, 2009 12:54:50 PM -0400 Samuel Weiler wrote: > Jeffrey Hutzelman > draft-ietf-kitten-extended-mech-inquiry-06 Looks good to me, but it would be good to assign another reviewer, too. From adamson@itd.nrl.navy.mil Thu May 28 09:33:51 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052BD28C2F2 for ; Thu, 28 May 2009 09:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 8FU5f-xV2eai for ; Thu, 28 May 2009 09:33:50 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 6C33D28C2AC for ; Thu, 28 May 2009 09:32:30 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n4SGXaSr011293; Thu, 28 May 2009 12:33:36 -0400 Received: from macsimus.itd.nrl.navy.mil ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009052812333522300 ; Thu, 28 May 2009 12:33:35 -0400 Message-Id: <6939BED8-48A5-4B3D-B185-E882DE35CDC6@itd.nrl.navy.mil> From: Brian Adamson To: David Harrington In-Reply-To: <05a401c9ccf6$67ac3550$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 12:33:36 -0400 References: <05a401c9ccf6$67ac3550$0600a8c0@china.huawei.com> X-Mailer: Apple Mail (2.935.3) Cc: 'Magnus Westerlund' , secdir@ietf.org, tim.polk@nist.gov, Pasi.Eronen@nokia.com, M.Handley@cs.ucl.ac.uk, cabo@tzi.org, 'Joe Macker' , 'Lorenzo Vicisano' Subject: Re: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 16:33:51 -0000 All, I have submitted an updated NORM draft that I hope fully addresses Dave's comments here. I actually took his recommendations on clarity of requirements language (SHOULDs, etc) throughout the whole document and not just the security issues section. There were a number of cases where there were lower-case "should", "must", etc that needed to be emphasized with upper case or alternative language used to make the requirements aspects clearer. This was a worthwhile exercise as I found a few more grammatical errors, etc as well. Brian Adamson adamson@itd.nrl.navy.mil On May 4, 2009, at 4:25 PM, David Harrington wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > The document specifies a protocol (or an update to a protocol) that > provides end-to-end reliable transport of bulk data objects or streams > > over multicast routing and forwarding services. It also provides a > congestion control scheme. It is designed to permit different > upper layer services to utilize its services in different ways. > > I previousaly reviewed the -09- revision, where I asked that the > specification tighen up requirements, ala RFC2119, especially in the > Security Considerations. That was done to a degree. > > More should be done. There are places with text like "It is expected > that ..." > that might be better expressed as SHOULDs. There are lower case > must/should/may/require uses. > > Since this is a requested early review, let me also comment on > document clarity. > > I found some of the paragraphs have conditionals in them, often > following a > statement of MUST or SHOULD compliance. I think the "However ..." > conditionals > really hurt the clarity of the specification. For example: > Large NORM group sizes will necessitate some form of key management > that does rely upon shared secrets. The GDOI and GSAKMP protocols > mentioned here allow for certificate-based authentication. It is > RECOMMENDED these certificates use IP addresses for authentication > although it may alternatively possible to have authentication > associated with pre-assigned NormNodeId values. However, it is > likely that available group key management implementations will not > be NORM-specific. > > Is the information after "RECOMMENDED these certificates use IP > addresses for authentication" really needed here? > If I alternately have authentication associated with re-assigned > NormNodeId values, and do not support IP adresses for authentication, > am I still compliant? > > A pet peeve - "it should be noted that" is almost always not needed. > Just make the statement, > which effectively notes the point. Nothing "should" about it! > > The same pet peeve variations: unnecessary introductory phrases or > clauses in sentences: > > s/The principal issue is that configuration > and operation of IPsec typically requires privileged user > authorization./Configuration > and operation of IPsec typically requires privileged user > authorization./ > s/It is expected that additional specifications may/ > Additional specifications MAY/ > > Some words to look at whether they are really necessary: > Additionally > However > Thus > It is expected that > As previously noted, > Note that > also > as always > as mentioned in section x.x > as noted > > > > > > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > From cwallace@cygnacom.com Thu May 28 10:36:23 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D427E3A69FC; Thu, 28 May 2009 10:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.571, 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 WY6jMDIuqImV; Thu, 28 May 2009 10:36:22 -0700 (PDT) Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by core3.amsl.com (Postfix) with ESMTP id 42C9028C1A1; Thu, 28 May 2009 10:36:01 -0700 (PDT) Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 9ebce1a4.2169314224.53862.00-022.p03c11o142.symantecmail.net (envelope-from ); Thu, 28 May 2009 11:37:45 -0600 (MDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9DFBB.01CB7C68" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 28 May 2009 13:37:43 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ltru-4646bis-22 Thread-Index: AcnfuwGF1zGJ2r6lRBqKiYTv54zhcw== From: "Carl Wallace" To: "secdir" , , , X-Spam: [F=0.2000000000; S=0.200(2009052001)] X-MAIL-FROM: X-SOURCE-IP: [65.242.48.5] Subject: [secdir] draft-ietf-ltru-4646bis-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 17:36:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9DFBB.01CB7C68 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 I don't see any issues with this draft. One question, has any consideration been given to posting a detached signature covering the registry, similar to what RFC 5485 describes for I-Ds? =20 =20 ------_=_NextPart_001_01C9DFBB.01CB7C68 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.

 

I don’t see any issues with this = draft.  One question, has any consideration been given to posting a detached = signature covering the registry, similar to what RFC 5485 describes for = I-Ds?

 

 

------_=_NextPart_001_01C9DFBB.01CB7C68-- From weiler+ietf@watson.org Thu May 28 19:24:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB703A6B4F for ; Thu, 28 May 2009 19:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 wqIyq4eUhhSe for ; Thu, 28 May 2009 19:24:21 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 55B323A6933 for ; Thu, 28 May 2009 19:24:21 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n4T2PuON089913 for ; Thu, 28 May 2009 22:25:56 -0400 (EDT) (envelope-from weiler+ietf@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n4T2PujQ089909 for ; Thu, 28 May 2009 22:25:56 -0400 (EDT) (envelope-from weiler+ietf@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 28 May 2009 22:25:56 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 29 May 2009 03:25:56 +0100 (BST) X-Mailman-Approved-At: Thu, 28 May 2009 19:26:33 -0700 Subject: [secdir] assignments for June 2nd and 4th X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 02:24:22 -0000 Minimal changes since the assignments sent earlier this week: a couple of new assignments, and a couple of docs moved to the telechat agenda. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-06-04 Reviewer Draft Rob Austein T draft-ietf-sip-ua-privacy-08 Pat Cain TR draft-crocker-email-arch-13 Ran Canetti T draft-ietf-avt-seed-srtp-11 Alan DeKok T draft-ietf-dnsext-dnsproxy-05 Donald Eastlake T draft-ietf-ippm-more-twamp-02 Stephen Farrell T draft-ietf-netlmm-pmip6-ipv4-support-12 Alexey Melnikov TR draft-ietf-sip-outbound-18 Glen Zorn T draft-ietf-geopriv-sip-lo-retransmission-02 Last calls and special requests: Reviewer Draft Ran Canetti draft-eronen-enterprise-number-documentation-01 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Dave Cridland draft-housley-aes-key-wrap-with-pad-02 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Shawn Emery draft-ietf-avt-app-rtp-keepalive-05 Tobias Gondrom draft-sinnreich-sip-tools-06 Phillip Hallam-Baker draft-ietf-kitten-gssapi-store-cred-04 Steve Hanna draft-peterson-rai-rfc3427bis-01 Steve Hanna draft-ietf-avt-rtcpssm-18 Dan Harkins draft-ietf-avt-rtp-mps-02 David Harrington draft-dusseault-impl-reports-02 Sam Hartman draft-ietf-opsawg-operations-and-management-07 Paul Hoffman draft-ietf-sip-eku-05 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Love Hornquist-Astrand draft-ietf-smime-3278bis-07 Jeffrey Hutzelman draft-ietf-kitten-extended-mech-inquiry-06 Charlie Kaufman draft-ietf-kitten-rfc2853bis-05 Scott Kelly draft-livingood-woundy-p4p-experiences-07 Stephen Kent draft-ietf-geopriv-l7-lcp-ps-09 Tero Kivinen draft-ietf-webdav-bind-23 Julien Laganier draft-ietf-sip-certs-07 Julien Laganier draft-hollenbeck-rfc4934bis-01 Barry Leiba draft-hollenbeck-rfc4931bis-01 Chris Lonvick draft-hollenbeck-rfc4932bis-01 Catherine Meadows draft-ietf-speechsc-mrcpv2-18 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Catherine Meadows draft-hollenbeck-rfc4930bis-01 Sandy Murphy draft-hollenbeck-rfc4933bis-01 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Chris Newman draft-ietf-sip-connect-reuse-13 Magnus Nystrom draft-ietf-sipping-cc-framework-11 Hilarie Orman draft-ietf-geopriv-lbyr-requirements-07 Radia Perlman draft-ietf-geopriv-civic-address-recommendations-02 Eric Rescorla R draft-ietf-geopriv-http-location-delivery-14 Eric Rescorla draft-ietf-enum-iax-05 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Joe Salowey draft-dawkins-nomcom-dont-wait-03 Stefan Santesson draft-ietf-tsvwg-rsvp-l3vpn-02 Juergen Schoenwaelder draft-ietf-ospf-ospfv3-mib-14 Hannes Tschofenig draft-ietf-pce-monitoring-04 Sam Weiler draft-chown-v6ops-rogue-ra-03 Brian Weis draft-ietf-pce-p2mp-app-01 Nico Williams draft-ietf-v6ops-ra-guard-03 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 From Pasi.Eronen@nokia.com Fri May 29 04:18:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2453A6B61; Fri, 29 May 2009 04:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 OjS9Zw07Chg6; Fri, 29 May 2009 04:18:05 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E65B73A6A6A; Fri, 29 May 2009 04:18:04 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4TBITVr007441; Fri, 29 May 2009 06:18:58 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 14:18:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 14:18:10 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 29 May 2009 13:18:10 +0200 From: To: , Date: Fri, 29 May 2009 13:18:09 +0200 Thread-Topic: Pasi's AD Notes for May 2009 Thread-Index: AcngTyVYS6BtzClcQh2uUvzy/Nh8AA== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AE7A037@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 May 2009 11:18:10.0857 (UTC) FILETIME=[266E4990:01C9E04F] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for May 2009 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 11:18:06 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - I will be on parental leave/vacation (and off-line) from June 19=20 to July 19; the next AD notes will be posted before that - IESG had a face-to-face meeting on May 11-12 - Deployed new code for datatracker.ietf.org for IESG testing (if you're interested in testing "new tracker", drop me an email) - Replied to liaison statement from ITU-T SG 17 - IETF 75 preparation: SAAG agenda (if you have any topics, please=20 email Tim and me); requested slot for SAAG; requested room for=20 Security Directorate lunch - Updated security area part of the "requirements for open IESG=20 positions" text (for NomCom) with Tim - Processed errata for PKIX (RFC 5280), SSH (RFC 4335), KINK (RFC 4430) - Helping IANA to fix missing registries for KeyNote (RFC 2704/2792) and Diffie-Hellman DNS KEY records (RFC 2539) - Certicom posted updated IPR disclosures (1153, 1154) - Looking into appointing security advisor for ROLL WG with Tim (currently waiting for Tim to reply to emails) - (not wearing AD hat): Errata #1628 (for RFC 4742): waiting for NETCONF WG chairs/Dan to confirm this [since 2009-02-26] (some=20 emails in May, but not done yet) WORKING GROUPS DKIM - draft-ietf-dkim-overview: waiting for the authors to do the final=20 clarifications to address IESG discussion [since 2009-05-28] - draft-ietf-dkim-rfc4871-errata: went through IETF Last Call, on=20 agenda of 2009-06-04 IESG telechat - draft-ietf-dkim-ssp: waiting for WG chairs to confirm that the WG=20 is happy with the changes in version -10; on agenda of 2009-06-04 IESG telechat - Marked bunch of RFC 4871 errata as Verified or Held for Document Update.=20 - I still need to review what to do about errata 1385, 1532, and 1596 EMU - Quiet month IPSECME - draft-ietf-ipsecme-ikev2-redirect: publication requested; Tim will be the responsible AD for this draft - Virtual interim meeting held on 2009-05-05 - Working on fixing the IANA registrations of RFC 4543 - (not wearing AD hat) draft-ietf-ipsecme-ikev2-ipv6-config: I promised to update the draft (clean it, address TBDs) so it would be ready=20 for WGLC (as Experimental) if this path is chosen by WG. ISMS - draft-ietf-isms-secshell, draft-ietf-isms-tmsm, and draft-ietf-isms-transport-security-model: were approved by IESG, now in RFC Editor queue - draft-ietf-isms-radius-usage: waiting for authors to submit a revised draft to address the DISCUSSes [since 2009-05-14] - I need to follow up on rechartering [since 2009-05-25] KEYPROV - I need to catch up with the latest emails... PKIX - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for 3281update draft (not a normative reference, but authors preferred it this way). SASL - Some discussions about channel bindings, change control, and getting IETF standards track channel bindings for TLS SYSLOG - draft-ietf-syslog-sign: I need to check the updated version -26 =20 [since 2009-05-27] - Some discussions about rechartering TLS - draft-ietf-tls-extractor: in AD evaluation, waiting for Eric to=20 submit a revised draft [since 2009-05-27] - draft-ietf-tls-rfc4366-bis: went through WGLC; waiting for authors to submit a revised draft, and WG chairs to send=20 a publication request soon... - Looking into errata #117 (for RFC 4346) - (not WG item yet) I need to talk with the chairs and Michael about what to do with Mobi-D OTHER DOCUMENTS - draft-lebovitz-kmart-roadmap: I need to read this and=20 comment/contribute. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. DISCUSSES (active -- something happened within last month) - draft-igoe-secsh-aes-gcm: version -02 addressed my largest concern; waiting for authors to reply about the remaining ones=20 [since 2009-05-27] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-atlas-icmp-unnumbered: waiting for authors to reply to my comments [since 2009-04-21] - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] (pinged again on 2009-04-30) - draft-ietf-ipfix-file: waiting for authors to reply to my comments [since 2009-04-23] - draft-ietf-ntp-ntpv4-proto: waiting for authors to reply to my email or submit a revised ID [since 2009-04-16] - draft-ietf-ospf-lls: version -07 did not address my comments; waiting for a revised ID or RFC Editor Notes [since 2009-03-19] - draft-ietf-radext-management-authorization: changes agreed, waiting for authors to submit a revised ID [since 2009-04-20]=20 (pinged again 2009-05-28) DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cain-post-inch-phishingextns: authors have promised a new version some time in February [since 2009-01-29] - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30) - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] (but talked briefly with Radia at IETF74) - draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping- media-policy-dataset to progress (or more information from Robert) [since 2008-10-28] --end-- From dcrocker@bbiw.net Fri May 29 09:36:16 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6F33A687F; Fri, 29 May 2009 09:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 WkigGV5fxGTO; Fri, 29 May 2009 09:36:15 -0700 (PDT) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 6C05D3A6881; Fri, 29 May 2009 09:35:46 -0700 (PDT) Received: from [127.0.0.1] (adsl-68-122-35-252.dsl.pltn13.pacbell.net [68.122.35.252]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4TGbBVS011548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 09:37:16 -0700 Message-ID: <4A200F36.5050302@bbiw.net> Date: Fri, 29 May 2009 09:37:10 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Patrick Cain References: <082501c9e07b$51333740$f399a5c0$@com> In-Reply-To: <082501c9e07b$51333740$f399a5c0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 29 May 2009 09:37:16 -0700 (PDT) Cc: iesg@ietf.org, tony@att.net, secdir@ietf.org Subject: Re: [secdir] secdir re-review of draft-crocker-email-arch-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 16:36:16 -0000 thanks! d/ Patrick Cain wrote: > 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 was a re-review for an updated document. > > My previously raised concerns have been addressed. > > Pat > > -- Dave Crocker Brandenburg InternetWorking bbiw.net From SRS0=AF4up9=BZ=coopercain.com=pcain@yourhostingaccount.com Fri May 29 09:51:41 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC273A68DF; Fri, 29 May 2009 09:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 rA1neHztrhQh; Fri, 29 May 2009 09:51:41 -0700 (PDT) Received: from mailout15.yourhostingaccount.com (mailout15.yourhostingaccount.com [65.254.253.126]) by core3.amsl.com (Postfix) with ESMTP id 4A2023A68EA; Fri, 29 May 2009 09:50:54 -0700 (PDT) Received: from mailscan10.yourhostingaccount.com ([10.1.15.10] helo=mailscan10.yourhostingaccount.com) by mailout15.yourhostingaccount.com with esmtp (Exim) id 1MA52I-0002A0-DI; Fri, 29 May 2009 12:34:26 -0400 Received: from impout03.yourhostingaccount.com ([10.1.55.3] helo=impout03.yourhostingaccount.com) by mailscan10.yourhostingaccount.com with esmtp (Exim) id 1MA52H-0005hW-Ko; Fri, 29 May 2009 12:34:25 -0400 Received: from authsmtp06.yourhostingaccount.com ([10.1.18.6]) by impout03.yourhostingaccount.com with NO UCE id xUaQ1b00B07rVmq0000000; Fri, 29 May 2009 12:34:25 -0400 X-EN-OrigOutIP: 10.1.18.6 X-EN-IMPSID: xUaQ1b00B07rVmq0000000 Received: from familyroom8.bc.edu ([136.167.27.86] helo=familyroom) by authsmtp06.yourhostingaccount.com with esmtpa (Exim) id 1MA52G-0002UD-0E; Fri, 29 May 2009 12:34:24 -0400 Received: from familyroom by familyroom (PGP Universal service); Fri, 29 May 2009 12:34:24 -0500 X-PGP-Universal: processed; by familyroom on Fri, 29 May 2009 12:34:24 -0500 From: "Patrick Cain" To: , , Date: Fri, 29 May 2009 12:34:15 -0400 Message-ID: <082501c9e07b$51333740$f399a5c0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmovu1So8dPyjC7S422ZIuzOP+3Aw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-EN-UserInfo: 058f9b27fa04b0cf04458fb359a831ba:155e17fc3c7b3afdad05516cd0497062 X-EN-AuthUser: pcain@coopercain.com Sender: "Patrick Cain" X-EN-OrigIP: 136.167.27.86 X-EN-OrigHost: familyroom8.bc.edu Cc: tony@att.net Subject: [secdir] secdir re-review of draft-crocker-email-arch-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 17:44:16 -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 was a re-review for an updated document. My previously raised concerns have been addressed. Pat From charliek@microsoft.com Sat May 30 23:18:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879693A698D; Sat, 30 May 2009 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.098 X-Spam-Level: X-Spam-Status: No, score=-11.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyjQau5PLbSq; Sat, 30 May 2009 23:18:38 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B2CBD3A6912; Sat, 30 May 2009 23:18:38 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 30 May 2009 23:20:23 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([157.54.97.142]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Sat, 30 May 2009 23:20:22 -0700 From: Charlie Kaufman To: "'secdir@ietf.org'" , "'iesg@ietf.org'" , "mayank+ietf-2853@google.com" , "seema.malkani@sun.com" , "shawn.emery@sun.com" , "tlyu@mit.edu" Thread-Topic: Secdir review of draft-ietf-kitten-rfc2853bis-05.txt (GSSAPI JAVA BINDINGS) Thread-Index: Acnht+KgOQmkN2JhRZyaHaEt2kieOQ== Date: Sun, 31 May 2009 06:20:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B091201E883TK5EX14MBXC117red_" MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-kitten-rfc2853bis-05.txt (GSSAPI JAVA BINDINGS) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 06:18:39 -0000 --_000_D80EDFF2AD83E648BD1164257B9B091201E883TK5EX14MBXC117red_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any= other last call comments. Feel free to forward to any appropriate forum. This refresh of RFC 2853 (GSSAPI JAVA BINDINGS) is almost trivial. The only= technical changes are the renumbering of error codes and OID values becaus= e the values in RFC 2853 were internally inconsistent, missing, or (in the = case of OIDs) obsolete. There are a handful of other minor corrections in t= he document (none technical). The document was also refreshed to use the no= w-current copyright notices, etc. Since all of the error codes correspond to fatal errors, it is unlikely tha= t even interoperation with an implementation with bad codes could cause sec= urity problems (just confusing error messages). The security considerations= seemed reasonable in RFC 2853 and they are unchanged here. --Charlie --_000_D80EDFF2AD83E648BD1164257B9B091201E883TK5EX14MBXC117red_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I am reviewing this document as part of the security directorate's ongoing effor= t 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 ot= her last call comments. Feel free to forward to any appropriate forum.

 

This refresh of RFC 2853 (GSSAPI JAVA BINDINGS) is alm= ost trivial. The only technical changes are the renumbering of error codes and = OID values because the values in RFC 2853 were internally inconsistent, missing= , or (in the case of OIDs) obsolete. There are a handful of other minor correcti= ons in the document (none technical). The document was also refreshed to use th= e now-current copyright notices, etc.

 

Since all of the error codes correspond to fatal error= s, it is unlikely that even interoperation with an implementation with bad codes could cause security problems (just confusing error messages). The security considerations seemed reasonable in RFC 2853 and they are unchanged here.

 

         =        --Charlie

--_000_D80EDFF2AD83E648BD1164257B9B091201E883TK5EX14MBXC117red_-- From ananth@cisco.com Sun May 31 15:37:02 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F14928C1E9; Sun, 31 May 2009 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNAZlSlZvi+T; Sun, 31 May 2009 15:37:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 451143A6DE0; Sun, 31 May 2009 15:36:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,280,1241395200"; d="scan'208";a="313928317" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 May 2009 22:36:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4VMavQK005612; Sun, 31 May 2009 15:36:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4VMavtq018939; Sun, 31 May 2009 22:36:57 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 May 2009 15:36:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 31 May 2009 15:36:55 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5807564444@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-tcpm-tcpsecure-11.txt thread-index: AcnOeQd9tB+4hSOVSDeMVbkS/YCPnQTwBKqg References: <13D1EAB852BE194C94773A947138483D0749EF90@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "Sandra Murphy" , "Mitesh Dalal (mdalal)" X-OriginalArrivalTime: 31 May 2009 22:36:57.0071 (UTC) FILETIME=[4DF8DFF0:01C9E240] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11205; t=1243809417; x=1244673417; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20review=20of=20draft-ietf-tcpm-tcpsecure -11.txt |Sender:=20; bh=r91wy2Pdaheeb7/xigruEO7KUsoRRG762Q6aKjO1kp8=; b=bT2iJ5Gxr+AmoqBP1vMSnCnbiC/0t2GNrJq7J50g9fBAtI7z+a7h8jmhyZ +YCu+9g3+8T6JAHEW1Fu3K9Gj8/WWfAY+wzBFRpCCNKX4zxHi25SsbI/9rAL Q+NSqOjdQW; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: tcpm-chairs@tools.ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-tcpm-tcpsecure-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 22:37:02 -0000 Sandra, I am in the process of integrating all the last call comments received. I need some clarfications on some of your comments. Pl look for ANA>=20 > -----Original Message----- > From: Sandra Murphy [mailto:sandy@sparta.com]=20 > Sent: Wednesday, May 06, 2009 11:32 AM > To: Mitesh Dalal (mdalal) > Cc: iesg@ietf.org; secdir@ietf.org;=20 > draft-ietf-tcpm-tcpsecure@tools.ietf.org;=20 > tcpm-chairs@tools.ietf.org; Anantha Ramaiah (ananth) > Subject: RE: review of draft-ietf-tcpm-tcpsecure-11.txt >=20 > On Tue, 28 Apr 2009 11:31:01 -0700, Mitesh Dalal wrote: >=20 > Comments below in-line. >=20 > >Hi Sandra, > > > >Thank you for taking time to review the draft. Please see inline. > > > > > >---------- Forwarded message ---------- > >Date: Thu, 23 Apr 2009 14:19:11 -0400 (Eastern Daylight Time) > >From: Sandra Murphy > >To: iesg@ietf.org, secdir@ietf.org, > >draft-ietf-tcpm-tcpsecure@tools.ietf.org, > > tcpm-chairs@tools.ietf.org >=20 > > >=20 >=20 > >This document is intended to update rfc793. That means that=20 > it should=20 > >be very explicit about what text it is replacing and what=20 > the new text=20 > >is. > > > >Mitesh: The mitigation section of the discussed attack does=20 > highlight=20 > >the processing "rules" that are being modified. If you have explicit=20 > >suggestions to make it better, we welcome it. >=20 > Essentially, I'm thinking that you need to indicate >=20 > OLD: >=20 > 793 text > 793 text > 793 text >=20 > NEW: >=20 > draft text > draft text > draft text ANA> I guess each mitigation says something like : For rg:- [RFC0793] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows: 1) If the RST bit is set and the sequence number is outside the .... ...... Instead, this document requires that implementations SHOULD implement the following steps in place of those specified in [RFC0793] (as listed above). ...... ...... So, is very clear as which is the OLD RFC text and the NEW one proposed by this document. May be there are places out there would benefit some correction. But the place where the crux is described seems to be ok. > > > > > >The dicussions of interactions between TCP peers are always=20 > difficult=20 > >to phrase, as most terms are relative to viewpoint. The=20 > text in some=20 > >places is tough to read - who is the sender, who the receiver, etc. =20 > >The text also uses a lot of different terms to represent the same=20 > >entity - remote peer, remote end sender, remote TCP endpoint, etc. > > > >Mitesh: We may consider simplifying these terms to remote=20 > peer if that=20 > >helps. Point noted. Ok, I have retained the Sender/Receiver terminology as per RFC 793. I am using remote peer in all other places where "receiver" isn't very intriguing. >=20 > OK. Note that I recognize the difficulty of choosing an=20 > apporpriate term from among the common ones, which are=20 > relative to the point of view. Sure :-) >=20 >=20 > >The term "initial sequence number" has a special meaning in TCP and=20 > >should be avoided. > > > >Mitesh: Can you please elaborate the context? >=20 > Context in your draft: >=20 > 2) A sequence number that will be used in the RST. This sequence > number will be a starting point for a series of=20 > guesses to attempt > to present a RST segment to a connection endpoint that would be > acceptable to it. Any random value may be used to guess the > initial sequence number. > ^^^^^^^^^^^^^^^^^^^^^^^ >=20 > Context in RFC793: >=20 > [Lots of places in 793 refer to initial sequence number=20 > or to ISN. > And, of course, lots of literature.] >=20 > I think the draft means "the first guess", "the starting=20 > point", not the TCP "initial sequence number". Good point. I have used the term "starting sequence number." >=20 > > > >The text says that this mitigation SHOULD be used "in devices" which=20 > >typically host apps that are most vulnerable and MIGHT be used=20 > >elsewhere. Is there a suggestion that this would be under=20 > application=20 > >control? Chosen by the OS vendor (or device vendor)? For=20 > those who are=20 > >using Quagga routers (routing apps on top of intel boxes=20 > running some=20 > >*ix), would this be a socket option? > >What's the vision here? > > > >Mitesh: This implementation detail is outside the scope of=20 > the document. > >Although, implementors may > >make it a compile time option, application dependent control (as you=20 > >hint with socket option) or may make it mandatory for the stack. >=20 > The draft discusses issues of interoperability between a TCP=20 > stack that implements the new algorithm and one that does=20 > not. But I'm wondering about issues of interoperabality=20 > between applications and TCP stacks. An vulnerable app that=20 > wants the new algorithm on an OS that has decided to leave=20 > the decision in the TCP stack, etc. >=20 > For those systems where TCP stack and application are=20 > integrally implemented, i.e., "devices" like routers running=20 > BGP, the interoperability will be taken care of. But there=20 > are cases where an app that is vulnerable is running on a=20 > platform where the OS is a general purpose OS. In that case,=20 > you aren't considering just one integrally implemented "device". This is again an implementation advice and it is upto the implemantations to chose whatever form they want, I second what Mitesh has alluded to. >=20 > I'm just having trouble deciding what this all means in light=20 > of the recommendation of section 1.1: >=20 > SHOULD be implemented in devices that regularly need to=20 > maintain TCP > connections of the kind most vulnerable to the attacks=20 > described in > this document. Examples of such TCP connections are the ones that > tend to be long-lived and where the connection end points can be > determined, in cases where no auxiliary anti-spoofing protection > mechanisms like TCP MD5 [RFC2385] can be deployed. These=20 > mitigations > MAY be implemented in other cases. >=20 > I'm having difficulty figuring out how this will work. Maybe=20 > this is just the age-old inter-layer feature negotiation=20 > problem, and people will deal. Well, this is a good point. The AS was added when some members felt that this mitigation is useful only in some situations, however there were others who felt that these are general purpose and it may benefit some situations and in other situations it is harmless. Some felt that since this document has IPT, may be having an AS would help. This document has been floating around for 5 years and there is lot of dicsussions that have taken place in the past, so I am not sure it is a good idea to modify the AS. I am open if you have some specfic suggestions. >=20 > > > >I don't understand some parts of > > > > All TCP stacks MAY implement the following mitigation. =20 > TCP stacks > > which implement this mitigation MUST add an additional=20 > input check=20 > >to > > any incoming segment. The ACK value is considered=20 > acceptable only=20 > >if > > it is in the range of ((SND.UNA - MAX.SND.WND) <=3D SEG.ACK <=3D > > SND.NXT). All incoming segments whose ACK value doesn't=20 > satisfy the > > above condition MUST be discarded and an ACK sent back. =20 > It needs to > > be noted that RFC 793 on page 72 (fifth check) says: "If=20 > the ACK is=20 > >a > > duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK > > acknowledges something not yet sent (SEG.ACK > SND.NXT)=20 > then send an > > ACK, drop the segment, and return." This mitigation=20 > makes the ACK > > check more stringent since any ACK < SND.UNA wouldn't be=20 > accepted, > > instead only ACKs which are in the range ((SND.UNA -=20 > MAX.SND.WND) <=3D > > SEG.ACK <=3D SND.NXT) gets through. > > > >Seems that SEG.ACK could fall between the SND.UNA and SND.UNA -=20 > >MAX.SND.WND, in which case the new code accepts segments that the=20 > >existing text says "it is ignored". I would read the 793 text as the > >*ACK* is ignored, which means the new text would accept (and act on)=20 > >ACKs that are presently ignored. But looking at existing=20 Nope. We added more text to clarify this situation. The current RFC 793 will *accept* any ACK that satisfies the following in-equality : ((SND.UNA-(2^31-1)) <=3D SEG.ACK <=3D SND.NXT). The term "ignored" means that "ignore the ACK value and continue processing the TCP segment", if sequence no. etc., is Ok, the TCP segment would be accepted. "ignored" doesn't mean the segment is dropped :-) Only when the SEG.ACK > SND.NXT it gets dropped. Now all the new text is saying is to add a stringent boundary on the acceptability of ACK's. I re-read the whole "data mitigation" section and I am unable to come out with text which is more explanatory than the current existing one. > TCP code, it=20 > >looks like people have interpreted "it is ignored" as the=20 > *segment* is=20 > >ignored, i.e., dropped. In that case, this new text is accepting=20 No, see above. > >segments that in existing implementations would be dropped. > >Is that the intent? (Note: I could be easily wrong about=20 > the tcp_input > >code.) > if MAX.SND.WND > 0, then SND.UNA-MAX.SND.WND < SND.UNA, so if=20 > SEG.ACK < SND.UNA,it is possible that (SND.UNA - MAX.SND.WND)=20 > <=3D SEG.ACK and SEG.ACK < SND.UNA. So the statement > since any ACK < SND.UNA wouldn't be accepted=20 > disagrees with > ACKs which are in the range ((SND.UNA -=20 > MAX.SND.WND) <=3D > SEG.ACK <=3D SND.NXT) gets through. > for the SEG.ACK range SND.UNA - MAX.SND.WND <=3D SEG.ACK < SND.UNA Pl see above, I guess confusion is about the RFC 793 terminology on the term "ignored". >=20 > The second comment was about the difference in behavior=20 > between existing implementations and the new recommended=20 > algorithm. I'm interested in what turns up about that. The recommended algorithm wouldn't accept ACK's which are < (SND.UNA - MAX.SND.WND) >=20 >=20 > > > > > >There are some language errors (missed words, punctuation, all that=20 > >sort of boring stuff) that I could point out, or you could=20 > rely on the=20 > >RFC editor to find. > > > >Mitesh: Do send us stuff annotated and we can "refine" the=20 > document as=20 > >we move to the finish line. >=20 > Working on that. Well, any help in amy grammatcial/language stuff is appreciated. There might have some which have in-advertently missed out. Did I miss any email ? =20 Actually it has been out of the last call and the document is in the state where we need to get the next revision out ASAP. Hence a quick response is appreciated. Thanks for your detailed review. -Anantha From secdir-bounces@mit.edu Sat May 30 03:03:54 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145133A6BA8 for ; Sat, 30 May 2009 03:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.272 X-Spam-Level: X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=-2.273, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrDVco1vP+ed for ; Sat, 30 May 2009 03:03:53 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 094623A69E2 for ; Sat, 30 May 2009 03:03:52 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n4UA5bdB025853 for ; Sat, 30 May 2009 06:05:37 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n4UA5Zrh025841 for ; Sat, 30 May 2009 06:05:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n4UA5PKU003082 for ; Sat, 30 May 2009 06:05:25 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 6161D1F5EA2E for ; Sat, 30 May 2009 06:05:21 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id og9IsFoZl6ukwOYS for ; Sat, 30 May 2009 06:05:21 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA49F3A69E2; Sat, 30 May 2009 03:03:35 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AB73A6DA2 for ; Thu, 28 May 2009 20:08:59 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A24+6BSP+RZE for ; Thu, 28 May 2009 20:08:53 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id C0A033A6D78 for ; Thu, 28 May 2009 20:08:53 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1M9sUN-0000XH-HF for public-new-work-dist@listhub.w3.org; Fri, 29 May 2009 03:10:35 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1M9sUM-0000Wb-Sg for public-new-work@listhub.w3.org; Fri, 29 May 2009 03:10:34 +0000 Received: from homer.w3.org ([128.30.52.30]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1M9sUH-00031u-Fc; Fri, 29 May 2009 03:10:34 +0000 Received: from [IPv6:::1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 3EA3C4EECA; Thu, 28 May 2009 23:10:29 -0400 (EDT) Message-Id: <6A25BBD2-22AC-425D-8B57-ADE286FC30A2@w3.org> From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 28 May 2009 22:10:28 -0500 X-Mailer: Apple Mail (2.930.3) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1M9sUH-00031u-Fc db866745c12e83145e9a237458ab0970 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/43 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 29 May 2009 03:10:35 +0000 X-Mailman-Approved-At: Sat, 30 May 2009 03:03:34 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id n4UA5Zrh025841 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Sun, 31 May 2009 23:49:16 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: Device APIs and Policy Working Group (until 2009-06-25) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2009 10:03:54 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Ubiquitous Web Applications Activity [0] (see the W3C = Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Device APIs and Policy Working Group: http://www.w3.org/2009/05/DeviceAPICharter 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 2009-06-25 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 Dominique Haza=EBl-Massieux, Mobile Web Initiative Activity Lead = . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2007/uwa/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- 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 _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir