From jlentini@netapp.com Wed Sep 30 15:16: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 5418B3A6975; Wed, 30 Sep 2009 15:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 I1SKgu0pluIw; Wed, 30 Sep 2009 15:16:15 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 180163A6817; Wed, 30 Sep 2009 15:16:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,482,1249282800"; d="scan'208";a="251509073" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Sep 2009 15:17:37 -0700 Received: from jlentini-linux.nane.netapp.com (jlentini-linux.hq.netapp.com [10.97.16.21]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n8UMHYOj029898; Wed, 30 Sep 2009 15:17:34 -0700 (PDT) Date: Wed, 30 Sep 2009 18:17:31 -0400 (EDT) From: James Lentini X-X-Sender: jlentini@jlentini-linux.nane.netapp.com To: Nicolas Williams In-Reply-To: <20090930193620.GA902@Sun.COM> Message-ID: References: <20090930193620.GA902@Sun.COM> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 01 Oct 2009 05:49:20 -0700 Cc: Craig Everhart , secdir@ietf.org, Daniel Ellard , nfsv4@ietf.org, Manoj Naik , Renu Tewari , iesg@ietf.org Subject: Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 22:16:16 -0000 Nico, Thank you for your feedback. We will update the document to include the improvements you have suggested both to the security considerations (noting the authorization separation inherent in the design, the resource consumption considerations for NSDB objects, and the implications regarding NSDB authentication) and general description (regarding the absence of junctions in the NSDB and the benefits of using fixed size FSNs). On Wed, 30 Sep 2009, Nicolas Williams wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document describes the notion of "federated filesystem namespace" > and requirements for specifications of an actual set of federated > filesystem namespace components and even some requirements of actual > implementations. > > A federated namespace is one where multiple filesystems (or, rather, > "filesets") are put together into a larger filesystem-like namespace, > but where the various filesystems involved can be owned and administered > by widely varying entities. > > Authorization issues arise when filesystems migrate, and these are > neatly resolved in the federated namespace concept by separating the > location of references to filesystems from the location of fileset > location information. References to filesets ("junctions") live in > actual filesystem (think of a magic symlink or "shortcut"). Fileset > location information lives in a directory whose name is part of the > fileset's name as referenced by any junction that refers to it. > > Authorization of junction administration is a matter local to the > filesystems where the junctions live. Authorization of fileset location > administration is a matter local to the directory where the fileset > location information is published. > > There is one more level of separation as well, to allow for filesets > with replicas owned and administered by different entities. "Fileset > names" (FSNs) refer to directory objects which in turn refer to "fileset > location" objects (FSLs); both, FSNs and FSLs include the name of the > containing directory in their canonical name forms. > > The document does not describe the authorization separation involved. > And though it isn't strictly necessary, I believe that it would be > beneficial to have such a description. > > The document also does not clearly explain that junctions are not > published in any directory, which confused me greatly at first, as in my > opinion publishing FSN and FSL objects does not make the directories in > which they are published "namespace databases" (NSDBs). This is not a > security concern, of course. > > The document also does not explain that FSNs are intended to be small, > even fixed sized, or with highly compressible variable size portions[*]. > But a moment's thought about filesystem designs quickly reveals that > such a requirement is important. In my opinion such a requirement > should be documented. This too is not a security concern. > > The Security Considerations section is a bit skimpy. Its claims are > correct in my opinion. I would, however, add to it the following: > > - A note that the federated namespace concept helps distribute > responsibility for authorization (a very good thing). > > - A note that orphaned FSNs and FSLs cannot be easily distinguished > from ones referenced by junctions and FSNs, respectively. Therefore > objects will tend to pile up. This is a resource consumption > consideration. Resource control issues are, IMO, a security > consideration. > > Finally, I'm not sure if it's worth saying anything about the fact that > with the NSDB choice being up to the FSN and FSL publishers, there can > be a plethora of NSDBs in a federation, which brings scalability of > distributed authentication and trust into the picture. For example, > consider an NSDB that uses TLS and a self-signed server certificate to > authenticate itself, then a fingerprint of the certificate will have to > be part and parcel of the FSN/FSL names stored by junctions/FSNs > (respectively). A PKI would help, of course, but in a sufficiently > large federation it may be necessary to have multiple trust anchors, > rather than a single PKI root, which brings TA administration issues > into the picture. This is really nothing new, and so perhaps not worth > noting, but the potential for having to store, and the consequences > thereof, FSN NSDB authentication information in junctions, and FSL NSDB > authentication information in FSNs, does seem to me to be worth noting. > > [*] For example, assuming many FSNs but relatively few NSDBs, filesystem > implementors could choose store FSNs as {reference to NSDB name, FSN > object name relative to NSDB}. If the second item of the tuple is > itself fixed-sized then the whole tuple can be fixed sized. A table > of {NSDB name, reference} would be needed too, but it may be > critical to keep "inodes" fixed-sized, with little wastage, in which > case "interning" NSDB names as described above is a sufficient > compression technique. > > In fact, draft-ietf-nfsv4-federated-fs-protocol-03 does use UUIDs > for naming FSNs and FSLs, so that the above technique is certainly a > feasible way to keep inodes fixed-sized in spite of the fact that > FSNs are actually variable sized (the NSDB name where the FSN > resides is part of the FSN's name). > > Nico > -- > From Pasi.Eronen@nokia.com Thu Oct 1 08:32: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 865943A6974; Thu, 1 Oct 2009 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 GnREWR5yop6T; Thu, 1 Oct 2009 08:32:09 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 62E203A6853; Thu, 1 Oct 2009 08:32:09 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n91FW5EH010610; Thu, 1 Oct 2009 10:32:41 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 18:33:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 18:33:22 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 1 Oct 2009 17:33:22 +0200 From: To: , Date: Thu, 1 Oct 2009 17:33:21 +0200 Thread-Topic: Pasi's AD Notes for September 2009 Thread-Index: AcpCrIHz8bpAJvzbR4+2Umq6pFXwIw== Message-ID: <808FD6E27AD4884E94820BC333B2DB773C098395C0@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: 01 Oct 2009 15:33:22.0747 (UTC) FILETIME=[82AA08B0:01CA42AC] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for September 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: Thu, 01 Oct 2009 15:32:10 -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 - Sent a liaison statement reply to ITU-T regarding identity=20 management. - Informed NomCom that I'm not running for a second term (see http://www.ietf.org/mail-archive/web/secdir/current/msg00994.html) - Reviewed ROHCoIPsec drafts again for IETF last call. - (not wearing AD hat): Errata #1628 (for RFC 4742): IANA has now =20 fixed the registry and Dan verified the errata.=20 - Tools work: test suite improvements, Django 1.x transition, tools authentication model, IESG agenda-related tools, etc. - Requested room/slot for SAAG and SecDir lunch at IETF76. - Some discussions about SIDR algorithm agility. WORKING GROUPS DKIM - Waiting for Stephen and Barry for new charter text (noting that=20 current work items are completed and adding 4871bis) - I still need to review what to do about errata 1385, 1532, and 1596 - Talked about the mailing list with Tim/chairs/Dave; decided to keep the current list (and not move it to ietf.org) for the time being, since it's DKIM-signing the emails (and=20 EMU IPSECME - A virtual interim meeting was held on 2009-09-22. - Still working on fixing the IANA registrations of RFC 4543;=20 currently waiting for IANA [since 2009-07-31; pinged several times since then] - draft-ietf-ipsecme-ikev2-resumption: went through IETF last call;=20 now in IESG evaluation and on agenda of the 2009-10-08 telechat. - draft-ietf-ipsecme-ikev2-redirect (not wearing AD hat; Tim is=20 handling this one): was approved by IESG, now in RFC editor queue. - draft-ietf-ipsecme-traffic-visibility: waiting for the WG to=20 discuss my AD evaluation comments and eventually submit a revised ID [since 2009-09-17] (there are also some emails I haven't read yet, and may need to reply to) - draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat): went through IETF last call; on agenda of the 2009-10-08 telechat. - draft-kanno-ipsecme-camellia-xcbc (not WG item): the authors have asked if I would sponsor this as individual submission; currently waiting for me to take a look and reply [since 2009-09-29] ISMS - Some emails I haven't read yet... KEYPROV - Some emails I haven't read yet... PKIX - draft-ietf-pkix-sha2-dsa-ecdsa: in IETF last call until 2009-10-05. - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for draft-ietf-pkix-sha2-dsa-ecdsa. SASL - draft-ietf-sasl-scram: went through IETF Last Call; waiting for me to read all the emails and figure out next steps [since 2009-09-28] - (not WG item) draft-melnikov-sasl-scram-ldap: I am sponsoring this=20 as individual submission; currently in IETF last call until 2009-10-26. - (not WG item) draft-altman-tls-channel-bindings: I've promised to sponsor this as individual submission; currently waiting for=20 Nico to prepare the write-up before starting IETF Last Call=20 [since 2009-08-31] SYSLOG - Rechartering was approved by IESG. - draft-ietf-syslog-sign: went through IETF last call; waiting for the authors to reply to last call comments and submit a revised ID [since 2009-09-17] TLS - draft-ietf-tls-rfc4366-bis: went through IETF last call; waiting for Donald to reply to the last call comments and submit a=20 revised ID [since 2009-09-09] - Looking into errata #117 (for RFC 4346) - (not WG item) see SASL WG for draft-altman-tls-channel-bindings - draft-ietf-tls-extractor: was approved by IESG; now in RFC editor queue.=20 OTHER DOCUMENTS DISCUSSES (active -- something happened within last month) - draft-cain-post-inch-phishingextns: waiting for authors to submit a revised ID [since 2009-09-04] - draft-harkins-emu-eap-pwd: waiting for authors to reply to my comments [since 2009-09-25] - draft-housley-tls-authz-extns: waiting for authors to submit a revised ID [since 2009-09-22] - draft-solinas-rfc4753bis: waiting for authors to reply to my comments [since 2009-09-24] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-freed-sieve-in-xml: waiting for authors to propose changes or submit a revised ID [since 2009-08-13] - draft-ietf-netconf-partial-lock: waiting for authors to=20 propose text or submit a revised ID [since 2009-08-13] - draft-ietf-ntp-autokey: waiting for Ralph to get more information from WG [since 2009-08-20] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-07-26] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30 and 2009-06-09) - 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 and 2009-06-09) - draft-ietf-dime-diameter-api: waiting for Dan to get WG's opinion=20 on whether this will be useful and if yes, why [since 2009-06-18] - draft-ietf-ntp-ntpv4-proto: waiting for authors to reply to my email or submit a revised ID [since 2009-04-16] - 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 ekr@networkresonance.com Thu Oct 1 12:44: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 3EFB53A68B5; Thu, 1 Oct 2009 12:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.913, 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 7nij3u4vMM6K; Thu, 1 Oct 2009 12:44:20 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 7A25C28C1BB; Thu, 1 Oct 2009 12:44:16 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 856F750822; Thu, 1 Oct 2009 12:45:32 -0700 (PDT) Date: Thu, 01 Oct 2009 12:45:32 -0700 From: Eric Rescorla To: secdir@ietf.org, iesg@ietf.org, draft-ietf-ccamp-mpls-graceful-shutdown-12@tools.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: <20091001194532.856F750822@romeo.rtfm.com> Subject: [secdir] Secdir review of draft-ietf-ccamp-mpls-graceful-shutdown-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, 01 Oct 2009 19:44:21 -0000 I do not see any relevant security issues with this document. The phrase "Time or decision for removal of the resource being shut down" is used twice in this document. It's not entirely clear to me what this means. If it's a term of art in MPLS, maybe it's OK, but if not, perhaps a rephrase is in order. -Ekr From Nicolas.Williams@sun.com Fri Oct 2 12:51:59 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 5A9C93A682A; Fri, 2 Oct 2009 12:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 e8uchLVGKT3q; Fri, 2 Oct 2009 12:51:58 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 32C8B3A67C1; Fri, 2 Oct 2009 12:51:58 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n92JrQg6001675; Fri, 2 Oct 2009 19:53:26 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n92JrQ8R024427; Fri, 2 Oct 2009 13:53:26 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n92JJhus003047; Fri, 2 Oct 2009 14:19:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n92JJg5u003046; Fri, 2 Oct 2009 14:19:42 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 2 Oct 2009 14:19:42 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20091002191942.GJ887@Sun.COM> References: <1372_1254340959_n8UK2bOg025386_20090930193620.GA902@Sun.COM> <65075E890F4E784CD4416173@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65075E890F4E784CD4416173@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Cc: Craig Everhart , secdir@ietf.org, Daniel Ellard , nfsv4@ietf.org, Manoj Naik , Renu Tewari , iesg@ietf.org, James Lentini Subject: Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 19:51:59 -0000 On Wed, Sep 30, 2009 at 10:31:11PM -0400, Jeffrey Hutzelman wrote: > --On Wednesday, September 30, 2009 02:36:20 PM -0500 Nicolas Williams > wrote: > > > - A note that orphaned FSNs and FSLs cannot be easily distinguished > > from ones referenced by junctions and FSNs, respectively. Therefore > > objects will tend to pile up. This is a resource consumption > > consideration. Resource control issues are, IMO, a security > > consideration. > > I don't think this is a significant problem, or a security problem at all. > The fact that, once I have allocated my resources for an object, you might > decide to stop having any references to it, does not create a security > problem for me. This is analogous to my publishing a web page, and then > you later deciding not to link to it any more. I agree that orphaning over time is not a security problem. I was thinking more of the fact that to authorize someone to publish FSNs/FSLs in some NSDB is to authorize them to create unlimited amounts of garbage. Garbage collection being effectively impossible, the fact that authorization to publish is also authorization to consume all resources seems like a problem to me. One might want to implement resource controls at NSDBs ("Joe can create FSNs and FSLs in this NSDB, at the rate of 10 objects per-day" or "Jane can create up to 100 FSNs and FSLs in this NSDB"). One might also wish to have an optional way to document in an FSN the paths to junctions that are expected to reference the FSNs Similarly, an optional way to document in an FSL the FSNs that are expected to reference the FSL. Not that such documentation would be sufficient to make garbage collection possible; it'd only make it feasible to check _intended_ references. Nico -- From jhutz@cmu.edu Fri Oct 2 14:41: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 5A0EF28C13D; Fri, 2 Oct 2009 14:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=-0.419, 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 kZ4fqVxaKB-S; Fri, 2 Oct 2009 14:41:41 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id E6D9728C133; Fri, 2 Oct 2009 14:41:40 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n92LgmXJ016549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Oct 2009 17:42:49 -0400 (EDT) Date: Fri, 02 Oct 2009 17:42:48 -0400 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: <70430176023E61F897E5DC22@minbar.fac.cs.cmu.edu> In-Reply-To: <20091002191942.GJ887@Sun.COM> References: <1372_1254340959_n8UK2bOg025386_20090930193620.GA902@Sun.COM> <65075E890F4E784CD4416173@atlantis.pc.cs.cmu.edu> <20091002191942.GJ887@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: Craig Everhart , secdir@ietf.org, Daniel Ellard , nfsv4@ietf.org, Manoj Naik , Renu Tewari , iesg@ietf.org, James Lentini Subject: Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 21:41:45 -0000 --On Friday, October 02, 2009 02:19:42 PM -0500 Nicolas Williams wrote: > I agree that orphaning over time is not a security problem. I was > thinking more of the fact that to authorize someone to publish FSNs/FSLs > in some NSDB is to authorize them to create unlimited amounts of > garbage. Garbage collection being effectively impossible, the fact that > authorization to publish is also authorization to consume all resources > seems like a problem to me. One might want to implement resource > controls at NSDBs ("Joe can create FSNs and FSLs in this NSDB, at the > rate of 10 objects per-day" or "Jane can create up to 100 FSNs and FSLs > in this NSDB"). I don't know enough about NFSv4's intended model to know if that's actually a problem. In AFS, the equivalent objects are entries in the volume location database, only administrators get the power to create them, and they are tied fairly tightly to volumes. The resource you worry about people exhausting is the disk space occupied by volumes, not VLDB entries. What's not clear to me is whether the NFSv4 NSDB's are intended to be similar, or whether the intent is that relatively unprivileged users be able to create arbitrary entries. > One might also wish to have an optional way to document in an FSN the > paths to junctions that are expected to reference the FSNs Similarly, > an optional way to document in an FSL the FSNs that are expected to > reference the FSL. Not that such documentation would be sufficient to > make garbage collection possible; it'd only make it feasible to check > _intended_ references. That does sound like a useful feature. In practice, intended references are the ones you care about; if you decide a resource is going away, then anyone else who has unexpected references just loses. That said, one of the common problems AFS administrators run into is trying to enumerate all of the mount points, other than by doing a find-style traversal of the entire filesystem. It would be cool to see some sort of answer to this problem in NFS. From Nicolas.Williams@sun.com Fri Oct 2 15:22:05 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 376C33A682E; Fri, 2 Oct 2009 15:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.586 X-Spam-Level: X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=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 nMlIAv7wVcYt; Fri, 2 Oct 2009 15:22:04 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id F373D3A680F; Fri, 2 Oct 2009 15:22:03 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n92MNVTU017814; Fri, 2 Oct 2009 22:23:31 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n92MNVoL053629; Fri, 2 Oct 2009 16:23:31 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n92LnnRs003236; Fri, 2 Oct 2009 16:49:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n92LnmYY003235; Fri, 2 Oct 2009 16:49:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 2 Oct 2009 16:49:48 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20091002214947.GT887@Sun.COM> References: <1372_1254340959_n8UK2bOg025386_20090930193620.GA902@Sun.COM> <65075E890F4E784CD4416173@atlantis.pc.cs.cmu.edu> <20091002191942.GJ887@Sun.COM> <70430176023E61F897E5DC22@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70430176023E61F897E5DC22@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i Cc: Craig Everhart , secdir@ietf.org, Daniel Ellard , nfsv4@ietf.org, Manoj Naik , Renu Tewari , iesg@ietf.org, James Lentini Subject: Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 22:22:05 -0000 On Fri, Oct 02, 2009 at 05:42:48PM -0400, Jeffrey Hutzelman wrote: > --On Friday, October 02, 2009 02:19:42 PM -0500 Nicolas Williams > wrote: > >I agree that orphaning over time is not a security problem. I was > >thinking more of the fact that to authorize someone to publish FSNs/FSLs > >in some NSDB is to authorize them to create unlimited amounts of > >garbage. Garbage collection being effectively impossible, the fact that > >authorization to publish is also authorization to consume all resources > >seems like a problem to me. One might want to implement resource > >controls at NSDBs ("Joe can create FSNs and FSLs in this NSDB, at the > >rate of 10 objects per-day" or "Jane can create up to 100 FSNs and FSLs > >in this NSDB"). > > I don't know enough about NFSv4's intended model to know if that's actually > a problem. In AFS, the equivalent objects are entries in the volume > location database, only administrators get the power to create them, and > they are tied fairly tightly to volumes. The resource you worry about > people exhausting is the disk space occupied by volumes, not VLDB entries. > What's not clear to me is whether the NFSv4 NSDB's are intended to be > similar, or whether the intent is that relatively unprivileged users be > able to create arbitrary entries. The admins for some file server need not be the same as the admins for some NSDB. One possible practice is to have an NSDB per-file server in which to store FSLs, but FSNs really belong in a replicated DB. I expect that in practice there will be an NSDB per-site/domain and that NSDB will grant object create writes, in the o=fedfs container, to all file server admins in that site/domain. This is a rather minor concern. I think it merits a mention though. > >One might also wish to have an optional way to document in an FSN the > >paths to junctions that are expected to reference the FSNs Similarly, > >an optional way to document in an FSL the FSNs that are expected to > >reference the FSL. Not that such documentation would be sufficient to > >make garbage collection possible; it'd only make it feasible to check > >_intended_ references. > > That does sound like a useful feature. In practice, intended references > are the ones you care about; if you decide a resource is going away, then > anyone else who has unexpected references just loses. > > That said, one of the common problems AFS administrators run into is trying > to enumerate all of the mount points, other than by doing a find-style > traversal of the entire filesystem. It would be cool to see some sort of > answer to this problem in NFS. I agree. What do the authors think? Nico -- From bew@cisco.com Fri Oct 2 15:25:52 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 4A3B33A6861; Fri, 2 Oct 2009 15:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwz1Z6mWn8Lr; Fri, 2 Oct 2009 15:25:51 -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 433973A682E; Fri, 2 Oct 2009 15:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1924; q=dns/txt; s=sjiport06001; t=1254522440; x=1255732040; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Brian=20Weis=20|Subject:=20Secdir =20review=20of=20draft-ietf-mipshop-pfmipv6-09|Date:=20Fr i,=202=20Oct=202009=2015:27:17=20-0700|Message-Id:=20<49F 4ED8C-6275-433E-9B57-36FD713BD7B8@cisco.com>|To:=20secdir @ietf.org,=20iesg@ietf.org|Cc:=20draft-ietf-mipshop-pfmip v6@tools.ietf.org,=20mipshop-chairs@tools.ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit; bh=GW607npw6m2u4eTTVAzY7sdoA2CQ4zz26KwO61UZFIg=; b=cbndWVsLgczPY8AnkMqfPPES3/OqJF05aJ6rloxPRQjKjhxUbsh5Dw3l EXHQxizKhQWD7H1PZyZ7KBzeQPAAboQesS+dIfo3QlCjTn0VbsP1+flRy i2fkXKxBr/mXuJnTicFkc9zBBw/vD5BP95Hyp+c0Fp/9w61cmNEG52wR3 A=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=bew@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJsaxkqrR7O6/2dsb2JhbAC+E4hbATIJjmsGgkuBYYFW X-IronPort-AV: E=Sophos;i="4.44,497,1249257600"; d="scan'208";a="401088810" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2009 22:27:19 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n92MRJOn003395; Fri, 2 Oct 2009 15:27:19 -0700 Received: from dhcp-128-107-163-96.cisco.com (dhcp-128-107-163-96.cisco.com [128.107.163.96]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n92MRJ8s006549; Fri, 2 Oct 2009 22:27:19 GMT Message-Id: <49F4ED8C-6275-433E-9B57-36FD713BD7B8@cisco.com> From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Oct 2009 15:27:17 -0700 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1924; t=1254522439; x=1255386439; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Secdir=20review=20of=20draft-ietf-mipshop-pfmip v6-09 |Sender:=20; bh=GW607npw6m2u4eTTVAzY7sdoA2CQ4zz26KwO61UZFIg=; b=1QxSvdmvDY6YEex2Q1VwHVy38HcQglakyh1RN3JGz/AxZUtCIHMfkpm48e XCmYw3pEQCHtl1vLnk+Jk75a87d1rWcta5L9oh/rHbt2v4i8IWghJ7k05Dbm F/zG9NqM4z; Cc: mipshop-chairs@tools.ietf.org, draft-ietf-mipshop-pfmipv6@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-mipshop-pfmipv6-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 22:25:52 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds Proxy-based Fast Handover to Mobile IPv6 (MIPv6). It allows fast handover of a mobile device between mobile access gateway's without the mobile node itself being involved. The document primarily reuses messages flows from a previously defined handover method (RFC 5568), and Proxy Mobile IPv6 (RFC 5213). It also depends on the Security Considerations from RFC 5213 and RFC 5568, which seems appropriate given that the same message flows are used between the same network entities. These existing RFCs describe IPsec ESP as the method for protecting messages, and include details in setting up the SPD and PAD. I believe pointing to those documents for security consideration guidance is generally acceptable. There is one new message flow, which is the forwarding of data packet from the previous mobile access gateway (PMAG) to the next mobile access gateway (NMAG) during transition. The last paragraph in the security considerations section notes that these packets MAY be encrypted with IPsec "if protection of data traffic is required". A better statement might be that they SHOULD be encrypted if the link between the PMAG and NMAG exposes the MN packets to more threats than if they had followed their normal routed path. (One miscellaneous comment: It would be helpful to readers if you added a definition of "Local Mobility Anchor" to the Terminology section.) Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From weiler+secdir@watson.org Fri Oct 2 22:33: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 1C9983A6882 for ; Fri, 2 Oct 2009 22:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 n12ERrJWMCgF for ; Fri, 2 Oct 2009 22:33:11 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A3E1828C0CE for ; Fri, 2 Oct 2009 22:33: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 n935YcYD021942 for ; Sat, 3 Oct 2009 01:34:38 -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 n935Ycg6021938 for ; Sat, 3 Oct 2009 01:34:38 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 3 Oct 2009 01:34:38 -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]); Sat, 03 Oct 2009 01:34:39 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 05:33:12 -0000 There are 14 new assignments this week. Catherine Meadows is next in the rotation. Please try to complete last call reviews by the end of the last call. For documents on telechat, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-10-08 Reviewer Deadline Draft Dave Cridland T 2009-10-06 draft-ietf-ipsecme-ikev2-ipv6-config-02 Alan DeKok TR2009-10-06 draft-ietf-roll-home-routing-reqs-08 Tobias Gondrom T 2009-10-06 draft-ietf-mpls-tp-nm-req-05 Phillip Hallam-Baker T 2009-10-06 draft-ietf-pmol-sip-perf-metrics-04 Phillip Hallam-Baker T 2009-10-06 draft-ietf-mpls-tp-oam-requirements-03 Sandy Murphy T 2009-10-06 draft-ietf-speermint-voip-consolidated-usecases-14 Sandy Murphy T 2009-10-06 draft-ietf-rtgwg-ipfrr-framework-12 Chris Newman T 2009-10-06 draft-ietf-mboned-lightweight-igmpv3-mldv2-05 Yaron Sheffer TR2009-10-06 draft-ietf-msec-tesla-for-alc-norm-08 Sam Weiler T 2009-10-06 draft-ietf-eai-downgraded-display-02 For telechat 2009-10-22 Reviewer Deadline Draft Steve Hanna T 2009-10-20 draft-ietf-krb-wg-cross-problem-statement-04 Dan Harkins T 2009-10-20 draft-ietf-dhc-relay-id-suboption-07 David Harrington T 2009-10-20 draft-ietf-dhc-vpn-option-11 Last calls and special requests: Reviewer Deadline Draft Rob Austein 2009-10-07 draft-reschke-rfc2731bis-02 Pat Cain 2009-09-30 draft-ietf-vcarddav-carddav-09 Ran Canetti 2009-09-28 draft-ietf-sasl-scram-08 Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-01 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-03 Donald Eastlake None draft-ietf-geopriv-held-identity-extensions-00 Shawn Emery 2009-08-04 draft-ietf-alto-problem-statement-04 Shawn Emery 2009-10-05 draft-ietf-mpls-tp-gach-dcn-06 Stephen Farrell 2009-09-07 draft-ietf-tls-rfc4366-bis-05 Steve Hanna 2009-10-05 draft-ietf-pkix-sha2-dsa-ecdsa-08 Sam Hartman 2009-10-15 draft-ietf-idnabis-bidi-06 Paul Hoffman 2009-10-15 draft-ietf-idnabis-defs-11 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-04 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-16 Charlie Kaufman 2009-10-13 draft-ietf-idnabis-rationale-13 Scott Kelly 2009-10-15 draft-ietf-idnabis-tables-07 Stephen Kent 2009-10-14 draft-ietf-mmusic-connectivity-precon-06 Tero Kivinen 2009-10-14 draft-ietf-mmusic-rfc3388bis-03 Julien Laganier 2009-01-22 draft-ietf-sip-certs-09 Julien Laganier 2009-06-09 draft-ietf-enum-3761bis-04 Julien Laganier 2009-10-14 draft-ietf-ospf-af-alt-08 Barry Leiba 2009-10-14 draft-ietf-ospf-te-node-addr-06 Chris Lonvick 2009-10-26 draft-melnikov-sasl-scram-ldap-03 David McGrew 2009-10-28 draft-weiler-rsync-uri-01 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-10-07 draft-carpenter-renum-needs-work-03 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-04 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 Glen Zorn 2009-09-17 draft-ietf-rohc-ikev2-extensions-hcoipsec-09 From charliek@microsoft.com Mon Oct 5 13:33: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 74C6B3A6985; Mon, 5 Oct 2009 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 BiW+DEkW9A1N; Mon, 5 Oct 2009 13:33:35 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C5B803A6A35; Mon, 5 Oct 2009 13:33:35 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Oct 2009 13:35:15 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.58]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Mon, 5 Oct 2009 13:35:08 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "john+ietf@jck.com" , "vint@google.com" , "d3e3e3@gmail.com" , "idna-update@alvestrand.no" Thread-Topic: secdir review of draft-ietf-idnabis-rationale-13.txt Thread-Index: AcpF+1K5weWnWdVzQdy31RKVnjmSPA== Date: Mon, 5 Oct 2009 20:35:06 +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_D80EDFF2AD83E648BD1164257B9B091208282265TK5EX14MBXC115r_" MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 20:33:38 -0000 --_000_D80EDFF2AD83E648BD1164257B9B091208282265TK5EX14MBXC115r_ 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 I-D is part of a set of I-D's that update the RFCs on Internationalize= d Domain Names. This document is intended to become an Informational RFC an= d provides a rationale for the proposed changes (as well as for the initial= design of IDNA). Its Security Considerations section defers to draft-ietf-= idnabis-defs-11.txt, which has a good Security Considerations section. In my opinion, the change to IDNs that warrants the most concern is the fac= t that for some IDNs the new set of RFCs will specify a different represent= ation than the old one did. This could in theory cause security problems, t= hough that seems intuitively unlikely (to me, at least). I would question one statement in the document. >From Section 8.2: In the presence of DNSSEC, no form of a zone file or query response that co= ntains a U-label may be signed or the signature validated. [a U-label indicates a name form containing non-ASCII characters not proper= ly encoded with IDN]. I would expect that DNSSEC would operate at the layer below IDN, and could = therefore sign and validate any data that DNS could validly return. There m= ay be subtle reason for this restriction that I don't understand, but the j= ustification in the document didn't seem right. --Charlie --_000_D80EDFF2AD83E648BD1164257B9B091208282265TK5EX14MBXC115r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am reviewing this document as part of t= he 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 chai= rs should treat these comments just like any other last call comments. Feel= free to forward to any appropriate forum.

 

This I-D is part of a s= et of I-D’s that update the RFCs on Internationalized Domain Names. T= his document is intended to become an Informational RFC and provides a rati= onale for the proposed changes (as well as for the initial design of IDNA).= Its Security Considerations section defers to draft-ietf-idnabis-defs-11.t= xt, which has a good Security Considerations section.

 

In my opinion, the = change to IDNs that warrants the most concern is the fact that for some IDN= s the new set of RFCs will specify a different representation than the old = one did. This could in theory cause security problems, though that seems in= tuitively unlikely (to me, at least).

 

I would question one statement in t= he document.

 

From Section 8.2:

&n= bsp;

In the presence of DNSSEC, no form of a = zone file or query response that contains a U-label may be signed or the si= gnature validated.

 

=

[a U-label indicates a name form containing non-ASCII = characters not properly encoded with IDN].

 

I would expect that DNSSEC wou= ld operate at the layer below IDN, and could therefore sign and validate an= y data that DNS could validly return. There may be subtle reason for this r= estriction that I don’t understand, but the justification in the docu= ment didn’t seem right.

 = ;

       &= nbsp;        --Charlie

= --_000_D80EDFF2AD83E648BD1164257B9B091208282265TK5EX14MBXC115r_-- From ajs@shinkuro.com Mon Oct 5 13:55: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 B0DE33A698B; Mon, 5 Oct 2009 13:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.471, 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 uZb2UCzo5dOB; Mon, 5 Oct 2009 13:55:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 0881F3A68FF; Mon, 5 Oct 2009 13:55:07 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 704402FE8CA1; Mon, 5 Oct 2009 20:56:42 +0000 (UTC) Date: Mon, 5 Oct 2009 16:56:40 -0400 From: Andrew Sullivan To: Vint Cerf Message-ID: <20091005205639.GT25543@shinkuro.com> References: <83AA9570-4B1A-4D3A-A9F1-CE73E18B4DFC@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83AA9570-4B1A-4D3A-A9F1-CE73E18B4DFC@google.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "secdir@ietf.org" , "john+ietf@jck.com" , "idna-update@alvestrand.no" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 20:55:09 -0000 On Mon, Oct 05, 2009 at 04:39:44PM -0400, Vint Cerf wrote: > i think the point was precisely that DNSSEC should operate at DNS level > (using only LDH-form domain names or, in IDNA2008 parlance, A-labels. No > other form of label valid under IDNA2008 (such as a U-label) should be > used in conjunction with DNSSEC. > > If I have not quite got that right I am sure my colleagues on IDNA- > UPDATE with correct me. That's exactly right. DNSSEC operates on DNS responses, which are required to be A-labels. Therefore, DNSSEC is completely unaffected by IDNA. I think it would be a bad idea to add anything to any section, including the security considerations section, that made any remarks specifically about DNSSEC. If someone really wanted to add something about the effects of IDNA on the security of the DNS _as such_ (rather than the use of labels as humnans understand them), I'd suggest instead somethign to the following effect: "IDNA operates at a level above DNS, and therefore does not affect the security of the DNS protocols. Security issues in the DNS protocols are also security issues for IDNA, because IDNA depends on the DNS." Or something like that. (But I don't think adding anything is a good idea.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From tobias.gondrom@gondrom.org Mon Oct 5 14:04: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 65A883A67ED; Mon, 5 Oct 2009 14:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 jNbRYb0RjKzA; Mon, 5 Oct 2009 14:04:36 -0700 (PDT) Received: from leela.webpack.hosteurope.de (leela.webpack.hosteurope.de [217.115.142.65]) by core3.amsl.com (Postfix) with ESMTP id 4B0813A67E4; Mon, 5 Oct 2009 14:04:36 -0700 (PDT) Received: from 78-86-27-62.zone2.bethere.co.uk ([78.86.27.62] helo=[192.168.1.64]); authenticated by leela.webpack.hosteurope.de running ExIM with esmtpa id 1Muukz-0002mV-Re; Mon, 05 Oct 2009 23:06:09 +0200 Message-ID: <4ACA5FC1.1050704@gondrom.org> Date: Mon, 05 Oct 2009 22:06:09 +0100 From: Tobias Gondrom User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de; tobias.gondrom@gondrom.org; 1254776772; ba683aab; Cc: swallow@cisco.com, tim.polk@nist.gov, Pasi.Eronen@nokia.com, Scott.Mansfield@Ericsson.com, adrian.farrel@huawei.com, loa@pi.nu, hklam@Alcatel-Lucent.com, Eric.Gray@Ericsson.com Subject: [secdir] Secdir review of draft-ietf-mpls-tp-nm-req-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: Mon, 05 Oct 2009 21:04:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 0. From the security perspective, the requirements in this document appear to be sufficient, though not very detailed. As it's a requirments doc, this is ok. Obviously, I assume following specifications will be more detailed in how the described security requirments are satisfied. 1. DISCUSS: Question: as the document describes requirements and is in wide areas unprecise in how they shall be implemented I wonder why it aims to be “Standards Track” and not “Informational”? 2. COMMENT: Question: section Terminology: “Fault: A fault is the inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions (from [21], 3.26).” Why does a lack of external resources not constitute a fault? (the other two reasons I can understand but this one not? 3. COMMENT: section 5.2: “The MPLS-TP NE MUST perform persistency checks on fault causes before it declares a fault cause a failure.” I am not sure whether a “SHOULD” would be more appropriate here: First, depending on the type of fault a NE my consider a failure after the first fault cause and Second, two paragraphs below, you speak of configurable time “A data-plane forwarding path failure MUST be declared if the fault cause persists continuously for a configurable time (Time-D). The failure MUST be cleared if the fault cause is absent continuously for a configurable time (Time-C).” if it is configurable, it may also be configured to infinite small, which kind of contradicts with the “MUST” for persistency check? 4. COMMENT: Section 5.3.2: Question: should this “An MPLS-TP NE MUST support suppression of alarms based on configuration.” be changed to “An MPLS-TP NE MUST support suppression of alarms based on configuration and for a limited time.” Or do you may not want to allow infinite and unlimited suppression of alarms? 6. s/An MPLS-TP NE MUST support secure management protocols and SHOULD do so in a manner the reduce potential impact of a DoS attack./An MPLS-TP NE MUST support secure management protocols and SHOULD do so in a manner that reduces potential impact of a DoS attack. Kind regards, Tobias Tobias Gondrom email: tobias.gondrom@gondrom.org From phoffman@imc.org Mon Oct 5 14:07:47 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 17EA028C20B for ; Mon, 5 Oct 2009 14:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 DpIkmmqk0nYv for ; Mon, 5 Oct 2009 14:07:46 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 71E6F3A67E4 for ; Mon, 5 Oct 2009 14:07:42 -0700 (PDT) Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n95L9GLu049821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 14:09:17 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Oct 2009 14:08:31 -0700 To: Charlie Kaufman , "secdir@ietf.org" , "iesg@ietf.org" , "john+ietf@jck.com" , "vint@google.com" , "d3e3e3@gmail.com" , "idna-update@alvestrand.no" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 21:07:47 -0000 At 8:35 PM +0000 10/5/09, Charlie Kaufman wrote: >I would question one statement in the document. > >From Section 8.2: > >In the presence of DNSSEC, no form of a zone file or query response that contains a U-label may be signed or the signature validated. > >[a U-label indicates a name form containing non-ASCII characters not properly encoded with IDN]. > >I would expect that DNSSEC would operate at the layer below IDN, and could therefore sign and validate any data that DNS could validly return. There may be subtle reason for this restriction that I don't understand, but the justification in the document didn't seem right. Note that the sentences before the one that you flagged are: IDNA specifies that all internationalized domain names served by DNS servers that cannot be represented directly in ASCII MUST use the A-label form. Conversion to A-labels MUST be performed prior to a zone being signed by the private key for that zone. Because of this ordering, it is important to recognize that DNSSEC authenticates a domain name containing A-labels or conventional LDH-labels, not U-labels. The sentence that you flagged is just plain confusing and can be elided without loss of value to the document. From charliek@microsoft.com Mon Oct 5 14:38: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 861A928C24C; Mon, 5 Oct 2009 14:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbJCVhFJGAF0; Mon, 5 Oct 2009 14:38:39 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 93B2628C0F3; Mon, 5 Oct 2009 14:38:39 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Oct 2009 14:40:18 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.58]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Mon, 5 Oct 2009 14:40:14 -0700 From: Charlie Kaufman To: Paul Hoffman , "secdir@ietf.org" , "iesg@ietf.org" , "john+ietf@jck.com" , "vint@google.com" , "d3e3e3@gmail.com" , "idna-update@alvestrand.no" Thread-Topic: secdir review of draft-ietf-idnabis-rationale-13.txt Thread-Index: AQHKRf/9weWnWdVzQdy31RKVnjmSPJD3ewag Date: Mon, 5 Oct 2009 21:40:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 21:38:40 -0000 I considered putting in more context, but decided against it (clearly a mis= take). IDNA specifies that all internationalized domain names served by DNS use th= e IDNA encoding, but the DNS spec does not. So the full statement in the dr= aft appears to be saying that a DNS zone that does not use IDNA cannot use = DNSSEC (in the sense of it wouldn't work as opposed to it MUST NOT). I cann= ot figure out why that would be true, though as I said there may be some su= btlety I'm missing. I agree with Andrew that I can't see why this document = should mention DNSSEC at all. --Charlie -----Original Message----- From: Paul Hoffman [mailto:phoffman@imc.org]=20 Sent: Monday, October 05, 2009 2:09 PM To: Charlie Kaufman; secdir@ietf.org; iesg@ietf.org; john+ietf@jck.com; vin= t@google.com; d3e3e3@gmail.com; idna-update@alvestrand.no Subject: Re: secdir review of draft-ietf-idnabis-rationale-13.txt At 8:35 PM +0000 10/5/09, Charlie Kaufman wrote: >I would question one statement in the document. >=20 >From Section 8.2: >=20 >In the presence of DNSSEC, no form of a zone file or query response that c= ontains a U-label may be signed or the signature validated. >=20 >[a U-label indicates a name form containing non-ASCII characters not prope= rly encoded with IDN]. >=20 >I would expect that DNSSEC would operate at the layer below IDN, and could= therefore sign and validate any data that DNS could validly return. There = may be subtle reason for this restriction that I don't understand, but the = justification in the document didn't seem right. Note that the sentences before the one that you flagged are: IDNA specifies that all internationalized domain names served by DNS servers that cannot be represented directly in ASCII MUST use the A-label form. Conversion to A-labels MUST be performed prior to a zone being signed by the private key for that zone. Because of this ordering, it is important to recognize that DNSSEC authenticates a domain name containing A-labels or conventional LDH-labels, not U-labels.=20 The sentence that you flagged is just plain confusing and can be elided wit= hout loss of value to the document. From duerst@it.aoyama.ac.jp Mon Oct 5 18:25: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 7EACA28C174 for ; Mon, 5 Oct 2009 18:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 bL9rWZloQwHo for ; Mon, 5 Oct 2009 18:25:38 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 9FBE53A6A3D for ; Mon, 5 Oct 2009 18:25:38 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n961RDkn012409 for ; Tue, 6 Oct 2009 10:27:13 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5110_6052bb1a_b217_11de_a356_001d096c5782; Tue, 06 Oct 2009 10:27:13 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49829) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 6 Oct 2009 10:23:53 +0900 Message-ID: <4ACA9CE4.2050306@it.aoyama.ac.jp> Date: Tue, 06 Oct 2009 10:27:00 +0900 From: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Vint Cerf References: <83AA9570-4B1A-4D3A-A9F1-CE73E18B4DFC@google.com> In-Reply-To: <83AA9570-4B1A-4D3A-A9F1-CE73E18B4DFC@google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "secdir@ietf.org" , "john+ietf@jck.com" , "idna-update@alvestrand.no" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 01:25:40 -0000 I think what Charlie means is that there may be entries in the domain name system that are completely binary, and that it would be inappropriate for IDNA to prohibit such entries. I think this is okay, because the flagged text refers to U-Labels, not binary data in general. Regards, Martin. On 2009/10/06 5:39, Vint Cerf wrote: > i think the point was precisely that DNSSEC should operate at DNS level > (using only LDH-form domain names or, in IDNA2008 parlance, A-labels. No > other form of label valid under IDNA2008 (such as a U-label) should be > used in conjunction with DNSSEC. > > If I have not quite got that right I am sure my colleagues on > IDNA-UPDATE with correct me. > > vint > > > On Oct 5, 2009, at 4:35 PM, Charlie Kaufman wrote: > >> 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 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. Feel free to >> forward to any appropriate forum. >> >> This I-D is part of a set of I-Ds that update the RFCs on >> Internationalized Domain Names. This document is intended to become an >> Informational RFC and provides a rationale for the proposed changes >> (as well as for the initial design of IDNA). Its Security >> Considerations section defers to draft-ietf-idnabis-defs-11.txt, which >> has a good Security Considerations section. >> >> In my opinion, the change to IDNs that warrants the most concern is >> the fact that for some IDNs the new set of RFCs will specify a >> different representation than the old one did. This could in theory >> cause security problems, though that seems intuitively unlikely (to >> me, at least). >> >> I would question one statement in the document. >> >> From Section 8.2: >> >> In the presence of DNSSEC, no form of a zone file or query response >> that contains a U-label may be signed or the signature validated. >> >> [a U-label indicates a name form containing non-ASCII characters not >> properly encoded with IDN]. >> >> I would expect that DNSSEC would operate at the layer below IDN, and >> could therefore sign and validate any data that DNS could validly >> return. There may be subtle reason for this restriction that I dont >> understand, but the justification in the document didnt seem right. >> >> --Charlie > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update -- #-# Martin J. Drst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From vint@google.com Mon Oct 5 13:38: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 F1BCE3A6A34; Mon, 5 Oct 2009 13:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.531 X-Spam-Level: X-Spam-Status: No, score=-104.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njpoeFf3xgYH; Mon, 5 Oct 2009 13:38:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C7FEB3A67ED; Mon, 5 Oct 2009 13:38:18 -0700 (PDT) Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id n95KdqIg017598; Mon, 5 Oct 2009 13:39:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254775192; bh=TEN/3Dsjavhjdff2frYUzsw4hcs=; h=DomainKey-Signature:Cc:Message-Id:From:To:In-Reply-To: Content-Type:Mime-Version:Subject:Date:References:X-Mailer: X-System-Of-Record; b=mMzxV7iYSUIj3mFB7lz/P0G/AihvxEOo/9O2mXdlRtlI 9HF0eUKfFMg8M44AIPNeomZSUizlOj7kc4MjT2y74w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=cc:message-id:from:to:in-reply-to:content-type: mime-version:subject:date:references:x-mailer:x-system-of-record; b=PST0O8V0pT3zKbQ+Or3Il6y5SK6dIIxRpOELizsPDlta4YBTVzTUlbY4fl2K66KVi faebE6LWUJcsVAaCjoTGA== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by zps78.corp.google.com with ESMTP id n95Kdnvx011310; Mon, 5 Oct 2009 13:39:50 -0700 Received: by qyk9 with SMTP id 9so6063759qyk.30 for ; Mon, 05 Oct 2009 13:39:49 -0700 (PDT) Received: by 10.224.13.131 with SMTP id c3mr586176qaa.312.1254775189033; Mon, 05 Oct 2009 13:39:49 -0700 (PDT) Received: from 125.20.242.10.in-addr.arpa (mc75f36d0.tmodns.net [208.54.95.199]) by mx.google.com with ESMTPS id 23sm39982yxe.8.2009.10.05.13.39.47 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Oct 2009 13:39:48 -0700 (PDT) Message-Id: <83AA9570-4B1A-4D3A-A9F1-CE73E18B4DFC@google.com> From: Vint Cerf To: Charlie Kaufman In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-39--557405454 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Oct 2009 16:39:44 -0400 References: X-Mailer: Apple Mail (2.936) X-System-Of-Record: true X-Mailman-Approved-At: Mon, 05 Oct 2009 22:48:14 -0700 Cc: "john+ietf@jck.com" , "idna-update@alvestrand.no" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 20:38:20 -0000 --Apple-Mail-39--557405454 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable i think the point was precisely that DNSSEC should operate at DNS =20 level (using only LDH-form domain names or, in IDNA2008 parlance, A-=20 labels. No other form of label valid under IDNA2008 (such as a U-=20 label) should be used in conjunction with DNSSEC. If I have not quite got that right I am sure my colleagues on IDNA-=20 UPDATE with correct me. vint On Oct 5, 2009, at 4:35 PM, Charlie Kaufman wrote: > I am reviewing this document as part of the security directorate's =20 > ongoing effort to review all IETF documents being processed by the =20 > IESG. These comments were written primarily for the benefit of the =20= > security area directors. Document editors and WG chairs should =20 > treat these comments just like any other last call comments. Feel =20 > free to forward to any appropriate forum. > > This I-D is part of a set of I-D=92s that update the RFCs on =20 > Internationalized Domain Names. This document is intended to become =20= > an Informational RFC and provides a rationale for the proposed =20 > changes (as well as for the initial design of IDNA). Its Security =20 > Considerations section defers to draft-ietf-idnabis-defs-11.txt, =20 > which has a good Security Considerations section. > > In my opinion, the change to IDNs that warrants the most concern is =20= > the fact that for some IDNs the new set of RFCs will specify a =20 > different representation than the old one did. This could in theory =20= > cause security problems, though that seems intuitively unlikely (to =20= > me, at least). > > I would question one statement in the document. > > =46rom Section 8.2: > > In the presence of DNSSEC, no form of a zone file or query response =20= > that contains a U-label may be signed or the signature validated. > > [a U-label indicates a name form containing non-ASCII characters not =20= > properly encoded with IDN]. > > I would expect that DNSSEC would operate at the layer below IDN, and =20= > could therefore sign and validate any data that DNS could validly =20 > return. There may be subtle reason for this restriction that I don=92t = =20 > understand, but the justification in the document didn=92t seem right. > > --Charlie --Apple-Mail-39--557405454 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable i think the point was precisely = that DNSSEC should operate at DNS level (using only LDH-form domain = names or, in IDNA2008 parlance, A-labels. No other form of label valid = under IDNA2008 (such as a U-label) should be used in conjunction with = DNSSEC.

If I have not quite got that right I am sure = my colleagues on IDNA-UPDATE with correct = me.

vint


O= n Oct 5, 2009, at 4:35 PM, Charlie Kaufman wrote:

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 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. Feel free to forward to any appropriate = forum.
 
In my opinion, the change to IDNs = that warrants the most concern is the fact that for some IDNs the new = set of RFCs will specify a different representation than the old one = did. This could in theory cause security problems, though that seems = intuitively unlikely (to me, at least).
I would question one statement in = the document.
 
 
 
I would expect that DNSSEC would = operate at the layer below IDN, and could therefore sign and validate = any data that DNS could validly return. There may be subtle reason for = this restriction that I don=92t understand, but the justification in the = document didn=92t seem right.
X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5100D3A67CC; Mon, 5 Oct 2009 19:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 8K4G7qgQ3Kxo; Mon, 5 Oct 2009 19:19:14 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 6AE4C28C2C2; Mon, 5 Oct 2009 19:19:04 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MuzfF-0009XI-VD; Mon, 05 Oct 2009 22:20:34 -0400 Date: Mon, 05 Oct 2009 22:20:33 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Vint Cerf Message-ID: <75EDECD28B7D9CA9FB6DE684@PST.JCK.COM> In-Reply-To: <4ACA9CE4.2050306@it.aoyama.ac.jp> References: <83AA9570-4B1A-4D3A-A9F1-CE73E18B4DFC@google.com> <4ACA9CE4.2050306@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Mon, 05 Oct 2009 22:48:14 -0700 Cc: idna-update@alvestrand.no, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 02:19:15 -0000 --On Tuesday, October 06, 2009 10:27 +0900 "\"Martin J. D=C3=BCrst\"" wrote: > I think what Charlie means is that there may be entries in the > domain name system that are completely binary, and that it > would be inappropriate for IDNA to prohibit such entries. I > think this is okay, because the flagged text refers to > U-Labels, not binary data in general. IDNA doesn't -- it applies only to IDNA-aware and -conformant systems and name lookups which, by definition, do not involve binary labels. john From charliek@microsoft.com Tue Oct 6 00:31:49 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 BEE5C28B56A; Tue, 6 Oct 2009 00:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF2t6sDHmhT6; Tue, 6 Oct 2009 00:31:48 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B5A2F3A6AAA; Tue, 6 Oct 2009 00:31:48 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Oct 2009 00:33:29 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.58]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Tue, 6 Oct 2009 00:33:24 -0700 From: Charlie Kaufman To: John C Klensin , Paul Hoffman , "secdir@ietf.org" , "iesg@ietf.org" , "vint@google.com" , "d3e3e3@gmail.com" , "idna-update@alvestrand.no" Thread-Topic: secdir review of draft-ietf-idnabis-rationale-13.txt Thread-Index: AQHKRf/9weWnWdVzQdy31RKVnjmSPJD3ewaggACi4YD///9U8A== Date: Tue, 6 Oct 2009 07:33:19 +0000 Message-ID: References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> In-Reply-To: <17823AE7FE62B8814BE101BF@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 07:31:49 -0000 My reading of the IDNA spec was that no query response would ever contain a= U-label, and therefore saying that if the query response did contain a U-l= abel then DNSSEC couldn't sign or verify it seems nonsensical. I believe th= at DNSSEC is more like part of DNS than up at the layer of IDNA; it can sig= n anything that DNS can return. I believe the DNSSEC spec says that what is signed is the "wire form" of th= e name, which should be unambiguous unless different wire forms are used in= different contexts in the DNS protocol. For DNS servers following IDNA, th= e wire form would always be an A-label or an LDH-label. I could easily believe that there are problems when DNSSEC interacts with n= on-IDNA compliant names (either because the term "wire form" was ambiguous = in some contexts or because the DNSSEC spec did not consistently use that t= erminology). But I haven't heard anyone claim that yet. --Charlie -----Original Message----- From: John C Klensin [mailto:klensin@jck.com]=20 Sent: Monday, October 05, 2009 5:17 PM To: Charlie Kaufman; Paul Hoffman; secdir@ietf.org; iesg@ietf.org; vint@goo= gle.com; d3e3e3@gmail.com; idna-update@alvestrand.no Subject: RE: secdir review of draft-ietf-idnabis-rationale-13.txt --On Monday, October 05, 2009 21:40 +0000 Charlie Kaufman wrote: > I considered putting in more context, but decided against it (clearly=20 > a mistake). >=20 > IDNA specifies that all internationalized domain names served by DNS=20 > use the IDNA encoding, but the DNS spec does not. So the full=20 > statement in the draft appears to be saying that a DNS zone that does=20 > not use IDNA cannot use DNSSEC (in the sense of it wouldn't work as=20 > opposed to it MUST NOT). I cannot figure out why that would be true,=20 > though as I said there may be some subtlety I'm missing. I agree with=20 > Andrew that I can't see why this document should mention DNSSEC at=20 > all. Charlie, Thanks for the careful reading. Let me respond as holder of the pen (but o= ne who has put a lot of stuff into the document because the WG apparently w= anted it rather than because I was convinced it was necessary). There are at least two things going on here: (1) As a collection, the IDNA documents have a number of requirements that = are (or should be) stated as "if you sign up for IDNA, then you are require= d to behave this way". If anything appears to impose requirements on DNS i= mplementations, zones, or other features except in that "conforming to IDNA= " context, then it is unintended and almost certainly needs to be fixed. Som= etimes that constraint is present in order to make sure that future extensi= ons that use a "this prefix means something special" can occur without caus= ing problems for IDNA or being mutually exclusive, rather than because of a= n immediate need of IDNA as reflected in this set of documents. However, it turns out to be harder to impose and describe those constraints than one= might expect, so some of the instances of it may be convoluted. That said, IDNA cannot impose constraints on binary labels used in non-IDNA= -aware implementations. It has been clear since the dawn of the DNS, and c= ertainly since RFC 2181, that arbitrary octet strings are permitted to appe= ar in zones and in queries. Such octet strings can certainly be UTF-8 or ISO 8859-1; they can even be, = e.g., UTF-16 (UCS-2) in spite of the chaos that would cause for application= s that assumed they could use null octets as string terminators without bei= ng careful about it. However, whatever such labels might be, they aren't IDNA-conformant IDNs or= , as far as IETF Standards are concerned, IDNs at all. (2) As far as DNSSEC is concerned, you are quite correct: nothing in IDNA has anything to do with it. The text is there for two reas= ons: (i) Someone thought it important enough to mention and insisted that we do = so. It wasn't me. (ii) The "two (or more) representations of the same logical label" design t= hat underlies IDNA (both the new version and the old one) creates some odd = ambiguities with regard to many protocols and namespaces (see draft-iab-idn= -encoding for an evolving discussion of some of those issues). In some cas= es, one pretty much has to use the A-label (ACE-encoded) form. In others, = the U-label (native Unicode characters) form is anticipated and required. = Still others may be flexible. When I discussed IDNABIS at a SAAG meeting s= ome time ago, I was treated to an extended discussion (during and after the= meeting itself) about whether certificates and other credentials should ke= ep and interpret information in ACE (A-label) form or as native-character U= nicode strings and about the importance of being able to convert from dot-s= eparated labels to length-label pair form other than as part of calls to th= e DNS because some credentials were kept in the latter form. At least for = a while, some of us anticipated DNS servers that would accept zone files wi= th IDNs in U-label form as input and automagically do the conversion to A-l= abels, presumably performing IDNA validation as part of that process. =20 Is it desirable in that context to say "don't even think about computing DN= SSEC values on anything but the A-label" or "because the A-label is the onl= y thing an IDNA-conforming program can put in, or look up in, a zone, DNSSE= C is not affected"? I really don't know... and am certainly happy to make = whatever changes in those explanations that the community thinks appropriat= e. john From aland@deployingradius.com Tue Oct 6 02:48: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 09EDE28C16F; Tue, 6 Oct 2009 02:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_40=-0.185, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrZjPZwxas8L; Tue, 6 Oct 2009 02:48:29 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id DDEC028C16A; Tue, 6 Oct 2009 02:48:28 -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 7AD3412344AA; Tue, 6 Oct 2009 11:50:03 +0200 (CEST) Message-ID: <4ACB12CB.4040104@deployingradius.com> Date: Tue, 06 Oct 2009 11:50:03 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: secdir@ietf.org, IESG IESG , abr@zen-sys.com, jbu@zen-sys.com, giorgio.porcu@guest.telecomitalia.it References: <49903AFA.8020008@deployingradius.com> In-Reply-To: <49903AFA.8020008@deployingradius.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] SECDIR review of draft-ietf-roll-home-routing-reqs 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, 06 Oct 2009 09:48:30 -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 message is my updated review of the -08 version of the document. The original review is included below for completeness. The Security Considerations section of the document has been significantly improved. Both attacks and mitigation strategies are discussed. I have comments on that section. The current text is: ... The HC-LLN MUST deny any node that has not been authenticated to the HC-LLN and authorized to participate to the routing decision process. An attacker SHOULD be prevented from manipulating or disabling the routing function, for example, by compromising routing control messages. To this end, the routing protocol(s) MUST support message integrity. ... I'm not sure what the first SHOULD means in the second paragraph means. I would suggest combining and re-writing the two paragraphs to make the intent clearer: An attacker can snoop, replay, or originate arbitrary messages to a node in an attempt to manipulate or disable the routing function. To this end, the HC-LLN MUST authenticate a new node prior to allowing it to participate in the routing decision process. The routing protocol MUST support message integrity. I have no other comments. Alan DeKok wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document discusses the routing requirements for low-power and > lossy (e.g. "in-home") wireless networks. > > The document discusses the use of such networks to drive devices such > as lights, window shades, ... and health care reporting and monitoring. > The first sentence of the Security Considerations section says: > > Implementing security mechanisms in ROLL network devices may > degrade energy efficiency and increase cost. > > This sentence is simply inadequate, and shows that the priorities are > in the wrong place. > > If the methods outlined here are to be used in health care reporting > and monitoring, then device security must be a higher priority than > energy efficiency. The alternative is to design an "energy efficient" > device that is susceptible to attacks that cause illness or even death. > > The potential for abuse with cheap but insecure devices in healthcare > is so large as to be catastrophic for the people involved. The ability > to forge inaccurate values for (e.g.) insulin levels can result in > incorrect diagnosis and/or dosages. > > Different jurisdictions may also have legal restrictions on the use > and dissemination of healthcare information. Broadcasting data such as > insulin levels "in the clear" may be illegal. > > Even outside of the healthcare field, insecure protocols would allow > attackers to control window blinds, lights, and alarm systems. The side > effects here are possible voyeurism, robbery and/or home invasion. > Attacks on lights and other devices could lead to artificially increased > power bills, with side-effects ranging from increased debt to > law-enforcement suspicion that the home is being used to grow illegal crops. > > The second sentence of the Security Considerations section says: > > The routing protocol chosen for ROLL MUST allow for low-power, > low-cost network devices with limited security needs. > > Any device used for health care and/or home alarm systems CANNOT be > described as having "limited security needs". > > The third, and final, sentence of the Security Considerations section > says: > > Protection against unintentional inclusion in neighboring networks > MUST be provided. > > These requirements are inadequate for the stated purpose of the document. > > At the minimum, the protocol must protect against: > > - forgery of data from known devices > - alteration of data from known devices > - unauthorized commands from unknown control devices > - eavesdropping on private data > > These security requirements are difficult to meet. I recognize that > they may conflict with the desire to have cheap, low-power devices. > However, the potential for abuse, loss of property, and death due to > insecure devices is large, and cannot be ignored. > > Alan DeKok. > From vint@google.com Tue Oct 6 04:11:29 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 277473A6AC6; Tue, 6 Oct 2009 04:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce0qLBs2s+Dc; Tue, 6 Oct 2009 04:11:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 8E7043A6ACA; Tue, 6 Oct 2009 04:11:27 -0700 (PDT) Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id n96BD3gu019248; Tue, 6 Oct 2009 12:13:03 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254827583; bh=+lfeykz85C4x69lrEVgBPmbFyBc=; h=DomainKey-Signature:Cc:Message-Id:From:To:In-Reply-To: Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date: References:X-Mailer:X-System-Of-Record; b=GdL6SN8diAPE9xy6NSYDwXb5 DfVo7MURaOB1PImaOrrsbUBbkiBSLCIJqFWNYfT3jzykJ09ejWG6LIrLPWWYLA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=cc:message-id:from:to:in-reply-to:content-type: content-transfer-encoding:mime-version:subject:date:references:x-mailer:x-system-of-record; b=kQyv7sOMkUY/a4tXFXyUUgvem9RwOVwNaXLovL4wc907E6kitfjPdGs+y2FPBmxD+ beGjgY6tRdLR5WP0QeYJQ== Received: from pzk2 (pzk2.prod.google.com [10.243.19.130]) by spaceape9.eur.corp.google.com with ESMTP id n96BCwsf019469; Tue, 6 Oct 2009 04:12:59 -0700 Received: by pzk2 with SMTP id 2so1005875pzk.26 for ; Tue, 06 Oct 2009 04:12:58 -0700 (PDT) Received: by 10.115.117.13 with SMTP id u13mr2094381wam.150.1254827578248; Tue, 06 Oct 2009 04:12:58 -0700 (PDT) Received: from ?192.168.2.56? ([189.254.68.2]) by mx.google.com with ESMTPS id 23sm389608pxi.13.2009.10.06.04.12.55 (version=SSLv3 cipher=RC4-MD5); Tue, 06 Oct 2009 04:12:56 -0700 (PDT) Message-Id: <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> From: Vint Cerf To: Charlie Kaufman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Oct 2009 07:12:53 -0400 References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> X-Mailer: Apple Mail (2.936) X-System-Of-Record: true Cc: "secdir@ietf.org" , John C Klensin , "iesg@ietf.org" , Paul Hoffman , "idna-update@alvestrand.no" Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 11:11:29 -0000 if we mention DNSSEC at all (and perhaps it is not necessary since DNSSEC operates at the DNS level), we might simply say that IDNA is compatible with DNSSEC since signed DNS entries that reference IDNA A- labels are fully compatible with DNSSEC. It is a sort of gratuitous statement but perhaps it was requested because DNSSEC was "new" and the person requesting the reference wanted to be clear that IDNA didn't invalid the use of DNSSEC? vint On Oct 6, 2009, at 3:33 AM, Charlie Kaufman wrote: > My reading of the IDNA spec was that no query response would ever > contain a U-label, and therefore saying that if the query response > did contain a U-label then DNSSEC couldn't sign or verify it seems > nonsensical. I believe that DNSSEC is more like part of DNS than up > at the layer of IDNA; it can sign anything that DNS can return. > > I believe the DNSSEC spec says that what is signed is the "wire > form" of the name, which should be unambiguous unless different wire > forms are used in different contexts in the DNS protocol. For DNS > servers following IDNA, the wire form would always be an A-label or > an LDH-label. > > I could easily believe that there are problems when DNSSEC interacts > with non-IDNA compliant names (either because the term "wire form" > was ambiguous in some contexts or because the DNSSEC spec did not > consistently use that terminology). But I haven't heard anyone claim > that yet. > > --Charlie > > -----Original Message----- > From: John C Klensin [mailto:klensin@jck.com] > Sent: Monday, October 05, 2009 5:17 PM > To: Charlie Kaufman; Paul Hoffman; secdir@ietf.org; iesg@ietf.org; vint@google.com > ; d3e3e3@gmail.com; idna-update@alvestrand.no > Subject: RE: secdir review of draft-ietf-idnabis-rationale-13.txt > > > > --On Monday, October 05, 2009 21:40 +0000 Charlie Kaufman > wrote: > >> I considered putting in more context, but decided against it (clearly >> a mistake). >> >> IDNA specifies that all internationalized domain names served by DNS >> use the IDNA encoding, but the DNS spec does not. So the full >> statement in the draft appears to be saying that a DNS zone that does >> not use IDNA cannot use DNSSEC (in the sense of it wouldn't work as >> opposed to it MUST NOT). I cannot figure out why that would be true, >> though as I said there may be some subtlety I'm missing. I agree with >> Andrew that I can't see why this document should mention DNSSEC at >> all. > > Charlie, > > Thanks for the careful reading. Let me respond as holder of the pen > (but one who has put a lot of stuff into the document because the WG > apparently wanted it rather than because I was convinced it was > necessary). > > There are at least two things going on here: > > (1) As a collection, the IDNA documents have a number of > requirements that are (or should be) stated as "if you sign up for > IDNA, then you are required to behave this way". If anything > appears to impose requirements on DNS implementations, zones, or > other features except in that "conforming to IDNA" > context, then it is unintended and almost certainly needs to be > fixed. Sometimes that constraint is present in order to make sure > that future extensions that use a "this prefix means something > special" can occur without causing problems for IDNA or being > mutually exclusive, rather than because of an immediate > need of IDNA as reflected in this set of documents. However, > it turns out to be harder to impose and describe those constraints > than one might expect, so some of the instances of it may be > convoluted. > > That said, IDNA cannot impose constraints on binary labels used in > non-IDNA-aware implementations. It has been clear since the dawn of > the DNS, and certainly since RFC 2181, that arbitrary octet strings > are permitted to appear in zones and in queries. > Such octet strings can certainly be UTF-8 or ISO 8859-1; they can > even be, e.g., UTF-16 (UCS-2) in spite of the chaos that would cause > for applications that assumed they could use null octets as string > terminators without being careful about it. > However, whatever such labels might be, they aren't IDNA-conformant > IDNs or, as far as IETF Standards are concerned, IDNs at all. > > (2) As far as DNSSEC is concerned, you are quite correct: > nothing in IDNA has anything to do with it. The text is there for > two reasons: > > (i) Someone thought it important enough to mention and insisted that > we do so. It wasn't me. > > (ii) The "two (or more) representations of the same logical label" > design that underlies IDNA (both the new version and the old one) > creates some odd ambiguities with regard to many protocols and > namespaces (see draft-iab-idn-encoding for an evolving discussion of > some of those issues). In some cases, one pretty much has to use > the A-label (ACE-encoded) form. In others, the U-label (native > Unicode characters) form is anticipated and required. Still others > may be flexible. When I discussed IDNABIS at a SAAG meeting some > time ago, I was treated to an extended discussion (during and after > the meeting itself) about whether certificates and other credentials > should keep and interpret information in ACE (A-label) form or as > native-character Unicode strings and about the importance of being > able to convert from dot-separated labels to length-label pair form > other than as part of calls to the DNS because some credentials were > kept in the latter form. At least for a while, some of us > anticipated DNS servers that would accept zone files with IDNs in U- > label form as input and automagically do the conversion to A-labels, > presumably performing IDNA validation as > part of that process. > > Is it desirable in that context to say "don't even think about > computing DNSSEC values on anything but the A-label" or "because the > A-label is the only thing an IDNA-conforming program can put in, or > look up in, a zone, DNSSEC is not affected"? I really don't know... > and am certainly happy to make whatever changes in those > explanations that the community thinks appropriate. > > john > > > > From dave.cridland@isode.com Tue Oct 6 05:39: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 0C6D53A683A; Tue, 6 Oct 2009 05:39:51 -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 z-ameDhthApt; Tue, 6 Oct 2009 05:39:50 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EA5733A63CB; Tue, 6 Oct 2009 05:39:49 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 6 Oct 2009 13:41:08 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <15898.1254832898.040887@puncture> Date: Tue, 06 Oct 2009 13:41:38 +0100 From: Dave Cridland To: Security Area Directorate , The IESG , , , MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 12:39:51 -0000 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 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. Feel free to forward to any appropriate forum. This document extends the limited support for IPv6 VPN solutions in IKEv2, in particular allowing for multiple prefixes rather than a fixed number of addresses, which in turn allows various addressing strategies to be used. The Security Considerations section is actually quite unclear to me - at first glance, the opening phrase suggests that the solution does indeed do the thing it warns against, that is, assigning each client a unique, and therefore identifiable, prefix. It also fails to draw the reader's attention to any other relevent considerations - I'm assuming that the two and a half pages of security considerations in RFC 4306 have some direct relevance here. Also, the informative references noted in the Acknowledgements section would appear to have some potentially important security considerations - for example, RFC 4891's final consideration is: Please note that using IPsec for the scenarios described in Figures 1, 2, and 3 does not aim to protect the end-to-end communication. It protects just the tunnel part. It is still possible for an IPv6 endpoint not attached to the IPsec tunnel to spoof packets. ... given that IKEv2's previous support for IPv6 limited it to a single host at the client end, one assumes that this document introduces at least this security consideration. Dave. From klensin@jck.com Tue Oct 6 06:24: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 7B1233A6961; Tue, 6 Oct 2009 06:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 Q+UrQcfOd5vs; Tue, 6 Oct 2009 06:24:26 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 9DF153A67AE; Tue, 6 Oct 2009 06:24:26 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MvA3A-0000Ex-IQ; Tue, 06 Oct 2009 09:25:56 -0400 Date: Tue, 06 Oct 2009 09:25:55 -0400 From: John C Klensin To: Vint Cerf , Charlie Kaufman Message-ID: <9FDFFFAC141D4DF0C4522BD0@PST.JCK.COM> In-Reply-To: <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Paul Hoffman , idna-update@alvestrand.no, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 13:24:30 -0000 --On Tuesday, October 06, 2009 07:12 -0400 Vint Cerf wrote: > if we mention DNSSEC at all (and perhaps it is not necessary > since DNSSEC operates at the DNS level), we might simply say > that IDNA is compatible with DNSSEC since signed DNS entries > that reference IDNA A-labels are fully compatible with DNSSEC. > It is a sort of gratuitous statement but perhaps it was > requested because DNSSEC was "new" and the person requesting > the reference wanted to be clear that IDNA didn't invalid the > use of DNSSEC? Or, if my memory is correct, the IDNA didn't require any special handling in DNSSEC. john From ajs@shinkuro.com Tue Oct 6 06:31:47 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 85FF03A692A; Tue, 6 Oct 2009 06:31:47 -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 OjnWa3HaXMUi; Tue, 6 Oct 2009 06:31:46 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B53163A6925; Tue, 6 Oct 2009 06:31:46 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 436502FE8CA1; Tue, 6 Oct 2009 13:33:22 +0000 (UTC) Date: Tue, 6 Oct 2009 09:33:20 -0400 From: Andrew Sullivan To: John C Klensin Message-ID: <20091006133319.GB27462@shinkuro.com> References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> <9FDFFFAC141D4DF0C4522BD0@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9FDFFFAC141D4DF0C4522BD0@PST.JCK.COM> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: secdir@ietf.org, idna-update@alvestrand.no, iesg@ietf.org, Paul Hoffman , Vint Cerf Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 13:31:47 -0000 On Tue, Oct 06, 2009 at 09:25:55AM -0400, John C Klensin wrote: > Or, if my memory is correct, the IDNA didn't require any special > handling in DNSSEC. This is the point, I think. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From klensin@jck.com Tue Oct 6 06:35: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 A06123A690C; Tue, 6 Oct 2009 06:35:11 -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 rIpAYjvdN28i; Tue, 6 Oct 2009 06:35:10 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 917303A67AE; Tue, 6 Oct 2009 06:35:10 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MvADc-0000Q9-Fo; Tue, 06 Oct 2009 09:36:44 -0400 Date: Tue, 06 Oct 2009 09:36:43 -0400 From: John C Klensin To: Charlie Kaufman , Paul Hoffman , secdir@ietf.org, iesg@ietf.org, vint@google.com, d3e3e3@gmail.com, idna-update@alvestrand.no Message-ID: <5D784106504F4C12EAD9FFA5@PST.JCK.COM> In-Reply-To: References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 13:35:11 -0000 --On Tuesday, October 06, 2009 07:33 +0000 Charlie Kaufman wrote: > My reading of the IDNA spec was that no query response would > ever contain a U-label, and therefore saying that if the query > response did contain a U-label then DNSSEC couldn't sign or > verify it seems nonsensical. I believe that DNSSEC is more > like part of DNS than up at the layer of IDNA; it can sign > anything that DNS can return. > > I believe the DNSSEC spec says that what is signed is the > "wire form" of the name, which should be unambiguous unless > different wire forms are used in different contexts in the DNS > protocol. For DNS servers following IDNA, the wire form would > always be an A-label or an LDH-label. > > I could easily believe that there are problems when DNSSEC > interacts with non-IDNA compliant names (either because the > term "wire form" was ambiguous in some contexts or because the > DNSSEC spec did not consistently use that terminology). But I > haven't heard anyone claim that yet. Certainly it is the case that IDNA getting into trouble with DNSSEC (or vice versa) would require at least one of -- a sloppy reading of the IDNA specs -- a sloppy reading of the DNSSEC specs -- some odd case brought about by storing UTF-8 (or other) strings in the DNS, as discussed in draft-iab-idn-encoding. Of course, we've seen sloppy readings and odd cases in abundance, including a TLD or two that has registered strings in ISO 8859-1, insisted that they are IDNs, and claimed national sovereignty when criticized for that behavior. DNSSEC would of course work even for the latter as long as queries were in 8859-1, matching the stored form (if someone tried to make an IDNA query to find an 8859-1 label, it would fail with or without DNSSEC). It seems to me that the question is whether those cases are important enough to be worth a comment in Rationale (not one of the normative IDNA specs, but the non-normative explanation) and, if so, what it should say. john From hartmans@mit.edu Tue Oct 6 07:02:26 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 0DBBA3A68B4; Tue, 6 Oct 2009 07:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 WAmlJmYRnJxm; Tue, 6 Oct 2009 07:02:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 5419D28C1BF; Tue, 6 Oct 2009 07:02:25 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B250143BF; Tue, 6 Oct 2009 10:03:50 -0400 (EDT) To: Vint Cerf References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> From: Sam Hartman Date: Tue, 06 Oct 2009 10:03:50 -0400 In-Reply-To: <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> (Vint Cerf's message of "Tue\, 6 Oct 2009 07\:12\:53 -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: "secdir@ietf.org" , "idna-update@alvestrand.no" , "iesg@ietf.org" , Paul Hoffman , John C Klensin Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:02:26 -0000 >>>>> "Vint" == Vint Cerf writes: Vint> if we mention DNSSEC at all (and perhaps it is not necessary since Vint> DNSSEC operates at the DNS level), we might simply say that IDNA is Vint> compatible with DNSSEC since signed DNS entries that reference IDNA A- Vint> labels are fully compatible with DNSSEC. It is a sort of gratuitous Vint> statement but perhaps it was requested because DNSSEC was "new" and Vint> the person requesting the reference wanted to be clear that IDNA Vint> didn't invalid the use of DNSSEC? I'd be happy with either no reference to dnssec or to the sort of statement you propose above. I'd be happier with either than the current text. However in the grand scheme of things this issue is not a huge one. --Sam From kivinen@iki.fi Tue Oct 6 07:06: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 975D528C188; Tue, 6 Oct 2009 07:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 DOhBYc+a7qoq; Tue, 6 Oct 2009 07:06:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 66BEA28C183; Tue, 6 Oct 2009 07:06:06 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n96E7cMM008851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 17:07:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n96E7c6Z001396; Tue, 6 Oct 2009 17:07:38 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19147.20266.251586.760776@fireball.kivinen.iki.fi> Date: Tue, 6 Oct 2009 17:07:38 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: mmusic-chairs@tools.ietf.org, draft-ietf-mmusic-rfc3388bis@tools.ietf.org Subject: [secdir] Review of draft-ietf-mmusic-rfc3388bis-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:06:07 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document revises rfc3388 and the changes seem quite small: ---------------------------------------------------------------------- 10. Changes from RFC 3388 The grouping mechanism is now defined as an extendible framework. Earlier, [RFC3388] used to discourage extensions to this mechanism in favor of using new session description protocols. Given a semantics value, [RFC3388] used to restrict "m" line identifiers to only appear in a single group using that semantics. That restriction has been lifted. From conversations with implementers, it seems that the lifting of this restriction is unlikely to cause backwards compatibility problems. ---------------------------------------------------------------------- I do not see that those changes would introduce any new security considerations that the current Security Considerations section does not already cover. Of course as this is now extendible framework the new semantics might change this situation in future. The current Security Considerations section does already include note that using FID semantics the attacker who is able to modify group parameters can send a copy of the media to other destinations, but it also points out that integerity mechanims can be used to prevent this attack and that in "SIP S/MIME and TLS can be used to protect session description exchanges in an end-to-end and a hop-by-hop fashion respectively." -- kivinen@iki.fi From jefsey@jefsey.com Tue Oct 6 04:02: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 0E5623A68DA; Tue, 6 Oct 2009 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 HSNSk-Lt7eZl; Tue, 6 Oct 2009 04:02:39 -0700 (PDT) Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id 2C9AB3A67EA; Tue, 6 Oct 2009 04:02:39 -0700 (PDT) Received: from 89-158-60-18.rev.dartybox.com ([89.158.60.18]:1438 helo=jfcmh.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mv7pw-0002gO-Gm; Tue, 06 Oct 2009 04:04:08 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Oct 2009 13:04:04 +0200 To: Charlie Kaufman , John C Klensin ,Paul Hoffman , "secdir@ietf.org" ,"iesg@ietf.org" , "vint@google.com" , "d3e3e3@gmail.com" , "idna-update@alvestrand.no" From: JFC Morfin In-Reply-To: References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20091006110239.2C9AB3A67EA@core3.amsl.com> X-Mailman-Approved-At: Tue, 06 Oct 2009 07:39:04 -0700 Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 11:02:40 -0000 At 09:33 06/10/2009, Charlie Kaufman wrote: >My reading of the IDNA spec was that no query response would ever >contain a U-label, and therefore saying that if the query response >did contain a U-label then DNSSEC couldn't sign or verify it seems >nonsensical. I believe that DNSSEC is more like part of DNS than up >at the layer of IDNA; it can sign anything that DNS can return. > >I believe the DNSSEC spec says that what is signed is the "wire >form" of the name, which should be unambiguous unless different wire >forms are used in different contexts in the DNS protocol. For DNS >servers following IDNA, the wire form would always be an A-label or >an LDH-label. > >I could easily believe that there are problems when DNSSEC interacts >with non-IDNA compliant names (either because the term "wire form" >was ambiguous in some contexts or because the DNSSEC spec did not >consistently use that terminology). But I haven't heard anyone claim that yet. Charlie, the debate over IDNA has lasted many years. During that many years some "WG IDNA culture" developped with its own terminology. In turn that terminology evolved as the consensus developped. It makes things more difficult to grasp for outsiders like you and us ("contributing users" coming from the outer world, I had to teach). Our user's point of view may help you figuring things out (they are discussed in http://tools.ietf.org/html/draft-iucg-punyplus-02). Basically we consider a naming pile wich includes three layers. We name them: * UDN - as User Domain Names (in UTF), to be converted back/forth. This is what the user types and see. * ADN - as Application Domain Names (in the way application wants them), to be converted back/forth. This is what is really used by non-Internet IDNA limited applications and non-internet protocols (hoppefully stripped from non permitted chars if they want to be Internet DNS interoperable) * IDN - as Internet Domain Names (in what you call "wire form", i.e. strict Internet DNS names). DNSSEC fully applies on them. They result from the punycode encoding. To understand why this three layer pile is the easiest want to understand the whole system: - if fully respects the fundamental target to keep the DNS unaffected - the UDN layer (therefore the unchanged DNS layer) can fully support any cross-technology Semantic Addressing System without the need to encapsualte the DNS. DNSSEC and other discussed security oriented possibilities are unaffected. - user can directly type ADNs (what is named U-labels) or IDNs (what is named A-labels). - security issues can be reduced to simpler layer localized considerations. The only remaining problems are that the entire process is not end to end because upper-cases are not restored on the other end (what the punycode algorithm is now prevented to do for good reasons) and cannot be considered for DNS resolutions. Punyplus will address these two problems in a simple and robust way as an IDNA added value, once IDNA is published. Best jfc From yokota@kddilabs.jp Tue Oct 6 05:17: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 51C3E28C0EA; Tue, 6 Oct 2009 05:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 V0qGZo9k-3PS; Tue, 6 Oct 2009 05:17:30 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 4AA8028C0E6; Tue, 6 Oct 2009 05:17:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 1831CEC881; Tue, 6 Oct 2009 21:19:03 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [2001:200:601:402::145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9348FEC8C1; Tue, 6 Oct 2009 21:19:02 +0900 (JST) Received: from [IPv6:::1] (unknown [IPv6:2001:200:601:400:d8ef:f3f4:d59f:b954]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 5C4741BA74; Tue, 6 Oct 2009 21:13:31 +0900 (JST) Message-ID: <4ACB359F.2020703@kddilabs.jp> Date: Tue, 06 Oct 2009 21:18:39 +0900 From: Hidetoshi Yokota User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Weis References: <49F4ED8C-6275-433E-9B57-36FD713BD7B8@cisco.com> In-Reply-To: <49F4ED8C-6275-433E-9B57-36FD713BD7B8@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Tue, 06 Oct 2009 07:39:04 -0700 Cc: mipshop-chairs@tools.ietf.org, draft-ietf-mipshop-pfmipv6@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mipshop-pfmipv6-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 12:17:31 -0000 Hello Brian, We greatly appreciate your thorough review. The provided comments about the security statement for the data packets and an addition in the terminology section will be reflected in the very next version. Best regards, -- Hidetoshi Brian Weis wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This document adds Proxy-based Fast Handover to Mobile IPv6 (MIPv6). It > allows fast handover of a mobile device between mobile access gateway's > without the mobile node itself being involved. > > The document primarily reuses messages flows from a previously defined > handover method (RFC 5568), and Proxy Mobile IPv6 (RFC 5213). It also > depends on the Security Considerations from RFC 5213 and RFC 5568, which > seems appropriate given that the same message flows are used between the > same network entities. These existing RFCs describe IPsec ESP as the > method for protecting messages, and include details in setting up the > SPD and PAD. I believe pointing to those documents for security > consideration guidance is generally acceptable. > > There is one new message flow, which is the forwarding of data packet > from the previous mobile access gateway (PMAG) to the next mobile access > gateway (NMAG) during transition. The last paragraph in the security > considerations section notes that these packets MAY be encrypted with > IPsec "if protection of data traffic is required". A better statement > might be that they SHOULD be encrypted if the link between the PMAG and > NMAG exposes the MN packets to more threats than if they had followed > their normal routed path. > > (One miscellaneous comment: It would be helpful to readers if you added > a definition of "Local Mobility Anchor" to the Terminology section.) > > Brian > From klensin@jck.com Tue Oct 6 07:43: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 7F5463A6848; Tue, 6 Oct 2009 07:43:33 -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 FbczmqZ1SNMV; Tue, 6 Oct 2009 07:43:30 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id EA3973A68E8; Tue, 6 Oct 2009 07:43:23 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MvBHd-00031r-7X; Tue, 06 Oct 2009 10:44:57 -0400 Date: Tue, 06 Oct 2009 10:44:56 -0400 From: John C Klensin To: Sam Hartman , Vint Cerf , Charlie Kaufman Message-ID: In-Reply-To: References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Paul Hoffman , idna-update@alvestrand.no, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:43:33 -0000 --On Tuesday, October 06, 2009 10:03 -0400 Sam Hartman wrote: >>>>>> "Vint" == Vint Cerf writes: > > Vint> if we mention DNSSEC at all (and perhaps it is not > necessary since Vint> DNSSEC operates at the DNS level), >... > I'd be happy with either no reference to dnssec or to the sort > of statement you propose above. I'd be happier with either > than the current text. However in the grand scheme of things > this issue is not a huge one. Editor's opinion: People are obviously sensitive to exactly what, if anything, is said about this. If there is consensus that "say nothing" (or "no reference") is an acceptable alternative, I would recommend that we simply remove that entire subsection rather than trying to fine-tune it. I'm not sure that would be the right answer in a more perfect world, but I'm concerned that we could spend a lot of cycles trying to get things exactly right at this late stage in document processing... or that we could make a quick patch that we would regret later. FWIW, if we do start rewriting, the section needs work beyond the confusing sentence that started the discussion. I'm not sure that the first paragraph (which describes what DNSSEC is about) is needed any more. The first sentence of the second paragraph should stress "public DNS" or something tautological about what an "internationalized domain name" is to skirt the draft-iab-idn-encoding issues. The one problem I see with removing the section entirely has to do with the last paragraph, on which I don't think anyone has commented. As I assume people on the IDNA list are aware, there are some almost-conforming DNS server products that are heavily promoted in some parts of the world as enabling a better quality of IDN support. At least one variation accepts queries in the local character set of choice, performs some orthographic variation processing, and only then performs IDNA processing and makes A-label-based queries to authoritative servers. While the ways in which they don't work have been subtle enough in localized environments that their advocates have periodically claimed DNS and IDNA conformance, they will certainly not work with DNSSEC validation to the desktop because the zone will be signed over the A-labels but the queries will be made with U-labels or something else. When the initial form of that paragraph was written a year or two ago, it seemed worthwhile to warn about that situation. However, at this point, maybe it isn't worthwhile enough to justify the effort to fine-tune this section. In an ideal world, the warning probably belongs in the DNSSEC specs, rather than here, anyway. john From ajs@shinkuro.com Tue Oct 6 08:04: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 67A5C3A694F; Tue, 6 Oct 2009 08:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.528, 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 kgeI7RKvmXPG; Tue, 6 Oct 2009 08:04:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 87F523A67F7; Tue, 6 Oct 2009 08:04:47 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9564C2FE8CA1; Tue, 6 Oct 2009 15:06:23 +0000 (UTC) Date: Tue, 6 Oct 2009 11:06:21 -0400 From: Andrew Sullivan To: John C Klensin Message-ID: <20091006150621.GO27462@shinkuro.com> References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: secdir@ietf.org, Sam Hartman , idna-update@alvestrand.no, iesg@ietf.org, Paul Hoffman , Vint Cerf Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 15:04:48 -0000 On Tue, Oct 06, 2009 at 10:44:56AM -0400, John C Klensin wrote: > said about this. If there is consensus that "say nothing" (or > "no reference") is an acceptable alternative, I would recommend > that we simply remove that entire subsection rather than trying > to fine-tune it. I can support that. > When the initial form of that paragraph was written a year or > two ago, it seemed worthwhile to warn about that situation. > However, at this point, maybe it isn't worthwhile enough to > justify the effort to fine-tune this section. In an ideal > world, the warning probably belongs in the DNSSEC specs, rather > than here, anyway. Strictly, it's not a protocol issue, but an operations issue, and therefore ought probably to be operational advice (likely to be reviewed in DNSOP). I cannot believe I am getting up in public and saying this, but if people really need that advice to be written down somewhere I am willing to write an I-D to say it. Especially if that clears the issues with the current IDNA drafts. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ebw@abenaki.wabanaki.net Tue Oct 6 08:18: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 9068A3A697A; Tue, 6 Oct 2009 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 TtotvkOJ+Wq5; Tue, 6 Oct 2009 08:18:26 -0700 (PDT) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by core3.amsl.com (Postfix) with ESMTP id BBF413A6860; Tue, 6 Oct 2009 08:18:26 -0700 (PDT) Received: from limpet.local (cpe-67-241-43-7.twcny.res.rr.com [67.241.43.7]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id n96F3uZp069437; Tue, 6 Oct 2009 11:03:57 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4ACB6013.3050800@abenaki.wabanaki.net> Date: Tue, 06 Oct 2009 11:19:47 -0400 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andrew Sullivan References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> <20091006150621.GO27462@shinkuro.com> In-Reply-To: <20091006150621.GO27462@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 06 Oct 2009 08:23:18 -0700 Cc: secdir@ietf.org, Vint Cerf , John C Klensin , iesg@ietf.org, Paul Hoffman , idna-update@alvestrand.no, Sam Hartman Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 15:18:27 -0000 Andrew, I thought you were being rational up to this point. I'll help Andrew if he decides to take the (fatal) step, and if he thinks it useful. It really should be a minor note, but given the level of confusion around IDN and DNSSEC, we may end up there anyway. Eric Andrew Sullivan wrote: > On Tue, Oct 06, 2009 at 10:44:56AM -0400, John C Klensin wrote: > > >> said about this. If there is consensus that "say nothing" (or >> "no reference") is an acceptable alternative, I would recommend >> that we simply remove that entire subsection rather than trying >> to fine-tune it. >> > > I can support that. > > >> When the initial form of that paragraph was written a year or >> two ago, it seemed worthwhile to warn about that situation. >> However, at this point, maybe it isn't worthwhile enough to >> justify the effort to fine-tune this section. In an ideal >> world, the warning probably belongs in the DNSSEC specs, rather >> than here, anyway. >> > > Strictly, it's not a protocol issue, but an operations issue, and > therefore ought probably to be operational advice (likely to be > reviewed in DNSOP). I cannot believe I am getting up in public and > saying this, but if people really need that advice to be written down > somewhere I am willing to write an I-D to say it. Especially if that > clears the issues with the current IDNA drafts. > > A > > From tobias.gondrom@gondrom.org Tue Oct 6 09:31: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 7E8653A6821; Tue, 6 Oct 2009 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 UpE6IU3V-tdo; Tue, 6 Oct 2009 09:31:17 -0700 (PDT) Received: from leela.webpack.hosteurope.de (leela.webpack.hosteurope.de [217.115.142.65]) by core3.amsl.com (Postfix) with ESMTP id 3D22C3A6767; Tue, 6 Oct 2009 09:31:16 -0700 (PDT) Received: from 78-86-27-62.zone2.bethere.co.uk ([78.86.27.62] helo=[192.168.1.64]); authenticated by leela.webpack.hosteurope.de running ExIM with esmtpa id 1MvCy2-0000Av-Pi; Tue, 06 Oct 2009 18:32:50 +0200 Message-ID: <4ACB7133.3070409@gondrom.org> Date: Tue, 06 Oct 2009 17:32:51 +0100 From: Tobias Gondrom User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de; tobias.gondrom@gondrom.org; 1254846775; 067734a1; Cc: kaushik@cisco.com, tim.polk@nist.gov, Pasi.Eronen@nokia.com, Paul_Sangster@symantec.com Subject: [secdir] Secdir review of draft-ietf-nea-pa-tnc-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 16:31:19 -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. First and for all: from the security perspective, I see a major issue which is discussed in my last point #5. The remaining issues are minor comments: 0. This draft is closely linked to one other work-in-progress draft draft-ietf-nea-pb-tnc-05 which is also linked as normative references. draft-ietf-nea-pa-tnc MUST ONLY proceed if the normative referred doc can advance as well. 1. COMMENT: section 4.1, page 17: Question: could Bit 0 (0x80), the NOSKIP flag, result in a kind of Denial of Service vulnerability: client sneaking in on message in a whole collection and thus disabling the evaluation of all, although all prerequisites for a network endpoint to be serviced are fulfilled? 2. COMMENT: section 4.1. paragraph “PA-TNC Attribute Length” Question: maybe the paragraph would want to state what happens if the length is incorrect: recommendation would be that in such a case the length should be considered as a hint and parsed for the begin of the next messages and the following messages can (SHOULD?) still be parsed and interpreted. 3. COMMENT: 4.2.6. Port Filter considering potential size limits for messages, might it be a good idea to allow ranges of port numbers (e.g. B 220-8000) instead of a (potentially larger) list of port numbers? 4. COMMENT: 4.2.11. Forwarding Enabled just a hinge: if forwarding is enabled, might it be helpful to add a qualifier about the allowed forwarding addresses, so that the server can determine whether this is acceptable within the policy. (forwarding to addresses within the same network subunit may be acceptable?) 5. DISCUSS: 5. Security Consideration: This section mentions that “PA-TNC security protocols are described in separate specifications which layer upon the base PA-TNC protocol described in this specification.” Actually, I have not seen this security protocol on the WG page and am quite worried about this. (I found an old 00-version that expired August 2008, I have not reviewed its content.) PA-TNC can disclose a lot about the security properties of an endpoint and actually also of a server landscape. Therefore it MUST be ensured that the requests and responses are made by authorized parties (and e.g. not by any network the client stumbles upon). In fact for the protocol both parties must be authenticated and authorized. Sections 5.2.1. to 5.2.6 describe nicely a variety of threats if this is not fulfilled. And this is correct. But the draft is short on how to prevent these risks. Section 5.1. and 5.2. recognize the importance of trusted counterparties in the communication, but seem to ignore that PA-TNC SHOULD NOT (or even MUST NOT) be used without mechanisms allowing this bi-lateral trust. To ensure interoperability the authentication mechanism SHOULD use common standard mechanisms and could include them in this document. (even if it would be just as simple as e.g. use TLS two-party authentication, or other means deemed appropriate by the WG). Summarizing: the draft should add one or more of the following: 1.A common authentication mechanism to be used. 2.That PA-TNC MUST use an underlying protocol that ensures two-side authentication and evaluate the the authentication data to decide on authorization of disclosure of data. 3.PA-TNC is only valid in conjunction with the mentioned PA-TC security protocol which is not specified, yet? Probably the easiest solution would be to add a section to the security considerations: “PA-TNC MUST use means of two-side authentication to ensure the required underlying trust relationship between both parties is not exploited. <...continue with more text...>” Please excuse me for being that strong about it, but I can lterally imagine dozens of potential security exploits if this would be implemented without good underlying security mechanisms. And from my understanding the current draft does not "REQUIRE" underlying security, which worries me. I like the draft's concept, but believe it must add a bit more towards secure use to be released. But maybe I just missed something? Kind regards, Tobias Tobias Gondrom email: tobias.gondrom@gondrom.org From phoffman@imc.org Tue Oct 6 10:11: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 457313A6A0E; Tue, 6 Oct 2009 10:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 KFL7tjpShpau; Tue, 6 Oct 2009 10:11:14 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 89F363A6A0D; Tue, 6 Oct 2009 10:11:14 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n96HCkLr024690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 10:12:48 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5D784106504F4C12EAD9FFA5@PST.JCK.COM> References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> <5D784106504F4C12EAD9FFA5@PST.JCK.COM> Date: Tue, 6 Oct 2009 10:12:44 -0700 To: John C Klensin From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: idna-update@alvestrand.no, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:11:15 -0000 At 9:36 AM -0400 10/6/09, John C Klensin wrote: >Of course, we've seen sloppy readings and odd cases in >abundance, including a TLD or two that has registered strings in >ISO 8859-1, insisted that they are IDNs, and claimed national >sovereignty when criticized for that behavior. If people are going to rely on this logic to keep (modified) wording about DNSSEC in the document, we will need to see actual cases. I strongly prefer the "remove DNSSEC from the document" option. From eblanconil@gmail.com Tue Oct 6 08:58: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 5F71928C0D8; Tue, 6 Oct 2009 08:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 AxI81OWWCQB5; Tue, 6 Oct 2009 08:58:18 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id F039728C1DB; Tue, 6 Oct 2009 08:58:17 -0700 (PDT) Received: by fxm28 with SMTP id 28so3583254fxm.42 for ; Tue, 06 Oct 2009 08:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9T843maL0xDj7CndgiWOYP3jQ+sR9wWPov/n5iR7zYA=; b=kkG/dgV1d6vpmkkr+8PRvT3xYiueodvQUsmIwbO+gpK2iXKjM/fnUzOdSXxUZ64cPm HQaOkFQKNYwnQYu15KKmoswB1W91Ce4nBjghQ5d6X6QXGGm9bIclz1G2bfoZ3f/ZiLmY rgOIU0NipM2KgB8YhWGVm5IgbBf/sh1X7+0Vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=otjrKBIXeyiZ9F4qOZu8olvQposeYIg6OHHuuUWSUGuoK80z7ZP7cjjB18sAon0zMn rr7p72VMRefOAKH3OSNyczmlUF9pf9durzb21sBqcm1CbMmoeAe6MaPBOnTl5tFDLBEO nyQKLEipbD6OTZLGmy1gYKYPu+17Z4DGLPNIk= MIME-Version: 1.0 Received: by 10.86.154.32 with SMTP id b32mr688078fge.10.1254844791016; Tue, 06 Oct 2009 08:59:51 -0700 (PDT) In-Reply-To: <20091006150621.GO27462@shinkuro.com> References: <17823AE7FE62B8814BE101BF@PST.JCK.COM> <2FA54714-6D7F-46E3-A2CA-BC9D44CBC29B@google.com> <20091006150621.GO27462@shinkuro.com> Date: Tue, 6 Oct 2009 17:59:50 +0200 Message-ID: <6589127a0910060859u2da6723k2c00f00ecd1d3722@mail.gmail.com> From: Elisabeth Blanconil To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 06 Oct 2009 11:08:22 -0700 Cc: secdir@ietf.org, Vint Cerf , John C Klensin , iesg@ietf.org, Paul Hoffman , idna-update@alvestrand.no, Sam Hartman Subject: Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 15:58:19 -0000 Full agreement. Or would we have to update IDNA each time the DNS has an extra feature? Just to repeat that IDNA respects the DNS? That was it not supposed to be a multilayer model? Elisabeth Blanconil 2009/10/6 Andrew Sullivan : > On Tue, Oct 06, 2009 at 10:44:56AM -0400, John C Klensin wrote: > >> said about this. =A0 If there is consensus that "say nothing" (or >> "no reference") is an acceptable alternative, I would recommend >> that we simply remove that entire subsection rather than trying >> to fine-tune it. > > I can support that. > >> When the initial form of that paragraph was written a year or >> two ago, it seemed worthwhile to warn about that situation. >> However, at this point, maybe it isn't worthwhile enough to >> justify the effort to fine-tune this section. =A0 =A0In an ideal >> world, the warning probably belongs in the DNSSEC specs, rather >> than here, anyway. > > Strictly, it's not a protocol issue, but an operations issue, and > therefore ought probably to be operational advice (likely to be > reviewed in DNSOP). =A0I cannot believe I am getting up in public and > saying this, but if people really need that advice to be written down > somewhere I am willing to write an I-D to say it. =A0Especially if that > clears the issues with the current IDNA drafts. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Idna-update mailing list > Idna-update@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update > From hallam@gmail.com Tue Oct 6 18:59: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 0DD0F28C0E4 for ; Tue, 6 Oct 2009 18:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jya4V8qXO41 for ; Tue, 6 Oct 2009 18:59:09 -0700 (PDT) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 1874C3A6876 for ; Tue, 6 Oct 2009 18:59:09 -0700 (PDT) Received: by ywh15 with SMTP id 15so4218561ywh.5 for ; Tue, 06 Oct 2009 19:00:44 -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; bh=V8bTMCC4uOr9zNcpraG30rhMzba29VMgC8S9eoP89zE=; b=g5KLwXDzQTuRChqt+4dC/mZhhZXryku/ocXVLLqG2TfswUChZZ+0S47X+OKLEdQwgZ pEhDCjIVvr21wC/+iBpOBBPQoPp1e7ep1NN3vA9MqnzjwQtDebFMrDtSZEgR5Jlf4/BW vzlQzMOsfU9uRmekJDswIFGzXgne3sfQ8HJjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wrGDGN5C8PVSjK6yMR+UXRgHx/FuysY+sPvc8Ylc5fIQK+nlYaPQE0T4K4b/aT10rc ZL+OtTeVC6RS/72b4glG0asddxl2AXqPc1KIrK9eUL2jL5tLfRgSQ+nMKb2OEINbp2lz zng3dcddaVOV6T10ukfQrtn0YFDr6kuXSM3ow= MIME-Version: 1.0 Received: by 10.90.23.21 with SMTP id 21mr1110329agw.59.1254880843962; Tue, 06 Oct 2009 19:00:43 -0700 (PDT) Date: Tue, 6 Oct 2009 22:00:43 -0400 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, d.malas@cablelabs.com, acmorton@att.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review of draft-ietf-pmol-sip-perf-metrics-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 01:59:12 -0000 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 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. Feel free to forward to any appropriate forum. This document defines metrics for measuring the performance of SIP systems but not a protocol for their exchange. As such it is entirely appropriate that this document relies on the security section in the main SIP protocol which is extensive. One small area of concern is that the security considerations section appears to operate under the assumption that the chief security concern would be confidentiality. While it is possible that this might be the case, it is also quite likely that any metrics system would be employed for purposes in connection with billing. Hence there is likely to be an integrity concern with one party or another manipulating metrics for the purpose of avoiding payments due or for imposing unjustified payments or penalties. -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From hallam@gmail.com Tue Oct 6 19:41: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 9BA2828C21F for ; Tue, 6 Oct 2009 19:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 1cx-XVEfsmpY for ; Tue, 6 Oct 2009 19:41:15 -0700 (PDT) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id DA28928C1E5 for ; Tue, 6 Oct 2009 19:41:14 -0700 (PDT) Received: by ywh15 with SMTP id 15so4245488ywh.5 for ; Tue, 06 Oct 2009 19:42: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; bh=DsMP+EYk2c3+/xgjG7EFW9jZYbCwh6Dh8WvC6QJJOS0=; b=qdRykWsv2FAznIfwH0m6xMocc0GxSfJmUf2/R3fsvnlb6kL+cJBE4c0vRT9eGIENWn EbsA4iVvjplTEROL7K//Ahzgy6L6+DkzqFYLvCk+Y8dLLxdPMy9LCU5S7El4yyec7K4Y gsZIFRewfBPsdPHwEyMMSa3g/4DMQII0oWipI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=V5H5Dt9zP6OeFSuut8PWLToYqWa8cVwQ0QLCL7WbwLmUHJal7URzdUk8fME2SDaRPa 10v097YOoJRC/GlazOfvjOITn6sHjqoBDFCI07qmxqGolIFjL4/4A39aObTyKx5P5G/L o2cBHvS/WStscGXtik4ER02ttfARo3VfkbP5g= MIME-Version: 1.0 Received: by 10.91.74.11 with SMTP id b11mr1150186agl.39.1254883370900; Tue, 06 Oct 2009 19:42:50 -0700 (PDT) Date: Tue, 6 Oct 2009 22:42:50 -0400 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, martin.vigoureux@alcatel-lucent.com, dward@cisco.com, malcolm.betts@huawei.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR review of draft-ietf-mpls-tp-oam-requirements-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 02:41:16 -0000 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 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. Feel free to forward to any appropriate forum. This documents sets out requirements for Operations, Administration and Maintenance of MPLS Transport Profile. It is a high level architectural requirements document, intentionally separated from the details of specific implementations. As such it is appropriate for the security considerations section to be at a high level. It is however a mystery to this reader why encryption is specified as a should but integrity protections only merit a MAY. I would be much more reassured by a document that ignores confidentiality issues completely (as has been the general policy for low level routing &ct.) and points out the fact that this is yet another opportunity for a malicious party to play merry heck by introducing bogus data that other parts of the network will then operate on. For example, introduction of bogus messages would allow an attacker to reserve excessive bandwidth in the name of another party, possibly performing a DoS attack or possibly to perform a financial fraud, causing some party to incur costs for bandwidth not required. In comparison the confidentiality issues are rather minor, and in any event almost certainly subsumed by the fact that anyone who can observe the content of the OAM packets can almost certainly observe the volumes of the data flows and infer that information. While confidentiality is a nice to have, it is not worth much without integrity. I suggest that the security considerations section makes the ability to support integrity protections a MUST or SHOULD requirement. If only a SHOULD is applied, confidentiality would be better demoted to MAY. -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From eric.gray@ericsson.com Wed Oct 7 04:08:04 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 A7B2028C15C; Wed, 7 Oct 2009 04:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.372 X-Spam-Level: X-Spam-Status: No, score=-5.372 tagged_above=-999 required=5 tests=[AWL=1.227, 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 8i4yoyOitLpf; Wed, 7 Oct 2009 04:08:03 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 9181E28C15B; Wed, 7 Oct 2009 04:08:03 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n97B9SvT021821; Wed, 7 Oct 2009 06:09:31 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 06:09:30 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 06:09:30 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 7 Oct 2009 07:09:30 -0400 From: Eric Gray To: Tobias Gondrom , "iesg@ietf.org" , "secdir@ietf.org" Date: Wed, 7 Oct 2009 07:09:27 -0400 Thread-Topic: Secdir review of draft-ietf-mpls-tp-nm-req-05.txt Thread-Index: AcpF/8sLTZXa7qQ6QXWrlXJ1vfqMGwBPEM8g Message-ID: References: <4ACA5FC1.1050704@gondrom.org> In-Reply-To: <4ACA5FC1.1050704@gondrom.org> 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: 07 Oct 2009 11:09:30.0560 (UTC) FILETIME=[A46C8400:01CA473E] Cc: "swallow@cisco.com" , "tim.polk@nist.gov" , "Pasi.Eronen@nokia.com" , Scott Mansfield , "adrian.farrel@huawei.com" , "hklam@Alcatel-Lucent.com" , "loa@pi.nu" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-nm-req-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, 07 Oct 2009 11:08:04 -0000 Tobias, Thanks for your review and comments. The decision to publish this document as a standards track RFC was based on the previous restriction that ITU-T cannot refer to an Informational RFC. This restriction=20 has only just been relaxed to allow references to an RFC that results from the IETF consensus process, so it may no longer be necessary to publish this draft as a standards=20 track RFC.=20 That decision is out of my hands. Some definitions included are verbatim extractions from ITU-T publications, taken to avoid the need for a normative reference to those publications. As such, they are not actually subject to change and - if you disagree with them - I would suggest taking it up with applicable Questions in Study Group 15 at ITU-T. We tried to clarify the use of RFC 2119 language in=20 this document and were somewhat limited in our ability to do so by the requirements enforced by "idnits" that the text must appear verbatim in the draft. The intent in - for example - making a statement that the NE MUST perform persistency checks is to ensure protocol and management=20 specifications ensure that doing so is possible based on configuration. The case where persitistency checking is effectively disabled by configuration could be considered the degenerate case where required persistency is zero. The intention with alarm suppression is that some alarms are not desired in some configurations or under some conditions. Escalation procedures MAY, in certain situations, result in escalating an alarm condition to one that is not suppressed. Hence - to directly answer your question - suppression is permanent for those specific alarms for which it is configured, and as long as it is not configured otherwise. The instance of "the" that you pointed out should be changed to "that" as you suggest. Again, thanks for the review! -- Eric -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org]=20 Sent: Monday, October 05, 2009 5:06 PM To: iesg@ietf.org; secdir@ietf.org Cc: tim.polk@nist.gov; Pasi.Eronen@nokia.com; Eric Gray; Scott Mansfield; h= klam@Alcatel-Lucent.com; swallow@cisco.com; loa@pi.nu; adrian.farrel@huawei= .com Subject: Secdir review of draft-ietf-mpls-tp-nm-req-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. 0. From the security perspective, the requirements in this document appear to be sufficient, though not very detailed. As it's a requirments doc, this is ok. Obviously, I assume following specifications will be more detailed in how the described security requirments are satisfied. 1. DISCUSS: Question: as the document describes requirements and is in wide areas unprecise in how they shall be implemented I wonder why it aims to be "Standards Track" and not "Informational"? 2. COMMENT: Question: section Terminology: "Fault: A fault is the inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions (from [21], 3.26)." Why does a lack of external resources not constitute a fault? (the other two reasons I can understand but this one not? 3. COMMENT: section 5.2: "The MPLS-TP NE MUST perform persistency checks on fault causes before it declares a fault cause a failure." I am not sure whether a "SHOULD" would be more appropriate here: First, depending on the type of fault a NE my consider a failure after the first fault cause and Second, two paragraphs below, you speak of configurable time "A data-plane forwarding path failure MUST be declared if the fault cause persists continuously for a configurable time (Time-D). The failure MUST be cleared if the fault cause is absent continuously for a configurable time (Time-C)." if it is configurable, it may also be configured to infinite small, which kind of contradicts with the "MUST" for persistency check? 4. COMMENT: Section 5.3.2: Question: should this "An MPLS-TP NE MUST support suppression of alarms based on configuration." be changed to "An MPLS-TP NE MUST support suppression of alarms based on configuration and for a limited time." Or do you may not want to allow infinite and unlimited suppression of alarms? 6. s/An MPLS-TP NE MUST support secure management protocols and SHOULD do so in a manner the reduce potential impact of a DoS attack./An MPLS-TP NE MUST support secure management protocols and SHOULD do so in a manner that reduces potential impact of a DoS attack. Kind regards, Tobias Tobias Gondrom email: tobias.gondrom@gondrom.org From Sandra.Murphy@cobham.com Wed Oct 7 04:52: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 7D0C83A6936 for ; Wed, 7 Oct 2009 04:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 y4clGCJYKb1O for ; Wed, 7 Oct 2009 04:52:35 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 1301E3A69BA for ; Wed, 7 Oct 2009 04:52:34 -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 n97BrlFm027578; Wed, 7 Oct 2009 06:53:47 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n97BrjO0009898; Wed, 7 Oct 2009 06:53:47 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 07:53:45 -0400 Date: Wed, 7 Oct 2009 07:53:43 -0400 (Eastern Daylight Time) From: Sandra Murphy To: secdir@ietf.org, stbryant@cisco.com, mshand@cisco.com Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 07 Oct 2009 11:53:45.0186 (UTC) FILETIME=[D2B44C20:01CA4744] Subject: [secdir] comments on draft-ietf-rtgwg-ipfrr-framework-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, 07 Oct 2009 11:52:36 -0000 I am reviewing this document draft-ietf-rtgwg-ipfrr-framework-12 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 (that you received well after last call). Feel free to forward to any appropriate forum. This draft describes a framework for mechanisms to compute backup "repair" paths that allow traffic to continue to forward to the destination around failed links or nodes. This is similar to a mechanism in MPLS to provide backup LSPs by using RSVP-TE. For background, I also looked at RFC4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 5296 Basic Specification for IP Fast Reroute: Loop-Free Alternates draft-ietf-rtgwg-lf-conv-frmwk-06 A Framework for Loop-free Convergence draft-bryant-ipfrr-tunnels-03 IP Fast Reroute using tunnels draft-ietf-rtgwg-ipfrr-notvia-addresses-03 IP Fast Reroute Using Not-via Addresses The security considerations covers some concerns introduced by using fast-reroute mechanisms where providing repair paths may introduce vulnerabilities, particularly where the repair paths could interfere with existing robustness mechanisms (reverse path forwarding and TTL limits). I wonder if the knowledge of computed repair paths could be useful to an attacker in doing traffic-shaping, i.e., an attacker who was doing link-cutting to affect traffic flow. Similarly, the ability to influence the computation of the repair path could be valuable. Perhaps the framework document could mention that the proposed solutions should consider the need to protect the computation from exposure (to the same extent infrastructure information is protected from exposure) and corruption/contamination if such an attack were a concern. Note: RFC5286 dismisses this concern, without noting the benefit of an attacker to be able to producing a desired forwarding change if a failure (and therefore repair activity) could be induced: Traffic to certain destinations can be temporarily routed via next-hop routers that would not be used with the same topology change if this mechanism wasn't employed. However, these next-hop routers can be used anyway when a different topological change occurs, and hence this can't be viewed as a new security threat. The notvia-addresses draft does seem to recognize this risk from repair paths: The repair endpoints present vulnerability in that they might be used as a method of disguising the delivery of a packet to a point in the network. The loop-free convergence framework draft in the last-called version said: All micro-loop control mechanisms raise significant security issues which must be addressed in their detailed technical description. which I thought should be reflected in this framework, but that has changed in the post-last-call version to: This document analyzes the problem of micro-loops and summarizes a number of potential solutions that have been proposed. These solutions require only minor modifications to existing routing protocols and therefore do not add additional security risks. However a full security analysis would need to be provided within the specification of a particular solution proposed for deployment. I'm curious as to how "significant security issues" changed to "do not add additional security risks", but I don't have the time to track down the last call comments that created that change. (I'd say that adding any additional information to a routing protocol may not change the underlying vulnerabilities of the routing protocol but certainly provides new means to cause damage when exploiting the known vulenrabilities.) Non-security related comments: The following comment would have been useful to see before section 6: 6. Scope and applicability The initial scope of this work is in the context of link state IGPs. Link state protocols provide ubiquitous topology information, which facilitates the computation of repairs paths. The following comment would have been useful to see before section 4.2.5: Complete protection against multiple unrelated failures is out of scope of this work. Some terms in this document are never defined and/or used ambiguously. The following terms are not in the terminology list: repair path Shared Risk Link Groups (SRLG) - perhaps so common in the teleco world and in optical networks that definition was judged unnecessary. "link(node) protecting" "being protected" "fully protected (link/node)" "unprotectable" - it would seem to refer to a link or node failure for which a repair path is being computed, but may also mean mechanisms to avoid micro-loops. a path being "affected" by a reconvergence - which I think means that reconvergence to a new forwarding tree does not change any link in the repair path a repair path being "valid for a node" or "valid for destinations" Some text I found confusing: Page 7: 2. In topologies that are susceptible to micro-loops, a mechanism to prevent the effects of any micro-loops during subsequent re- convergence. Because the loop free convergence draft distinguishes micro-loop prevention from micro-loop suppression, which attempts to avoid the impact on other traffic from micro-loops, I thought "the effects of any micro-loops" referred to this collateral damage. But later in that page it talks about micro-loop avoidance, which sounds like the loop free convergence draft's term "micro-loop prevention". So I'm not sure what is meant here. Page 10: 1. The percentage of links (or nodes) which can be fully protected for all destinations. This is appropriate where the requirement is to protect all traffic, but some percentage of the possible failures may be identified as being un-protectable. What does it mean to be "fully protected for all destinations"? Is that redundant? And what about "unprotectable"? Is it possible to have fully protected for all destinations fully protected for some destinations partially protected for all destinations partially protected for some destinations unprotectable for all destination unprotectable for some destinations etc.? The outline in section 4 has me a bit confused: 4. Mechanisms for IP Fast-reroute . . . . . . . . . . . . . . . . 7 4.1. Mechanisms for fast failure detection . . . . . . . . . . 7 4.2. Mechanisms for repair paths . . . . . . . . . . . . . . . 8 4.2.1. Scope of repair paths . . . . . . . . . . . . . . . . 9 4.2.2. Analysis of repair coverage . . . . . . . . . . . . . 9 4.2.3. Link or node repair . . . . . . . . . . . . . . . . . 10 4.2.4. Maintenance of Repair paths . . . . . . . . . . . . . 11 4.2.5. Multiple failures and Shared Risk Link Groups . . . . 11 4.3. Local Area Networks . . . . . . . . . . . . . . . . . . . 12 4.4. Mechanisms for micro-loop prevention . . . . . . . . . . . 12 Section 4.2.5 covers SRLG's as an example of multiple related failures, which it says are out of scope. Then section 4.3 covers LANs - which would seem to me to satisfy the definition of a SRLG. Is 4.3 supposed to be a subtopic under 4.2.5? It seems out of keeping with the mechanism focus of sections 4.1, 4.2 and 4.4. Also, 4.3 says: Protection against partial or complete failure of LANs is more complex than the point to point case. In general there is a trade- off between the simplicity of the repair and the ability to provide complete and optimal repair coverage. (That's a complete quote of that section, which is another reason for asking if it is really supposed to be a separate section) Does this imply that all previous discussion was about point to point links only? RFC 5286 has an extended discussion of computing backup paths for broadcast and NBMA links, so I was surprised to see this draft seem to indicate that LANs were out of scope. --Sandy Murphy From weiler@watson.org Wed Oct 7 08:18: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 C448C28C1B0; Wed, 7 Oct 2009 08:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 wyp7VBY24Xcy; Wed, 7 Oct 2009 08:18:22 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id E600828C18B; Wed, 7 Oct 2009 08:18: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 n97FK0aP052781; Wed, 7 Oct 2009 11:20:00 -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 n97FK0Di052769; Wed, 7 Oct 2009 11:20:00 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 7 Oct 2009 11:20:00 -0400 (EDT) From: Samuel Weiler To: iesg@ietf.org, secdir@ietf.org, eai-chairs@tools.ietf.org, fujiwara@jprs.co.jp 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, 07 Oct 2009 11:20:01 -0400 (EDT) Subject: [secdir] secdir review of draft-ietf-eai-downgraded-display-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: Wed, 07 Oct 2009 15:18:22 -0000 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 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 concur with Pasi's already-filed Discuss re: the difficulty of following Section 4. I suggest adding a plain-language summary. If my understanding is correct, that might be: Show the MIME-decoded versions of each "address header field" (the "Downgraded-" versions) if and only if the MUA's own running of the RFC5504 downgrading algorithm on that "Downgraded-" header matches (with some canonicalization) the corresponding header field in the message. Otherwise, and for all non-address headers, don't change the headers. The security considerations section refers to 5504 and 4952. I suggest including verbatim some of the warnings from 5504, particularly the fourth paragraph of 5504's section 7 noting that these transformations may break certain message integrity mechanisms. Editorial: "The "Downgraded-" header field and corresponding header field MAY NOT HAVE RELATIONS." [emphasis mine] is an awkward turn of phrase. From kent@bbn.com Thu Oct 8 03:42: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 9CA2F3A6A5D for ; Thu, 8 Oct 2009 03:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 h7gm5BjQExWO for ; Thu, 8 Oct 2009 03:41:58 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4B15E28C138 for ; Thu, 8 Oct 2009 03:41:57 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MvpX3-0007oT-Et; Thu, 08 Oct 2009 05:43:35 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 8 Oct 2009 06:40:31 -0400 To: fandreas@cisco.com, Gonzalo.Camarillo@ericsson.com, oran@cisco.com, dwing@cisco.com From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-957123881==_ma============" Cc: fluffy@cisco.com, rjsparks@nostrum.com, secdir@ietf.org Subject: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 10:42:02 -0000 --============_-957123881==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document "draft-ietf-mmusic-connectivity-precon-06" defines "a new connectivity precondition for the Session Description Protocol (SDP) precondition framework." Connectivity preconditions are used to delay session establishment (or modification) until media stream connectivity has been verified. The use of preconditions represents an interesting twist on the original SDP model, where the assumption was that an SDP session would be established before media streams were established! The use of preconditions is motivated in large part by the need for media streams to traverse firewalls and NATs. The Security Considerations section here starts by citing the Security Considerations section from the base preconditions RFC (3312). It also adds two paragraphs to discuss new considerations relevant to the precondition types defined in this document. This is an appropriate way to address new security issues that arise for extensions to previously-defined functions. RFC 3312 has a two-paragraph Security Considerations section, which identifies concerns, but make no recommendations about security mechanisms to employ! This document has a paragraph that RECOMMENDS use of integrity for the SDP traffic, e.g., via RFC 3261, to counter attacks against this portion of the system. This is a concrete recommendation that is appropriate for this aspect of the security concerns cited, and is applicable to the 3312 security concerns as well. The new security concerns that arise here result from reliance on other protocols to detect successful media stream establishment. This motivates concerns about two classes of DoS attacks: transient attacks that cause session establishment to fail (when the media streams could have been created) and transient attacks that make it appear that media streams have been established, when in fact they have not. TCP and ICE are the protocols cited specifically as one of interest. The text RECOMMDNDS making use of suitable authentication and integrity mechanisms for the relevant protocols to counter both forms of attacks. The text also says that "the mechanisms SHOULD consider how to prevent denial of service attacks." I find this text to be too vague to be useful. It ought to cite specific mechanisms in RFCs, at least as examples, preferably as recommendations. The lack of specific, cited mechanisms makes this section almost vacuous. I suggest that the authors revise the text here to cite appropriate mechanisms. --============_-957123881==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-mmusic-connectivity-precon-06
I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
The document "draft-ietf-mmusic-connectivity-precon-06" defines "a new connectivity precondition for the Session Description Protocol (SDP) precondition framework." Connectivity preconditions are used to delay session establishment (or modification) until media stream connectivity has been verified. The use of preconditions represents an interesting twist on the original SDP model, where the assumption was that an SDP session would be established before media streams were established! The use of preconditions is motivated in large part by the need for media streams to traverse firewalls and NATs.

The Security Considerations section here starts by citing the Security Considerations section from the base preconditions RFC (3312). It also adds two paragraphs to discuss new considerations relevant to the precondition types defined in this document. This is an appropriate way to address new security issues that arise for extensions to previously-defined functions. RFC 3312 has a two-paragraph Security Considerations section, which identifies concerns, but make no recommendations about security mechanisms to employ! This document has a paragraph that RECOMMENDS use of integrity for the SDP traffic, e.g., via RFC 3261, to counter attacks against this portion of the system. This is a concrete recommendation that is appropriate for this aspect of the security concerns cited, and is applicable to the 3312 security concerns as well.

The new security concerns that arise here result from reliance on other protocols to detect successful media stream establishment. This motivates concerns about two classes of DoS attacks: transient attacks that cause session establishment to fail (when the media streams could have been created) and transient attacks that make it appear that media streams have been established, when in fact they have not.

TCP and ICE are the protocols cited specifically as one of interest. The text RECOMMDNDS making use of suitable authentication and integrity mechanisms for the relevant protocols to counter both forms of attacks. The text also says that "the mechanisms SHOULD consider how to prevent denial of service attacks."

I find this text to be too vague to be useful. It ought to cite specific mechanisms in RFCs, at least as examples, preferably as recommendations. The lack of specific, cited mechanisms makes this section almost vacuous. I suggest that the authors revise the text here to cite appropriate mechanisms.
--============_-957123881==_ma============-- From hartmans@mit.edu Thu Oct 8 08:08: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 AAF073A6AA4 for ; Thu, 8 Oct 2009 08:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.163, 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 ViMHGjAQRI5V for ; Thu, 8 Oct 2009 08:08:36 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CD8313A6AA2 for ; Thu, 8 Oct 2009 08:08:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id AE07E20205; Thu, 8 Oct 2009 11:10:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7F0CD43C4; Thu, 8 Oct 2009 11:10:01 -0400 (EDT) To: Stephen Kent References: From: Sam Hartman Date: Thu, 08 Oct 2009 11:10:01 -0400 In-Reply-To: (Stephen Kent's message of "Thu\, 8 Oct 2009 06\:40\:31 -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: fluffy@cisco.com, secdir@ietf.org, oran@cisco.com, Gonzalo.Camarillo@ericsson.com, fandreas@cisco.com, dwing@cisco.com, rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 15:08:36 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> I find this text to be too vague to be useful. It ought Stephen> to cite specific mechanisms in RFCs, at least as Stephen> examples, preferably as recommendations. The lack of Stephen> specific, cited mechanisms makes this section almost Stephen> vacuous. I suggest that the authors revise the text here Stephen> to cite appropriate mechanisms. Arje there any? Last time I looked at ICE, it didn't have integrity mechanisms. Also, let's say that you added an integrity mechanism to ICE. How would it help against attacks that prevented media streams from being established? You could defend against attacks that caused media streams to appear to be established. For example in the DTLS SRTP case, if you wait for the DTLS negotiation to conclude, and if you exchanged a fingerprint in SDP, you have fairly high confidence that you did in fact establish the media stream. I don't know how that interacts with everything else going on in this draft. One question I'd ask is how important are these attacks? The first category in particular--DOS attacks that prevent media streams from appearing to establish--seems quite difficult to defend against. Perhaps documenting it as a residual threat would be appropriate. How much detail we go into to the second class of attack seems to depend on how important of a threat it is. If it is relatively unimportant, perhaps it is sufficient to point out that integrity at the media layer bound to an integrity protected exchange at the SDP layer could be sufficient to defeat the attack. I agree with Steve that specific citations to such mechanisms should be included. However if the attack is more important, then perhaps we need to develop this into specific recommendations for common media stream classes. From loa@pi.nu Wed Oct 7 07:16: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 0C8E928C0E6; Wed, 7 Oct 2009 07:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 oRkOqQG2uCPd; Wed, 7 Oct 2009 07:16:17 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 957EE28C0F1; Wed, 7 Oct 2009 07:16:16 -0700 (PDT) Received: from [156.106.216.142] (unknown [156.106.216.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id BCAA2D404F; Wed, 7 Oct 2009 16:17:52 +0200 (CEST) Message-ID: <4ACCA30D.9030206@pi.nu> Date: Wed, 07 Oct 2009 16:17:49 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eric Gray References: <4ACA5FC1.1050704@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 08 Oct 2009 08:19:42 -0700 Cc: "swallow@cisco.com" , "secdir@ietf.org" , "tim.polk@nist.gov" , "Pasi.Eronen@nokia.com" , Scott Mansfield , "iesg@ietf.org" , "hklam@Alcatel-Lucent.com" , "adrian.farrel@huawei.com" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-nm-req-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, 07 Oct 2009 14:16:18 -0000 Tobias, on the being Standards Track or not you are 50% right. ITU/T has changed their rules, but the document we need in the IETF (the IAB boilerplate doc) is not yet published, so I don't want the proposed status changed for requirements. Let us hope that we can do it for the Frameworks. /Loa Eric Gray wrote: > Tobias, > > Thanks for your review and comments. > > The decision to publish this document as a standards > track RFC was based on the previous restriction that ITU-T > cannot refer to an Informational RFC. This restriction > has only just been relaxed to allow references to an RFC > that results from the IETF consensus process, so it may no > longer be necessary to publish this draft as a standards > track RFC. > > That decision is out of my hands. > > Some definitions included are verbatim extractions > from ITU-T publications, taken to avoid the need for a > normative reference to those publications. As such, they > are not actually subject to change and - if you disagree > with them - I would suggest taking it up with applicable > Questions in Study Group 15 at ITU-T. > > We tried to clarify the use of RFC 2119 language in > this document and were somewhat limited in our ability to > do so by the requirements enforced by "idnits" that the > text must appear verbatim in the draft. The intent in - > for example - making a statement that the NE MUST perform > persistency checks is to ensure protocol and management > specifications ensure that doing so is possible based on > configuration. The case where persitistency checking is > effectively disabled by configuration could be considered > the degenerate case where required persistency is zero. > > The intention with alarm suppression is that some > alarms are not desired in some configurations or under > some conditions. Escalation procedures MAY, in certain > situations, result in escalating an alarm condition to one > that is not suppressed. Hence - to directly answer your > question - suppression is permanent for those specific > alarms for which it is configured, and as long as it is > not configured otherwise. > > The instance of "the" that you pointed out should > be changed to "that" as you suggest. > > Again, thanks for the review! > > -- > Eric > > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > Sent: Monday, October 05, 2009 5:06 PM > To: iesg@ietf.org; secdir@ietf.org > Cc: tim.polk@nist.gov; Pasi.Eronen@nokia.com; Eric Gray; Scott Mansfield; hklam@Alcatel-Lucent.com; swallow@cisco.com; loa@pi.nu; adrian.farrel@huawei.com > Subject: Secdir review of draft-ietf-mpls-tp-nm-req-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. > > > 0. From the security perspective, the requirements in this document > appear to be sufficient, though not very detailed. As it's a requirments > doc, this is ok. Obviously, I assume following specifications will be > more detailed in how the described security requirments are satisfied. > > 1. DISCUSS: > Question: as the document describes requirements and is in wide areas > unprecise in how they shall be implemented I wonder why it aims to be > "Standards Track" and not "Informational"? > > 2. COMMENT: > Question: section Terminology: "Fault: A fault is the inability of a > function to perform a required action. This does not include an > inability due to preventive maintenance, lack of external resources, or > planned actions (from [21], 3.26)." > Why does a lack of external resources not constitute a fault? (the other > two reasons I can understand but this one not? > > > 3. COMMENT: > section 5.2: > "The MPLS-TP NE MUST perform persistency checks on fault causes before > it declares a fault cause a failure." > I am not sure whether a "SHOULD" would be more appropriate here: > First, depending on the type of fault a NE my consider a failure after > the first fault cause and > Second, two paragraphs below, you speak of configurable time "A > data-plane forwarding path failure MUST be declared if the fault cause > persists continuously for a configurable time (Time-D). The failure MUST > be cleared if the fault cause is absent continuously for a configurable > time (Time-C)." if it is configurable, it may also be configured to > infinite small, which kind of contradicts with the "MUST" for > persistency check? > > 4. COMMENT: > Section 5.3.2: Question: > should this "An MPLS-TP NE MUST support suppression of alarms based on > configuration." be changed to "An MPLS-TP NE MUST support suppression of > alarms based on configuration and for a limited time." > Or do you may not want to allow infinite and unlimited suppression of > alarms? > > > 6. > s/An MPLS-TP NE MUST support secure management protocols and SHOULD do > so in a manner the reduce potential impact of a DoS attack./An MPLS-TP > NE MUST support secure management protocols and SHOULD do so in a manner > that reduces potential impact of a DoS attack. > > Kind regards, Tobias > > > Tobias Gondrom > email: tobias.gondrom@gondrom.org > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From kent@bbn.com Thu Oct 8 08:24: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 4D8B33A687C for ; Thu, 8 Oct 2009 08:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 wDudE9qeS0Pi for ; Thu, 8 Oct 2009 08:24:14 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CD03628C27B for ; Thu, 8 Oct 2009 08:24:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MvusA-00084W-9q; Thu, 08 Oct 2009 11:25:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 8 Oct 2009 11:23:23 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: fluffy@cisco.com, secdir@ietf.org, oran@cisco.com, Gonzalo.Camarillo@ericsson.com, fandreas@cisco.com, dwing@cisco.com, rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 15:24:15 -0000 At 11:10 AM -0400 10/8/09, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > Stephen> I find this text to be too vague to be useful. It ought > Stephen> to cite specific mechanisms in RFCs, at least as > Stephen> examples, preferably as recommendations. The lack of > Stephen> specific, cited mechanisms makes this section almost > Stephen> vacuous. I suggest that the authors revise the text here > Stephen> to cite appropriate mechanisms. > > >Arje there any? Last time I looked at ICE, it didn't have integrity >mechanisms. Also, let's say that you added an integrity mechanism to >ICE. How would it help against attacks that prevented media streams >from being established? I didn't have anything in mind, but if there are no suitable references, then the RECOMMENDATION is disingenuous and definitely not acceptable, IMHO. >... >One question I'd ask is how important are these attacks? The first >category in particular--DOS attacks that prevent media streams from >appearing to establish--seems quite difficult to defend against. >Perhaps documenting it as a residual threat would be appropriate. I was not making a value judgement about the relative importance of such attacks, just stating what the authors chose to cite as security issues. An alternative would be for the authors to make an argument about why these DoS issues are not significant and thus that these new preconditions introduce no new security considerations. But, that's not what they chose to do. See comment above. Steve From hartmans@mit.edu Thu Oct 8 09:01: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 CBB0128C28B for ; Thu, 8 Oct 2009 09:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=-0.162, 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 9SEWxAtvMRoI for ; Thu, 8 Oct 2009 09:01:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id EBFE928C289 for ; Thu, 8 Oct 2009 09:01:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3BAAB20205; Thu, 8 Oct 2009 12:02:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6CD3643C4; Thu, 8 Oct 2009 12:02:43 -0400 (EDT) To: Stephen Kent References: From: Sam Hartman Date: Thu, 08 Oct 2009 12:02:43 -0400 In-Reply-To: (Stephen Kent's message of "Thu\, 8 Oct 2009 11\:23\:23 -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: fluffy@cisco.com, secdir@ietf.org, oran@cisco.com, Gonzalo.Camarillo@ericsson.com, fandreas@cisco.com, dwing@cisco.com, Sam Hartman , rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 16:01:18 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> At 11:10 AM -0400 10/8/09, Sam Hartman wrote: >> >>>>> "Stephen" == Stephen Kent writes: Stephen> I find this text to be too vague to be useful. It ought Stephen> to cite specific mechanisms in RFCs, at least as Stephen> examples, preferably as recommendations. The lack of Stephen> specific, cited mechanisms makes this section almost Stephen> vacuous. I suggest that the authors revise the text here Stephen> to cite appropriate mechanisms. >> >> >> Arje there any? Last time I looked at ICE, it didn't have >> integrity mechanisms. Also, let's say that you added an >> integrity mechanism to ICE. How would it help against attacks >> that prevented media streams from being established? Stephen> I didn't have anything in mind, but if there are no Stephen> suitable references, then the RECOMMENDATION is Stephen> disingenuous and definitely not acceptable, IMHO. You and I are in complete agreement here. >> ... One question I'd ask is how important are these attacks? >> The first category in particular--DOS attacks that prevent >> media streams from appearing to establish--seems quite >> difficult to defend against. Perhaps documenting it as a >> residual threat would be appropriate. Stephen> I was not making a value judgement about the relative Stephen> importance of such attacks, just stating what the authors Stephen> chose to cite as security issues. An alternative would be Stephen> for the authors to make an argument about why these DoS Stephen> issues are not significant and thus that these new Stephen> preconditions introduce no new security Stephen> considerations. But, that's not what they chose to do. Stephen> See comment above. Stephen> Steve _______________________________________________ Stephen> secdir mailing list secdir@ietf.org Stephen> https://www.ietf.org/mailman/listinfo/secdir We're also in agreement here. However it's my opinion that the authors may want to engage in some thought about their threat model. The primary point of my message was to encourage them to do that. From Sandra.Murphy@cobham.com Thu Oct 8 10:10: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 6772228C0E6 for ; Thu, 8 Oct 2009 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 XoLGWcninGZb for ; Thu, 8 Oct 2009 10:10:26 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2AF0128C1B0 for ; Thu, 8 Oct 2009 10:10:25 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n98HC6Be017736; Thu, 8 Oct 2009 12:12:06 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n98HC5uU004833; Thu, 8 Oct 2009 12:12:05 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 13:12:05 -0400 Date: Thu, 8 Oct 2009 13:12:02 -0400 (Eastern Daylight Time) From: Sandra Murphy To: secdir@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Oct 2009 17:12:05.0276 (UTC) FILETIME=[75A87DC0:01CA483A] Cc: adam.uzelac@globalcrossing.com, yiu_lee@cable.comcast.com Subject: [secdir] a few brief comments on raft-ietf-speermint-voip-consolidated-usecases-14 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, 08 Oct 2009 17:10:27 -0000 I am reviewing this document draft-ietf-speermint-voip-consolidated-usecases-14 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 (that you received well after last call). Feel free to forward to any appropriate forum. This document covers use cases for voip to guide development of work in the speermint wg. As such, it introduces no security concerns. It points to the threats document for discussion of threats related to peering. I did have questions, and attempted to contact the authors at the last IETF, but one author did not attend and the other author and I were not able to meet (and as I missed the last call they wanted to consider only minor changes). The draft discusses five different use cases, some of which have security aspects. The comments below could be covered in the threats document. Static Direct Peering Static Direct Peering (with an assisting LUF and LRF ) Static Indirect Peering (with han assisting LUF and LRF) Static Indirect Peering On-demand Peering The indirect peering cases say that there may be multiple intermediate SSPs between the originating and terminating SSP. There's no discussion of the trust environment for that model (though there is a bit of discussion of the trust involved in outsourcing to an assigting LUF or LRF in the second case). I found mentions in the terminology draft of federations, and imagine that these indirect cases would require a federation model. If that is the case, it should be mentioned here. The terminology draft talks of indirect peering as a single transit SSP, not the multiple intermediate SSPs mentioned here. Some of the discussion of the indirect case here seem to consider only a single transit (so the origin and termination SSPs would both be directly connected to all tansits involved), but section 5.4 says there may be multiple. A federation with a common trust model would work. The direct peering -assisting LUF/LRF case says the the assisting SSP might have other customers and would have to be trusted to separate them all. The common LUF/LRF function uses DNS, which has no mechanism for providing searation like that. However, I'm told that there are implementations that do provide that service. I presume it is OK to rely on an implementation feature and negotiation between the origin and assisting LUF to require such a feature? --Sandy From weiler+secdir@watson.org Thu Oct 8 19:56: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 973DD3A67DA for ; Thu, 8 Oct 2009 19:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 CxYA-nzU-m7K for ; Thu, 8 Oct 2009 19:56:26 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 989EB3A67B5 for ; Thu, 8 Oct 2009 19:56:26 -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 n992w8EK040435 for ; Thu, 8 Oct 2009 22:58:09 -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 n992w81N040432 for ; Thu, 8 Oct 2009 22:58:08 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 8 Oct 2009 22:58:08 -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]); Thu, 08 Oct 2009 22:58:09 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 02:56:27 -0000 Radia Perlman is next in the rotation. Please try to complete last call reviews by the end of the last call. For documents on telechat, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-10-22 Reviewer Deadline Draft Steve Hanna T 2009-10-20 draft-ietf-krb-wg-cross-problem-statement-04 Dan Harkins T 2009-10-20 draft-ietf-dhc-relay-id-suboption-07 David Harrington T 2009-10-20 draft-ietf-dhc-vpn-option-11 Catherine Meadows T 2009-10-20 draft-ietf-eai-pop-07 Last calls and special requests: Reviewer Deadline Draft Rob Austein 2009-10-07 draft-reschke-rfc2731bis-03 Pat Cain 2009-09-30 draft-ietf-vcarddav-carddav-09 Ran Canetti 2009-09-28 draft-ietf-sasl-scram-09 Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-01 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-03 Donald Eastlake None draft-ietf-geopriv-held-identity-extensions-00 Shawn Emery 2009-08-04 draft-ietf-alto-problem-statement-04 Shawn Emery 2009-10-05 draft-ietf-mpls-tp-gach-dcn-06 Stephen Farrell 2009-09-07 draft-ietf-tls-rfc4366-bis-05 Steve Hanna 2009-10-05 draft-ietf-pkix-sha2-dsa-ecdsa-10 Sam Hartman R2009-10-23 draft-hammer-oauth-03 Sam Hartman 2009-10-15 draft-ietf-idnabis-bidi-06 Paul Hoffman 2009-10-15 draft-ietf-idnabis-defs-11 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-04 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-16 Charlie Kaufman 2009-10-13 draft-ietf-idnabis-rationale-13 Scott Kelly 2009-10-15 draft-ietf-idnabis-tables-07 Julien Laganier 2009-01-22 draft-ietf-sip-certs-09 Julien Laganier 2009-06-09 draft-ietf-enum-3761bis-04 Julien Laganier 2009-10-14 draft-ietf-ospf-af-alt-08 Barry Leiba 2009-10-14 draft-ietf-ospf-te-node-addr-06 Chris Lonvick 2009-10-26 draft-melnikov-sasl-scram-ldap-03 David McGrew 2009-10-28 draft-weiler-rsync-uri-01 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Russ Mundy 2009-10-21 draft-ietf-hokey-preauth-ps-09 Sandy Murphy 2009-10-23 draft-nottingham-site-meta-03 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Chris Newman 2009-10-20 draft-ietf-forces-sctptml-06 Magnus Nystrom 2009-11-02 draft-altman-tls-channel-bindings-07 Hilarie Orman 2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-10-07 draft-carpenter-renum-needs-work-03 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-04 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 Glen Zorn 2009-09-17 draft-ietf-rohc-ikev2-extensions-hcoipsec-09 From lunohod.baikonur@googlemail.com Fri Oct 9 11:25: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 2E43128C228 for ; Fri, 9 Oct 2009 11:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.021, 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 wRuzATqJ+4nf for ; Fri, 9 Oct 2009 11:25:17 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 2CB8228C22B for ; Fri, 9 Oct 2009 11:25:17 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so25347qwi.31 for ; Fri, 09 Oct 2009 11:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=CjT2ddB5829gan/VKIMdmAKZx0nccbvvSirOqMXGMj8=; b=awHpE7ClAkzAhWEo5M7WxEISgc/0oQnPfPQR0YIwS+Y0ZjXw9tRqyNX2LCHmyEitxZ tIYlaoQz2RSQ7bpBaR0pvJ+kTjCyy/a/jO7RlOlcuwH0sHhhdGmA9sC3yqIRtc8B2iYO G7pU1ajpxZf7/8wHWfRZZiRkTwcOsbdqaGQrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=Wvta991y9lA+tzZoUIsyOYKYhyCuRVovhFo9NFrgnM9wRA31yhrzMoY69HwRFTs3Gk MlTOT88xAF12wFOCjuPDxeWWlUBsHrszxlsB+9RjxZsaz7F76EihIk5cobmDvqm3VO+o TmkxxMIdLh/tJcjT9tCO7sBbOx3NjlaVu412I= MIME-Version: 1.0 Sender: lunohod.baikonur@googlemail.com Received: by 10.229.32.82 with SMTP id b18mr1871649qcd.10.1255112818609; Fri, 09 Oct 2009 11:26:58 -0700 (PDT) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD3286D2@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328370@il-ex01.ad.checkpoint.com> <7236D8B61D923C0A53A03F7E@caldav.corp.apple.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD3286D2@il-ex01.ad.checkpoint.com> Date: Fri, 9 Oct 2009 19:26:58 +0100 X-Google-Sender-Auth: 1b3c420c83795b7b Message-ID: <29d3c4cb0910091126i38b60642vb9ac8ab929a75f9b@mail.gmail.com> From: Alexey Melnikov To: Yaron Sheffer , tim.polk@nist.gov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Cyrus Daboo , Lisa Dusseault , secdir Subject: Re: [secdir] SecDir review of draft-ietf-calsify-2446bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 18:25:18 -0000 Hi Yaron, On Tue, Sep 22, 2009 at 10:47 PM, Yaron Sheffer wro= te: [...] >> Proposal: >> >> Section 6.2: remove the sentence: >> >> =A0 =A0This may be accomplished using >> =A0 =A0public key technology, specifically Security Multiparts for MIME >> =A0 =A0[RFC1847] in the iTIP transport binding. >> >> Section 6.2.1: change title to: "Securing iTIP transactions" >> >> Change first sentence to: >> >> =A0 =A0iTIP transport bindings MUST provide a mechanism to enable >> authentication of the >> =A0 =A0sender's identity, and privacy and integrity of the data being >> =A0 =A0transmitted. >> >> The reference to 1847 would be removed entirely. > > [YS] If there are still bindings that do use S/MIME, you might want to ha= ve > "if S/MIME is used to provide these assurances..." and the rest of the ex= isting subsection. This text belongs to iMIP (iTIP binding to SMTP), which is a separate document that I am editing. So at this point I think all of your issues were addressed in the latest version posted by Cyrus. Regards, Alexey From shanna@juniper.net Fri Oct 9 12:37: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 8C07B28C12F; Fri, 9 Oct 2009 12:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 DkX08BO0RZQQ; Fri, 9 Oct 2009 12:37:35 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 5D6233A696B; Fri, 9 Oct 2009 12:37:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSs+RZZ0IdsnG/SrlgnZxKad28vhypxg4@postini.com; Fri, 09 Oct 2009 12:39:21 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 9 Oct 2009 12:37:24 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 9 Oct 2009 15:37:23 -0400 From: Stephen Hanna To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-krb-wg-cross-problem-statement@tools.ietf.org" Date: Fri, 9 Oct 2009 15:37:22 -0400 Thread-Topic: secdir review of draft-ietf-krb-wg-cross-problem-statement-04 Thread-Index: AcpI+qkS8jP8gG3tQPe3IferT5xYbQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-krb-wg-cross-problem-statement-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, 09 Oct 2009 19:37:36 -0000 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I apologize for submitting these comments late. This document describes issues that arise during Kerberos cross-realm operation, especially those related to two desired uses of cross-realm Kerberos at Shell. I am not a Kerberos expert although I am fairly familiar with the operation of the protocol. I know a good deal about multi-domain security since I did research in that area for several years at Sun (although mainly with PKI). Since this is a working group draft from the Kerberos WG, I assume that the document has passed WGLC and therefore represents WG consensus. However, I have some concerns. My main concern is that the document seems to be based mainly on the experiences of one customer. Surely there must be many more customers that have used cross-realm Kerberos over the years. If they have run into issues, those should be reflected in the document. If they have not had problems, then I would suggest that the issues are very limited in scope and probably no remedies are needed. We need to consider what's best for the Internet as a whole, not just one customer. Here are my more detailed comments: There is an extra period in the third paragraph of section 1 between "to" and "and". In section 2.1, "limited limit" should be "limited time" and "consists on" should be "consists of" (twice). Also "user access" should be "user accesses". And "anytime" should be "at all times". In section 3, after "sub systems", you need a period not a comma. The phrase "control center" should be "control centers". And "each is named" should be "each one called a". Also, "connected each other" should be "connected to each other". "In the both" should be "in both". In section 3, I suggest replacing this text: Because there is a requirement of the explosion-proof. The requirement restricts the amount of total energy in the device. with this text: These adjustments restrict the amount of total energy in the device, thereby reducing the risk of explosions. Also, I suggest clarification of this text: If it took time for data to reach, they could not be associated. The travel time of data from the device to the other device is demanded within 1 second at least. I think the authors may mean this: In order for one device to control another, the time required for data to travel between the devices cannot be more than one second. The requirements are not really demonstrated from the text above. For example, R-1 says: R-1 It is necessary to partition a management domain into some domains. Or it is necessary to delegate a management authority to another independent management domain. Maybe this is required due to time constraints (the less than one second rule), which lead to latency or performance issues if a single KDC is used. Maybe it is required due to a lack of trust between the entities responsible for managing the domains. The reason for this requirement is not explained so it is not compelling. Similarly, the rationale for R-2 is not described clearly. Couldn't two organizations manage a single Kerberos domain? The issue described in section 5.1 seems to be fundamental to the way that cross-realm operations are performed in Kerberos. If intermediary realms are involved then they need to be trusted. One could address this problem by not having intermediate realms (fully connecting all realms) but this would require many shared keys and therefore not scale well. The issue described in section 5.3 is valid but it has not been demonstrated that a direct trust model is needed. Thanks, Steve From weiler+secdir@watson.org Fri Oct 9 18:22:14 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 F3C393A6874 for ; Fri, 9 Oct 2009 18:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6-3-amQBlUO for ; Fri, 9 Oct 2009 18:22:13 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 1E40228C0F5 for ; Fri, 9 Oct 2009 18:22:12 -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 n9A1NwQP076997 for ; Fri, 9 Oct 2009 21:23:58 -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 n9A1Nv6s076994 for ; Fri, 9 Oct 2009 21:23:58 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 9 Oct 2009 21:23:57 -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, 09 Oct 2009 21:23:58 -0400 (EDT) Subject: [secdir] RFID Experiments at IETF76 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, 10 Oct 2009 01:22:14 -0000 Short version: anyone want to help with some RFID fun in Hiroshima? If so, let me know. Long version: I'm assuming everyone saw the announcement of the RFID experiment to be conducted in Hiroshima. If not, see the IETF list threads "Important Information about IETF 76 Meeting Registration" and "Some more background on the RFID experiment in Hiroshima" from August 18th and September 10th, respectively, as well as: http://www.inet.info.hiroshima-cu.ac.jp/ietf76-exp/index.html#bluesheet While we haven't been given much detail about the system to be used, it's my understanding that the RFID cards have no access control and can be both read and written by anyone. In the late 1990's the security ADs and others had a habit of running password sniffers at SAAG and the IETF plenary, then showing the results to the assembled masses, in the interest of raising public awareness. In that same spirit, I'm thinking of some similar fun with RFID. Anyone interested in helping is more than welcome. More details upon expression of interest. -- Sam From gwz@net-zen.net Sat Oct 10 01:10: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 3842B28C0FC for ; Sat, 10 Oct 2009 01:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggXupvv7xJGv for ; Sat, 10 Oct 2009 01:10:11 -0700 (PDT) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id 3D64428C0E4 for ; Sat, 10 Oct 2009 01:10:11 -0700 (PDT) Received: (qmail 9542 invoked from network); 10 Oct 2009 08:11:57 -0000 Received: from unknown (124.122.162.221) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 10 Oct 2009 08:11:56 -0000 From: "Glen Zorn" To: , , , , , , , Date: Sat, 10 Oct 2009 15:11:31 +0700 Organization: Network Zen Message-ID: <00bc01ca4981$4a40a5c0$dec1f140$@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: AcpJgUZTvvSj8esxQBWoNMBBXN7O9g== Content-Language: en-us Subject: [secdir] secdir review of draft-ietf-rohc-ikev2-extensions-hcoipsec-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: Sat, 10 Oct 2009 08:10:12 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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. COMMENTS General ------- There are lots of occurrences of constructions similar to "The Notify Payload (defined in [IKEV2]) is illustrated in Figure 1." Roughly translated into English, this says "The Notify Payload (defined in the reference to RFC 4306) is illustrated in Figure 1." which, of course is nonsense: the _reference_ to RFC 4306 doesn't define, the document does. Suggest changing all such instances to something like "The Notify Payload (defined in RFC 4302 [IKEV2]) is illustrated in Figure 1." Abstract -------- I can't tell what the intended status of this draft might be (i.e., Standards Track, etc.). The I-D Tracker says that the draft wants to be a Proposed Standard, but there is no reference to RFC 2119 nor any use of 2119 keywords. It might be a good idea to fix this (under the assumption that the editor will do so, I'll not further comment upon 'must' that probably should be 'MUST', etc. There shouldn't be any references in the Abstract. The acronym "ROHC" should be expanded on first usage. Section 2.1 ----------- Paragraph 4 says: A new Notify Message Type value, denoted ROHC_SUPPORTED, indicates that the Notify payload is conveying ROHC channel parameters. The value for the ROHC_SUPPORTED message is specified in Section 4. However, that's not really true: section 4 just says that IANA needs to assign a value. Suggest changing to: A new Notify Message Type value, denoted ROHC_SUPPORTED, indicates that the Notify payload is conveying ROHC channel parameters (Section 4). The description of the Notify Payload fields doesn't include the SPI field or the Notification Data field. Since the SPI Size field is specified to be zero, I would assume that the SPI field itself must be omitted. Is that correct? If so (RFC 4306 isn't crystalline on the subject, either) & since the diagram of the payload and the description are specific to this application, I think the this should be stated, if not illustrated in the diagram itself. Also, I think that the contents of the Notification Data field should be described; maybe something like Notification Data (variable length) (2 octets) This field contains three or more ROHC Attributes (section 2.1.1). I find the headings for this section and the next misleading: this section is headed "ROHC Channel Parameters that are Signaled" when it actually seems to be talking about the "ROHC_SUPPORTED Notify Message", while the next is headed "ROHC_SUPPORTED Notify Message" when it is actually describing "ROHC Attributes". Suggest changing the headings accordingly. Section 2.1.1 ------------- The format and description of the ROHC Attribute are quite confusing: on the one hand, the ROHC Attribute Type field is stated to be 2 octets in length, but on the other hand the actual value is only 15 bits (as reflected in the IANA Considerations section); further, since the length is not reflected in the registry value itself, an implementation would need to set the AF bit (claimed to be, but not, part of the Attribute Type) according to the Attribute type. A different, perhaps more elegant, way to accomplish the same goal might be to dispense with the AF bit altogether and simply specify that fixed-length Attributes are numbered 0x8000-0xFFFF, while variable-length Attributes are allocated from the range 0x0000-0x7FFF. Section 2.1.2 ------------- The sub-headings on the attribute descriptions are disconcerting: since the first paragraph lists the attributes by name (MAX_CID, etc.), I scanned for those in the following paragraphs but was met with textual descriptions (like "Maximum Context Identifier") which might better be placed in the description itself. Suggest changing them to list the name first; it might also be nice to put the actual Attribute number in the header for quick reference. So the suggestion is to change, for example, Maximum Context Identifier (MAX_CID, AF = 1) The MAX_CID attribute is a mandatory attribute. Exactly one to MAX_CID (Maximum Context Identifier, AF = 1) The MAX_CID attribute is a mandatory attribute. Exactly one or (if you accept my numbering suggestion above) MAX_CID (0x8001) The MAX_CID (Maximum Context Identifier) attribute is a mandatory attribute. Exactly one Under ROHC_INTEG it says "The attribute contains an integrity algorithm". I'm assuming that this is actually not true (unless some _really_ amazing advances in compression have occurred recently ;-). Suggest changing to "The attribute value contains the identifier of an integrity algorithm". Under "ROHC_ICV_LEN": The acronym "ICV" should be expanded on first usage. Suggest changing "If ROHC_ICV_LEN length is zero" to "If the value of the ROHC_ICV_LEN attribute is zero" Under "MRRU" it says "If present, the attribute value is two octets in length." but this doesn't seem to make sense. Suggest changing to "The attribute value is two octets in length." From SRS0=U9wYKh=F7=coopercain.com=pcain@yourhostingaccount.com Sat Oct 10 09:12: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 CD0F83A696D; Sat, 10 Oct 2009 09:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.019 X-Spam-Level: *** X-Spam-Status: No, score=3.019 tagged_above=-999 required=5 tests=[AWL=3.204, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVjxpNgnO-EX; Sat, 10 Oct 2009 09:12:00 -0700 (PDT) Received: from mailout07.yourhostingaccount.com (mailout07.yourhostingaccount.com [65.254.253.58]) by core3.amsl.com (Postfix) with ESMTP id EF10F3A68F3; Sat, 10 Oct 2009 09:11:59 -0700 (PDT) Received: from mailscan09.yourhostingaccount.com ([10.1.15.9] helo=mailscan09.yourhostingaccount.com) by mailout07.yourhostingaccount.com with esmtp (Exim) id 1MweZm-0004xO-Js; Sat, 10 Oct 2009 12:13:46 -0400 Received: from impout02.yourhostingaccount.com ([10.1.55.2] helo=impout02.yourhostingaccount.com) by mailscan09.yourhostingaccount.com with esmtp (Exim) id 1MweZm-0004n6-8Q; Sat, 10 Oct 2009 12:13:46 -0400 Received: from authsmtp06.yourhostingaccount.com ([10.1.18.6]) by impout02.yourhostingaccount.com with NO UCE id r4Dl1c00607rVmq0000000; Sat, 10 Oct 2009 12:13:46 -0400 X-EN-OrigOutIP: 10.1.18.6 X-EN-IMPSID: r4Dl1c00607rVmq0000000 Received: from c-76-118-182-57.hsd1.ma.comcast.net ([76.118.182.57] helo=familyroom) by authsmtp06.yourhostingaccount.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim) id 1MweZl-0007jg-SE; Sat, 10 Oct 2009 12:13:45 -0400 Received: from familyroom by familyroom (PGP Universal service); Sat, 10 Oct 2009 12:13:46 -0500 X-PGP-Universal: processed; by familyroom on Sat, 10 Oct 2009 12:13:46 -0500 From: "pat cain" To: , , , , Date: Sat, 10 Oct 2009 12:13:33 -0400 Message-ID: <06f701ca49c4$a17e5830$e47b0890$@coopercain.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpESb12CD4/SJsCQIO+sQrQEY0DDA== 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: "pat cain" X-EN-OrigIP: 76.118.182.57 X-EN-OrigHost: c-76-118-182-57.hsd1.ma.comcast.net Subject: [secdir] secdir review of draft-ietf-vcarddav-carddav-09 (second try) 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, 10 Oct 2009 16:35:34 -0000 [This is a resend; one of the ietf mailers apparently doesn't like me. :( ] 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, draft-ietf-vcarddav-carddav-09, defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. --- The security consideration sections discusses the topics that I would have expected. I have no problems with this document. Pat Cain From dharkins@lounge.org Sat Oct 10 11:11: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 5C9463A67B6; Sat, 10 Oct 2009 11:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPHouxqVc2Bn; Sat, 10 Oct 2009 11:11:17 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id A973D3A6778; Sat, 10 Oct 2009 11:11:17 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8A7C7A888116; Sat, 10 Oct 2009 11:13:04 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 10 Oct 2009 11:13:04 -0700 (PDT) Message-ID: Date: Sat, 10 Oct 2009 11:13:04 -0700 (PDT) From: "Dan Harkins" To: secdir@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dhc-chairs@tools.ietf.org, john_brzozowski@cable.comcast.com, iesg@ietf.org, mjs@cisco.com Subject: [secdir] review of draft-ietf-dhc-relay-id-suboption-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: Sat, 10 Oct 2009 18:11:18 -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 draft defines a sub-option of DHCP's Relay Information Option to identify relay agents. It is straightforward, easy to read, and provides good use cases to justify the need for this sub-option. I think it is ready for publication modulo a couple of minor issues. The Security Considerations mentions that security issues with the Relay Information Option are discussed in RFC 3046 and RFC 4030 but I think it might be a good idea to be a bit more specific and mention the security considerations of the draft in question, even if all it did was say something like, "This memo defines a sub-option of the Relay Information Option and therefore is subject to the security considerations of RFC 3046 and RFC 4030...." The draft defines two types of identifiers to populate this new sub-option, one uses the DHCP Unique Identifier (DUID) and the other is a simple ASCII string. For interoperability purposes, I think one of those should be mandatory-to-implement (I suggest DUID). regards, Dan. From alex@cisco.com Thu Oct 8 22:03: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 1BFE928C14E; Thu, 8 Oct 2009 22:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Znr2RMCv3M1; Thu, 8 Oct 2009 22:03:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B74973A6828; Thu, 8 Oct 2009 22:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=43889; q=dns/txt; s=sjiport02001; t=1255064715; x=1256274315; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Alexander=20Clemm=20(alex)"=20 |Subject:=20RE:=20[secdir]=20secdir=20review=20of=20draft -ietf-syslog-sign-27|Date:=20Thu,=208=20Oct=202009=2022:0 5:12=20-0700|Message-ID:=20<85B2F271FDF6B949B3672BA5A7BB6 2FB089E8F06@xmb-sjc-236.amer.cisco.com>|To:=20"Tina=20TSO U"=20,=20"secdir"=20, =20|Cc:=20, =20,=0D=0A=20=20 =20=20=20=20=20=20"Chris=20Lonvick=20(clonvick)"=20,=0D=0A=20=20=20=20=20=20=20=20,=20,=0D=0A=20=20=20=20 =20=20=20=20"Alexander=20Clemm=20(alex)"=20|MIME-Version:=201.0|In-Reply-To:=20<00a301ca367a$420da 160$8e27460a@china.huawei.com>|References:=20<4AAE56EF.50 80002@ieca.com>=20<006801ca3677$25943b00$8e27460a@china.h uawei.com>=20<00a301ca367a$420da160$8e27460a@china.huawei .com>; bh=EmNNX/vDnbUOJ55ADu5+me+cGpDIZqMsghQQMqZu5Rs=; b=CX/BjX1RepsQ7X+OMyePiP/zzBitFK66iCokB8UPjOervAo2gsRgF6qH reEAjn1oXrv8IA/ga6CcvkLxOgR1apO57HfXT10GT/8eUScrJ+JVCS+bq 7OYHYlHFpKgO5ibp6K1kQgVQyOJ16R7mo+h/pS7JdDJsP6Vx44V4PfvmS w=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAB9hzkqrR7Hu/2dsb2JhbACCJy2/XZg9gjAOgWwE X-IronPort-AV: E=Sophos;i="4.44,530,1249257600"; d="scan'208,217";a="212852784" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2009 05:05:14 +0000 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.14.3) with ESMTP id n9955EKj008547; Fri, 9 Oct 2009 05:05:14 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 22:05:14 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA489E.1575F3FE" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 Oct 2009 22:05:12 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB089E8F06@xmb-sjc-236.amer.cisco.com> In-Reply-To: <00a301ca367a$420da160$8e27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] secdir review of draft-ietf-syslog-sign-27 Thread-Index: Aco2ek7wTFF8WPJFQGWjDynwgpqBowSIAsAQ References: <4AAE56EF.5080002@ieca.com> <006801ca3677$25943b00$8e27460a@china.huawei.com> <00a301ca367a$420da160$8e27460a@china.huawei.com> From: "Alexander Clemm (alex)" To: "Tina TSOU" , "secdir" , X-OriginalArrivalTime: 09 Oct 2009 05:05:14.0003 (UTC) FILETIME=[15BA1630:01CA489E] X-Mailman-Approved-At: Sun, 11 Oct 2009 23:40:45 -0700 Cc: draft-ietf-syslog-sign@tools.ietf.org, Pasi.Eronen@nokia.com, syslog-chairs@tools.ietf.org, "Alexander Clemm \(alex\)" Subject: Re: [secdir] secdir review of draft-ietf-syslog-sign-27 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, 09 Oct 2009 05:03:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA489E.1575F3FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Thank you for your review. Please see responses, inline, delimited with . Please let me know if you feel that those responses adequately resolve the issue, or clarify any problems that you feel have not been adequately addressed. =20 =20 Thank you and kind regards --- Alexander Clemm =20 From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Tuesday, September 15, 2009 8:03 PM To: secdir; iesg@ietf.org Cc: syslog-chairs@tools.ietf.org; draft-ietf-syslog-sign@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-syslog-sign-27 =20 Sending to draft-ietf-syslog-sign@tools.ietf.org =20 =20 B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message -----=20 From: Tina TSOU =20 To: iesg@ietf.org ; secdir =20 Cc: draft-ietf-syslog-sign-27@tools.ietf.org ; syslog-chairs@tools.ietf.org=20 Sent: Wednesday, September 16, 2009 10:41 AM Subject: [secdir] secdir review of draft-ietf-syslog-sign-27 =20 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IESG.=20 These comments were written primarily for the benefit of the security=20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last call comments. In general, from the security point of view, this draft does not specify what=20 the loghost should do in case of packet loss, DoS attack, etc. Should the=20 device try to retrieve the sys log information again?=20 =20 Section 1, third paragraph (talking about Certificate Block): not to=20 over-complicate matters, but this is really talking about the content of a=20 Payload Block. Rather than introduce that term, perhaps rephrase the paragraph=20 slightly to make clear that multiple Certificate Blocks may be used. What's the key management information here? Is it Certificate information or public key information? =20 Additionally, a signer sends Certificate Blocks to provide key management information between the signer and the collector. A Certificate Block has a field to denote the type of key material which may be such things as a PKIX certificate, an OpenPGP certificate, or even an indication that a key had been pre- distributed. In the cases of certificates being sent, the certificates may have to be split across multiple Certificate Blocks carried in separate messages. =20 Change accepted =20 =20 Section 1, fifth paragraph, first sentence: not clear what "previous" refers to.=20 The phrase "of the previous messages" doesn't seem to add anything and can be=20 dropped. Suggest adding "syslog" after "received" and "corresponding" before=20 "Signature Block", so the sentence reads: =20 The collector may verify that the hash of each received syslog message matches the signed hash contained in the corresponding Signature Block. =20 Change accepted =20 =09 Section 4.2.3: It is strongly suggested that the field currently identified as=20 Signature Group (SG) be renamed to Signature Group Interpretation (SGI) to avoid=20 confusion. The statement that SPRI identifies the actual signature group also=20 comes a bit late (beginning of the fourth paragraph). It should be moved up to=20 the first paragraph. =20 Note that changing SG to SGI affects the tables in section 4.2 and 5.3.2 and IANA considerations. Note also that the field is called SIG instead of SG in section 5.3.2.3. =20 There does not seem to be a need for that change - section 4.2.3 contains an additional clarification which clearly points out the difference between SG field and the Signature Group itself; this should be sufficient. =20 =09 In section 5.3.2, P23, what's the main difference between using Signature block and using Certificate block? It seems Certificate Block overlaps with Signature Block, e.g., Both block are digitally signed, why is only certificate block termed "certificate block", why not term certificate block as "signature block"? =20 =20 The question is confusing. The difference between Signature Block and Certificate Block should be clear (as also evidenced from the proposed text in the first comment) and there should be no issue that they might be confused. Signature Blocks contain the signatures of previously sent messages, whereas Certificate Blocks contain key material - two very distinct purposes. No changes are made. =20 In section 5.3.2.9, the point is made that the timestamp of the Certificate=20 Block message is the same as that of the Payload Block. In fact, they differ=20 very slightly in the example. Is that intended? =20 =20 Proposed wording change as follows: Note that the Certificate Block message in this example has a time stamp that is very close to the time stamp in the Payload Block. =20 The fact that the time stamps are so close implies that this is the first=20 Certificate Block message sent in this reboot session; additional Certificate Block messages can be=20 sent later with a later time stamp, which will carry the same Payload Block=20 that will still contain the same time stamp. =20 =20 In section 6, near the bottom of the first paragraph, a couple of words are=20 missing. It is suggested that the sentence be changed to read: =20 =09 The collector MUST ignore duplicates of Signature Blocks and Certificate ^^^^^^^^^^^^^^ Blocks it has already received and authenticated. =20 Suggested change is accepted. There does not seem to be compelling reason to change the structure at this point, propose to keep as is. The last message number is in fact introduced in item b. As it is stated there clearly, it is a cursor that is maintained by the collector to keep track of the point to which it has received message signatures. Additional explanation does not appear to be necessary. =20 =20 =09 In section 8.1, This specification uses Public Key Cryptography technologies. The proper party or parties have to control the private key portion of a public-private key pair. Any party that controls a private key can sign anything it pleases. =20 As regarding the last sentence, Is it appropriate to use "pleases" here? How about using *favors* or *prefers* instead of *pleases*? =20 "Pleases" appears to be the appropriate term in this context - it expresses that it can in effect do whatever it wants - "favors" or "prefers" would imply there are a choices to select between, which does not sound quite right in this context. No change is made. =20 =20 =09 In section 8.2, As a signer, it is advisable to avoid message lengths exceeding 2048 octets. Various problems might result if a signer were to send messages with a length greater than 2048 octets, because relays MAY truncate messages with lengths greater than 2048 octets which would make it impossible for collectors to validate a hash of the packet. To increase the chance of interoperability, it tends to be best to be conservative with what you send but liberal in what you are able to receive. =20 From the above paragraph, we can see it is necessary to restrict the length of message, So I would like to suggest changing the last sentence as: " To increase the chance of interoperability, it tends to be best to=20 limit the length of what you send but loose what you are able to receive. " to make it more precise. Is it reasonable to do this? =09 =09 The "conservative" and "liberal" saying dates back to Jon Postel and RFC 760. We think this should stay as is. =20 =20 =20 In section 8.3, Syslog does not strongly associate the message with the message originator. That association is established by the collector upon verification of the Signature Block.=20 =20 What's the difference between associating the message with the message originator and signature? If they are the same thing, I think the association should be pre-established in collector? Is it a correct understanding? =09 =09 It is up to facility and application-ID to indicate who or what actually triggered the original message; for the purposes of this here, "originator" refers to the sender of the message, not the source of the event that triggers the sending of the message. The wording should stand. =20 =20 =20 =09 =20 In section 8.4, Event messages might be recorded and replayed by an attacker. Using the information contained in the Signature Blocks, a reviewer can determine whether the received messages are the ones originally sent by an originator. The reviewer can also identify messages that have been replayed. =20 I am wondering what the information is in the signature block can be used to prevent replaying? Count or sequence number, time stamp, if there is such thing, it is better to point it out which field of signature block is used for anti-replaying. =20 =20 Section 7 implicitly explains how messages can be identified that have been replayed. In that case, in step 3.b (section 7.1), the authenticated log file would already contain the message. Step 3.b does not explicitly state to flag the fact that a replayed message was received, but adding such a capability if desired would be near-trivial (and IMHO hence does not need to be explained) and in any event the authenticated log file would clearly contain only one instance of the authenticated message. =20 To make it even clearer, the following wording is added to section 8.4: =20 Using the methods for verification of logs=20 outlined in Section 7, a replayed message can be detected by checking prior to writing a message to the authenticated log file whether the message is=20 already contained in it. =20 =20 =20 =20 B. R. Tina http://tinatsou.weebly.com/contact.html =20 =20 =20 =20 ________________________________ _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir ------_=_NextPart_001_01CA489E.1575F3FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thank you for your review.  Please see responses, = inline, delimited with <ALEX>.  Please let me know if you feel that = those responses adequately resolve the issue, or clarify any problems that you = feel have not been adequately addressed. 

 

Thank you and kind regards

--- Alexander Clemm

 

From:= Tina TSOU [mailto:tena@huawei.com]
Sent: Tuesday, September 15, 2009 8:03 PM
To: secdir; iesg@ietf.org
Cc: syslog-chairs@tools.ietf.org; = draft-ietf-syslog-sign@tools.ietf.org
Subject: Re: [secdir] secdir review of = draft-ietf-syslog-sign-27

 

 

 

B. R.
Tina

----- Original Message -----

From: Tina TSOU

To: iesg@ietf.org = ; secdir =

Sent:<= /b> Wednesday, = September 16, 2009 10:41 AM

Subject: [secdir] = secdir review of draft-ietf-syslog-sign-27

 

I have reviewed this document as part of the = security directorate's
ongoing effort to review all IETF documents being processed by the IESG. =
  These comments were written primarily for the benefit of the = security
area directors.  Document editors and WG chairs should treat these =
comments just like any other last call comments.
In general, from the security point of view, this draft does not specify = what
the loghost should do in case of packet loss, DoS attack, etc. Should = the
device try to retrieve the sys log information again?
 
Section 1, third paragraph (talking about Certificate Block): not to =
over-complicate matters, but this is really talking about the content of = a
Payload Block. Rather than introduce that term, perhaps rephrase the = paragraph
slightly to make clear that multiple Certificate Blocks may be used. = What's the key management information here? Is it Certificate information or public = key information?

 

    Additionally, a signer sends = Certificate Blocks to provide key
    management information between the signer and the collector.  A
    Certificate Block has a field to denote the type of = key material
    which may be such things as a PKIX certificate, an = OpenPGP
    certificate, or even an indication that a key had = been pre-
    distributed.  In the cases of certificates being = sent, the
    certificates may have to be split across multiple Certificate
    Blocks carried in separate messages.

 

<ALEX>  Change accepted 

</ALEX>

 

Section 1, fifth paragraph, first sentence: not = clear what "previous" refers to.
The phrase "of the previous messages" doesn't seem to add = anything and can be
dropped. Suggest adding "syslog" after "received" = and "corresponding" before
"Signature Block", so the sentence reads:

 

    The collector may verify that = the hash of
    each received syslog message matches the signed hash contained in the
    corresponding Signature Block.

 

 <ALEX> Change accepted

</ALEX>

 


Section 4.2.3: It is strongly suggested that the field currently = identified as
Signature Group (SG) be renamed to Signature Group Interpretation (SGI) = to avoid
confusion. The statement that SPRI identifies the actual signature group = also
comes a bit late (beginning of the fourth paragraph). It should be moved = up to
the first paragraph.

 

Note that changing SG to SGI affects the tables in = section 4.2 and 5.3.2 and IANA considerations. Note also that the field is = called SIG instead of SG in section 5.3.2.3.

 

<ALEX>  There does not seem to be a need for that change - section 4.2.3 contains an additional clarification which clearly points out the difference between = SG field and the Signature Group itself; this should be = sufficient.

</ALEX>

 


In section 5.3.2, P23, what's the main difference between using = Signature block and using Certificate block? It seems Certificate Block overlaps with = Signature Block, e.g., Both block are digitally signed, why is only certificate = block termed "certificate block", why not term certificate block as "signature block"?

 

<ALEX>  =

The question = is confusing.  The difference between Signature Block and Certificate = Block should be clear (as also evidenced from the proposed text in the first = comment) and there should be no issue that they might be confused.  = Signature Blocks contain the signatures of previously sent messages, whereas = Certificate Blocks contain key material - two very distinct purposes.  No = changes are made.

</ALEX>

 

In section 5.3.2.9, the point is made that the = timestamp of the Certificate
Block message is the same as that of the Payload Block. In fact, they = differ
very slightly in the example. Is that intended?

 

<ALEX> =

Proposed = wording change as follows:

        &= nbsp;           &n= bsp;  Note that the Certificate Block message in this example has a time = stamp

        &= nbsp;           &n= bsp;  that is very close to the time stamp in the Payload Block.  =

        &= nbsp;           &n= bsp;  The fact that the time stamps are so close implies that this is the first =

        &= nbsp;           &n= bsp;  Certificate Block message

        &= nbsp;           &n= bsp;  sent in this reboot session; additional Certificate Block messages can be =

        &= nbsp;           &n= bsp;  sent later with a later time stamp, which will carry the same Payload Block =

        &= nbsp;           &n= bsp;  that will still contain the same time stamp.  =

</ALEX>

 

In section 6, near the bottom of the first = paragraph, a couple of words are
missing. It is suggested that the sentence be changed to = read:

 

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;           The
    collector MUST ignore duplicates of Signature Blocks = and Certificate
            &= nbsp;           &n= bsp; ^^^^^^^^^^^^^^
    Blocks it has already received and = authenticated.

 

<ALEX>

Suggested change is = accepted.

</ALEX

 

Section 7 is informative. Perhaps it belongs in an = appendix.
 

<ALEX>

There does not seem to be compelling reason to change the structure at this point, propose to keep as = is.

</ALEX


In section 7.1,
 4.  Set the last message number processed to the value of = the
           First = Message Number plus the Count of the Signature Block
           minus = 1.
Why is the Last message number not defined in this document?
 

<ALEX>

The last = message number is in fact introduced in item b.  As it is stated there clearly, it = is a cursor that is maintained by the collector to keep track of the point to = which it has received message signatures.  Additional explanation does = not appear to be necessary. 

</ALEX>

 


In section 8.1,
 This specification uses Public Key Cryptography = technologies.  The
   proper party or parties have to control the private key = portion of a
   public-private key pair.  Any party that controls a = private key can
   sign anything it pleases.
 
As regarding the last sentence, Is it appropriate to use = "pleases" here? How about using *favors* or *prefers* instead of *pleases*?
 

<ALEX>

"Pleases" appears to be the appropriate term in this context - it expresses that it can in = effect do whatever it wants - "favors" or "prefers" would = imply there are a choices to select between, which does not sound quite right = in this context.  No change is made. 

</ALEX>

 


In section 8.2,
As a signer, it is advisable to avoid message lengths exceeding 2048
   octets.  Various problems might result if a signer = were to send
   messages with a length greater than 2048 octets, because = relays MAY
   truncate messages with lengths greater than 2048 octets = which would
   make it impossible for collectors to validate a hash of the packet.
   To increase the chance of interoperability, it tends to be = best to be
   conservative with what you send but liberal in what you are = able to
   receive.
 
   From the above paragraph, we can see it is necessary to = restrict
   the length of message, So I would like to suggest changing = the last
   sentence as:
   "
   To increase the chance of interoperability, it tends to be = best to
   limit the length of what you send but loose what you are = able to
   receive.
   "
   to make it more precise. Is it reasonable to do this?

<ALEX>

The “conservative” and “liberal” = saying dates back to Jon Postel and RFC 760.  We think this should stay as is. 

</ALEX>

 
 
In section 8.3,
Syslog does not strongly associate the message with the message
   originator.  That association is established by the = collector upon
   verification of the Signature Block.
  
What's the difference between associating the message with the message originator
and signature? If they are the same thing, I think the association = should be pre-established
in collector? Is it a correct understanding?

<ALEX>

 It is up to facility and application-ID to = indicate who or what actually triggered the original message; for the purposes of = this here, "originator" refers to the sender of the message, not the = source of the event that triggers the sending of the message.  The wording = should stand. 

</ALEX>

 


 
In section 8.4,
Event messages might be recorded and replayed by an attacker.  = Using
   the information contained in the Signature Blocks, a = reviewer can
   determine whether the received messages are the ones = originally sent
   by an originator.  The reviewer can also identify = messages that have
   been replayed.

 

I am wondering what the information is in the = signature block can be used to
prevent replaying? Count or sequence number, time stamp, if there is = such thing, it is better to
point it out which field of signature block is used for = anti-replaying.
 
<ALEX> =

Section 7 = implicitly explains how messages can be identified that have been replayed.  = In that case, in step 3.b (section 7.1), the authenticated log file would = already contain the message.  Step 3.b does not explicitly state to flag = the fact that a replayed message was received, but adding such a capability if = desired would be near-trivial (and IMHO hence does not need to be explained) and = in any event the authenticated log file would clearly contain only one instance = of the authenticated message. 

To make it = even clearer, the following wording is added to section = 8.4:

 

        &= nbsp;           &n= bsp;  Using the methods for verification of logs

        &= nbsp;           &n= bsp;  outlined in Section 7, a replayed message can be detected by = checking

        &= nbsp;           &n= bsp;  prior to writing a message to the authenticated log file whether the message = is

        &= nbsp;           &n= bsp;  already contained in it.

</ALEX>

 
 
 

 

 

 

 

 

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir

------_=_NextPart_001_01CA489E.1575F3FE-- From Paul_Sangster@symantec.com Mon Oct 12 11:23:59 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 035C428C222; Mon, 12 Oct 2009 11:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhQC1WpwCS12; Mon, 12 Oct 2009 11:23:57 -0700 (PDT) Received: from extu-mxob-2.symantec.com (extu-mxob-2.symantec.com [216.10.194.135]) by core3.amsl.com (Postfix) with ESMTP id AC6C528C1DD; Mon, 12 Oct 2009 11:23:57 -0700 (PDT) Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by extu-mxob-2.symantec.com (8.14.1/8.14.1) with ESMTP id n9CINquB011727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2009 11:23:52 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1MxPYm-0001uA-8L; Mon, 12 Oct 2009 11:23:52 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 11:23:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 11:23:50 -0700 Message-ID: In-Reply-To: <4ACB7133.3070409@gondrom.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-nea-pa-tnc-04.txt Thread-Index: AcpGoqt8LLhFfYFtS7WkhToyUx4MKgEwnDcw References: <4ACB7133.3070409@gondrom.org> From: "Paul Sangster" To: "Tobias Gondrom" , , X-OriginalArrivalTime: 12 Oct 2009 18:23:52.0632 (UTC) FILETIME=[26B1DB80:01CA4B69] X-Mailman-Approved-At: Mon, 12 Oct 2009 23:28:16 -0700 Cc: tim.polk@nist.gov, Pasi.Eronen@nokia.com, kaushik@cisco.com Subject: Re: [secdir] Secdir review of draft-ietf-nea-pa-tnc-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:23:59 -0000 =20 > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org]=20 > Sent: Tuesday, October 06, 2009 9:33 AM > To: iesg@ietf.org; secdir@ietf.org > Cc: tim.polk@nist.gov; Pasi.Eronen@nokia.com;=20 > shanna@juniper.net; sethomso@cisco.com; kaushik@cisco.com;=20 > Paul Sangster > Subject: Secdir review of draft-ietf-nea-pa-tnc-04.txt >=20 > I have reviewed this document as part of the security=20 > directorate's ongoing effort to review all IETF documents=20 > being processed by the IESG. > These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs=20 > should treat these comments just like any other last call comments. Thanks for the review, some comments and questions below... >=20 >=20 > First and for all: from the security perspective, I see a=20 > major issue which is discussed in my last point #5. The=20 > remaining issues are minor comments:=20 >=20 >=20 > 0. This draft is closely linked to one other work-in-progress=20 > draft draft-ietf-nea-pb-tnc-05 which is also linked as=20 > normative references. draft-ietf-nea-pa-tnc MUST ONLY proceed=20 > if the normative referred doc can advance as well.=20 Agreed, this is what the working group had in mind as well. >=20 >=20 > 1. COMMENT: section 4.1, page 17: > Question: could Bit 0 (0x80), the NOSKIP flag, result in a=20 > kind of Denial of Service vulnerability: client sneaking in=20 > on message in a whole collection and thus disabling the=20 > evaluation of all, although all prerequisites for a network=20 > endpoint to be serviced are fulfilled? Not sure I understand the question. The Posture Validator (on the NEA Server) would have policy that dictates what information it must receive from the client. If the client chose to send less attributes (e.g. privacy filter) or unsupported attributes were sent with NOSKIP, this could just prevent the endpoint for gaining access to the requested resource (e.g. network access) or asset. Is this the case you had in mind? If so, it doesn't seem to be a security threat just an issue with the NEA client's configuration. >=20 >=20 > 2. COMMENT: section 4.1. paragraph "PA-TNC Attribute Length" > Question: maybe the paragraph would want to state what=20 > happens if the length is incorrect: recommendation would be=20 > that in such a case the length should be considered as a hint=20 > and parsed for the begin of the next messages and the=20 > following messages can (SHOULD?) still be parsed and interpreted. Section 4.1 pretains to the Attribute Header TLV, so we could beef up the discussion of *if* the recipient is aware that the length field is incorrect what it should do. We suggest that it should send an error attribute like it does when its known to be too small. Incorrect length values can cause some real problems so its best to error out if one is detected. For example, variable length attributes without another embedded/correct length field or unknown attributes can't be skipped if the length isn't known. >=20 >=20 > 3. COMMENT: 4.2.6. Port Filter > considering potential size limits for messages, might it be a=20 > good idea to allow ranges of port numbers (e.g. B 220-8000)=20 > instead of a (potentially larger) list of port numbers? We believe we can support port filter lists with the current syntax. In order to help send less traffic we allow for the sender to either send blocked ports or allowed ports using the B flag. Frequently the endpoint only allows a very small number of allowed inbound ports so the report is very short since everything else is blocked. >=20 > =20 > 4. COMMENT: 4.2.11. Forwarding Enabled > just a hinge: if forwarding is enabled, might it be helpful=20 > to add a qualifier about the allowed forwarding addresses, so=20 > that the server can determine whether this is acceptable=20 > within the policy. (forwarding to addresses within the same=20 > network subunit may be acceptable?) This attribute is to detect forwarding of network traffic across network interfaces (e.g. not allowing endpoints VPNing into network to have another connection to Internet). The most common customer request is to not allow bridging/routing traffic across networks at all and we wanted to avoid trying to express forwarding policy inside this attribute. If a need to be more specific is raised we could add an additional attribute to cover this case using the attribute extensibility model. >=20 >=20 > 5. DISCUSS: 5. Security Consideration: > This section mentions that "PA-TNC security protocols are=20 > described in separate specifications which layer upon the=20 > base PA-TNC protocol described in this specification." > Actually, I have not seen this security protocol on the WG=20 > page and am quite worried about this. (I found an old=20 > 00-version that expired August 2008, I have not reviewed its=20 > content.) PA-TNC can disclose a lot about the security=20 > properties of an endpoint and actually also of a server=20 > landscape. Therefore it MUST be ensured that the requests and=20 > responses are made by authorized parties (and e.g. not by any=20 > network the client stumbles upon). In fact for the protocol=20 > both parties must be authenticated and authorized. Sections=20 > 5.2.1. to 5.2.6 describe nicely a variety of threats if this=20 > is not fulfilled. And this is correct. But the draft is short=20 > on how to prevent these risks.=20 We will update the sections mentioning the security protocol and highlight better how/when PT security is addressing a particular threat. Based upon the trust model (in section 5.1 and the use cases in scope for the NEA charter - no remote Posture Validators or Posture Collectors), the NEA WG opt'ed to not pursue a PA-TNC security protocol. We will add text explaining this to the next revision. >=20 > Section 5.1. and 5.2. recognize the importance of trusted=20 > counterparties in the communication, but seem to ignore that=20 > PA-TNC SHOULD NOT (or even MUST NOT) be used without=20 > mechanisms allowing this bi-lateral trust.=20 >=20 > To ensure interoperability the authentication mechanism=20 > SHOULD use common standard mechanisms and could include them=20 > in this document. (even if it would be just as simple as e.g.=20 > use TLS two-party authentication, or other means deemed=20 > appropriate by the WG).=20 The RFC 5209 discusses these requirements in section 7.2 including: " PT-2 The PT protocol MUST be capable of supporting mutual authentication, integrity, confidentiality, and replay protection of the PB messages between the Posture Transport Client and the Posture Transport Server." This requirement will guide the selection of NEA standard PT protocols (the next working group work item). Because of this requirement, PA is able to be confident that such security mechanisms exist in the PT protocol. >=20 > Summarizing: the draft should add one or more of the following:=20 > 1.A common authentication mechanism to be used. > 2.That PA-TNC MUST use an underlying protocol that ensures=20 > two-side authentication and evaluate the the authentication=20 > data to decide on authorization of disclosure of data.=20 > 3.PA-TNC is only valid in conjunction with the mentioned=20 > PA-TC security protocol which is not specified, yet? See above >=20 > Probably the easiest solution would be to add a section to=20 > the security considerations:=20 > "PA-TNC MUST use means of two-side authentication to ensure=20 > the required underlying trust relationship between both=20 > parties is not exploited. <...continue with more text...>" PA-TNC will be able to determine the authenticated identities passed up the stack by PT. This PT strong authentication will be used to establish the trust relationship and is the basis for several policy decisions by the NEA Client (e.g. privacy, trust). Since PA-TNC is enveloped in the PT protocol (via the PB protocol) it will be bound to PT's trust decisions using the peer's identity. >=20 > Please excuse me for being that strong about it, but I can=20 > lterally imagine dozens of potential security exploits if=20 > this would be implemented without good underlying security=20 > mechanisms. And from my understanding the current draft does=20 > not "REQUIRE" underlying security, which worries me. I like=20 > the draft's concept, but believe it must add a bit more=20 > towards secure use to be released. But maybe I just missed something?=20 =20 Understandable and of course we are concerned about such attacks as well. The NEA architecture forces PA-TNC to operate on top of PB and PT where the security protections are present. PA by requirement C-4 MUST not be aware of what PT is running below but it can leverage the PT authenticated identities with confidence since PT is required to support strong security in requirement PT-2. > Kind regards, Tobias >=20 >=20 > Tobias Gondrom > email: tobias.gondrom@gondrom.org >=20 >=20 From anthonybryan@gmail.com Mon Oct 12 23:26: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 C6ED228C0F8 for ; Mon, 12 Oct 2009 23:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8fvaVlVevs1 for ; Mon, 12 Oct 2009 23:26:25 -0700 (PDT) Received: from mail-yx0-f199.google.com (mail-yx0-f199.google.com [209.85.210.199]) by core3.amsl.com (Postfix) with ESMTP id EC82D3A6914 for ; Mon, 12 Oct 2009 23:26:24 -0700 (PDT) Received: by yxe37 with SMTP id 37so3432382yxe.31 for ; Mon, 12 Oct 2009 23:26:23 -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; bh=eHiahTvgCcx8dTEz8OpEd09uwoikgy0A0tHncTvU3a8=; b=v2kvPYyfYubEFcdJfid+0pOhEB0wa2L/15H4/TxL+UIWTMy13jeX/9uH5GFeQhXEqk 274VywxtNbRRLyhrTJSsvPJzhdF/eA5zlB/pzUSxl6xatIPRgY/7juRT4dwpsLqgBm+M lGZk3zPW7ITR8uFO90Yn8vKMGEcZKSQ8N/fqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Q9PbqAMFMhOC87Vh3pM+Y99mIFFarzO8965iKp7LtV6AIdao9MxGgpK6qEZ9Gw1upY H618ud5QxWMecp4eFwxvEwPQBEOGtAWSaln1m/WcEyoYDsg2M/xbNtT27sGR9+HQWS19 rOoDQpXVRcgSHfGGAY4oTjXrDFPDqBhQaGbGw= MIME-Version: 1.0 Received: by 10.150.113.3 with SMTP id l3mr11869337ybc.90.1255415182364; Mon, 12 Oct 2009 23:26:22 -0700 (PDT) Date: Tue, 13 Oct 2009 02:26:22 -0400 Message-ID: From: Anthony Bryan To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 12 Oct 2009 23:28:16 -0700 Subject: [secdir] Request for early review of draft-bryan-http-digest-algorithm-values-update 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, 13 Oct 2009 06:26:25 -0000 Lisa Dusseault suggested I ask for early review here. All help is appreciated! A new version of I-D, draft-bryan-http-digest-algorithm-values-update-01.txt has been successfuly submitted by Anthony Bryan and posted to the IETF repository. Filename: draft-bryan-http-digest-algorithm-values-update Revision: 01 Title: Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registry Update Creation_date: 2009-10-07 WG ID: Independent Submission Number_of_pages: 5 Abstract: [RFC3230] created the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" which defines values for digest algorithms used in HTTP. This draft adds new values to the registry and updates previous values. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From Pasi.Eronen@nokia.com Mon Oct 12 23:54:47 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 7D32728C111 for ; Mon, 12 Oct 2009 23:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWxS4m+5xQ5D for ; Mon, 12 Oct 2009 23:54:46 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CCE453A6895 for ; Mon, 12 Oct 2009 23:54:46 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9D6sYhX008051 for ; Tue, 13 Oct 2009 01:54:47 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:54:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:54:07 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 13 Oct 2009 08:54:06 +0200 From: To: Date: Tue, 13 Oct 2009 08:54:05 +0200 Thread-Topic: Security Directorate lunch in IETF76 Thread-Index: AcpL0fS7kzjG7/SAS5i9jLL6XFPFUQ== Message-ID: <808FD6E27AD4884E94820BC333B2DB773C099C1126@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: 13 Oct 2009 06:54:07.0628 (UTC) FILETIME=[F5B924C0:01CA4BD1] X-Nokia-AV: Clean Subject: [secdir] Security Directorate lunch in IETF76 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, 13 Oct 2009 06:54:47 -0000 As usual, we're planning to have the Security Directorate=20 lunch on Tuesday. We'll send the details (such as room number) when we get them. If there's anything special you'd like to discuss, please drop an email to Tim and me. Best regards, Pasi & Tim From uri@MIT.EDU Tue Oct 13 10:31:03 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 697A13A697C for ; Tue, 13 Oct 2009 10:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 gwQPy+2jjiiT for ; Tue, 13 Oct 2009 10:31:02 -0700 (PDT) Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by core3.amsl.com (Postfix) with ESMTP id 26BDB3A690D for ; Tue, 13 Oct 2009 10:31:01 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n9DHUYqq016221; Tue, 13 Oct 2009 13:30:48 -0400 (EDT) Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by central-city-carrier-station.mit.edu (8.13.6/8.9.2) with ESMTP id n9DGxmNl008596; Tue, 13 Oct 2009 12:59:53 -0400 (EDT) Received: from webmail-6.mit.edu (WEBMAIL-6.MIT.EDU [18.9.23.16]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id n9DGxg0M011394; Tue, 13 Oct 2009 12:59:43 -0400 (EDT) Received: from webmail-6.mit.edu (webmail-6.mit.edu [127.0.0.1]) by webmail-6.mit.edu (8.13.8) with ESMTP id n9DGoi5u002610; Tue, 13 Oct 2009 12:50:44 -0400 Received: (from nobody@localhost) by webmail-6.mit.edu (8.13.8/8.13.8/Submit) id n9DGoi0e002608; Tue, 13 Oct 2009 12:50:44 -0400 X-Authentication-Warning: webmail-6.mit.edu: nobody set sender to uri@mit.edu using -f Received: from LLPROXY.LL.MIT.EDU (LLPROXY.LL.MIT.EDU [129.55.200.20]) (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Tue, 13 Oct 2009 12:50:44 -0400 Message-ID: <20091013125044.szphqm8fb4s80gk8@webmail.mit.edu> X-Priority: 3 (Normal) Date: Tue, 13 Oct 2009 12:50:44 -0400 From: Uri Blumenthal To: Anthony Bryan References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Scanned-By: MIMEDefang 2.42 Cc: secdir@ietf.org Subject: Re: [secdir] Request for early review of draft-bryan-http-digest-algorithm-values-update 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, 13 Oct 2009 17:31:03 -0000 I've reviewed this draft. It just adds more hash functions to HTTP Digest mechanism, and as such - does not add any security exposures beyond those discussed in RFC 3230 and 2617. I'm OK with it. Quoting Anthony Bryan : > Lisa Dusseault suggested I ask for early review here. All help is > appreciated! > > A new version of I-D, > draft-bryan-http-digest-algorithm-values-update-01.txt has been > successfuly submitted by Anthony Bryan and posted to the IETF > repository. > > Filename: draft-bryan-http-digest-algorithm-values-update > Revision: 01 > Title: Hypertext Transfer Protocol (HTTP) Digest Algorithm > Values Registry Update > Creation_date: 2009-10-07 > WG ID: Independent Submission > Number_of_pages: 5 > > Abstract: > [RFC3230] created the IANA registry named "Hypertext Transfer > Protocol (HTTP) Digest Algorithm Values" which defines values for > digest algorithms used in HTTP. This draft adds new values to the > registry and updates previous values. > > -- > (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] > )) Easier, More Reliable, Self Healing Downloads > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From hartmans@mit.edu Tue Oct 13 11:47: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 9D93F28C22B; Tue, 13 Oct 2009 11:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 ofLnkVBCdznc; Tue, 13 Oct 2009 11:47:05 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B05613A657C; Tue, 13 Oct 2009 11:47:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9416D2045D; Tue, 13 Oct 2009 14:47:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7FD69413F; Tue, 13 Oct 2009 14:46:59 -0400 (EDT) To: draft-ietf-idnabis-bidi@tools.ietf.org, iesg@ietf.org, secdir@ietf.org, idnabis-chairs@tools.ietf.org From: Sam Hartman Date: Tue, 13 Oct 2009 14:46:59 -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 Subject: [secdir] Secdir review of draft-ietf-idnabis-bidi 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, 13 Oct 2009 18:47: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. Feel free to forward to any appropriate forum. This document describes a new rule for handling bidirectional attributes of Unicode characters and the bidirectional text wrapping algorithm. I am not qualified to evaluate the security implications of this draft: I do not understand all the implications, and recommend that the security ADs take a close look. The draft is well written. Even given my limited information on the subject, I found the draft relatively clear--or, at least, clear enough that I understood some of my gaps. There is one major deficiency in the security considerations section. The major attack against naming systems is incorrect mappings; in the case of DNS mappings used by humans this broadly falls into the category of phishing or other cases where humans are confused into thinking they have accessed a desired resource but in fact have accessed some other resource.. Section 3 discusses several requirements that could not be met and several confusing situations. However the security considerations section does not discuss the security implications of this, or even discuss phishing/confusing names at all. I'll give the editors some slack here: I have no idea what to write either. However it seems like we should write something. I think advice from the security ADs on what level of detail would be desired in the security considerations section of this document would be in order. I found section 3 particularly useful. I think it is important than someone who understands this better than I look at the attacks that are enabled by the requirements that were considered and rejected to understand how serious they are. All in all, this is a great document. From hartmans@mit.edu Tue Oct 13 14:02: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 CD4133A6849; Tue, 13 Oct 2009 14:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[AWL=1.254, 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 n+KlrN76H1ZZ; Tue, 13 Oct 2009 14:02:19 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 16BFA3A681A; Tue, 13 Oct 2009 14:02:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 752CA201CB; Tue, 13 Oct 2009 17:02:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A3192413F; Tue, 13 Oct 2009 17:02:13 -0400 (EDT) To: John C Klensin References: <20091013195732.09F5C28C10F@core3.amsl.com> <5CA1EFAE05D975C1D2802079@PST.JCK.COM> From: Sam Hartman Date: Tue, 13 Oct 2009 17:02:13 -0400 In-Reply-To: <5CA1EFAE05D975C1D2802079@PST.JCK.COM> (John C. Klensin's message of "Tue\, 13 Oct 2009 16\:24\:06 -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, secdir@ietf.org Subject: Re: [secdir] Last Call: draft-gennai-smime-cnipa-pec (Certified Electronic Mail) to Proposed Standard 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, 13 Oct 2009 21:02:19 -0000 I'd like to echo John's concern. If this was not simply a case of clicking the wrong button, then I think a longer last call announcement explaining why the IESG believes standards track is appropriate and why the IESG believes this document meets our criteria for proposed standard would be in order. Here are my initial reasons why I don't think the presumption that the document is ready for standards track review holds in this case [1]. * The abstract claims this document describes what is done in Italy, not what should be done * The use of mail headers, particularly from and reply-to seems likely to require review and discussion in the e-mail community * I'm not sure this mechanism is consistent with BCP 61 or the Internet threat model. In particular, section 5 describes several key threats but does not describe mandatory-to-implement mechanisms to meet these threats. We'd never accept this from an IETF working group outside the security area, we shouldn't accept this from a security area document. * The security considerations section 8 is very weak. I think that a lot of what should belong there is actually in section 5, but even so this does not feel like an IETF document. [1] We've had a lot of discussions about what level of consensus is required to publish standards track documents that are individual submissions. However I at least believe that there's a presumption that documents forwarded to last call by the IESG are at least ready to be reviewed as standards track, so I feel the need to give specific reasons why that presumption does not hold in a given case. From clonvick@cisco.com Tue Oct 13 14:57: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 1310A3A6971; Tue, 13 Oct 2009 14:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=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 jKXJt-k-lpu1; Tue, 13 Oct 2009 14:57:19 -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 00BE73A6808; Tue, 13 Oct 2009 14:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=2749; q=dns/txt; s=sjiport06001; t=1255471041; x=1256680641; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Chris=20Lonvick=20|Subject: =20SECDIR=20review=20of=20draft-melnikov-sasl-scram-ldap- 03|Date:=20Tue,=2013=20Oct=202009=2014:57:20=20-0700=20(P DT)|Message-ID:=20|To:=20alexey.melnikov@isode.com,=20pas i.eronen@nokia.com,=20iesg@ietf.org,=0D=0A=20=20=20=20=20 =20=20=20secdir@ietf.org|cc:=20Tom=20Yu=20, =20Kurt=20Zeilenga=20 |MIME-Version:=201.0; bh=T9zu4JukYnmxB5J95YzTegnV3JzcJHFdxJeCcxYOlEE=; b=qCdLkWa0oh97KLB3ZCe3ydPawPrkxLfr8nLarmEP4Z3lc8pXG2QkG4yd 7nU3unUdqIuLHAmJoZLPqLjtUN/L5Fmbeyf3NNMYEBpiN5vhzoKBGwwg7 SrYA3xoEUGEBd7s/YJ0xZIUA+TgnOkzbYbEUhPJIlNyYXq8YwwR2JskwR Q=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAIuU1EqrR7Hu/2dsb2JhbACPcgGxQpgshC0EgVs X-IronPort-AV: E=Sophos;i="4.44,553,1249257600"; d="scan'208";a="408583010" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2009 21:57:21 +0000 Received: from sjc-cde-007.cisco.com (sjc-cde-007.cisco.com [171.69.23.150]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9DLvKKm005955; Tue, 13 Oct 2009 21:57:20 GMT Date: Tue, 13 Oct 2009 14:57:20 -0700 (PDT) From: Chris Lonvick To: alexey.melnikov@isode.com, pasi.eronen@nokia.com, iesg@ietf.org, secdir@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-melnikov-sasl-scram-ldap-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 21:57:20 -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. Althought this isn't a WG document, it does state that discussion may take place on the sasl WG list, so I'm cc'ing the Chairs of that WG. Overall, the concept is pretty straightforward and the description is succinct. However, I do have some items that I would like to see addressed before I would recommend that this become an RFC. Your ABNF is not complete. You are using values taken from the complete ABNF in RFC 3112 so your ABNF is not going to properly parse. I think that mostly all you need to do there is to copy the ABNF from RFC 3112 and insert your values. You'll also need to define iter-count in the document somewhere. (draft-ietf-sasl-scram-07 doesn't reference "iter-count"; only iteration count.) Perhaps: CURRENT: The "authInfo" part of the authPassword attribute is the iteration count, followed by ":" and base-64 [BASE64] encoded salt. SUGGESTED: The "authInfo" part of the authPassword attribute is the iteration count [SCRAM] (identified here as the iter-count), followed by ":" and base-64 [BASE64] encoded salt [SCRAM]. An example is needed and I see that you have an anchor for that. Please complete that. Your Security Considerations section needs some work. Each sentence you have there is actually a separate paragraph. Rather than reworking that, I'd suggest that you start the section by stating that this specification utilizes the framework of RFC 4422 and the security concerns expressed there apply. If needed, you could call out individual concerns from that Section 6. Then you could call out any specific concerns that apply specifically to this document. Just as a nit, you're mixing reference types. RFC 3112 is referenced as [AUTHTYPE] whereas RFC 2119 is referenced as [RFC2119]. These should be consistent. I'd also recommend that you revise the abstract a bit for clarity. CURRENT: This memo describes how authPassword LDAP attribute can be used for storing secrets used by Salted Challenge Response (SCRAM) Simple Authentication and Security Layer (SASL) Mechanism. SUGGESTED: This memo describes how the LDAP attribute of authPassword can be used for storing secrets used by the Salted Challenge Response (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. Best regards, Chris From ietfdbh@comcast.net Thu Oct 15 08:32:56 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 2B44E28C10C for ; Thu, 15 Oct 2009 08:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, 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 hDePWXyWjY0V for ; Thu, 15 Oct 2009 08:32:54 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 5381328C0FF for ; Thu, 15 Oct 2009 08:32:54 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA08.westchester.pa.mail.comcast.net with comcast id syL91c00317dt5G583YCv5; Thu, 15 Oct 2009 15:32:12 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA13.westchester.pa.mail.comcast.net with comcast id t3Yw1c00U284sdk3Z3YxsE; Thu, 15 Oct 2009 15:32:58 +0000 From: "David Harrington" To: , Date: Thu, 15 Oct 2009 11:32:55 -0400 Message-ID: <062201ca4dac$c53d4100$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: Acok8dFSknGT3MZ4R+WLBKpRUjkJ/AmcfRKw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: raj@cisco.com, 'IETF-Discussion list' , mjs@cisco.com, dhc-chairs@tools.ietf.org, iesg@ietf.org, john_brzozowski@cable.comcast.com, jayk@cisco.com, kkinnear@cisco.com Subject: [secdir] SECDIR and OPSDIR review of draft-ietf-dhc-vpn-option-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, 15 Oct 2009 15:32:56 -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. ... AND ... I have performed an unofficial Operations Directorate review. (i.e., I wasn't assigned as the OPSDIR reviewer) Background: This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. ========================= SECDIR Review ========================= The security review 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 found the security considerations section reasonably thorough. Some of the considerations are of the form "there is this known problem; you should do whatever you can to mitigate it." I wonder if some specific mitigation mechanisms might have been described and standardized. In section 4, a relay agent can insert a VSS option into a client request, and then remove it from the server response. I am a little concerned that the server does not actually get to differentiate which entity is making the VSS request, and the relay is thus masquerading as the client. ========================= OPSDIR Review Questions: ========================= The operations review comments were written primarily for the benefit of the OPS area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I do not normally work at the DHCP level, so some of my comments may simply be misunderstandings of DHCP. Is the document readable? yes. Does it contain nits? yes. The document seems to lack a disclaimer for pre-RFC5378 work Is the document class appropriate? yes. Is the problem well stated? yes. Is the problem really a problem? yes. Does the document consider existing solutions? yes. Does the solution break existing technology? possibly. 1) Section 4 says "Deploying relay agents which support and emit VSS sub-options in concert with DHCPv4 servers which do not support the VSS option or sub-option as defined in this document SHOULD NOT be done, as such an ensemble will not operate correctly together because all of the IP addresses will be allocated from the global or default VPN regardless of the VPN on which the client's reside." 2) I have concerns that there are potential conflicts that are not being addressed: " There are many other scenarios which can be created with multiple relay agents each inserting VSS information into different Relay- forward messages, relay agent VSS information conflicting with client VSS information, or DHCP server VSS information conflicting with relay agent and client VSS information. Since these scenarios do not describe situations that are useful today, specifying precisely how to resolve all of these conflicts is unlikely to be valuable in the event that these scenarios actually become practical in the future. The current use of the VSS option and sub-option require that each entity knows the part that it plays in dealing with VPN data. Each entity -- client, relay agent or agents, and server -- SHOULD know through some policy or configuration beyond the scope of this document whether it is responsible for specifying VPN information using the VSS option or sub-option or responsible for responding to VSS information specified by another entity, or simply ignoring any VSS information which it might see. Some simple conflict resolution approaches are discussed below, in the hopes that they will cover simple cases that may arise from scenarios beyond those envisioned today. However, for more complex scenarios, or simple scenarios where appropriate conflict resolution strategies differ from those discussed in this document, a document detailing the usage scenarios and appropriate conflict resolution strategies SHOULD be created and submitted for discussion and approval." 3) section 7 says " In either case above, care should be taken to ensure that a client or relay agent receiving a reply containing a VSS option will correctly understand the VSS option. Otherwise, the client or relay agent will end up using the address as though it were a global address." This could have a negative impact on the existing network deployment. Does the solution preclude future activity? yes. It declares the VPN types 2-254 to be invalid "as of this memo", but doesn't discuss how they could become valid in the future. The IANA section seems to waffle on whether it can or cannot be expanded in the future. Is the solution sufficiently configurable? There is quite a bit of text that says the entity "has been configured in some way" In some cases, the configuration MUST be done correctly for the system to work, but the configuration requirements are not detailed. For example, Section 4 says "It is important to ensure that each entity ... is configured correctly." and "There is no conflict between different entities trying to specify different VSS information -- each entity knows its role through policy or configuration external to this document." and "In the event that there were more than one relay agent involved in this transaction, some external configuration or policy would be needed to inform the DHCPv6 server into which Relay-reply message the VSS option should go." These sound like normative requirements, but there is no attempt to standardize the configuration. Can performance be measured? How? performance measurement is not discussed. Does the solution scale well? I think this should scale as well as DHCP. I suppose that the server might be expected to have lots of storage if it needs to track the address ranges for a large number of VPNs, but I don't think that would be a limiting factor for a DHCP server. general comments: 1. The Terminology section defines upstream and downstream using terms that have not been defined. It is unclear to me whether access concentrator and subscriber are similar to server and client. 2. In section 3.4, might it be better to declare 2-254 as reserved rather than invalid? The text says "invalid as of this memo". Should there be a mechanism to support enterprise-specific VSS? 3. In section 4, it says DHCP can assign the same IP address to nodes in a VPN and in the global IP space, because the address is qualified by the VPN. Is this always true? Is there any potential for conflict, such as in forwarding loops, if the two addresses spaces are handled by the same device? 4. I think section 4 would benefit from sub-sections to separate the scenarios, and all the "in this scenario" phrases could be eliminated. Diagrams of the scenarios would be helpful. 5. Will legacy DHCP entities ignore the VSS option by default? or will the presence of the option somehow impact entity behaviors (e.g., by dropping packets)? 6. In section 5, it says the relay SHOULD insert VSS information into requests from a client. What happens if the client has inserted a VSS option? That isn't discussed. 7. Section 5 says "Anytime a relay agent places a VSS option or sub-option in a DHCP request, it MUST send it only to a DHCP server which supports the VSS option or sub-option." How does it know? is there an option discovery mechanism? 8. In section 5, if a relays requests a specific VPN, but the server returns an address not within that VPN, then the relay should drop the packet. Should the relay let the server know that it dropped the packet and why? Won't the server assume the address has actually been assigned to the client, thus reducing the pool of available addresses? 9. In section 5, "If an IP address that is on the requested VPN is not required, then the relay agent is free to accept the IP address that is not on the VPN that was requested." Then why request it? Under what conditions would it not be required? how does the relay know whether it is or is not required? 10. In section 5, it says "There are only two pieces of information which can be determined ..." but the speciied behaviors could also result from mis-configuration, right? And the relay cannot tell whether it is a deliberate behavior or a mis-configuration. 11. section 5: " Thus, if a DHCPv4 relay agent has a requirement to determine if the address allocated by a DHCPv4 server is on a particular VPN, it must use some other approach than the appearance of the VSS sub-option in the reply packet to make this determination." What other approach works? 12. section 5: " Note that in some environments a relay agent may choose to always place a VSS option or sub-option into packets and messages that it forwards in order to forestall any attempt by a downstream relay agent or client to specify VSS information. In this case, a type field of 255 is used to denote the global, default VPN. When the type field of 255 is used, there MUST NOT be any additional VSS Information in the VSS option." This section does not say that the relay must check to make sure there is no existing VSS option. Section 5 talks about relays inserting VSS options, buit does not specify that the relay must check that no VSS=255 is present in the message already. But section 7.3 talks about resolving conflicting VSS options. I am not sure the potential conflicts abd resolutions are covered adequately. 13. section 5.1 what does "if the relay agent is unable to honor the server requirement" mean? This could be made less ambiguous. 14. section 5.1 " The DHCP server MUST NOT place VSS information in an outgoing packet if the relay agent or DHCP client is unprepared to properly interpret the VSS information." This seems ambiguous. How will the server know if the other entities can properly interpret the VSS information? s/send in/insert/ 15. section 4 says "The DHCP client, in this scenario, does not know the VPN on which it resides." section 6 says " A DHCPv4 or DHCPv6 client will employ the VSS option to communicate VSS information to their respective servers. This information MUST be included in every message concerning any IP address on a different VPN than the global or default VPN." these statements seem to conflict regarding the client's knowledge. 16. section 6: " Clients should be aware that some DHCP servers will return a VSS option with different values than that which was sent in. In addition, a client may receive a response from a DHCP server with a VSS option when none was sent in by the Client." So should subsequent messages from the client use the original VSS information or the server-returned or relay-returned VSS info? Can a return message contain multiple VSS options? If I read the document correctly, multiple relays can add their own VSS options, and a server typically copies all the options. If a client is expected to include the VSS option information in subsequent messages, does it include multiple VSS options? The second paragraph of 6 says that is not allowed. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From barryleiba.mailing.lists@gmail.com Thu Oct 15 13:44: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 AA28128C16D; Thu, 15 Oct 2009 13:44:27 -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 tJof-rjy30rz; Thu, 15 Oct 2009 13:44:26 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id B27DE28C16C; Thu, 15 Oct 2009 13:44:26 -0700 (PDT) Received: by ywh13 with SMTP id 13so2030476ywh.29 for ; Thu, 15 Oct 2009 13:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/60+cSjt0cbIxhnL7sFrV6yfplUrLkKZoSBPdweyRrU=; b=Zn6GNCZTOVCI1AroxDfNYEaY6OPbYkqUBN4vdMYoCiTmv0LiBpvQcpLyHKnuUu5KRk vrInlSGFTuUBbyMh7UkrFaItJuuoyT/4XbKslVFbhct383oOHdcz/9tbcK4KIIioa6Wl 7R6xetEIyBEvxLlkfCKQvfFsv9KfBaMqIiCCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=tsIh2ejNCCoW9XT7hGY93nSIoi7z8revf2mY6gklRYbrA+udUBX36ZXk9ZYxaVAjjW 6ZlezTjR31AWzf1TW3u5AcaQxQJahUJPdQoOCEXhur92zDw/NNAftEWOM8/DUbsN2ofM rb4d9Kujzuib9CpMWCfYNgAtCwk91xayRv1rc= MIME-Version: 1.0 Received: by 10.150.26.5 with SMTP id 5mr1143144ybz.228.1255639467351; Thu, 15 Oct 2009 13:44:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Oct 2009 16:44:27 -0400 Message-ID: <6c9fcc2a0910151344o41516489ufd9b132d398f94d2@mail.gmail.com> From: Barry Leiba To: Chris Lonvick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-melnikov-sasl-scram-ldap-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 20:44:27 -0000 On Tue, Oct 13, 2009 at 5:57 PM, Chris Lonvick wrote: > I'd also recommend that you revise the abstract a bit for clarity. > CURRENT: > =A0 This memo describes how authPassword LDAP attribute can be used for > =A0 storing secrets used by Salted Challenge Response (SCRAM) Simple > =A0 Authentication and Security Layer (SASL) Mechanism. > SUGGESTED: > =A0 This memo describes how the LDAP attribute of authPassword can be use= d > =A0 for storing secrets used by the Salted Challenge Response (SCRAM) > =A0 mechanism in the Simple Authentication and Security Layer (SASL) > =A0 framework. I agree that strings of attributive nouns and noun-phrases can be confusing, especially when they're long and also shown as acronyms. I think the second half of your suggested change is good. But I think the first half actually makes it worse, by making it look like there's some attribute of authPassword that's called "LDAP". The best way to clarify that part is just to put the attribute name in quotes: SUGGESTED++: This memo describes how the "authPassword" LDAP attribute can be used for storing secrets used by the Salted Challenge Response (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. Barry From clonvick@cisco.com Thu Oct 15 14:39:24 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 4602D3A67E2; Thu, 15 Oct 2009 14:39:24 -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, 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 GRBoDvoFm5hU; Thu, 15 Oct 2009 14:39:23 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F239C3A62C1; Thu, 15 Oct 2009 14:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=1787; q=dns/txt; s=rtpiport02001; t=1255642767; x=1256852367; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Chris=20Lonvick=20|Subject: =20Re:=20[secdir]=20SECDIR=20review=20of=20draft-melnikov -sasl-scram-ldap-03|Date:=20Thu,=2015=20Oct=202009=2014:3 9:24=20-0700=20(PDT)|Message-ID:=20|To:=20barryleiba@compu ter.org|cc:=20alexey.melnikov@isode.com,=20pasi.eronen@no kia.com,=20iesg@ietf.org,=0D=0A=20=20=20=20=20=20=20=20se cdir@ietf.org|MIME-Version:=201.0|In-Reply-To:=20<6c9fcc2 a0910151344o41516489ufd9b132d398f94d2@mail.gmail.com> |References:=20=0D=0A=20<6c9fcc2a0910151344o41516489ufd9b 132d398f94d2@mail.gmail.com>; bh=EmO9DBzVLvTvlcn0OGZ66DvwiAot3cA8VqKJ9XTzVUo=; b=fxPhCoV2CuWn6xL9LKZdXQJAdeq4lzqxGyO+6CPsL9bBvwIXwOL+gHq+ +CpcdAAE6gyE+xnELE+Y7lRRx2vpqsD5vnl+4aM9+Bh9DIK5/kzjBpzAE Bu3/aR/QG5bUB4hEbMNnHHlOMVz2vmsoXYYzJwI1GiDvH2MVnClte0ESN M=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMoz10qtJV2Z/2dsb2JhbADBHZg3hDAE X-IronPort-AV: E=Sophos;i="4.44,568,1249257600"; d="scan'208";a="63335486" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 15 Oct 2009 21:39:25 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id n9FLdOoA010463; Thu, 15 Oct 2009 21:39:25 GMT Date: Thu, 15 Oct 2009 14:39:24 -0700 (PDT) From: Chris Lonvick To: barryleiba@computer.org In-Reply-To: <6c9fcc2a0910151344o41516489ufd9b132d398f94d2@mail.gmail.com> Message-ID: References: <6c9fcc2a0910151344o41516489ufd9b132d398f94d2@mail.gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1423418003-1255642764=:6529" Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-melnikov-sasl-scram-ldap-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 21:39:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1423418003-1255642764=:6529 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Barry, I like that better as well. Best regards, Chris On Thu, 15 Oct 2009, Barry Leiba wrote: > On Tue, Oct 13, 2009 at 5:57 PM, Chris Lonvick wrote= : >> I'd also recommend that you revise the abstract a bit for clarity. >> CURRENT: >> =A0 This memo describes how authPassword LDAP attribute can be used for >> =A0 storing secrets used by Salted Challenge Response (SCRAM) Simple >> =A0 Authentication and Security Layer (SASL) Mechanism. >> SUGGESTED: >> =A0 This memo describes how the LDAP attribute of authPassword can be us= ed >> =A0 for storing secrets used by the Salted Challenge Response (SCRAM) >> =A0 mechanism in the Simple Authentication and Security Layer (SASL) >> =A0 framework. > > I agree that strings of attributive nouns and noun-phrases can be > confusing, especially when they're long and also shown as acronyms. I > think the second half of your suggested change is good. But I think > the first half actually makes it worse, by making it look like there's > some attribute of authPassword that's called "LDAP". The best way to > clarify that part is just to put the attribute name in quotes: > SUGGESTED++: > This memo describes how the "authPassword" LDAP attribute can be used > for storing secrets used by the Salted Challenge Response (SCRAM) > mechanism in the Simple Authentication and Security Layer (SASL) > framework. > > Barry > ---559023410-1423418003-1255642764=:6529-- From weiler+secdir@watson.org Thu Oct 15 19:57: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 670D23A687F for ; Thu, 15 Oct 2009 19:57:12 -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 mMMoXDi0PcMD for ; Thu, 15 Oct 2009 19:57:11 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 6D2653A6810 for ; Thu, 15 Oct 2009 19:57: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 n9G2vE0U024477 for ; Thu, 15 Oct 2009 22:57:14 -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 n9G2vElJ024473 for ; Thu, 15 Oct 2009 22:57:14 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 15 Oct 2009 22:57:14 -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]); Thu, 15 Oct 2009 22:57:14 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 02:57:12 -0000 Carl Wallace is next in the rotation. Please try to complete last call reviews by the end of the last call. For documents on telechat, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-10-22 Reviewer Deadline Draft Ran Canetti T 2009-10-20 draft-ietf-sasl-scram-10 Shawn Emery T 2009-10-20 draft-ietf-mpls-tp-gach-dcn-06 Steve Hanna T 2009-10-20 draft-ietf-pkix-sha2-dsa-ecdsa-10 Julien Laganier T 2009-10-20 draft-ietf-sip-certs-09 Catherine Meadows T 2009-10-20 draft-ietf-eai-pop-07 Joe Salowey T 2009-10-20 draft-ietf-bmwg-ipsec-meth-05 Stefan Santesson T 2009-10-20 draft-ietf-bmwg-ipsec-term-12 Tina TSOU TR2009-10-20 draft-ietf-syslog-sign-28 Sean Turner T 2009-10-20 draft-braden-independent-submission-01 Kurt Zeilenga TR2009-10-20 draft-ietf-hokey-key-mgm-09 Last calls and special requests: Reviewer Deadline Draft Rob Austein 2009-10-07 draft-reschke-rfc2731bis-03 Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-01 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Donald Eastlake None draft-ietf-geopriv-held-identity-extensions-00 Shawn Emery 2009-08-04 draft-ietf-alto-problem-statement-04 Stephen Farrell 2009-09-07 draft-ietf-tls-rfc4366-bis-05 Sam Hartman R2009-10-23 draft-hammer-oauth-03 Paul Hoffman 2009-10-15 draft-ietf-idnabis-defs-11 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-04 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-16 Charlie Kaufman None draft-baker-ietf-core-03 Scott Kelly 2009-10-15 draft-ietf-idnabis-tables-07 Julien Laganier 2009-06-09 draft-ietf-enum-3761bis-04 Julien Laganier 2009-10-14 draft-ietf-ospf-af-alt-08 Barry Leiba 2009-10-14 draft-ietf-ospf-te-node-addr-06 David McGrew 2009-10-28 draft-weiler-rsync-uri-01 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Russ Mundy 2009-10-21 draft-ietf-hokey-preauth-ps-09 Sandy Murphy 2009-10-23 draft-nottingham-site-meta-03 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Chris Newman 2009-10-20 draft-ietf-forces-sctptml-06 Magnus Nystrom 2009-11-02 draft-altman-tls-channel-bindings-07 Hilarie Orman 2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Radia Perlman None draft-bryan-http-digest-algorithm-values-update-02 Eric Rescorla 2009-11-10 draft-gennai-smime-cnipa-pec-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Juergen Schoenwaelder 2009-10-29 draft-ietf-behave-turn-uri-03 Yaron Sheffer 2009-10-28 draft-ietf-ipsecme-traffic-visibility-09 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-10-07 draft-carpenter-renum-needs-work-03 Hannes Tschofenig 2009-10-23 draft-ietf-l3vpn-ospfv3-pece-03 Tina TSOU 2009-10-28 draft-ietf-mboned-rfc3171bis-07 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-04 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 From gonzalo.camarillo@ericsson.com Fri Oct 16 04:17: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 D4D9F28C1FE for ; Fri, 16 Oct 2009 04:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.287, 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 ovjtSMr6RK-X for ; Fri, 16 Oct 2009 04:17:24 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3515928C1F3 for ; Fri, 16 Oct 2009 04:17:23 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-09-4ad85645e410 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 73.CD.24026.54658DA4; Fri, 16 Oct 2009 13:17:26 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 13:17:25 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 13:17:24 +0200 Message-ID: <4AD85644.5020904@ericsson.com> Date: Fri, 16 Oct 2009 14:17:24 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2009 11:17:24.0906 (UTC) FILETIME=[3CDFB8A0:01CA4E52] X-Brightmail-Tracker: AAAAAA== Cc: fluffy@cisco.com, secdir@ietf.org, oran@cisco.com, fandreas@cisco.com, dwing@cisco.com, rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 11:17:25 -0000 Hi Stephen, thanks for your review. You are right that the current text is too vague. I have taken a stab at expanding it so that the threats and possible solutions are clearer. Let us know if this new text would address your comments. The old text can be found at: http://tools.ietf.org/html/draft-ietf-mmusic-connectivity-precon-06#section-7 The following is the new text: 7. Security Considerations General security considerations for preconditions are discussed in [RFC3312] and [RFC4032]. As discussed in [RFC4032], it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. S/MIME [RFC3853] provides such end- to-end integrity protection, as described in [RFC3261]. Additionally, the following security issues relate specifically to connectivity preconditions. Connectivity preconditions rely on mechanisms beyond SDP such as TCP [RFC0793] connection establishment, or ICE connectivity checks [I-D.ietf-mmusic-ice] to establish and verify connectivity between an offerer and an answerer. An attacker that prevents those mechanism from succeeding (e.g., by keeping ICE connectivity checks from arriving to their destination) can prevent media sessions from being established. While this attack relates to connectivity preconditions, it is actually an attack against the connection establishment mechanisms used by the endpoints. This attack can be performed in the presence or in the absence of connectivity preconditions. In their presence, the whole session setup will be disrupted. In their absence, only the establishment of the particular stream under attack will be disrupted. This specification does not provide any mechanism against attackers able to block traffic between the endpoints involved in the session because such an attacker will always be able to launch DoS (Denial of Service) attacks. Instead of blocking the connectivity checks, the attacker can generate forged connectivity checks that would cause the endpoints to assume that there was connectivity when there was actually no connectivity. This attack would result in a poor user's experience because the session would be established without all the media streams being ready. The same attack can be used, regardless of whether or not connectivity preconditions are used, to attempt to hijack a connection. The forged connectivity checks would trick the endpoints into sending media to the wrong direction. To prevent these attacks, it is RECOMMENDED that the mechanisms used to check connectivity are adequately secured by message authentication and integrity protection. For example, Section 2.5 of [I-D.ietf-mmusic-ice] discusses how message integrity and data origin authentication are implemented in ICE connectivity checks. Thanks, Gonzalo Stephen Kent wrote: > I reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. > The document "draft-ietf-mmusic-connectivity-precon-06" defines "a new > connectivity precondition for the Session Description Protocol (SDP) > precondition framework." Connectivity preconditions are used to delay > session establishment (or modification) until media stream connectivity > has been verified. The use of preconditions represents an interesting > twist on the original SDP model, where the assumption was that an SDP > session would be established before media streams were established! The > use of preconditions is motivated in large part by the need for media > streams to traverse firewalls and NATs. > > The Security Considerations section here starts by citing the Security > Considerations section from the base preconditions RFC (3312). It also > adds two paragraphs to discuss new considerations relevant to the > precondition types defined in this document. This is an appropriate way > to address new security issues that arise for extensions to > previously-defined functions. RFC 3312 has a two-paragraph Security > Considerations section, which identifies concerns, but make no > recommendations about security mechanisms to employ! This document has a > paragraph that RECOMMENDS use of integrity for the SDP traffic, e.g., > via RFC 3261, to counter attacks against this portion of the system. > This is a concrete recommendation that is appropriate for this aspect of > the security concerns cited, and is applicable to the 3312 security > concerns as well. > > The new security concerns that arise here result from reliance on other > protocols to detect successful media stream establishment. This > motivates concerns about two classes of DoS attacks: transient attacks > that cause session establishment to fail (when the media streams could > have been created) and transient attacks that make it appear that media > streams have been established, when in fact they have not. > > TCP and ICE are the protocols cited specifically as one of interest. The > text RECOMMDNDS making use of suitable authentication and integrity > mechanisms for the relevant protocols to counter both forms of attacks. > The text also says that "the mechanisms SHOULD consider how to prevent > denial of service attacks." > > I find this text to be too vague to be useful. It ought to cite specific > mechanisms in RFCs, at least as examples, preferably as recommendations. > The lack of specific, cited mechanisms makes this section almost > vacuous. I suggest that the authors revise the text here to cite > appropriate mechanisms. From Pasi.Eronen@nokia.com Fri Oct 16 04:18: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 6A4FA3A6824; Fri, 16 Oct 2009 04:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 sDoCnBpzpac5; Fri, 16 Oct 2009 04:18:29 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8200A3A67CF; Fri, 16 Oct 2009 04:18:29 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9GBI9dg022182; Fri, 16 Oct 2009 06:18:31 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 14:18:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 14:18:18 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 16 Oct 2009 13:18:18 +0200 From: To: , , , , Date: Fri, 16 Oct 2009 13:18:17 +0200 Thread-Topic: secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt Thread-Index: AcpGglvNPwIUeRb/QYqgl0FsfKOUywHzw7Pg Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.com> References: <15898.1254832898.040887@puncture> In-Reply-To: <15898.1254832898.040887@puncture> 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: 16 Oct 2009 11:18:18.0549 (UTC) FILETIME=[5CD8FE50:01CA4E52] X-Nokia-AV: Clean Subject: Re: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 11:18:30 -0000 (replying as document author, not AD) Thanks for your review, Dave! > The Security Considerations section is actually quite unclear to me - > at first glance, the opening phrase suggests that the solution does > indeed do the thing it warns against, that is, assigning each client > a unique, and therefore identifiable, prefix.=20 It indeed does this, and the paragraph should be clearer about it. Perhaps something like this? =20 The mechanism described in this document assigns each client a unique prefix, which makes using randomized interface identifiers [RFC4941] ineffective from privacy point of view: the client is still uniquely identified by the prefix. [...] > It also fails to draw the reader's attention to any other relevent > considerations - I'm assuming that the two and a half pages of > security considerations in RFC 4306 have some direct relevance here. Since this is a very small extension to RFC 4306, indeed all the security considerations of RFC 4306 still apply. Perhaps we should add something like: Since this document is an extension to IKEv2, the security=20 considerations in [IKEv2] apply here as well. > Also, the informative references noted in the Acknowledgements > section would appear to have some potentially important security > considerations - for example, RFC 4891's final consideration is: >=20 > Please note that using IPsec for the scenarios described in > Figures 1, 2, and 3 does not aim to protect the end-to-end > communication. It protects just the tunnel part. It is still > possible for an IPv6 endpoint not attached to the IPsec tunnel to > spoof packets. >=20 > ... given that IKEv2's previous support for IPv6 limited it to a > single host at the client end, one assumes that this document > introduces at least this security consideration. I don't think RFC 4891 is relevant here; remote access VPNs are almost never end-to-end, and the situation is the same with IPv4 and IPv6. So this document doesn't introduce anything new here... Best regards, Pasi From dave.cridland@isode.com Fri Oct 16 04:26: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 21ED928B23E; Fri, 16 Oct 2009 04:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 FHnXGs7OFbMt; Fri, 16 Oct 2009 04:26:53 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0AB213A677D; Fri, 16 Oct 2009 04:26:53 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 16 Oct 2009 12:26:22 +0100 X-SMTP-Protocol-Errors: NORDNS References: <15898.1254832898.040887@puncture> <808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.com> Message-Id: <3527.1255692381.824936@puncture> Date: Fri, 16 Oct 2009 12:26:21 +0100 From: Dave Cridland To: "Pasi.Eronen@nokia.com" , Security Area Directorate , The IESG , , MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 11:26:54 -0000 On Fri Oct 16 12:18:17 2009, Pasi.Eronen@nokia.com wrote: > (replying as document author, not AD) > > Thanks for your review, Dave! > > > The Security Considerations section is actually quite unclear to > me - > > at first glance, the opening phrase suggests that the solution > does > > indeed do the thing it warns against, that is, assigning each > client > > a unique, and therefore identifiable, prefix. > > It indeed does this, and the paragraph should be clearer about it. > Perhaps something like this? > > The mechanism described in this document assigns each client a > unique prefix, which makes using randomized interface identifiers > [RFC4941] ineffective from privacy point of view: the client is > still uniquely identified by the prefix. [...] > > Yes, that's much clearer. > > It also fails to draw the reader's attention to any other relevent > > considerations - I'm assuming that the two and a half pages of > > security considerations in RFC 4306 have some direct relevance > here. > > Since this is a very small extension to RFC 4306, indeed all the > security considerations of RFC 4306 still apply. Perhaps we > should add something like: > > Since this document is an extension to IKEv2, the security > considerations in [IKEv2] apply here as well. > > It seems to be traditional, yes. > > Also, the informative references noted in the Acknowledgements > > section would appear to have some potentially important security > > considerations - for example, RFC 4891's final consideration is: > > > > Please note that using IPsec for the scenarios described in > > Figures 1, 2, and 3 does not aim to protect the end-to-end > > communication. It protects just the tunnel part. It is still > > possible for an IPv6 endpoint not attached to the IPsec tunnel > to > > spoof packets. > > > > ... given that IKEv2's previous support for IPv6 limited it to a > > single host at the client end, one assumes that this document > > introduces at least this security consideration. > > I don't think RFC 4891 is relevant here; remote access VPNs are > almost > never end-to-end, and the situation is the same with IPv4 and IPv6. > So > this document doesn't introduce anything new here... I was under the impression it potentially moved one of the ends in any communication away from the tunnel endpoint? That is, if one is connecting into a secured, trusted network, using this secured VPN tunnel, that doesn't mean that any packets traversing a local network to get to that tunnel are secured. (For whatever meaning of secured you intend to put here). To put it another way, under RFC 4306, the client VPN'ing into the network is always "attached to the IPSec tunnel", whereas this document extends things such that this may not be the case. I'm not jumping up and down insisting on this, by the way, I'm just trying to make sure you understood what I meant. :-) Dave. From Pasi.Eronen@nokia.com Fri Oct 16 05:04:29 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 82C9B3A68D8; Fri, 16 Oct 2009 05:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.268, 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 knpqlVypreFz; Fri, 16 Oct 2009 05:04:28 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 21D2E3A6876; Fri, 16 Oct 2009 05:04:27 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9GC4DiA031583; Fri, 16 Oct 2009 15:04:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:04:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 15:04:07 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 16 Oct 2009 14:04:06 +0200 From: To: , , , , Date: Fri, 16 Oct 2009 14:04:05 +0200 Thread-Topic: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt Thread-Index: AcpOU50j6jqX5uXoQMiLJ+QPsDPXOgABILpw Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09A4479C@NOK-EUMSG-01.mgdnok.nokia.com> References: <15898.1254832898.040887@puncture> <808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.com> <3527.1255692381.824936@puncture> In-Reply-To: <3527.1255692381.824936@puncture> 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: 16 Oct 2009 12:04:07.0145 (UTC) FILETIME=[C3237590:01CA4E58] X-Nokia-AV: Clean Subject: Re: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 12:04:29 -0000 Dave Cridland wrote: > I was under the impression it potentially moved one of the ends in > any communication away from the tunnel endpoint? >=20 > That is, if one is connecting into a secured, trusted network, using > this secured VPN tunnel, that doesn't mean that any packets > traversing a local network to get to that tunnel are secured. (For > whatever meaning of secured you intend to put here). >=20 > To put it another way, under RFC 4306, the client VPN'ing into the > network is always "attached to the IPSec tunnel", whereas this > document extends things such that this may not be the case. No, not really; a VPN client using plain RFC 4306 can also share its IPv4 VPN connection to other hosts in the vicinity if it wants; it just needs to do NATting, while here we avoid the NAT. (And this is relatively common case for IPv4 VPNs nowadays -- the "other hosts" using the VPN connection are most likely VMs running on the same physical hardware.) Best regards, Pasi From julienl@qualcomm.com Fri Oct 16 08:02: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 2DC473A6974; Fri, 16 Oct 2009 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH3U20fDtrn1; Fri, 16 Oct 2009 08:02:07 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 347EB3A6817; Fri, 16 Oct 2009 08:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1255705331; x=1287241331; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"Pasi.Eronen@nokia.com"=20, =0D=0A=20=20=20=20=20=20=20=20"dave.cridland@isode.com" =0D=0A=09,=0D=0A=20=20=20=20=20 =20=20=20"secdir@ietf.org"=20,=20"iesg@i etf.org"=20,=0D=0A=20=20=20=20=20=20=20=20 "cmadson@cisco.com"=20|Date:=20Fri,=20 16=20Oct=202009=2008:02:05=20-0700|Subject:=20RE:=20secdi r=20review=20of=20draft-ietf-ipsecme-ikev2-ipv6-config-02 .txt|Thread-Topic:=20secdir=20review=20of=20draft-ietf-ip secme-ikev2-ipv6-config-02.txt|Thread-Index:=20AcpGglvNPw IUeRb/QYqgl0FsfKOUywHzw7PgAAd6zLA=3D|Message-ID:=20|References:=20<15898.1254832898.040887@puncture >=0D=0A=20<808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK -EUMSG-01.mgdnok.nokia.com>|In-Reply-To:=20<808FD6E27AD48 84E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.c om>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5772"=3B=20a=3D"25402044"; bh=IadwjP7iKt+BCd5IU9rQJH87u+A0PzqVbpTXleIQ7Lo=; b=jVxLUm9beECvNhvElnhLPzMfn0hxuAALCi3o6bVX7iFCFzaJ+4ZdkMqq 3utZ9Vl0Sii9d0qjk0crAvUFM6Hbhc8fRc0KRVX9C6D+kuyr5O2iWZeN5 8q2nz/yj4s+j8RTTCXiF+yigNBYQf/BGo6odO5C6S70dqgVmGU08tvrF/ Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5772"; a="25402044" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2009 08:02:11 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GF2AWr007878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 08:02:11 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GF289U006091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Oct 2009 08:02:08 -0700 (PDT) Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Oct 2009 08:02:07 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 16 Oct 2009 08:02:07 -0700 From: "Laganier, Julien" To: "Pasi.Eronen@nokia.com" , "dave.cridland@isode.com" , "secdir@ietf.org" , "iesg@ietf.org" , "cmadson@cisco.com" Date: Fri, 16 Oct 2009 08:02:05 -0700 Thread-Topic: secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt Thread-Index: AcpGglvNPwIUeRb/QYqgl0FsfKOUywHzw7PgAAd6zLA= Message-ID: References: <15898.1254832898.040887@puncture> <808FD6E27AD4884E94820BC333B2DB773C09A4472C@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C09A4472C@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 Subject: Re: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 15:02:08 -0000 Pasi.Eronen wrote: >=20 > (replying as document author, not AD) >=20 > Thanks for your review, Dave! Ditto! > > The Security Considerations section is actually quite unclear to me - > > at first glance, the opening phrase suggests that the solution does > > indeed do the thing it warns against, that is, assigning each client > > a unique, and therefore identifiable, prefix. >=20 > It indeed does this, and the paragraph should be clearer about it. > Perhaps something like this? >=20 > The mechanism described in this document assigns each client a > unique prefix, which makes using randomized interface identifiers > [RFC4941] ineffective from privacy point of view: the client is > still uniquely identified by the prefix. [...] Hmm. How about being more explicit about the implications, something along = these lines:=20 The mechanism described in this document assigns each client a unique prefi= x. Doing so might make the use of randomized interface identifiers [RFC4941= ] ineffective from privacy point of view because the client would still be = uniquely identified by the prefix. However, to be able to track a client ba= sed on its prefix, one has to be aware of the fact that the client configur= es all of its addresses within the same prefix. [...] Thoughts? --julien From phoffman@imc.org Fri Oct 16 08:21: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 DFCF528C22E for ; Fri, 16 Oct 2009 08:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 J5bXPjbZ7U2B for ; Fri, 16 Oct 2009 08:21:45 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3225F28C21B for ; Fri, 16 Oct 2009 08:21:45 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9GFLlKV053756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2009 08:21:48 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 16 Oct 2009 08:21:45 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: draft-ietf-idnabis-defs@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-idnabis-defs 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, 16 Oct 2009 15:21:46 -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. Feel free to forward to any appropriate forum. This document is one of a series of four that make up the revised IDNA protocol (draft-ietf-idnabis-defs, -tables, -protocol, -bidi). The four document are intertwined, so the security considerations for all should be considered at the same time. Having said that, I find no significant issues with the security considerations in any of the four documents, including this one. Given the messy nature of both internationalization and designing user input mechanisms, these documents do the best that they can, and are not noticeably worse (and are hopefully better) than the previous IDNA protocol. From scott@hyperthought.com Sat Oct 17 05:57:17 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 5CD4328C0E6 for ; Sat, 17 Oct 2009 05:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ5I1FKaKi28 for ; Sat, 17 Oct 2009 05:57:16 -0700 (PDT) Received: from smtp162.dfw.emailsrvr.com (smtp162.dfw.emailsrvr.com [67.192.241.162]) by core3.amsl.com (Postfix) with ESMTP id B47103A6837 for ; Sat, 17 Oct 2009 05:57:16 -0700 (PDT) Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 60CE5302EE; Sat, 17 Oct 2009 08:57:20 -0400 (EDT) Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id A1784302C5; Sat, 17 Oct 2009 08:57:19 -0400 (EDT) Message-ID: <4AD9BF2E.8010606@hyperthought.com> Date: Sat, 17 Oct 2009 05:57:18 -0700 From: "Scott G. Kelly" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, paf@cisco.com, idnabis-chairs@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-idnabis-tables-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: Sat, 17 Oct 2009 12:57:17 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document specifies rules for deciding whether a code point should be included in an Internationalized Domain Name. It's a member of a 4-document group, and as Paul pointed out in a related review, should be considered as such. The security considerations section consists of one sentence: "The security issues associated with this work are discussed in [IDNA2008-protocol]." Following that link to the protocol document's security considerations section: "Security Considerations for this version of IDNA, except for the special issues associated with right to left and characters, are described in [IDNA2008-Defs]. Specific issues for labels containing characters associated with scripts written right to left appear in [IDNA2008-BIDI]." The security considerations in those two documents (especially the protocol document) do seem to cover the issues, although like Sam, I don't feel qualified to definitively state this, and so I think the security ADs should pay some attention to this collection of documents. Editorially, one might consider removing the reference indirection and pointing the reader directly at [IDNA2008-Defs] and [IDNA2008-BIDI]. --Scott From vint@google.com Sat Oct 17 09:01: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 B44D13A6938; Sat, 17 Oct 2009 09:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5mnkQYq5MsK; Sat, 17 Oct 2009 09:01:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 91DA13A6859; Sat, 17 Oct 2009 09:01:05 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id n9HG19SK029158; Sat, 17 Oct 2009 09:01:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1255795270; bh=dj3hrElotREcarE1j7Nqd7uvmE4=; h=DomainKey-Signature:Cc:Message-Id:From:To:In-Reply-To: Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date: References:X-Mailer:X-System-Of-Record; b=bwe+jWQH80kyH48dLA4AOMJm Ihgja7llf6BytPJDeAN6vX0kr5HDcyNPC7p9WR+yP0RPrv0b9vyqQQ1kHhHJfQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=cc:message-id:from:to:in-reply-to:content-type: content-transfer-encoding:mime-version:subject:date:references:x-mailer:x-system-of-record; b=J8rER469yiQ2S09V1ZJPE++/bIEc02Ix7TAv0zU6d8dJlqMkpurgtSsWKMgt6Ud6B LMTpgQ0RLM+8Qow4qI48w== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by wpaz33.hot.corp.google.com with ESMTP id n9HG16vo016967; Sat, 17 Oct 2009 09:01:07 -0700 Received: by qyk9 with SMTP id 9so2047400qyk.30 for ; Sat, 17 Oct 2009 09:01:06 -0700 (PDT) Received: by 10.224.123.154 with SMTP id p26mr1711760qar.218.1255795266603; Sat, 17 Oct 2009 09:01:06 -0700 (PDT) Received: from vint-macbookpro.home (static-72-66-6-47.washdc.fios.verizon.net [72.66.6.47]) by mx.google.com with ESMTPS id 23sm1903466qyk.7.2009.10.17.09.01.04 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Oct 2009 09:01:05 -0700 (PDT) Message-Id: <4C70B55D-9260-429A-9B2D-CE355C282BF4@google.com> From: Vint Cerf To: "Scott G. Kelly" In-Reply-To: <4AD9BF2E.8010606@hyperthought.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Oct 2009 12:01:03 -0400 References: <4AD9BF2E.8010606@hyperthought.com> X-Mailer: Apple Mail (2.936) X-System-Of-Record: true Cc: idnabis-chairs@tools.ietf.org, paf@cisco.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-idnabis-tables-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: Sat, 17 Oct 2009 16:01:07 -0000 scott, good point - we will attend to this editorial suggestion. v On Oct 17, 2009, at 8:57 AM, Scott G. Kelly wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > The document specifies rules for deciding whether a code point > should be > included in an Internationalized Domain Name. It's a member of a > 4-document group, and as Paul pointed out in a related review, > should be > considered as such. > > The security considerations section consists of one sentence: > > "The security issues associated with this work are discussed in > [IDNA2008-protocol]." > > Following that link to the protocol document's security considerations > section: > > "Security Considerations for this version of IDNA, except for the > special issues associated with right to left and characters, are > described in [IDNA2008-Defs]. Specific issues for labels containing > characters associated with scripts written right to left appear in > [IDNA2008-BIDI]." > > The security considerations in those two documents (especially the > protocol document) do seem to cover the issues, although like Sam, I > don't feel qualified to definitively state this, and so I think the > security ADs should pay some attention to this collection of > documents. > > Editorially, one might consider removing the reference indirection and > pointing the reader directly at [IDNA2008-Defs] and [IDNA2008-BIDI]. > > --Scott From Shawn.Emery@Sun.COM Sat Oct 17 23:54: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 93A533A67A3; Sat, 17 Oct 2009 23:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 1qsdTgpw0rLn; Sat, 17 Oct 2009 23:54:09 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 0E6123A63EB; Sat, 17 Oct 2009 23:54:08 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9I6sEKt023062; Sun, 18 Oct 2009 06:54:14 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRP00B0074XS300@mail-amer.sun.com>; Sun, 18 Oct 2009 00:54:14 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [174.51.225.48]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRP00LIY76DSQ50@mail-amer.sun.com>; Sun, 18 Oct 2009 00:54:14 -0600 (MDT) Date: Sun, 18 Oct 2009 00:53:09 -0600 From: Shawn M Emery Sender: Shawn.Emery@Sun.COM To: secdir@ietf.org Message-id: <4ADABB55.9090906@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Cc: alto-chairs@tools.ietf.org, draft-ietf-alto-problem-statement@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-alto-problem-statement-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: Sun, 18 Oct 2009 06:54:10 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes various network congestion/latency issues faced by P2P and client/server applications, and offers guidance for resolving these issues by providing these applications network topology and bandwidth information, etc. The security considerations section does exist and describes that the solutions to these network issues involves a 3rd party that both sends and receives sensitive information for the applications. The draft then suggests that this information should be protected/authenticated and references the requirements document, draft-ietf-alto-reqs, for this guidance. draft-ietf-alto-reqs outlines security requirements, such as mutual authentication, privacy, etc. So really I didn't find any security issues within the scope of the reviewed document. General comments(s): Thanks for including the various examples. Editorial comment(s): s/with a public/with public/ -- Shawn. From jsalowey@cisco.com Sun Oct 18 22:04:47 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 585553A672E for ; Sun, 18 Oct 2009 22:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 IBtw4XabdtUm for ; Sun, 18 Oct 2009 22:04:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 903DA3A63EC for ; Sun, 18 Oct 2009 22:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1283; q=dns/txt; s=sjiport02001; t=1255928694; x=1257138294; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20|Subject:=20Secdir=20review=20of=20draft-ietf-bmwg- ipsec-meth-05|Date:=20Sun,=2018=20Oct=202009=2022:04:51 =20-0700|Message-ID:=20|To:=20,=20,=0D=0A =20=20=20=20=20=20=20=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable; bh=pqp4Jhg6v8P3pwg7ZGHRXYMTviQiR9T29yK0r3HO4IU=; b=UE7mClHEfN88toJj6jGUfSx9r4SlGFFxffFqCqsYVMp0d7BU+5X3Pw5j UWQp5IhcvOnqXIhNoSME0dyXNk5kJrQf0nA1WgY9iVXF4XIXoVKZMNuV/ pG1kEMlMjCslhGNjT/O7bVlCwCRR+29OaitUWhGAs2AXdE0jto9ux5oBZ A=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJaQ20qrR7Hu/2dsb2JhbADCN5YvhDEE X-IronPort-AV: E=Sophos;i="4.44,583,1249257600"; d="scan'208";a="215563689" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 19 Oct 2009 05:04:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9J54rnG013829; Mon, 19 Oct 2009 05:04:53 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Oct 2009 22:04:53 -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, 18 Oct 2009 22:04:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-bmwg-ipsec-meth-05 Thread-Index: AcpQebCsTsSZvQMvRLawMy9z8Q5Tow== From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 19 Oct 2009 05:04:53.0080 (UTC) FILETIME=[B162FD80:01CA5079] Subject: [secdir] Secdir review of draft-ietf-bmwg-ipsec-meth-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 05:04:47 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The document seems useful and well written. I have two comments: 1) The AES transforms are SHOULD, it seems we should be moving towards a MUST for these ciphers. Why are they a SHOULD? Is it because of the base IPSEC documents? If SHOULD is what is really wanted I think it would be good to have some explanation of why and how/if things are expected to evolve over time. =20 2) The security considerations section says there are no security considerations associated with this document. Yet the document has a section on denial of service attacks. It seems the security considerations section should acknowledge that these tests may provide some useful information about the expected of DOS attacks on the performance of the device or system under test. It would be great if it could say a bit more about the useful information collected, but that may be beyond the scope of the document.=20 Cheers, Joe From secdir-bounces@mit.edu Sat Oct 17 08:01: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 DAA323A695E for ; Sat, 17 Oct 2009 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=-2.744, BAYES_05=-1.11, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 TqaIoQyr6z3M for ; Sat, 17 Oct 2009 08:01:21 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D954E3A6930 for ; Sat, 17 Oct 2009 08:01:20 -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 n9HF1PCl017937 for ; Sat, 17 Oct 2009 11:01:25 -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 n9HF1OCD017931 for ; Sat, 17 Oct 2009 11:01:24 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n9HF1H7w029767 for ; Sat, 17 Oct 2009 11:01:17 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 99F42139BF56 for ; Sat, 17 Oct 2009 11:01:11 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id vSYSsikYl3OrtJAS for ; Sat, 17 Oct 2009 11:01:11 -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 7AE103A697C; Sat, 17 Oct 2009 08:01:05 -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 E950928C14F for ; Fri, 16 Oct 2009 16:16: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 dfm0Jh59Nd4a for ; Fri, 16 Oct 2009 16:16:59 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2D15B28C15A for ; Fri, 16 Oct 2009 16:16:58 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Myw2f-0004v7-2h for public-new-work-dist@listhub.w3.org; Fri, 16 Oct 2009 23:17:01 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Myw2e-0004sC-6i for public-new-work@listhub.w3.org; Fri, 16 Oct 2009 23:17:00 +0000 Received: from ssh.w3.org ([128.30.52.60] helo=jay.w3.org) by maggie.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Myw2b-00085f-3R; Fri, 16 Oct 2009 23:16:59 +0000 Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Myw2a-0007av-CU; Fri, 16 Oct 2009 19:16:56 -0400 Message-Id: From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 18:16:56 -0500 X-Mailer: Apple Mail (2.936) 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: maggie.w3.org 1Myw2b-00085f-3R f1fa873d2126d7c7726d47e1f0ce59b1 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/50 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 16 Oct 2009 23:17:01 +0000 X-Mailman-Approved-At: Sat, 17 Oct 2009 08:01:04 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 19 Oct 2009 00:41:29 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: HTML5 Japanese Interest Group (until 2009-11-13) 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, 17 Oct 2009 15:01:21 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the HTML Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the HTML5 Japanese Interest Group: http://www.w3.org/2009/09/html5-ig-jp-charter.html (English) http://www.w3.org/2009/09/html5-ig-jp-charter.ja.html (Japanese) 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-11-13 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 Mike Smith, HTML Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/MarkUp/Activity [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 From Shawn.Emery@Sun.COM Mon Oct 19 00:59: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 DB6633A68A5; Mon, 19 Oct 2009 00:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 JshYcCfNgZkO; Mon, 19 Oct 2009 00:59:41 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id DC98F3A6820; Mon, 19 Oct 2009 00:59:40 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9J7xkVl024417; Mon, 19 Oct 2009 07:59:46 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRR000004OXQZ00@mail-amer.sun.com>; Mon, 19 Oct 2009 01:59:46 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [174.51.225.48]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRR00IRQ4VMCBA0@mail-amer.sun.com>; Mon, 19 Oct 2009 01:59:46 -0600 (MDT) Date: Mon, 19 Oct 2009 01:58:41 -0600 From: Shawn M Emery Sender: Shawn.Emery@Sun.COM To: secdir@ietf.org Message-id: <4ADC1C31.6060207@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-gach-dcn@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-mpls-tp-gach-dcn-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 07:59:41 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes a method for encapsulating and delivery of Data Communication Network (DCN) messages over the General Associated Channel (G-ACh). The purpose of which, is to allow additional mechanisms to control/manage MPLS (Multiprotocol Label Switching) networks. The security considerations section does exist and describes that DCN messages are required to have adequate security mechanisms. The section doesn't describe what those mechanisms are, but should at least provide a reference from other MPLS RFC/I-Ds that do. General comments(s): None. Editorial comment(s): Expand the abbreviation of OAM in the introduction section. The following sentence is truncated: There is no need to create a CCh for every LSP between a pair of s/security attack/security attacks/ -- Shawn. From j.schoenwaelder@jacobs-university.de Mon Oct 19 02:45:59 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 3356028C132; Mon, 19 Oct 2009 02:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_20=-0.74, 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 Rl-ccnzgVC6A; Mon, 19 Oct 2009 02:45:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 332A73A67A3; Mon, 19 Oct 2009 02:45:58 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB117C0016; Mon, 19 Oct 2009 11:46:04 +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 eqVwz8k+v1hr; Mon, 19 Oct 2009 11:46:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9190C0014; Mon, 19 Oct 2009 11:46:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8484FD47A60; Mon, 19 Oct 2009 11:46:03 +0200 (CEST) Date: Mon, 19 Oct 2009 11:46:03 +0200 From: Juergen Schoenwaelder To: petithug@acm.org Message-ID: <20091019094603.GB4708@elstar.local> Mail-Followup-To: petithug@acm.org, iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 09:45:59 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document introduces the turn: and turns: URI schemes. The security considerations point to the relevant documents, one of them being RFC 3958. Section 8 of RFC 3958 states that S-NAPTR application protocols "should define some form of end-to-end authentication to ensure that the correct destination has been reached." I think it would be useful to spell how TURN meets this or whether there are reasons why TURN does not need such a sanity check. (1-2 sentences should be enough.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Adrian.Farrel@huawei.com Mon Oct 19 04:41:46 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 4D9CB3A681F; Mon, 19 Oct 2009 04:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWEo1WTGfPdG; Mon, 19 Oct 2009 04:41:44 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id C6D243A67D4; Mon, 19 Oct 2009 04:41:44 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRR00JA1F5RC7@usaga01-in.huawei.com>; Mon, 19 Oct 2009 04:41:51 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRR0053FF5ONB@usaga01-in.huawei.com>; Mon, 19 Oct 2009 04:41:51 -0700 (PDT) Date: Mon, 19 Oct 2009 12:37:04 +0100 From: Adrian Farrel To: Shawn M Emery , secdir@ietf.org Message-id: <319F18AE86FD41619D03842D26812186@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4ADC1C31.6060207@sun.com> Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-gach-dcn@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-mpls-tp-gach-dcn-06 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: Mon, 19 Oct 2009 11:41:46 -0000 Thanks for the review, Shawn. > The security considerations section does exist and describes that DCN > messages are required to have adequate security mechanisms. The section > doesn't describe what those mechanisms are, but should at least provide a > reference from other MPLS RFC/I-Ds that do. I'm a little unclear what you are asking for here. The draft defines a channel (i.e. a logical data link) down which any packet-based protocol could be run. Are you suggesting that this draft should contain a reference to the security mechanisms for each protocol that might be run down the channel? That seems like an impossible task. We could, I suppose, add text to note that "the MPLS data plane does not include any security mechanisms of its own, therefore it is important that protocols using the DCN apply their own security." Cheers, Adrian From Shawn.Emery@Sun.COM Mon Oct 19 07:37: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 4B95128C0FA; Mon, 19 Oct 2009 07:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 99CJwgJiGlK1; Mon, 19 Oct 2009 07:37:07 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id F3BC328C138; Mon, 19 Oct 2009 07:37:06 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9JEbD5u016311; Mon, 19 Oct 2009 14:37:13 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRR00E00MO72K00@mail-amer.sun.com>; Mon, 19 Oct 2009 08:37:13 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [174.51.225.48]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRR00D65NA0AZ60@mail-amer.sun.com>; Mon, 19 Oct 2009 08:37:12 -0600 (MDT) Date: Mon, 19 Oct 2009 08:36:06 -0600 From: Shawn M Emery In-reply-to: <319F18AE86FD41619D03842D26812186@your029b8cecfe> Sender: Shawn.Emery@Sun.COM To: Adrian Farrel Message-id: <4ADC7956.2020108@sun.com> References: <4ADC1C31.6060207@sun.com> <319F18AE86FD41619D03842D26812186@your029b8cecfe> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-tp-gach-dcn@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-mpls-tp-gach-dcn-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:37:08 -0000 Adrian Farrel wrote: > Thanks for the review, Shawn. > >> The security considerations section does exist and describes that DCN >> messages are required to have adequate security mechanisms. The >> section doesn't describe what those mechanisms are, but should at >> least provide a reference from other MPLS RFC/I-Ds that do. > > I'm a little unclear what you are asking for here. > The draft defines a channel (i.e. a logical data link) down which any > packet-based protocol could be run. > Are you suggesting that this draft should contain a reference to the > security mechanisms for each protocol that might be run down the > channel? That seems like an impossible task. > > We could, I suppose, add text to note that "the MPLS data plane does > not include any security mechanisms of its own, therefore it is > important that protocols using the DCN apply their own security." Yes or a reference to something like RFC 3985's security considerations section, as it also does a good job in explaining the inherit risks of existing packet protocols and possible solutions. Regards, -- Shawn. From hartmans@mit.edu Mon Oct 19 09:06:26 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 5A0173A681E for ; Mon, 19 Oct 2009 09:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.677, 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 OjqXb1Oy+3nx for ; Mon, 19 Oct 2009 09:06:25 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 50B883A6778 for ; Mon, 19 Oct 2009 09:06:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4AED42003E; Mon, 19 Oct 2009 12:06:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A1891446F; Mon, 19 Oct 2009 12:06:26 -0400 (EDT) To: Gonzalo Camarillo References: <4AD85644.5020904@ericsson.com> From: Sam Hartman Date: Mon, 19 Oct 2009 12:06:26 -0400 In-Reply-To: <4AD85644.5020904@ericsson.com> (Gonzalo Camarillo's message of "Fri\, 16 Oct 2009 14\:17\:24 +0300") 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: fluffy@cisco.com, secdir@ietf.org, oran@cisco.com, fandreas@cisco.com, dwing@cisco.com, rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 16:06:26 -0000 >>>>> "Gonzalo" == Gonzalo Camarillo writes: Gonzalo> [RFC4032], it is strongly RECOMMENDED that integrity Gonzalo> protection be applied to the SDP session descriptions. Gonzalo> S/MIME [RFC3853] provides such end- to-end integrity Gonzalo> protection, as described in [RFC3261]. Additionally, the I'm surprised you're referencing S/MIME here rather than something like identity. I understand none of the above have huge deployment, but I thought we had a fairly strong understanding that S/MIME was not the direction we were moving towards. From dwing@cisco.com Mon Oct 19 09:11:35 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 0FBCF3A68F9 for ; Mon, 19 Oct 2009 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 4YRnDSMhSTT8 for ; Mon, 19 Oct 2009 09:11:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2650B3A6899 for ; Mon, 19 Oct 2009 09:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1163; q=dns/txt; s=sjiport05001; t=1255968701; x=1257178301; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20|Subject:=20RE: =20[secdir]=20review=20of=20draft-ietf-mmusic-connectivit y-precon-06|Date:=20Mon,=2019=20Oct=202009=2009:11:38=20- 0700|Message-ID:=20<003b01ca50d6$d6d2e7d0$c4f0200a@cisco. com>|To:=20"'Sam=20Hartman'"=20, =0D=0A=20=20=20=20=20=20=20=20"'Gonzalo=20Camarillo'"=20< Gonzalo.Camarillo@ericsson.com>|Cc:=20"'Stephen=20Kent'" =20,=20,=20,=0D=0A=20=20=20=20=20=20=20=20,=20,=20|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20< tsliqebxta5.fsf@mit.edu>|References:=20<4AD85644.5020904@ericsson.com>=20; bh=alINKYAvlM4m0eUk2j2LB57WbVWoj154fQEv+iOdAPw=; b=AtTfWxqTV0DeG06HDmrU9e3iRgzO8WBI70wbvPWxXvx3VdLCUnXUtlBt rJI5bi8HQ0e+g6EwxiRj5F08K8HCy1p5REuSyR6nsmJDusx2Qr/Opog8w iDuo0UGR2RJ1b0Oc8ZX74/SZsF77I1ff63ofUwBNwzJpdo/EudsY6ES0r 8=; Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,586,1249257600"; d="scan'208";a="99596809" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2009 16:11:39 +0000 Received: from dwingwxp01 ([10.32.240.196]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9JGBcJu007366; Mon, 19 Oct 2009 16:11:38 GMT From: "Dan Wing" To: "'Sam Hartman'" , "'Gonzalo Camarillo'" References: <4AD85644.5020904@ericsson.com> Date: Mon, 19 Oct 2009 09:11:38 -0700 Message-ID: <003b01ca50d6$d6d2e7d0$c4f0200a@cisco.com> 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.3350 Thread-Index: AcpQ1h6Ym/HgXZDQQrGzRQ1L6l6HqgAAIu7Q X-Mailman-Approved-At: Mon, 19 Oct 2009 09:13:04 -0700 Cc: fluffy@cisco.com, secdir@ietf.org, oran@cisco.com, fandreas@cisco.com, rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 16:11:35 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Monday, October 19, 2009 9:06 AM > To: Gonzalo Camarillo > Cc: Stephen Kent; fluffy@cisco.com; secdir@ietf.org; > oran@cisco.com; fandreas@cisco.com; dwing@cisco.com; > rjsparks@nostrum.com > Subject: Re: [secdir] review of > draft-ietf-mmusic-connectivity-precon-06 > > >>>>> "Gonzalo" == Gonzalo Camarillo > writes: > > Gonzalo> [RFC4032], it is strongly RECOMMENDED that integrity > Gonzalo> protection be applied to the SDP session descriptions. > Gonzalo> S/MIME [RFC3853] provides such end- to-end integrity > Gonzalo> protection, as described in [RFC3261]. Additionally, the > > > I'm surprised you're referencing S/MIME here rather than something > like identity. > I understand none of the above have huge deployment, but I > thought we had a fairly strong understanding that S/MIME was > not the direction we were moving towards. You're right. S/MIME doesn't work and and isn't used. The suggestion for integrity protection should be RFC4474 ("SIP Identity"). -d From mshand@cisco.com Tue Oct 20 04:25: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 5F23E3A6900 for ; Tue, 20 Oct 2009 04:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nolcQa4H5-Dx for ; Tue, 20 Oct 2009 04:25:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 199C33A67AC for ; Tue, 20 Oct 2009 04:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mshand@cisco.com; l=10849; q=dns/txt; s=amsiport01001; t=1256037949; x=1257247549; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20mike=20shand=20|Subject:=20Re: =20comments=20on=20draft-ietf-rtgwg-ipfrr-framework-12 |Date:=20Tue,=2020=20Oct=202009=2012:25:49=20+0100 |Message-ID:=20<4ADD9E3D.1030709@cisco.com>|To:=20Sandra =20Murphy=20|CC:=20secdir@ietf.org,=20s tbryant@cisco.com,=20Ross=20Callon=20,=0D=0A=20=20=20=20=20=20=20=20"John=20G.=20Scudder"=20< jgs@juniper.net>,=20Alia=20Atlas=20, =0D=0A=20=20=20=20=20=20=20=20ZININ=20Alex=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20; bh=XhnYvA8CV642ONiY4A0vtr7myOMxnKTN31mXGvZLBq8=; b=PI4wNuJtZxfaI8hoGFXLt0Hkqr6zFiUxoRvrpgXMaloi2jMCGFKUnhlw sjrzO0x/Fu1+SVDIM34AUjL2xMDRzh4bWgFsNBMwmuHd9UO3d7cIrSqgv cW+YU3DcYK5Sn1ufh5N52pPzMtBGODLQHZCN0DHBAeDRoYgrgp2ZEMn7g A=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,590,1249257600"; d="scan'208";a="52237547" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2009 11:25:47 +0000 Received: from [64.103.65.18] (dhcp-gpk02-vlan300-64-103-65-18.cisco.com [64.103.65.18]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9KBPlLR001393; Tue, 20 Oct 2009 11:25:47 GMT Message-ID: <4ADD9E3D.1030709@cisco.com> Date: Tue, 20 Oct 2009 12:25:49 +0100 From: mike shand User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 20 Oct 2009 04:26:30 -0700 Cc: ZININ Alex , secdir@ietf.org, Alia Atlas , Ross Callon , "John G. Scudder" , stbryant@cisco.com Subject: Re: [secdir] comments on draft-ietf-rtgwg-ipfrr-framework-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, 20 Oct 2009 11:25:43 -0000 Thank you for your comments. We propose to address them as follows. Please see inline. Sandra Murphy wrote: > I am reviewing this document draft-ietf-rtgwg-ipfrr-framework-12 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 (that you > received well after last call). Feel free to forward to any > appropriate forum. > > This draft describes a framework for mechanisms to compute backup > "repair" paths that allow traffic to continue to forward to the > destination around failed links or nodes. This is similar to a > mechanism in MPLS to provide backup LSPs by using RSVP-TE. > > For background, I also looked at > RFC4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels > RFC 5296 Basic Specification for IP Fast Reroute: Loop-Free Alternates > draft-ietf-rtgwg-lf-conv-frmwk-06 A Framework for Loop-free Convergence > draft-bryant-ipfrr-tunnels-03 IP Fast Reroute using tunnels > draft-ietf-rtgwg-ipfrr-notvia-addresses-03 IP Fast Reroute Using > Not-via Addresses > > The security considerations covers some concerns introduced by using > fast-reroute mechanisms where providing repair paths may introduce > vulnerabilities, particularly where the repair paths could interfere > with existing robustness mechanisms (reverse path forwarding and > TTL limits). Our assumption is that there are no document actions above this point. > > I wonder if the knowledge of computed repair paths could > be useful to an attacker in doing traffic-shaping, i.e., an attacker who > was doing link-cutting to affect traffic flow. Similarly, the ability > to influence the computation of the repair path could be valuable. > Perhaps the framework document could mention that the proposed solutions > should consider the need to protect the computation from exposure (to the > same extent infrastructure information is protected from exposure) and > corruption/contamination if such an attack were a concern. These considerations are equally applicable to routing protocols in general and it does not seem appropriate to conduct a detailed analysis in this document. > > Note: > RFC5286 dismisses this concern, without noting the benefit of an > attacker to be able to producing a desired forwarding change if a > failure (and therefore repair activity) could be induced: > > Traffic to certain > destinations can be temporarily routed via next-hop routers that > would not be used with the same topology change if this mechanism > wasn't employed. However, these next-hop routers can be used anyway > when a different topological change occurs, and hence this can't be > viewed as a new security threat. > > The notvia-addresses draft does seem to recognize this risk from repair > paths: > > The repair endpoints present vulnerability in that they might be used > as a method of disguising the delivery of a packet to a point in the > network. > > The loop-free convergence framework draft in the last-called version > said: > > All micro-loop control mechanisms raise significant security issues > which must be addressed in their detailed technical description. > > which I thought should be reflected in this framework, > but that has changed in the post-last-call version to: > > This document analyzes the problem of micro-loops and summarizes a > number of potential solutions that have been proposed. These > solutions require only minor modifications to existing routing > protocols and therefore do not add additional security risks. > However a full security analysis would need to be provided within the > specification of a particular solution proposed for deployment. > > I'm curious as to how "significant security issues" changed to > "do not add additional security risks", but I don't have the time > to track down the last call comments that created that change. The original statement was just a place-holder held over from the first draft of the document. > > (I'd say that adding any additional information to a routing protocol > may not change the underlying vulnerabilities of the routing protocol > but certainly provides new means to cause damage when exploiting the > known vulenrabilities.) > > Non-security related comments: > > The following comment would have been useful to see before section 6: > > 6. Scope and applicability > > The initial scope of this work is in the context of link state IGPs. > Link state protocols provide ubiquitous topology information, which > facilitates the computation of repairs paths. We have moved this after the introduction. > > The following comment would have been useful to see before section > 4.2.5: > > Complete protection against multiple unrelated failures is out of > scope of this work. > We have copied this to the scope and applicability section. > Some terms in this document are never defined and/or used ambiguously. > > The following terms are not in the terminology list: > repair path We have added a definition:- "The path used by a repairing node to send traffic that it is unable to send via the normal path owing to a failure." > > Shared Risk Link Groups (SRLG) - perhaps so common in the teleco world > and in optical networks that definition was judged unnecessary. We think this is well known > > "link(node) protecting" "being protected" "fully protected > (link/node)" "unprotectable" - it would seem to refer to a link or node > failure for which a repair path is being computed, but may also mean > mechanisms to avoid micro-loops. In the context of this document they all refer to path protection. This doesn't seem to need any further clarification. > > a path being "affected" by a reconvergence - which I think means that > reconvergence to a new forwarding tree does not change any link > in the repair path Yes. A path not being affected means that there is no change to the path as a result of re-convergence of routers along the path. > > a repair path being "valid for a node" or "valid for destinations" Valid means that it is a functioning repair path. A repair path may be valid for a link failure, but not for a node failure. > > Some text I found confusing: > > Page 7: > > 2. In topologies that are susceptible to micro-loops, a mechanism to > prevent the effects of any micro-loops during subsequent re- > convergence. > > Because the loop free convergence draft distinguishes micro-loop > prevention > from micro-loop suppression, which attempts to avoid the impact on other > traffic from micro-loops, I thought "the effects of any micro-loops" > referred to this collateral damage. But later in that page it talks > about micro-loop avoidance, which sounds like the loop free convergence > draft's term "micro-loop prevention". So I'm not sure what is meant > here. We have revised this read:- "In topologies that are susceptible to micro-loops, a micro-loop control mechanism may be required" and inserted a reference to the loop free convergence framework. > > Page 10: > > 1. The percentage of links (or nodes) which can be fully protected > for all destinations. This is appropriate where the requirement > is to protect all traffic, but some percentage of the possible > failures may be identified as being un-protectable. > > > What does it mean to be "fully protected for all destinations"? Is that > redundant? And what about "unprotectable"? Is it possible to have > fully protected for all destinations > fully protected for some destinations > partially protected for all destinations > partially protected for some destinations > unprotectable for all destination > unprotectable for some destinations > etc.? Yes. We have revised the text to read :- 1. The percentage of links (or nodes) which can be fully protected (i.e. for all destinations). This is appropriate where the requirement is to protect all traffic, but some percentage of the possible failures may be identified as being un-protectable. 2. The percentage of destinations which can be protected for all link (or node) failures. This is appropriate where the requirement is to protect against all possible failures, but some percentage of destinations may be identified as being un-protectable. > > The outline in section 4 has me a bit confused: > 4. Mechanisms for IP Fast-reroute . . . . . . . . . . . . . . . . 7 > 4.1. Mechanisms for fast failure detection . . . . . . . . . . 7 > 4.2. Mechanisms for repair paths . . . . . . . . . . . . . . . 8 > 4.2.1. Scope of repair paths . . . . . . . . . . . . . . . . 9 > 4.2.2. Analysis of repair coverage . . . . . . . . . . . . . 9 > 4.2.3. Link or node repair . . . . . . . . . . . . . . . . . 10 > 4.2.4. Maintenance of Repair paths . . . . . . . . . . . . . 11 > 4.2.5. Multiple failures and Shared Risk Link Groups . . . . 11 > 4.3. Local Area Networks . . . . . . . . . . . . . . . . . . . 12 > 4.4. Mechanisms for micro-loop prevention . . . . . . . . . . . 12 > > Section 4.2.5 covers SRLG's as an example of multiple related failures, > which it says are out of scope. Then section 4.3 covers LANs - which > would seem to me to satisfy the definition of a SRLG. Is 4.3 supposed > to be a subtopic under 4.2.5? It seems out of keeping with the > mechanism focus of sections 4.1, 4.2 and 4.4. > > Also, 4.3 says: > > Protection against partial or complete failure of LANs is more > complex than the point to point case. In general there is a trade- > off between the simplicity of the repair and the ability to provide > complete and optimal repair coverage. > > (That's a complete quote of that section, which is another reason for > asking if it is really supposed to be a separate section) > > Does this imply that all previous discussion was about point to point > links only? We have moved section 4.3 to become 4.2.5 leaving the SRLG section as 4.2.6 > > > > RFC 5286 has an extended discussion of computing backup paths for > broadcast and NBMA links, so I was surprised to see this draft seem > to indicate that LANs were out of scope. They are not out of scope, but they do require special consdieration in the context of each repair mechanism. Mike & Stewart > > > > > > --Sandy Murphy > From d3e3e3@gmail.com Tue Oct 20 07:38:17 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 9A31A3A6A1E; Tue, 20 Oct 2009 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.263, 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 8Csb4Xa6YPo2; Tue, 20 Oct 2009 07:38:16 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 1645D3A6A1B; Tue, 20 Oct 2009 07:38:15 -0700 (PDT) Received: by fxm18 with SMTP id 18so6498587fxm.37 for ; Tue, 20 Oct 2009 07:38:19 -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:cc:content-type; bh=WskCWQkSRNQQ5QotzdQZpv3DbT4AwxUeZ7+5kZa19Po=; b=Q7XfFQvvt1TMd8t7Phinahbiy0j4zkn4WLcxlS733U6BuenAb6+qzuoHGX4xqdYJXK kvN02vEhohD1Z8IHv8pqL5Kw4dan/h8oGvwgtK5aiR3BkEYRqzSaFheP7amaRo8j1ABW lHxWtcobQa8+iceP2eAu0t+y4fRdWHg5nYNTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=CLP9ZQSahd8hCLozOiwp1aGSe8XWVDLF8avqSxY01UBXllfEw/I0ELtENBbhICTawD rBf9zzCpV7+L5HcfrEj8MJgS4btE/okAkCsScDt2L3ObDKljOy86SNX2LH1e/ZTJsVV9 FZk1DT47sbjFXqwFsfVvxdO9S8o6/RkaH6/lM= MIME-Version: 1.0 Received: by 10.204.11.17 with SMTP id r17mr6442721bkr.41.1256049499166; Tue, 20 Oct 2009 07:38:19 -0700 (PDT) Date: Tue, 20 Oct 2009 10:38:19 -0400 Message-ID: <1028365c0910200738i7d302349s58cad647e10e9951@mail.gmail.com> From: Donald Eastlake To: Richard Barnes , Alissa Cooper , Hannes.Tschofenig@gmx.net, martin.thomson@andrew.com, james.winterbottom@andrew.com Content-Type: multipart/alternative; boundary=000325557a0e37da0704765ed02a Cc: Cullen Jennings , IETF Discussion , secdir@ietf.org Subject: [secdir] draft-ietf-geopriv-held-identity-extensions-00 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, 20 Oct 2009 14:38:17 -0000 --000325557a0e37da0704765ed02a Content-Type: text/plain; charset=ISO-8859-1 This is an early security directorate review at the request of the working group. This draft is of extensions to existing drafts. Those existing drafts permit a Device to request its location using HTTP based on the source IP address in the requesting packets and include security precautions based on the transport used. The first extension expands "identity" to beyond a simple IP address by providing additional or alternative identity. The second extension permits an authorized third party to request the location of a Device for which it provides the identity. The data representation used within location requests is XML and, while the schema given looks reasonable, I didn't review it in detail. Privacy and Security Considerations This draft appears to have good grasp on the security problems in authenticating a suitable identity for the requestor of location information and the Device whose location is sought. The problems and the general unsuitability of transient or ambiguous identities are discussed as is the care that needs to be taken with identities that might have different meaning depending on network context, such as an address beyond a NAT box. Appropriate authentication of identity elements is mandated. The draft reasonably specifies that a policy establishment mechanism must exist which dictates when a third party would be authorized to request the location of a Device and that the default policy must be to deny all such requests. Overall, at the high level provided, the Privacy and and Security Considerations look good. Trivia Notwithstanding the fact that it is expanded in the title of the document, it couldn't hurt to also give the expansion of HELD in the Terminology section of the draft. Sometimes people fail to see things in what you would think was the most obvious place :-) I found this draft a bit heavy on the acronyms that, in some cases, make it a little harder to understand while saving only a little space, but this is just a matter of taste. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com --000325557a0e37da0704765ed02a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is an early=A0security directorate=A0review at the request of the= working group.

This draft is of extensions t= o existing drafts. Those existing
drafts permit a Device to reque= st its location using HTTP based on the
source IP address in the requesting packets and include security
=
precautions based on the transport used. The first extension expands
"identity" to beyond a simple IP address by providing ad= ditional or
alternative identity. The second extension permits an authorized third=
party to request the location of a Device for which it provides = the
identity.

The data representation us= ed within location requests is XML and,
while the schema given looks reasonable, I didn't review it in det= ail.


Privacy and Security Considera= tions

This draft appears to have good grasp on the= security problems in
authenticating a suitable identity for the requestor of location
=
information and the Device whose location is sought. The problems and<= /div>
the general unsuitability of transient or ambiguous identities ar= e
discussed as is the care that needs to be taken with identities that
might have different meaning depending on network context, such as= an
address beyond a NAT box.

Appropriat= e authentication of identity elements is mandated.

The draft reasonably specifies that a policy establishm= ent mechanism
must exist which dictates when a third party would = be authorized to
request the location of a Device and that the de= fault policy must be
to deny all such requests.

Overall, at the hi= gh level provided, the Privacy and and Security
Considerations lo= ok good.


Trivia

Notwithstanding the fact that it is expanded in the title of the
=
document, it couldn't hurt to also give the expansion of HELD in t= he
Terminology section of the draft. Sometimes people fail to see= things
in what you would think was the most obvious place :-)

<= /div>
I found this draft a bit heavy on the acronyms that, in some case= s,
make it a little harder to understand while saving only a litt= le
space, but this is just a matter of taste.

Th= anks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd= =A0 +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA=
d3e3e3@gmail.com
--000325557a0e37da0704765ed02a-- From catherine.meadows@nrl.navy.mil Tue Oct 20 09:27: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 68B313A68DE; Tue, 20 Oct 2009 09:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcfFtu8FWs3s; Tue, 20 Oct 2009 09:27:49 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 3AA613A682A; Tue, 20 Oct 2009 09:27:48 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n9KGKO0J010324; Tue, 20 Oct 2009 12:20:24 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n9KGKM2M003545; Tue, 20 Oct 2009 12:20:22 -0400 (EDT) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009102012202227001 ; Tue, 20 Oct 2009 12:20:22 -0400 Message-Id: <57D85170-46BE-4137-A64E-31098E0C8F91@nrl.navy.mil> From: Catherine Meadows To: secdir@ietf.org, rg+ietf@qualcomm.com, chris.newman@sun.com, iesg@ietf.org, harald@alvestrand.no, lee@cnnic.cn, alexey.melnikov@isode.com Content-Type: multipart/alternative; boundary=Apple-Mail-7-723170312 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Oct 2009 12:22:40 -0400 X-Mailer: Apple Mail (2.936) Subject: [secdir] Secdir review of draft-ietf-eai-pop-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:27:54 -0000 --Apple-Mail-7-723170312 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 POP3 protocol using the POP3 Extension Mechanism to 1) permit un-encoded UTF-8 in headers 2) add a mechanism to support login names outside ASCII character sets 3) add a mechanism to support UTF-8 protocol-level error strings in a language appropriate for the user The authors have done a good job of identifying the possible security implications of this approach and have also give references to the appropriate documents for the security implications of using UTF-8 in general. I don't see any further issues that need to be addressed here. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-7-723170312 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of = the security directorate's
ongoing effort to review all IETF = documents being processed by the IESG.
These comments were written = primarily for the benefit of the security
area directors. =  Document editors and WG chairs should treat these
comments just = like any other last call comments.

This document extends the POP3 protocol = using the POP3 Extension Mechanism
to
1) permit un-encoded UTF-8 in = headers
2) add a mechanism to support login names = outside ASCII character sets
3) add a = mechanism to support UTF-8 protocol-level error strings in a language = appropriate for the user

The authors have = done a good job of identifying the possible security implications of = this approach and have
also give references to the appropriate = documents for the security implications of using UTF-8 in = general.
I don't see any further issues that need to = be addressed here.

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

= --Apple-Mail-7-723170312-- From shanna@juniper.net Tue Oct 20 10:14: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 87FB428C146 for ; Tue, 20 Oct 2009 10:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWTZGVVo05v1 for ; Tue, 20 Oct 2009 10:14:10 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 91B533A68AC for ; Tue, 20 Oct 2009 10:14:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSt3v52ky6vUEYyNUdpPKWtNyrn+gCerg@postini.com; Tue, 20 Oct 2009 10:14:19 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Oct 2009 10:10:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 20 Oct 2009 13:10:37 -0400 From: Stephen Hanna To: "secdir@ietf.org" Date: Tue, 20 Oct 2009 13:08:46 -0400 Thread-Topic: secdir review for draft-ietf-pkix-sha2-dsa-ecdsa-10.txt Thread-Index: AcpRp+vw9ahUqlr+STSUAXn8dc4F/gAAAWPA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review for draft-ietf-pkix-sha2-dsa-ecdsa-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 17:14:11 -0000 Forgot to cc secdir. Thanks, Steve=20 -----Original Message----- From: Stephen Hanna=20 Sent: Tuesday, October 20, 2009 1:08 PM To: 'draft-ietf-pkix-sha2-dsa-ecdsa@tools.ietf.org'; iesg@ietf.org Subject: secdir review for draft-ietf-pkix-sha2-dsa-ecdsa-10.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. This document defines ASN.1 OIDs for DSA and ECDSA digital signatures with SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithms. These OIDs may be used in X.509 certificates to indicate the signature algorithm used. The specification is clear, well conceived, and well written. The Security Considerations section is brief but it points to documents that provide an appropriate level of supplementary information. In summary, I do not have any security concerns related to this document. From petithug@acm.org Tue Oct 20 10:59:32 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 8DB723A677E; Tue, 20 Oct 2009 10:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSyMznZImovV; Tue, 20 Oct 2009 10:59:31 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id E2F7B3A6859; Tue, 20 Oct 2009 10:59:31 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 8B2726C9852C; Tue, 20 Oct 2009 17:59:39 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id C33246C98524; Tue, 20 Oct 2009 17:59:38 +0000 (UTC) Message-ID: <4ADDFA8A.40902@acm.org> Date: Tue, 20 Oct 2009 10:59:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Juergen Schoenwaelder References: <20091019094603.GB4708@elstar.local> In-Reply-To: <20091019094603.GB4708@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 20 Oct 2009 11:00:55 -0700 Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 17:59:32 -0000 Hi Juergen, Thanks for the review. See my response below. Juergen Schoenwaelder wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document introduces the turn: and turns: URI schemes. The security > considerations point to the relevant documents, one of them being RFC > 3958. Section 8 of RFC 3958 states that S-NAPTR application protocols > "should define some form of end-to-end authentication to ensure that > the correct destination has been reached." I think it would be useful > to spell how TURN meets this or whether there are reasons why TURN > does not need such a sanity check. (1-2 sentences should be enough.) I propose to replace the second paragraph of section 6 by the following text. Let me know if it addresses your comment: "The Application Service Tag and Application Protocol Tags defined in this document do not introduce any specific security issues beyond the security considerations discussed in [RFC3958]. [RFC3958] requests that an S-NAPTR application defines some form of end-to-end authentication to ensure that the correct destination has been reached. This is achieved by the mandatory Long-Term Credential Mechanism defined by [RFC5389] and additionally for a "turns" URI by the usage of TLS." -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From jon.peterson@neustar.biz Tue Oct 20 16:15: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 0F48F3A68D6; Tue, 20 Oct 2009 16:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 B8tuWcqsOh1G; Tue, 20 Oct 2009 16:15:56 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 5FA443A66B4; Tue, 20 Oct 2009 16:15:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1256080562; x=1256166962; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=BO/gDx6evCKycYhS/7z/kxEg73pLVpDJyt6zeP4iwyVBnXrAzvDMq/AERa0R0eoYHsWgTRzPCwHSwc ZRZ4FrLQ== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.18885369; Tue, 20 Oct 2009 19:16:00 -0400 Received: from 192.168.128.150 ([192.168.128.150]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Oct 2009 23:15:46 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 20 Oct 2009 16:15:44 -0700 From: Jon Peterson To: Stephen Hanna , "iesg@ietf.org" , "secdir@ietf.org" , "draft-peterson-rai-rfc3427bis@tools.ietf.org" Message-ID: Thread-Topic: secdir review of draft-peterson-rai-rfc3427bis-02.txt Thread-Index: AcoPYx3URs99g7Z4T5WHm8QuiidkThCeCHAK In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [secdir] secdir review of draft-peterson-rai-rfc3427bis-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:15:58 -0000 Hello Stephen, Sorry for the lengthy delay getting back to you on this one. This is a very detailed and helpful review that caught a lot of important issues. I've given your points below some consideration, and discussed a bit with the RAI ADs. To the most important issue first: I do agree that the level of security expertise required of the Designated Expert is a potential area of concern. The decision to allow IANA registration of headers supervised by a Designated Expert was not an easy one, though we believe it balances the needs of the community to specify new headers freely and rapidly with the basic mandate to prevent conflicts in the namespace and preserve interoperability. The SIP community has become large and diverse, and represents a huge number of interests who define new proprietary headers today without leaving a trace in the IANA precisely because the original RF3427 process is too cumbersome. We would like to lure those parties into registering those headers with this more lightweight process. As the "stuckee" who reviewed many of the P- header submissions under the original RFC3427 over the past six years, it was my own judgment that external parties mostly used the P- header process to specify the conveyance of information which had value to their own systems but did not alter SIP transaction processing. Reducing the P- header process to the one in RFC3427bis, where these IANA-registered headers are "informational" in nature ,is a small incremental step from the P- usage under the original RFC3427. If a proposed header introduced a new SIP security mechanism to replace, say, RFC2617-style authentication or TLS, I think it unambiguously would not be purely "informational" in nature - they would, as new text in RFC3427 says, "redefine or contradict normative behavior defined in standards track SIP specifications." While I agree that the review of a RAI Area Expert is not the same as a security review, I do believe the Designated Expert can distinguish between a mechanism that changes the behavior of SIP and one that does not. I suspect anything that undermined the security of SIP in that sense would fail this check, and thus be ineligible for registration through this "informational" channel. Does that make sense? This is your most substantive comment, but it also proposes that we reverse more or less the sole motivation for this document - making it easier to register headers of an informational nature. Regarding the second concern about IANA registration of headers, the longevity of external references versus RFCs, for the most part (from the precedent of P- headers) we expect that external standards bodies will be a primary customer of this mechanism, and thus we don't want to rule out pointers to their own long-lived publications. RFC5226 does have a registration model called "Specification Required" which, on balance, I wouldn't object to using here if that would remove your concern. It might appear that the other stipulations in RFC3427 Section 4.1 that applied to reviewers of P- headers no longer apply in RFC3427bis, but actually almost all of them are preserved, including the review of overlap (that's actually in RFC3427bis Section 4 in the paragraph right before bullet 1), and of course the Expert Reviewer. The only things actually removed are the request for clear documents (which is a bit of a motherhood-and-apple-pie requirement) and the applicability statement, and that only because there is no longer necessarily an RFC for it to live in - we can't expect an external publication to have an IETF-ready applicability statement. To some of your more detailed points: > * Does the term "consensus" in the first sentence of the > third paragraph of section 3 refer to WG consensus or > IETF consensus? I believe that it refers to WG consensus > but this should be clarified. It does indeed mean WG consensus, fixed. > * The last sentence of the fifth paragraph in section 3 > says that the DISPATCH working group may "approve > proposals for extensions if the requirements are judged > to be appropriate to SIP, but are not sufficiently > general for standards track activity." I think that > these proposals would then proceed as individual > submissions. If that's right, I suggest that this be > mentioned in this sentence. This sentence is actually a holdover from the original RFC3427 and needs to be eliminated, as a separate reviewer recently pointed out. The DISPATCH WG is not chartered to perform any protocol work whatsoever. So in a sense you are correct that these proposals would proceed as individual submissions, but the DISPATCH WG does not in any sense "approve" them. > * The first paragraph of section 4.1 says that "Normal > event packages can be created and registered by the > publication of any Working Group RFC (Informational, > Standards Track, Experimental), provided that the RFC > is a chartered working group item." However, the > next paragraph describes how individual submissions > for event packages may be published. This seems to > be a contradiction. Maybe the sentence that I just > quoted is not intended to exhaustively describe all > the ways that event packages can be created. If that's > the case, the sentence should be clarified. I'm not quite sure I see the contradiction you do here - but nor do I really think the first sentence you quote above really adds any value to the section, so I'm happy to remove it. The remainder of the guidance here is more exact. These below are all very welcome! > * Paragraph four of section 4.1 says that the procedure > for registering event packages developed outside the > scope of an IETF working group is "RFC Required". > However, the process described in the following > paragraphs would better be described as "RFC Required > with Designated Expert Review". Okay, I'll put that. > * As the first paragraph in the Security Considerations > section says, feature interactions can have significant > security implications. However, the text should go one > step beyond to require that all RFCs that modify or > extend SIP must consider the security implications of > feature interactions. Okay, I'll tag that on to the last sentence of the Sec Cons. > * The fifth paragraph of section 7 says that "For event > template packages, registrations must follow the RFC5226 > processes for Standards Action." Actually, the earlier > part of this document included an additional requirement > that such specifications must be developed by an IETF > Working Group. Probably that should be documented here. Added. > * The fifth paragraph of section 7 also states that > IETF Review is the process used for ordinary event > packages. That is not consistent with section 4.1, > which states that the process for these is RFC Required > (with Designated Expert review). I think that > section 4.1 is correct and the text in section 7 > should be updated. Fixed. > Here are my non-substantive comments. > > * In the first paragraph of section 2, "SIP has to preserve" > should be "SIP has been to preserve". Fxd. > * In the first paragraph of section 2.1, the word "exists" > should be removed from the end of the first sentence. Fxd. > * In the second paragraph of section 2.1, the phrase > "updates or obsoletes" is not clear. I suggest using > the phrase "documents that update or obsolete". > Further, I suggest adding the phrase "or their successors" > at the end of that sentence. Fxd. > * In the third paragraph of section 2.1, "will the use" > should be "will use". In the following sentence, delete > the phrase "and the rest of this document". That is > a copy and paste error left over from RFC 3427, > I think. In the last sentence of this paragraph, > I suggest changing "any protocol in the IETF" to > "SIP (and any protocol in the IETF)". The emphasis > should be on SIP in this document. Yeah, that latter bit is all legacy text, nuking. > * In the fourth paragraph of section 2.1, change the > first sentence to say "IETF working group" instead > of just "working group". I think that's the intent > but someone could read it to include working groups > of other organizations also. Fxd. > * In the second paragraph of section 4, there's an > extra comma after "While". Also, I think the word > "general" is missing after the phrase "deal with > a point solution and are not". Fxd and Fxd. > * In the sixth paragraph of section 4, the phrase > "Informational IETF specifications" would be > clearer if it was replaced by "Informational RFCs". Fxd. > * The first paragraph of section 4.1 includes a > reference to "[6]" but references in this spec > are of the form "[RFCXXXX]". I believe this > reference is supposed to be [RFC3265]. Fxd. > * In the numbered list at the end of section 4.1, > several references use the wrong format. The > references to [6] should be [RFC3265] and the > reference to [3] should be [RFC3261], I think. Fxd. > * The text "(See Section 4)" appears in the list > at the end of section 4.1 but the meaning of > this text is not clear. Please clarify. That's in reference to the "must not redefine or contradict normative behavior" text in Section 4 - I think that's clear where it is now. > * More numeric references appear in section 6. > These can easily be transformed to the more > explicit style used in this document since > the RFC numbers are adjacent to the references. Fxd! From julienl@qualcomm.com Tue Oct 20 17: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 5B51A3A6991; Tue, 20 Oct 2009 17:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.663 X-Spam-Level: X-Spam-Status: No, score=-105.663 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldUfqJWOxfDC; Tue, 20 Oct 2009 17:50:30 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 71B2A3A696C; Tue, 20 Oct 2009 17:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256086239; x=1287622239; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"secdir@ietf.org"=20,=0D=0A=20=20 =20=20=20=20=20=20"draft-ietf-sip-certs@tools.ietf.org" =0D=0A=09,=0D=0A=20 =20=20=20=20=20=20=20"iesg@ietf.org"=20 |Date:=20Tue,=2020=20Oct=202009=2017:49:23=20-0700 |Subject:=20SecDir=20review=20of=20draft-ietf-sip-certs-0 9|Thread-Topic:=20SecDir=20review=20of=20draft-ietf-sip-c erts-09|Thread-Index:=20AcpR6FThXyKfBp67R2K2ZM1BoMekew=3D =3D|Message-ID:=20|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5777"=3B=20a=3D"25705831"; bh=LWRVoi9Jv/2pqAiHtzjKAwOPJB0NBf9jLJMuCVkTCXM=; b=ngRVR88oNQ9Xt+1GyFVSSyBOgX3j7ro40V2YWoK1EdsH9AzGFSDMtX8Z h7wT9QzCGox+kDo3tCBXhRxX08VAw7BCJfkCNTvDZe63BqO+DtX3pEzta mXNbdqtZrJuiLl6QfykyMG4IOgSkhwrENaygHq6PYk79TAzsQ8jWLlvAE Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5777"; a="25705831" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2009 17:50:38 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9L0oc6k018943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2009 17:50:38 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9L0oStp003314 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Oct 2009 17:50:38 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 20 Oct 2009 17:49:25 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Tue, 20 Oct 2009 17:49:25 -0700 From: "Laganier, Julien" To: "secdir@ietf.org" , "draft-ietf-sip-certs@tools.ietf.org" , "iesg@ietf.org" Date: Tue, 20 Oct 2009 17:49:23 -0700 Thread-Topic: SecDir review of draft-ietf-sip-certs-09 Thread-Index: AcpR6FThXyKfBp67R2K2ZM1BoMekew== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-sip-certs-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 00:50:31 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines a credential service that allows SIP user agents store their certificates and to retrieve the certificates of=20 other users. These user agents certificates are not required to be signed by well known certificate authorities and can possibly be self-signed.=20 The mechanism leverages on the SIP Identity framework to provide the required features.=20 I have found this document to be especially well written and easily=20 understandable, even by a non-SIP expert such as myself. The security=20 considerations section is comprehensive and seems to analyze the protocol adequately. --julien From julienl@qualcomm.com Tue Oct 20 18:08: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 238F43A688F; Tue, 20 Oct 2009 18:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.725 X-Spam-Level: X-Spam-Status: No, score=-103.725 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNx1AqV3-IMo; Tue, 20 Oct 2009 18:08:47 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 438763A67A7; Tue, 20 Oct 2009 18:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256087335; x=1287623335; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"secdir@ietf.org"=20,=0D=0A=20=20 =20=20=20=20=20=20"draft-ietf-ospf-af-alt@tools.ietf.org" =0D=0A=09,=0D=0A =20=20=20=20=20=20=20=20"iesg@ietf.org"=20 ,=0D=0A=20=20=20=20=20=20=20=20"ospf-chairs@tools.ietf.or g"=20,=0D=0A=20=20=20=20=20 =20=20=20"ospf-ads@tools.ietf.org"=20|Date:=20Tue,=2020=20Oct=202009=2018:07:09=20-0700 |Subject:=20SecDir=20review=20of=20draft-ietf-ospf-af-alt -08|Thread-Topic:=20SecDir=20review=20of=20draft-ietf-osp f-af-alt-08|Thread-Index:=20AcpR6tA/gpHqtZMTQK6E1jGiwjESN w=3D=3D|Message-ID:=20|Accept-Language:=20 en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5777"=3B=20a=3D"25705592"; bh=lC+rmNG7NFogpfJcdxn2uWKcxSWAJHbjT4ofF7oqOV0=; b=kzITH58vefxp6ZE0SON6/r2t3STK7gG7rfSerqcaI+5DLmCopXLujoi0 7LNC93fkMrjZ2+Uu1nlE7MSNX11X0GaJgjq3qzkfA7vv81ZhJJWUG/vob nkLbAx6JZ+/t14YJFqKjf8XPjvOuWutXT0kq2+/vN6fuTUwg+z+aoV57d g=; X-IronPort-AV: E=McAfee;i="5300,2777,5777"; a="25705592" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2009 18:08:40 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9L18eSF024673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2009 18:08:40 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9L18dL9010366 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Oct 2009 18:08:39 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 20 Oct 2009 18:07:11 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Tue, 20 Oct 2009 18:07:11 -0700 From: "Laganier, Julien" To: "secdir@ietf.org" , "draft-ietf-ospf-af-alt@tools.ietf.org" , "iesg@ietf.org" , "ospf-chairs@tools.ietf.org" , "ospf-ads@tools.ietf.org" Date: Tue, 20 Oct 2009 18:07:09 -0700 Thread-Topic: SecDir review of draft-ietf-ospf-af-alt-08 Thread-Index: AcpR6tA/gpHqtZMTQK6E1jGiwjESNw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-ospf-af-alt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 01:08:48 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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. This draft specifies a mechanism for supporting multiple address families (= e.g., multicast IPv6, unicast IPv4, and multicast IPv4) in OSPFv3 using mul= tiple instances of the protocol. An address family is mapped to an OSPFv3 i= nstance via the Instance ID field included in the OSPFv3 header. The security considerations sections seems adequate in pointing to existing= OSPFv3 specifications since this extension does not seem to introduce addi= tional security issues compared to that of basic OSPFv3, and the fact that = the multiple instances supporting different address families will have to s= hare the same IPsec SAs when IPsec is used to protect OSPFv3 (due to the ab= sence of a traffic selector operating on the Instance ID field of the OSPFv= 3 header) is acknowledged. Small typo in the sec-cons: s/IPsec [IPsec]. can/IPsec [IPsec] can/ --julien From tena@huawei.com Tue Oct 20 20:25:53 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 D7FF928C184; Tue, 20 Oct 2009 20:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.928 X-Spam-Level: X-Spam-Status: No, score=-99.928 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cybNbW1F+Rjo; Tue, 20 Oct 2009 20:25:52 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 9A58928C185; Tue, 20 Oct 2009 20:25:52 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU004QWHJ2WW@szxga01-in.huawei.com>; Wed, 21 Oct 2009 11:25:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU000SPHJ25K@szxga01-in.huawei.com>; Wed, 21 Oct 2009 11:25:50 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00HREHJ2AU@szxml04-in.huawei.com>; Wed, 21 Oct 2009 11:25:50 +0800 (CST) Date: Wed, 21 Oct 2009 11:25:50 +0800 From: Tina TSOU To: iesg@ietf.org, secdir@ietf.org, draft-ietf-syslog-sign@tools.ietf.org, syslog-chairs@tools.ietf.org Message-id: <00d701ca51fe$2fff1630$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_HRQrkKnZHKMxKP+sFmTlCA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [secdir] SecDir re-check of draft-ietf-syslog-sign-28 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, 21 Oct 2009 03:25:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HRQrkKnZHKMxKP+sFmTlCA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT I have reviewed draft-ietf-syslog-sign-27 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a mechanism, called syslog-sign in this document, which adds origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to syslog. I sent the review of draft-ietf-syslog-sign-27 some time ago. I re-checked the draft-ietf-syslog-sign-28. I have no more further comments. B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_HRQrkKnZHKMxKP+sFmTlCA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

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

 

This document=20 describes a mechanism, called syslog-sign in this document, which adds = origin=20 authentication, message integrity, replay resistance, message = sequencing, and=20 detection of missing messages to syslog.

 

I = sent the=20 review of draft-ietf-syslog-sign-27 some time ago. I re-checked the=20 draft-ietf-syslog-sign-28. I have no more further comments.

 

 

B.=20 R.
Tina
http://tinatsou.weebly.com/contact.html

 

 

 

--Boundary_(ID_HRQrkKnZHKMxKP+sFmTlCA)-- From watson@qualcomm.com Tue Oct 20 11:46:03 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 8B79F3A69E7; Tue, 20 Oct 2009 11:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.448 X-Spam-Level: X-Spam-Status: No, score=-105.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5NC0trfuiPN; Tue, 20 Oct 2009 11:46:02 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A04CA3A6939; Tue, 20 Oct 2009 11:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1256064370; x=1287600370; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20T om=20Yu=20,=20"iesg@ietf.org"=20,=0D=0A=20=20=20=20=20=20=20=20"secdir@ietf.org"=0D =0A=09,=0D=0A=20=20=20=20=20=20=20=20"rm t-chairs@tools.ietf.org"=20, =0D=0A=20=20=20=20=20=20=20=20"Luby,=20Michael"=20,=0D=0A=20=20=20=20=20=20=20=20"Vicisano,=20L orenzo"=0D=0A=09|Date:=20Tue,=2020 =20Oct=202009=2011:46:08=20-0700|Subject:=20Re:=20secdir =20review=20of=20draft-ietf-rmt-pi-alc-revised-08 |Thread-Topic:=20secdir=20review=20of=20draft-ietf-rmt-pi -alc-revised-08|Thread-Index:=20Aco+TAWpROyR/gAsR5Sjwhufo N9YfwTaZBFr|Message-ID:=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C7035380345BCwatsonqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5777"=3B=20a=3D"25682749"; bh=OFahZbACY4k2nXuqFZkbegUCCCsI/qVGi3CvBF5bdgM=; b=Dw3RAHtw4xCo+nG47ObQ6FcTPVItO/8z/sl9EdNsrh9kG+e86zWGRbaS oNewJVvf6+/zLLv2DU3uu+K/hEkXutU4bvF8JUFnIVxGAGztg9iOuVjZi hb/q4YhEG7tuR2s9iAe5V3GZtt2EyuBGa/Vw7aBllrP+1DujmXZeBdMj9 c=; X-IronPort-AV: E=McAfee;i="5300,2777,5777"; a="25682749" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2009 11:46:10 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9KIkAGE003330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2009 11:46:10 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9KIk9gU013380 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Oct 2009 11:46:09 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 20 Oct 2009 11:46:08 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Tue, 20 Oct 2009 11:46:08 -0700 From: "Watson, Mark" To: Tom Yu , "iesg@ietf.org" , "secdir@ietf.org" , "rmt-chairs@tools.ietf.org" , "Luby, Michael" , "Vicisano, Lorenzo" Date: Tue, 20 Oct 2009 11:46:08 -0700 Thread-Topic: secdir review of draft-ietf-rmt-pi-alc-revised-08 Thread-Index: Aco+TAWpROyR/gAsR5SjwhufoN9YfwTaZBFr Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7035380345BCwatsonqualcommcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 20 Oct 2009 23:05:49 -0700 Subject: Re: [secdir] secdir review of draft-ietf-rmt-pi-alc-revised-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:46:03 -0000 --_000_C7035380345BCwatsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom, Thanks for the comments. I will change the reference mentioned below. Does anyone have a recommendation for an Ipsec expert who could take a look= at the Security Considerations section as suggested by Tom ? Regards, Mark Watson On 9/25/09 6:52 PM, "Tom Yu" wrote: Security: The Security Considerations section looks reasonably thorough. It might be a good idea for an IPsec expert to take another look at it, as I am not very familiar with IPsec. Editorial: Section 1.3 indicates that the Any-Source Multicast (ASM) model of multicast is defined in RFC 1112. That RFC does not actually use that terminology, even though it may define the concept. The first RFC that I can find that uses the term Any-Source Multicast is RFC 3569. --_000_C7035380345BCwatsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: secdir review of draft-ietf-rmt-pi-alc-revised-08 Tom,

Thanks for the comments. I will change the reference mentioned below.

Does anyone have a recommendation for an Ipsec expert who could take a look= at the Security Considerations section as suggested by Tom ?

Regards,

Mark Watson


On 9/25/09 6:52 PM, "Tom Yu" <tlyu@MI= T.EDU> wrote:

Security:

The Security Considerations section looks reasonably thorough.  It
might be a good idea for an IPsec expert to take another look at it,
as I am not very familiar with IPsec.

Editorial:

Section 1.3 indicates that the Any-Source Multicast (ASM) model of
multicast is defined in RFC 1112.  That RFC does not actually use that=
terminology, even though it may define the concept.  The first RFC
that I can find that uses the term Any-Source Multicast is RFC 3569.

--_000_C7035380345BCwatsonqualcommcom_-- From j.schoenwaelder@jacobs-university.de Wed Oct 21 02:51:52 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 C02023A68F6; Wed, 21 Oct 2009 02:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=0.731, 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 y-bqL32BaTxB; Wed, 21 Oct 2009 02:51:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7BFB43A68A7; Wed, 21 Oct 2009 02:51:51 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF7E4C0021; Wed, 21 Oct 2009 11:51:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tCzsEf2e4VfN; Wed, 21 Oct 2009 11:51:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B71FC001E; Wed, 21 Oct 2009 11:51:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A67A5D4CB6F; Wed, 21 Oct 2009 11:51:57 +0200 (CEST) Date: Wed, 21 Oct 2009 11:51:57 +0200 From: Juergen Schoenwaelder To: Marc Petit-Huguenin Message-ID: <20091021095157.GC3177@elstar.local> Mail-Followup-To: Marc Petit-Huguenin , "iesg@ietf.org" , "secdir@ietf.org" References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADDFA8A.40902@acm.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 09:51:52 -0000 On Tue, Oct 20, 2009 at 07:59:38PM +0200, Marc Petit-Huguenin wrote: > Hi Juergen, > > Thanks for the review. See my response below. > > Juergen Schoenwaelder wrote: > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > The document introduces the turn: and turns: URI schemes. The security > > considerations point to the relevant documents, one of them being RFC > > 3958. Section 8 of RFC 3958 states that S-NAPTR application protocols > > "should define some form of end-to-end authentication to ensure that > > the correct destination has been reached." I think it would be useful > > to spell how TURN meets this or whether there are reasons why TURN > > does not need such a sanity check. (1-2 sentences should be enough.) > > I propose to replace the second paragraph of section 6 by the following text. > Let me know if it addresses your comment: > > "The Application Service Tag and Application Protocol Tags defined in > this document do not introduce any specific security issues beyond > the security considerations discussed in [RFC3958]. [RFC3958] > requests that an S-NAPTR application defines some form of end-to-end > authentication to ensure that the correct destination has been > reached. This is achieved by the mandatory Long-Term Credential > Mechanism defined by [RFC5389] and additionally for a "turns" URI by > the usage of TLS." I checked RFC 5389 and it says: This section defines two mechanisms for STUN that a client and server can use to provide authentication and message integrity; these two mechanisms are known as the short-term credential mechanism and the long-term credential mechanism. These two mechanisms are optional, and each usage must specify if and when these mechanisms are used. Since this sounds optional, I am confused now since your text talks about a _mandatory_ Long-Term Credential Mechanism. Questions: - Is the Long-Term Credential Mechanism mandatory or optional? RFC 5389 sounds like it is optional - any other documents I am missing? - If it is optional in RFC 5389, is it sufficient to say "This can be achieved by the optional Long-Term Credential Mechanism defined by [RFC5389] ..."? (The problem with this is that someone deploying things can be out of luck doing the right thing if implementations do not support doing the right thing.) - Or, if it is optional in RFC 5389, should the security considerations of the URI scheme require implementation of the Long-Term Credential Mechanism, that is making implementation mandatory for usage with turn URIs? /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 Oct 21 03:01: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 45A0C3A697A; Wed, 21 Oct 2009 03:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.010, 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 DhgFmMn0Lp6q; Wed, 21 Oct 2009 03:01:20 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C8AA53A68A7; Wed, 21 Oct 2009 03:01:19 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-71-4adedbf626b3 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 32.BF.08816.6FBDEDA4; Wed, 21 Oct 2009 12:01:26 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 12:01:06 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 12:01:06 +0200 Message-ID: <4ADEDBE2.2090704@ericsson.com> Date: Wed, 21 Oct 2009 12:01:06 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marc Petit-Huguenin , "iesg@ietf.org" , "secdir@ietf.org" References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> <20091021095157.GC3177@elstar.local> In-Reply-To: <20091021095157.GC3177@elstar.local> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Oct 2009 10:01:06.0253 (UTC) FILETIME=[67D977D0:01CA5235] X-Brightmail-Tracker: AAAAAA== Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.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, 21 Oct 2009 10:01:21 -0000 Hi Jurgen, I do understand your confusion. RFC 5389 is STUN. TURN is an extension of STUN, and TURN mandates authentication. The default to use mechanism however, is defined in STUN, thus the reference to RFC 5389. Magnus Juergen Schoenwaelder skrev: > On Tue, Oct 20, 2009 at 07:59:38PM +0200, Marc Petit-Huguenin wrote: >> Hi Juergen, >> >> Thanks for the review. See my response below. >> >> Juergen Schoenwaelder wrote: >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>> >>> The document introduces the turn: and turns: URI schemes. The security >>> considerations point to the relevant documents, one of them being RFC >>> 3958. Section 8 of RFC 3958 states that S-NAPTR application protocols >>> "should define some form of end-to-end authentication to ensure that >>> the correct destination has been reached." I think it would be useful >>> to spell how TURN meets this or whether there are reasons why TURN >>> does not need such a sanity check. (1-2 sentences should be enough.) >> I propose to replace the second paragraph of section 6 by the following text. >> Let me know if it addresses your comment: >> >> "The Application Service Tag and Application Protocol Tags defined in >> this document do not introduce any specific security issues beyond >> the security considerations discussed in [RFC3958]. [RFC3958] >> requests that an S-NAPTR application defines some form of end-to-end >> authentication to ensure that the correct destination has been >> reached. This is achieved by the mandatory Long-Term Credential >> Mechanism defined by [RFC5389] and additionally for a "turns" URI by >> the usage of TLS." > > I checked RFC 5389 and it says: > > This section defines two mechanisms for STUN that a client and server > can use to provide authentication and message integrity; these two > mechanisms are known as the short-term credential mechanism and the > long-term credential mechanism. These two mechanisms are optional, > and each usage must specify if and when these mechanisms are used. > > Since this sounds optional, I am confused now since your text talks > about a _mandatory_ Long-Term Credential Mechanism. Questions: > > - Is the Long-Term Credential Mechanism mandatory or optional? RFC 5389 > sounds like it is optional - any other documents I am missing? > > - If it is optional in RFC 5389, is it sufficient to say "This can be > achieved by the optional Long-Term Credential Mechanism defined by > [RFC5389] ..."? (The problem with this is that someone deploying > things can be out of luck doing the right thing if implementations > do not support doing the right thing.) > > - Or, if it is optional in RFC 5389, should the security > considerations of the URI scheme require implementation of the > Long-Term Credential Mechanism, that is making implementation > mandatory for usage with turn URIs? > > /js > -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Wed Oct 21 03:27:47 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 027DD3A69E1; Wed, 21 Oct 2009 03:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.693, 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 eC6VG+7WEjkJ; Wed, 21 Oct 2009 03:27:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 01BC23A69C9; Wed, 21 Oct 2009 03:27:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64AA7C001E; Wed, 21 Oct 2009 12:27:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OgvB19CGIDjp; Wed, 21 Oct 2009 12:27:53 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E537C0004; Wed, 21 Oct 2009 12:27:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6D5A9D4CEA7; Wed, 21 Oct 2009 12:27:52 +0200 (CEST) Date: Wed, 21 Oct 2009 12:27:52 +0200 From: Juergen Schoenwaelder To: Magnus Westerlund Message-ID: <20091021102752.GA4104@elstar.local> Mail-Followup-To: Magnus Westerlund , Marc Petit-Huguenin , "iesg@ietf.org" , "secdir@ietf.org" References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> <20091021095157.GC3177@elstar.local> <4ADEDBE2.2090704@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADEDBE2.2090704@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Marc Petit-Huguenin , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 10:27:47 -0000 On Wed, Oct 21, 2009 at 12:01:06PM +0200, Magnus Westerlund wrote: > I do understand your confusion. RFC 5389 is STUN. TURN is an extension > of STUN, and TURN mandates authentication. The default to use mechanism > however, is defined in STUN, thus the reference to RFC 5389. Thanks, now I understand this better. So does this wording describe the situation correctly: This is achieved for "turn" URIs by the Long-Term Credential Mechanism defined in [RFC5389], which is mandatory for TURN [RFCxxx]. For a "turns" URI, the usage of TLS addresses the requirement." Having both references would have helped me to understand the situation better (showing my ignorance of TURN ;-). /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 Oct 21 04:08: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 C15713A69F8; Wed, 21 Oct 2009 04:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.010, 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 wsVllAdoKIXw; Wed, 21 Oct 2009 04:08:33 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 6A6AA3A697D; Wed, 21 Oct 2009 04:08:32 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-08-4adeebb79809 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 62.15.08816.7BBEEDA4; Wed, 21 Oct 2009 13:08:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 13:08:29 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 13:08:28 +0200 Message-ID: <4ADEEBAC.9050405@ericsson.com> Date: Wed, 21 Oct 2009 13:08:28 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund , Marc Petit-Huguenin , "iesg@ietf.org" , "secdir@ietf.org" References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> <20091021095157.GC3177@elstar.local> <4ADEDBE2.2090704@ericsson.com> <20091021102752.GA4104@elstar.local> In-Reply-To: <20091021102752.GA4104@elstar.local> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Oct 2009 11:08:28.0582 (UTC) FILETIME=[D143EC60:01CA523E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.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, 21 Oct 2009 11:08:33 -0000 Juergen Schoenwaelder skrev: > On Wed, Oct 21, 2009 at 12:01:06PM +0200, Magnus Westerlund wrote: > >> I do understand your confusion. RFC 5389 is STUN. TURN is an extension >> of STUN, and TURN mandates authentication. The default to use mechanism >> however, is defined in STUN, thus the reference to RFC 5389. > > Thanks, now I understand this better. So does this wording describe > the situation correctly: > > This is achieved for "turn" URIs by the Long-Term Credential > Mechanism defined in [RFC5389], which is mandatory for TURN > [RFCxxx]. For a "turns" URI, the usage of TLS addresses the > requirement." > > Having both references would have helped me to understand the > situation better (showing my ignorance of TURN ;-). Yes, I think that part is good. I would note that TLS may not be sufficient for reaching the authentication goal. Only that is has the capability to reach them. But also for TLS you can use the Long-Term Credential mechanism to authenticate the user of a TURN server. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From julienl@qualcomm.com Wed Oct 21 08:45:14 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 885F328C12F; Wed, 21 Oct 2009 08:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.655 X-Spam-Level: X-Spam-Status: No, score=-105.655 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPlbpXa+osDO; Wed, 21 Oct 2009 08:45:13 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7197128C122; Wed, 21 Oct 2009 08:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256139922; x=1287675922; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"secdir@ietf.org"=20,=20"iesg@iet f.org"=20,=0D=0A=20=20=20=20=20=20=20=20"d raft-ietf-enum-3761bis@tools.ietf.org"=0D=0A=09,=0D=0A=20=20=20=20=20=20 =20=20"enum-chairs@tools.ietf.org"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"enum-ads@to ols.ietf.org"=0D=0A=09|Date:=20W ed,=2021=20Oct=202009=2008:44:28=20-0700|Subject:=20SecDi r=20review=20of=20draft-ietf-enum-3761bis-04 |Thread-Topic:=20SecDir=20review=20of=20draft-ietf-enum-3 761bis-04|Thread-Index:=20AcpSZV/MTRjN04DDQ9SkGrtr69VywA =3D=3D|Message-ID:=20|Accept-Language:=20e n-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5777"=3B=20a=3D"25758214"; bh=RbTrByrhV03zimWlUAkgAnPbkAbXX8F9KcRg8Y0L1xA=; b=maFOW38UIodv5SDwQca55zswKA0l8V9/4V5AkZJ4jZd49p+mYEL300Ks eYWfUxsvonTA36mQPaP1L9cbDowwwmin73RZbNgyAeKay9i8tZ6SHfvhR /Epv6es/Bg1di5DypM4BgfDfnXb7JG6DotwLL61qRJXlTa0JojYIvcc8K w=; X-IronPort-AV: E=McAfee;i="5300,2777,5777"; a="25758214" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2009 08:45:07 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9LFj6fn002047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2009 08:45:07 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9LFj2iL015770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Oct 2009 08:45:06 -0700 (PDT) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 21 Oct 2009 08:44:51 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Wed, 21 Oct 2009 08:44:30 -0700 From: "Laganier, Julien" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-enum-3761bis@tools.ietf.org" , "enum-chairs@tools.ietf.org" , "enum-ads@tools.ietf.org" Date: Wed, 21 Oct 2009 08:44:28 -0700 Thread-Topic: SecDir review of draft-ietf-enum-3761bis-04 Thread-Index: AcpSZV/MTRjN04DDQ9SkGrtr69VywA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-enum-3761bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 15:45:14 -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 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. This document describes a Dynamic Delegation Discovery System (DDDS) applic= ation relying on the DNS database for storage of E.164 numbers, and resolut= ion of those into URIs to be used to contact the recipients via various ser= vices (e.g., SIP, H323).=20 I have found the description of the DDDS application well written and easil= y understandable. The security considerations section seemed fair and reaso= nable in pointing out the insecure character of DNS used alone, referencing= DNSSEC as a mechanism countering the threats specific to DNS, and recommen= ding services to authenticate peers as part of the setup process for the se= rvice itself rather than blindly trust the addressing mechanisms in use. I have one minor suggestion on rewording this sentence: Because of these threats, a deployed ENUM service SHOULD include mechanisms to ameliorate these threats. Don't you want to say "counter" rather than "ameliorate" (or maybe "amelior= ate the security of the service under these threats") ? --julien From petithug@acm.org Wed Oct 21 09:51: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 934413A6990; Wed, 21 Oct 2009 09:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.124 X-Spam-Level: X-Spam-Status: No, score=-102.124 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYJ0m7QELIGO; Wed, 21 Oct 2009 09:51:32 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id A31E93A6842; Wed, 21 Oct 2009 09:51:29 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 2AE666C9852C; Wed, 21 Oct 2009 16:51:38 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 21CE06C98524; Wed, 21 Oct 2009 16:51:35 +0000 (UTC) Message-ID: <4ADF3C17.2070408@acm.org> Date: Wed, 21 Oct 2009 09:51:35 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Magnus Westerlund , Juergen Schoenwaelder References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> <20091021095157.GC3177@elstar.local> <4ADEDBE2.2090704@ericsson.com> <20091021102752.GA4104@elstar.local> <4ADEEBAC.9050405@ericsson.com> In-Reply-To: <4ADEEBAC.9050405@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 21 Oct 2009 12:04:54 -0700 Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.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, 21 Oct 2009 16:51:33 -0000 Thanks Magnus and Juergen. See comment inline. Magnus Westerlund wrote: > Juergen Schoenwaelder skrev: >> On Wed, Oct 21, 2009 at 12:01:06PM +0200, Magnus Westerlund wrote: >> >>> I do understand your confusion. RFC 5389 is STUN. TURN is an extension >>> of STUN, and TURN mandates authentication. The default to use mechanism >>> however, is defined in STUN, thus the reference to RFC 5389. >> Thanks, now I understand this better. So does this wording describe >> the situation correctly: >> >> This is achieved for "turn" URIs by the Long-Term Credential >> Mechanism defined in [RFC5389], which is mandatory for TURN >> [RFCxxx]. For a "turns" URI, the usage of TLS addresses the >> requirement." >> >> Having both references would have helped me to understand the >> situation better (showing my ignorance of TURN ;-). > > Yes, I think that part is good. > > I would note that TLS may not be sufficient for reaching the > authentication goal. Only that is has the capability to reach them. But > also for TLS you can use the Long-Term Credential mechanism to > authenticate the user of a TURN server. Here the modified proposed text that should address all your concerns. Let me know if this is OK: "The Application Service Tag and Application Protocol Tags defined in this document do not introduce any specific security issues beyond the security considerations discussed in [RFC3958]. [RFC3958] requests that an S-NAPTR application defines some form of end-to-end authentication to ensure that the correct destination has been reached. This is achieved for "turn" and "turns" URIs by the Long- Term Credential Mechanism defined in [RFC5389], which is mandatory for TURN [I-D.ietf-behave-turn]. Additionally for a "turns" URI, the usage of TLS has the capability to address the requirement." -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From barryleiba.mailing.lists@gmail.com Wed Oct 21 12:32: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 8C31A3A69A4; Wed, 21 Oct 2009 12:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 ANlqULAlVZa1; Wed, 21 Oct 2009 12:32:49 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 9F5253A67F5; Wed, 21 Oct 2009 12:32:49 -0700 (PDT) Received: by ywh13 with SMTP id 13so9706598ywh.29 for ; Wed, 21 Oct 2009 12:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type; bh=Cf5pPcSO+eIXP5LrsniInSaqgZ/Q0GTF72tJV1dpAtY=; b=u3akFxBRcQ2AvSlnHaTR2EInBRH8JoZ05qcgV3J24rIBUnsZQk8PisKtYDBa8ZUsZp L/dwDJotvKmwOpuYVuDmfrcRGc7uACqH2WavHjayF0j125GW+MMOsenLkOOwMxnBvcAX alhfszU4RZirYgvBEVAu0GNKv6Sl/AJvanatg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=uvvlkk43PtUw1ZVhnVp2QWcORKa2semwIrUSa8moguXK8zeDzCykKYPbNxR+3+Nf+7 YU9IdcNuAHL/6a9O7d614hdcDjTXzJY0kEaaXqmCPipdBAZeVEKtF4wBfkWQWR6Nv7I2 g2PkfTVFqnQjgl7NF4j4iKmUGRGsxctQYWvpA= MIME-Version: 1.0 Received: by 10.151.20.15 with SMTP id x15mr13760569ybi.312.1256153575992; Wed, 21 Oct 2009 12:32:55 -0700 (PDT) Date: Wed, 21 Oct 2009 15:32:55 -0400 Message-ID: <6c9fcc2a0910211232p2b78f256w31bd5d5920d47502@mail.gmail.com> From: Barry Leiba To: secdir , iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-ospf-te-node-addr@tools.ietf.org, ospf-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-ospf-te-node-addr-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:32:50 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I see no problem with this document. It points to the base Traffic Engineering extensions for security considerations, and that seems correct. I'll add a note that I appreciated having abbreviations spelled out in the introduction. Thanks. Barry From j.schoenwaelder@jacobs-university.de Wed Oct 21 15:11:05 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 8BC1928C107; Wed, 21 Oct 2009 15:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=0.658, 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 jHsvjbUgWOfz; Wed, 21 Oct 2009 15:11:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1A59C3A6A4C; Wed, 21 Oct 2009 15:11:04 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95E27C0023; Thu, 22 Oct 2009 00:11:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eb0ACUXAQrAm; Thu, 22 Oct 2009 00:11:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A71B6C0021; Thu, 22 Oct 2009 00:11:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 474ADD4DE33; Thu, 22 Oct 2009 00:11:10 +0200 (CEST) Date: Thu, 22 Oct 2009 00:11:10 +0200 From: Juergen Schoenwaelder To: Marc Petit-Huguenin Message-ID: <20091021221110.GA4987@elstar.local> Mail-Followup-To: Marc Petit-Huguenin , Magnus Westerlund , "iesg@ietf.org" , "secdir@ietf.org" References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> <20091021095157.GC3177@elstar.local> <4ADEDBE2.2090704@ericsson.com> <20091021102752.GA4104@elstar.local> <4ADEEBAC.9050405@ericsson.com> <4ADF3C17.2070408@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADF3C17.2070408@acm.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Magnus Westerlund , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 22:11:05 -0000 On Wed, Oct 21, 2009 at 06:51:35PM +0200, Marc Petit-Huguenin wrote: [...] > Here the modified proposed text that should address all your > concerns. Let me know if this is OK: > > "The Application Service Tag and Application Protocol Tags defined in > this document do not introduce any specific security issues beyond > the security considerations discussed in [RFC3958]. [RFC3958] > requests that an S-NAPTR application defines some form of end-to-end > authentication to ensure that the correct destination has been > reached. This is achieved for "turn" and "turns" URIs by the Long- > Term Credential Mechanism defined in [RFC5389], which is mandatory > for TURN [I-D.ietf-behave-turn]. Additionally for a "turns" URI, the > usage of TLS has the capability to address the requirement." Looks perfect to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rahul@juniper.net Wed Oct 21 18:19: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 B13D63A685A; Wed, 21 Oct 2009 18:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8YcmOop+YYw; Wed, 21 Oct 2009 18:19:36 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id BDEC13A63D3; Wed, 21 Oct 2009 18:19:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSt+zLMPVDVA0EdQSfFKN4u1Pt8ptVvJr@postini.com; Wed, 21 Oct 2009 18:19:45 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 21 Oct 2009 18:17:28 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:17:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:17:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:17:27 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9M1HRj62581; Wed, 21 Oct 2009 18:17:27 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Wed, 21 Oct 2009 18:17:26 -0700 From: Rahul Aggarwal To: barryleiba@computer.org In-Reply-To: <6c9fcc2a0910211232p2b78f256w31bd5d5920d47502@mail.gmail.com> Message-ID: <20091021181718.O40803@sapphire.juniper.net> References: <6c9fcc2a0910211232p2b78f256w31bd5d5920d47502@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-OriginalArrivalTime: 22 Oct 2009 01:17:27.0258 (UTC) FILETIME=[6B150BA0:01CA52B5] Cc: draft-ietf-ospf-te-node-addr@tools.ietf.org, ospf-chairs@tools.ietf.org, iesg@ietf.org, secdir Subject: Re: [secdir] secdir review of draft-ietf-ospf-te-node-addr-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 01:19:36 -0000 Hi Barry, Thanks for the review! rahul On Wed, 21 Oct 2009, Barry Leiba wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I see no problem with this document. It points to the base Traffic > Engineering extensions for security considerations, and that seems > correct. > > I'll add a note that I appreciated having abbreviations spelled out in > the introduction. Thanks. > > Barry > From tena@huawei.com Wed Oct 21 23:50: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 50DF23A6807; Wed, 21 Oct 2009 23:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.77 X-Spam-Level: X-Spam-Status: No, score=-100.77 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vytpUuJV1l8J; Wed, 21 Oct 2009 23:50:43 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B83F528C0DE; Wed, 21 Oct 2009 23:50:42 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRW00KTALOQXU@szxga04-in.huawei.com>; Thu, 22 Oct 2009 14:50:50 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRW00617LOQFD@szxga04-in.huawei.com>; Thu, 22 Oct 2009 14:50:50 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRW00287LOQQD@szxml06-in.huawei.com>; Thu, 22 Oct 2009 14:50:50 +0800 (CST) Date: Thu, 22 Oct 2009 14:50:49 +0800 From: Tina TSOU To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mboned-rfc3171bis@tools.ietf.org, mboned-chairs@tools.ietf.org Message-id: <007c01ca52e3$fdd32ed0$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_3QKpis9ZSmhNcMUFIlpyRA)" X-Priority: 3 X-MSMail-priority: Normal References: <00d701ca51fe$2fff1630$8e27460a@china.huawei.com> Subject: [secdir] SecDir review of draft-ietf-mboned-rfc3171bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 06:50:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3QKpis9ZSmhNcMUFIlpyRA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, I have reviewed draft-ietf-mboned-rfc3171bis-07 as part of the security = directorate's ongoing effort to review all IETF documents being = processed by the IESG. These comments were written primarily for the = benefit of the security area directors. Document editors and WG chairs = should treat these comments just like any other last call comments.=20 =20 This document provides guidance for the Internet Assigned Numbers = Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes = RFC 3171 and RFC 3138. 1. Introduction ... In general, due to the relatively small size of the IPv4 multicast address space, further assignment of IPv4 multicast address space is recommended only in limited circumstances. Specifically, the IANA should only assign addresses in those cases where the dynamic selection (SDP/SAP), GLOP, SSM or Administratively Scoped address spaces cannot be used.=20 [Tina: Why should we emphasize the purpose of SDP/SAP here is used for = dynamic selection? Should the purpose GLOP or SSM be highlighted as = well? =A1=B0The dynamic selection (SDP/SAP), GLOP, SSM or Administratively = scoped address space cannot be used" in the last sentence is a little = bit ambiguous. Is "the dynamic selection (SDP/SAP), GLOP,SSM can not be = used" identical to the description "the dynamic selection = (DSP/SAP)address spaces, GLOP address spaces, SSM address space can not = be used"? If yes, I am okay with the text as it was. If not, I would = like suggest you to fix this ambiguous issue.] ... 3. Definition of Current Assignment Practice ... 224.0.2.0 - 224.0.255.255 (65024) AD-HOC Block I ... The IANA generally assigns addresses from the Local Network Control, Internetwork Control and AD-HOC blocks. Assignment guidelines for each of these blocks, as well as for the Source Specific Multicast, GLOP and Administratively Scoped Blocks, are described below. [Tina: What (65024) in the size field are denoted as? how about = (251/16s)? I would like to suggest you to add some text to explain what = the format of size field is?] ... 8. Source Specific Multicast Block (232/8) The Source Specific Multicast (SSM) is an extension of IP Multicast in which traffic is forwarded to receivers from only those multicast sources for which the receivers have explicitly expressed interest, and is primarily targeted at one-to-many (broadcast) applications. Note that this block was initially assigned to the VMTP transient groups [IANA]. [Tina: Would you like to provide some reference to SSM? What are VMTP = transient groups? How is it related to IPv4 multicast addresses?] ... 9. GLOP Block (233/8) Addresses in the GLOP block are globally scoped statically assigned addresses. The assignment is made, for a domain with 16 bit Autonomous System Number (ASN), by mapping a domain's autonomous system number, expressed in octets as X.Y, into the middle two octets of the GLOP block, yielding an assignment of 233.X.Y.0/24. The mapping and assignment is defined in [RFC3180]. Domains with 32 bit ASN should apply for space in AD-HOC Block III, or consider using IPv6 multicast addresses. [Tina: Is it better to replace the *should* in the last sentence of = section 9 with *MAY*?] =20 B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_3QKpis9ZSmhNcMUFIlpyRA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi,

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

 

This document provides guidance for the Internet Assigned = Numbers=20 Authority (IANA) in assigning IPv4 multicast addresses.  It = obsoletes RFC=20 3171 and RFC 3138.

 
1.  Introduction
 
...
   In general, due to the relatively small size of = the IPv4=20 multicast
   address space, further assignment of IPv4 = multicast=20 address space is
   recommended only in limited=20 circumstances.  Specifically, the IANA
   should only = assign=20 addresses in those cases where the dynamic
   selection = (SDP/SAP),=20 GLOP, SSM or Administratively Scoped address
   spaces = cannot be=20 used.
 

 [Tina: Why should we emphasize = the=20 purpose of SDP/SAP here is used for dynamic selection? Should the = purpose GLOP=20 or SSM be highlighted as well?
=A1=B0The dynamic selection (SDP/SAP), = GLOP, SSM or=20 Administratively scoped address space cannot be used" in the last = sentence is a=20 little bit ambiguous. Is "the dynamic selection (SDP/SAP), GLOP,SSM can = not be=20 used"  identical to the description "the dynamic selection = (DSP/SAP)address=20 spaces, GLOP address spaces, SSM address space can not be used"? If yes, = I am=20 okay with the text as it was. If not, I would like suggest you to fix = this=20 ambiguous issue.]

 

...

3.  Definition = of Current=20 Assignment Practice

...

224.0.2.0 -=20 224.0.255.255     (65024)    AD-HOC = Block=20 I

...

The IANA generally = assigns=20 addresses from the Local Network Control,
   Internetwork = Control=20 and AD-HOC blocks.  Assignment guidelines for
   each = of these=20 blocks, as well as for the Source Specific Multicast,
   = GLOP and=20 Administratively Scoped Blocks, are described below.

 

[Tina: What (65024) in the = size=20 field are denoted as? how about (251/16s)? I would like to suggest you = to add=20 some text to explain what the format of size field=20 is?]


...

8.  Source Specific Multicast Block=20 (232/8)

   The Source Specific Multicast (SSM) = is an=20 extension of IP Multicast
   in which traffic is forwarded = to=20 receivers from only those multicast
   sources for which = the=20 receivers have explicitly expressed interest,
   and is = primarily=20 targeted at one-to-many (broadcast) applications.
   Note = that this=20 block was initially assigned to the VMTP transient
   = groups=20 [IANA].

[Tina: Would you like to = provide=20 some reference to SSM? What are VMTP transient groups? How is it related = to IPv4=20 multicast addresses?]

 

...

9.  GLOP Block=20 (233/8)

   = Addresses in the=20 GLOP block are globally scoped statically assigned
  =20 addresses.  The assignment is made, for a domain with 16=20 bit
   Autonomous System Number (ASN), by mapping a = domain's=20 autonomous
   system number, expressed in octets as X.Y, = into the=20 middle two octets
   of the GLOP block, yielding an = assignment of=20 233.X.Y.0/24.  The
   mapping and assignment is = defined in=20 [RFC3180].  Domains with 32 bit
   ASN should apply = for space=20 in AD-HOC Block III, or consider using
   IPv6 multicast=20 addresses.

 

[Tina: Is it better = to replace=20 the *should* in the last sentence of section 9 with=20 *MAY*?]

 

 

B.=20 R.
Tina
http://tinatsou.weebly.com/contact.html

--Boundary_(ID_3QKpis9ZSmhNcMUFIlpyRA)-- From Kurt.Zeilenga@Isode.com Thu Oct 22 07:24:26 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 613F63A69E8; Thu, 22 Oct 2009 07:24:26 -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 5tADLkd+VrfR; Thu, 22 Oct 2009 07:24:25 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9307D3A688C; Thu, 22 Oct 2009 07:24:25 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 22 Oct 2009 15:24:34 +0100 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga In-Reply-To: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> Date: Thu, 22 Oct 2009 07:24:12 -0700 Message-Id: <72C5C4F0-43E5-4EC1-A674-7F28C8AAD84B@Isode.com> References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> To: The IESG X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: draft-ietf-hokey-key-mgm@tools.ietf.org, Security Area Directorate Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm 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, 22 Oct 2009 14:24:26 -0000 I have I have re-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. My previously raised concerns have been adequately addressed. I have no new concerns with this I-D. -- Kurt From weiler+secdir@watson.org Thu Oct 22 13:07: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 4D7CE3A69D3 for ; Thu, 22 Oct 2009 13:07:15 -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 I6ILkNcyG0gk for ; Thu, 22 Oct 2009 13:07:14 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 45D493A67B2 for ; Thu, 22 Oct 2009 13:07:14 -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 n9MK7Nep087570 for ; Thu, 22 Oct 2009 16:07:23 -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 n9MK7NwR087566 for ; Thu, 22 Oct 2009 16:07:23 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 22 Oct 2009 16:07:23 -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]); Thu, 22 Oct 2009 16:07:23 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 20:07:15 -0000 Nico Williams is next in the rotation. Please try to complete last call reviews by the end of the last call. For documents on telechat, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-11-19 Reviewer Deadline Draft Stephen Kent TR2009-11-17 draft-ietf-mmusic-connectivity-precon-06 Stefan Santesson T 2009-11-17 draft-ietf-bmwg-ipsec-term-12 Yaron Sheffer T 2009-11-17 draft-ietf-dna-simple-09 Carl Wallace T 2009-11-17 draft-ietf-6man-overlap-fragment-03 Last calls and special requests: Reviewer Deadline Draft Rob Austein 2009-10-07 draft-reschke-rfc2731bis-03 Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-02 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Stephen Farrell 2009-09-07 draft-ietf-tls-rfc4366-bis-05 Sam Hartman R2009-10-23 draft-hammer-oauth-03 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-16 Charlie Kaufman None draft-baker-ietf-core-03 David McGrew 2009-10-28 draft-weiler-rsync-uri-01 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Russ Mundy 2009-10-21 draft-ietf-hokey-preauth-ps-09 Sandy Murphy 2009-10-23 draft-nottingham-site-meta-03 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Chris Newman 2009-10-20 draft-ietf-forces-sctptml-06 Magnus Nystrom 2009-11-02 draft-altman-tls-channel-bindings-07 Radia Perlman None draft-bryan-http-digest-algorithm-values-update-03 Eric Rescorla 2009-11-10 draft-gennai-smime-cnipa-pec-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-10-07 draft-carpenter-renum-needs-work-03 Hannes Tschofenig 2009-10-23 draft-ietf-l3vpn-ospfv3-pece-03 Sean Turner 2009-10-28 draft-ietf-ipsecme-traffic-visibility-09 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2009-11-16 draft-melnikov-imap-keywords-06 Brian Weis 2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-04 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 From Pasi.Eronen@nokia.com Fri Oct 23 04:17:35 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 99DCF3A6864; Fri, 23 Oct 2009 04:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 zsHE17rNarFf; Fri, 23 Oct 2009 04:17:34 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6DED13A67FD; Fri, 23 Oct 2009 04:17:34 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9NBHCiM010625; Fri, 23 Oct 2009 14:17:37 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 14:16:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 14:16:51 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 23 Oct 2009 13:16:47 +0200 From: To: , Date: Fri, 23 Oct 2009 13:16:46 +0200 Thread-Topic: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt Thread-Index: AcpRr2HqbWs5MHteSKmzYzDotHQRYACHxHYg Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09B0BC50@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> In-Reply-To: <4ADDFA8A.40902@acm.org> 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: 23 Oct 2009 11:16:51.0029 (UTC) FILETIME=[5192C050:01CA53D2] X-Nokia-AV: Clean Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 11:17:35 -0000 Marc Petit-Huguenin wrote: > I propose to replace the second paragraph of section 6 by the > following text. Let me know if it addresses your comment: >=20 > "The Application Service Tag and Application Protocol Tags defined in > this document do not introduce any specific security issues beyond > the security considerations discussed in [RFC3958]. [RFC3958] > requests that an S-NAPTR application defines some form of end-to-end > authentication to ensure that the correct destination has been > reached. This is achieved by the mandatory Long-Term Credential > Mechanism defined by [RFC5389] and additionally for a "turns" URI by > the usage of TLS." We probably need some additional text about TLS here. The text in RFC 3958 asks for a very specific kind of "end-to-end" authentication: the authenticated identity of the server must be the same as the *input* to the S-NAPTR processing. So if the URI was "turns:example.com", and the DNS records are as follows: example.com. IN NAPTR 100 10 "S" "RELAY" "" turn.example.net. turn.example.net. IN SRV 10 0 10001 turnserver1.example.org. turnserver1.example.org. IN A 192.0.2.1 Then the server needs to present a certificate with name "example.com" (NOT "turn.example.net" or "turnserver1.example.org"). Is this the intent here? The reason behind this text in RFC 3958 is that otherwise an attacker could just spoof DNS reply "example.com. IN NAPTR 100 10 "S" "RELAY" "" turn.attacker.org.", and TLS wouldn't catch this. (Basically the same thing occurs in HTTPS, of course. If the URI is "https://www.example.com/", then the certificate must contain name "www.example.com", even if DNS replies with "www.example.com. IN=20 CNAME foo.attacker.org.") Best regards, Pasi From kkinnear@cisco.com Mon Oct 26 14:25: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 9EF733A62C1; Mon, 26 Oct 2009 14:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjDA+z+-QQV0; Mon, 26 Oct 2009 14:25:04 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 03FF33A680A; Mon, 26 Oct 2009 14:25:03 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMaw5UqtJV2d/2dsb2JhbADCCJdBgi+CEASBXg X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="64979826" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2009 21:25:16 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id n9QLPGGv021908; Mon, 26 Oct 2009 21:25:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 17:25:15 -0400 Received: from kkinnear-wxp01.cisco.com ([10.86.245.48]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 17:25:15 -0400 Message-Id: <4.3.2.7.2.20091026144425.02c31ec0@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Oct 2009 16:24:19 -0500 To: "David Harrington" , , From: Kim Kinnear In-Reply-To: <062201ca4dac$c53d4100$0600a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 26 Oct 2009 21:25:15.0590 (UTC) FILETIME=[CF39F660:01CA5682] X-Mailman-Approved-At: Mon, 26 Oct 2009 23:37:36 -0700 Cc: raj@cisco.com, 'IETF-Discussion list' , mjs@cisco.com, dhc-chairs@tools.ietf.org, iesg@ietf.org, john_brzozowski@cable.comcast.com, jayk@cisco.com, kkinnear@cisco.com Subject: Re: [secdir] SECDIR and OPSDIR review of draft-ietf-dhc-vpn-option-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, 26 Oct 2009 21:25:06 -0000 David, I'm a bit unsure to whom I should respond with answers to the questions you are asking. Other folks have included your questions in their responses. Since you initially raised these questions, I'll respond to you initially. Thanks for the review of the draft. My comments below are indented, each preceded by "Kim: ..." I have mildly reformatted the comments you sent in, as at least on my mail reader they seemed to wrap in some strange way that made them extremely hard to read. Regards -- Kim ------------------------------------------------ At 10:32 AM 10/15/2009, 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. ... AND ... I have performed an unofficial Operations Directorate review. (i.e., I wasn't assigned as the OPSDIR reviewer) Background: This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. ========================= SECDIR Review ========================= The security review 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 found the security considerations section reasonably thorough. Some of the considerations are of the form "there is this known problem; you should do whatever you can to mitigate it." I wonder if some specific mitigation mechanisms might have been described and standardized. Kim: I find this confusing. The one new issue I raised in this draft (as opposed to referencing other drafts) was: > The VSS option could be used by a client in order to obtain an IP > address from any VPN. This option would allow a client to perform a > more complete address-pool exhaustion attack since the client would > no longer be restricted to attacking address-pools on just its local > subnet. and I go on to suggest a way that relay agents can circumvent this attack -- which is certainly a mitigation mechanism in my book. So, I don't understand the source of this comment. In section 4, a relay agent can insert a VSS option into a client request, and then remove it from the server response. I am a little concerned that the server does not actually get to differentiate which entity is making the VSS request, and the relay is thus masquerading as the client. Kim: It is assumed that the relay agent is more "trusted" than the DHCP client in realistic deployments. Thus, our choice to "trust" what the relay agent tells us is actually a security feature. ========================= OPSDIR Review Questions: ========================= The operations review comments were written primarily for the benefit of the OPS area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I do not normally work at the DHCP level, so some of my comments may simply be misunderstandings of DHCP. Is the document readable? yes. Does it contain nits? yes. The document seems to lack a disclaimer for pre-RFC5378 work Kim: I know all of the authors, and we know where the information came from, and it is all ok, so we don't have to disclaim anything. Or did I get this wrong somehow? Is the document class appropriate? yes. Is the problem well stated? yes. Is the problem really a problem? yes. Does the document consider existing solutions? yes. Does the solution break existing technology? possibly. 1) Section 4 says "Deploying relay agents which support and emit VSS sub-options in concert with DHCPv4 servers which do not support the VSS option or sub-option as defined in this document SHOULD NOT be done, as such an ensemble will not operate correctly together because all of the IP addresses will be allocated from the global or default VPN regardless of the VPN on which the client's reside." Kim: In the real world, there are very few protocols that don't require you to deploy entities at both ends that support the protocol. Of course, the specific situation in this draft is not quite that just described -- the problem is that an existing server which does not support the VSS sub-option will respond in such a way that the relay agent may have trouble determining if the server responded correctly or incorrectly. Later in this email I suggest a way we can actually solve this problem by a slight extension of the draft. Kim: In the larger sense, you usually have to deploy matching support in client<->server ensembles to have things work correctly, so it isn't as if this is totally outlandish. And "work correctly" is an interesting term. While things may appear to "work correctly" at the relay agent when someone deploys a relay agent that supports the VSS sub-option against a DHCP server who does support it, that is only a local misapprehension. The ultimate client will not receive an IP address that will work. And so the failure will be noticed. And this isn't an occasional failure -- the whole VPN won't work. 2) I have concerns that there are potential conflicts that are not being addressed: Kim: Well, yes. Specifically. That is because these scenarios do not describe configurations that today make any sense. Trying to describe protocol actions for situations that make no operational sense today is akin to designing a protocol on speculation. Something that at least our WG keeps a sharp eye out for and quashes whenever it is noticed. I could take out all these words, if that would make this less concerning, but then people will ask "what about this" or "what about that", and I'll have to put some of it back in. "There are many other scenarios which can be created with multiple relay agents each inserting VSS information into different Relay- forward messages, relay agent VSS information conflicting with client VSS information, or DHCP server VSS information conflicting with relay agent and client VSS information. Since these scenarios do not describe situations that are useful today, specifying precisely how to resolve all of these conflicts is unlikely to be valuable in the event that these scenarios actually become practical in the future. The current use of the VSS option and sub-option require that each entity knows the part that it plays in dealing with VPN data. Each entity -- client, relay agent or agents, and server -- SHOULD know through some policy or configuration beyond the scope of this document whether it is responsible for specifying VPN information using the VSS option or sub-option or responsible for responding to VSS information specified by another entity, or simply ignoring any VSS information which it might see. Some simple conflict resolution approaches are discussed below, in the hopes that they will cover simple cases that may arise from scenarios beyond those envisioned today. However, for more complex scenarios, or simple scenarios where appropriate conflict resolution strategies differ from those discussed in this document, a document detailing the usage scenarios and appropriate conflict resolution strategies SHOULD be created and submitted for discussion and approval." 3) section 7 says " In either case above, care should be taken to ensure that a client or relay agent receiving a reply containing a VSS option will correctly understand the VSS option. Otherwise, the client or relay agent will end up using the address as though it were a global address." This could have a negative impact on the existing network deployment. Does the solution preclude future activity? yes. It declares the VPN types 2-254 to be invalid "as of this memo", but doesn't discuss how they could become valid in the future. The IANA section seems to waffle on whether it can or cannot be expanded in the future. Kim: Sorry, I'll say that they are reserved for future use. Is the solution sufficiently configurable? There is quite a bit of text that says the entity "has been configured in some way" In some cases, the configuration MUST be done correctly for the system to work, but the configuration requirements are not detailed. For example, Section 4 says "It is important to ensure that each entity ... is configured correctly." and "There is no conflict between different entities trying to specify different VSS information -- each entity knows its role through policy or configuration external to this document." and "In the event that there were more than one relay agent involved in this transaction, some external configuration or policy would be needed to inform the DHCPv6 server into which Relay-reply message the VSS option should go." These sound like normative requirements, but there is no attempt to standardize the configuration. Kim: There is certainly a set of standard configurations which make sense, and I suppose that I've just assumed that they were obvious and/or well known by the folks that would read this document. I expect that I can be more explicit about them so there is no doubt what they are, and I will do that. Can performance be measured? How? performance measurement is not discussed. Does the solution scale well? I think this should scale as well as DHCP. I suppose that the server might be expected to have lots of storage if it needs to track the address ranges for a large number of VPNs, but I don't think that would be a limiting factor for a DHCP server. general comments: 1. The Terminology section defines upstream and downstream using terms that have not been defined. It is unclear to me whether access concentrator and subscriber are similar to server and client. Kim: I'll fix this. 2. In section 3.4, might it be better to declare 2-254 as reserved rather than invalid? The text says "invalid as of this memo". Should there be a mechanism to support enterprise-specific VSS? Kim: Yes, I'll call them reserved. 3. In section 4, it says DHCP can assign the same IP address to nodes in a VPN and in the global IP space, because the address is qualified by the VPN. Is this always true? Is there any potential for conflict, such as in forwarding loops, if the two addresses spaces are handled by the same device? Kim: I believe this is always true. I don't believe there is any potential for conflict, or the underlying MPLS VPN capability wouldn't work at all. 4. I think section 4 would benefit from sub-sections to separate the scenarios, and all the "in this scenario" phrases could be eliminated. Diagrams of the scenarios would be helpful. Kim: Sub-sections would be a good idea here. Diagrams are less clear to me, in that they all kind of look the same. I'll see what I can do about diagrams, though. Perhaps sequence diagrams would be helpful. 5. Will legacy DHCP entities ignore the VSS option by default? or will the presence of the option somehow impact entity behaviors (e.g., by dropping packets)? Kim: Legacy DHCP entities should ignore options (and sub-options) they don't understand. Like this one. 6. In section 5, it says the relay SHOULD insert VSS information into requests from a client. What happens if the client has inserted a VSS option? That isn't discussed. Kim: At one point, we had the relay agent deal with this, but someone objected so we took it out. Now the server deals with this case -- which is what Section 7.3 is all about. 7. Section 5 says "Anytime a relay agent places a VSS option or sub-option in a DHCP request, it MUST send it only to a DHCP server which supports the VSS option or sub-option." How does it know? is there an option discovery mechanism? Kim: Throughout the DHCP protocol world there is no general way (and scant specific ways) to determine who supports what options from the bits on the wire. In two of the three cases, this document makes that easy, in one of the three cases, this document makes that more difficult. But later I propose to close even that hole. 8. In section 5, if a relays requests a specific VPN, but the server returns an address not within that VPN, then the relay should drop the packet. Should the relay let the server know that it dropped the packet and why? Won't the server assume the address has actually been assigned to the client, thus reducing the pool of available addresses? Kim: Yes, the server will believe it is assigned, but the client will request again since it didn't get an address. In general DHCP drops packets, and relay agents don't synthesize things like DHCPRELEASE packets. 9. In section 5, "If an IP address that is on the requested VPN is not required, then the relay agent is free to accept the IP address that is not on the VPN that was requested." Then why request it? Under what conditions would it not be required? how does the relay know whether it is or is not required? Kim: Interesting questions, and the answers are really outside of the scope of the document. I don't know of any deployments where people request addresses on VPN's but don't "require" them. All of the cases with which I am familiar they are required. But we didn't want to preclude this possibility. If you feel strongly, we could take this out. 10. In section 5, it says "There are only two pieces of information which can be determined ..." but the specified behaviors could also result from mis-configuration, right? And the relay cannot tell whether it is a deliberate behavior or a mis-configuration. Kim: If you don't get it back, then the server didn't support it. If it was supposed to support it, and someone misconfigured it, and it now doesn't support it, that is still not supporting it. If you get a VPN sub-option back that is different than the one you sent in, then the server gave you an address on a different VPN. If it wasn't supposed to, and was misconfigured to do so, well, it still did it. So I don't see what you are driving at here, I'm sorry. 11. section 5: " Thus, if a DHCPv4 relay agent has a requirement to determine if the address allocated by a DHCPv4 server is on a particular VPN, it must use some other approach than the appearance of the VSS sub-option in the reply packet to make this determination." What other approach works? Kim: The idea was to look at internal tables, ARP for the address, or otherwise perform some kind of consistency check. All very implementation dependent. Kim: Hmmm. One approach might be to send in two VPN sub-options, one "real", and the other (specified in the document) as "to-be-removed". Then, when someone did the right thing, they'd remove the one that was to-be-removed and return the one that was used. Then if the relay agent got a to-be-removed sub-option back, it would know that this server didn't support the capability and could drop the packet. I'll kick this around with the other authors, but this might be a way around the problem. 12. section 5: " Note that in some environments a relay agent may choose to always place a VSS option or sub-option into packets and messages that it forwards in order to forestall any attempt by a downstream relay agent or client to specify VSS information. In this case, a type field of 255 is used to denote the global, default VPN. When the type field of 255 is used, there MUST NOT be any additional VSS Information in the VSS option." This section does not say that the relay must check to make sure there is no existing VSS option. Section 5 talks about relays inserting VSS options, but does not specify that the relay must check that no VSS=255 is present in the message already. But section 7.3 talks about resolving conflicting VSS options. I am not sure the potential conflicts and resolutions are covered adequately. Kim: I don't know of a case that isn't covered. Maybe it is confusion about there "MUST NOT be any additional information...". That is in the option/sub-option with the 255, not the whole message. I can clear that up. 13. section 5.1 what does "if the relay agent is unable to honor the server requirement" mean? This could be made less ambiguous. 14. section 5.1 " The DHCP server MUST NOT place VSS information in an outgoing packet if the relay agent or DHCP client is unprepared to properly interpret the VSS information." This seems ambiguous. How will the server know if the other entities can properly interpret the VSS information? Kim:: Some external configuration -- certainly something external to this document (in the case where the DHCP server is trying to drive the VPN selection). Kim: In the case where the server is responding to an incoming VPN option/sub-option, then it is obvious whoever sent it understands it. s/send in/insert/ 15. section 4 says "The DHCP client, in this scenario, does not know the VPN on which it resides." section 6 says " A DHCPv4 or DHCPv6 client will employ the VSS option to communicate VSS information to their respective servers. This information MUST be included in every message concerning any IP address on a different VPN than the global or default VPN." these statements seem to conflict regarding the client's knowledge. Kim: Section 6 should be broadened to include relay agents acting on behalf of clients. 16. section 6: " Clients should be aware that some DHCP servers will return a VSS option with different values than that which was sent in. In addition, a client may receive a response from a DHCP server with a VSS option when none was sent in by the Client." So should subsequent messages from the client use the original VSS information or the server-returned or relay-returned VSS info? Kim: The server returned one, but typically the actual "end" DHCP clients aren't dealing with this, but the relay agents are. Can a return message contain multiple VSS options? If I readthe document correctly, multiple relays can add their own VSS options, and a server typically copies all the options. If a client is expected to include the VSS option information in subsequent messages, does it include multiple VSS options? The second paragraph of 6 says that is not allowed. Kim: Correct, only one VSS option should come back from a server -- if you send in two, and get two back, it either doesn't support this (if they are sub-options), or it is broken. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From magnusn@gmail.com Tue Oct 27 09:23: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 91C6828C1A4; Tue, 27 Oct 2009 09:23:02 -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=[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 ximW4pB0pB3h; Tue, 27 Oct 2009 09:23:01 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 74F9728C199; Tue, 27 Oct 2009 09:23:01 -0700 (PDT) Received: by ewy4 with SMTP id 4so317902ewy.37 for ; Tue, 27 Oct 2009 09:23:11 -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; bh=5tUefSnDmM95mfjy0AKqfcsW7wE/DYqzPpcWl2rS/VM=; b=Q90KeQdjLms4uqkc8qpdrzq3nvFRXyrBBjPC2Ov20pHNITeO4tY1BMKaOB7izZmO1a 10BZF6YWdI5HkHz7FLUfVIiFoEgoFcJooh0yjs3Lo1FemeRofeFbqsdGUzF/glNdxuU2 TH+wm+ZbSRviXa7hmnluRKSKnEfqaBlnMGUtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vLKAoiiAXp/OHGxOra0aIo46Gj+FFyynPsckrP6fDciKSPMaO+3ctKx3J5YxIzmnbr jw4c5v33eZsPhuq+jsGrhqRTemMXR88+byXMpBno8OLWQBMgyQF2b/jnwq/Xuz+yl8x7 menrVmPusIr1Gb/TLXFPfBZ2eBCqtcouvOZt4= MIME-Version: 1.0 Received: by 10.211.131.39 with SMTP id i39mr6066150ebn.98.1256660590863; Tue, 27 Oct 2009 09:23:10 -0700 (PDT) Date: Tue, 27 Oct 2009 09:23:10 -0700 Message-ID: <2f57b9e60910270923t63927d15k9465cdf471ed83d9@mail.gmail.com> From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, lzhu@microsoft.com, Nicolas.Williams@sun.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-altman-tls-channel-bindings-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:23:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines channel binding types for Transport Layer Security (TLS), in accordance with RFC 5056. The security considerations section seems adequate to me (especially the discussion about the consequences of sending channel binding data in the authentication mechanism). It would have been nice with an example of an authentication mechanism using one of the channel bindings in this document, perhaps in the form of an illustrative appendix. Nits: -Section 2 should reference RFC 5056, not RFC 5246. -There should be some spell checking, like "descritption" -- Magnus From Nicolas.Williams@sun.com Tue Oct 27 09:42: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 CF3E43A6A3E; Tue, 27 Oct 2009 09:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 pp+X53urarU2; Tue, 27 Oct 2009 09:42:19 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id A8B873A6841; Tue, 27 Oct 2009 09:42:19 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9RGgX7g001572; Tue, 27 Oct 2009 16:42:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9RGgXCb033230; Tue, 27 Oct 2009 10:42:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9RGNb8N001489; Tue, 27 Oct 2009 11:23:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9RGNaou001488; Tue, 27 Oct 2009 11:23:36 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 27 Oct 2009 11:23:36 -0500 From: Nicolas Williams To: Magnus =?iso-8859-1?Q?Nystr=F6m?= Message-ID: <20091027162336.GE1105@Sun.COM> References: <2f57b9e60910270923t63927d15k9465cdf471ed83d9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2f57b9e60910270923t63927d15k9465cdf471ed83d9@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-altman-tls-channel-bindings-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:42:20 -0000 On Tue, Oct 27, 2009 at 09:23:10AM -0700, Magnus Nystrm wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. Thanks! > It would have been nice with an example of an authentication mechanism > using one of the channel bindings in this document, perhaps in the > form of an illustrative appendix. I could certainly add a small example, particularly now that SCRAM is approved for publication. > Nits: > > -Section 2 should reference RFC 5056, not RFC 5246. Yes, thanks. This will be fixed. > -There should be some spell checking, like "descritption" As will this. (I'll look into an XML syntax-aware spell check module for VIM. If I had such a thing I'd use it.) Nico -- From secdir-bounces@mit.edu Tue Oct 27 13:00: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 66CF128C104 for ; Tue, 27 Oct 2009 13:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAj-lamFQqIK for ; Tue, 27 Oct 2009 13:00:36 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 65CAF3A6A79 for ; Tue, 27 Oct 2009 13:00:36 -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 n9RK0o33002432 for ; Tue, 27 Oct 2009 16:00:50 -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 n9RK0mM1002424 for ; Tue, 27 Oct 2009 16:00:48 -0400 Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n9RJsOWv028897 for ; Tue, 27 Oct 2009 16:00:45 -0400 (EDT) X-AuditID: 12074425-b7cf3ae000006bbb-23-4ae75156c25f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by (Symantec Brightmail Gateway) with SMTP id 62.6B.27579.65157EA4; Tue, 27 Oct 2009 16:00:23 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34BA43A6A7F; Tue, 27 Oct 2009 13:00:07 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 24F583A686C; Tue, 27 Oct 2009 13:00:02 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20091027200002.24F583A686C@core3.amsl.com> Date: Tue, 27 Oct 2009 13:00:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Brightmail-Tracker: AAAAARFf+IA= X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 27 Oct 2009 23:36:20 -0700 Subject: [secdir] [New-work] WG Review: Internet Area Working Group (intarea) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:00:37 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 3, 2009. Internet Area Working Group (intarea) --------------------------------------------------- Current Status: Proposed Working Group Last modified: 2009-10-22 Chairs: TBD Internet Area (int) Directors: Jari Arkko Ralph Droms Internet Area Advisor: Jari Arkko Ralph Droms Mailing Lists: General Discussion: int-area@ietf.org Subscribe online at: https://www.ietf.org/mailman/listinfo/int-area Description of Working Group: The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such work items in the IETF. The working group milestones are updated as needed to reflect the current work items and their associated milestones. New work must satisfy the following conditions: (1) WG consensus on the relevance for the Internet at large. (2) WG consensus on the suitability and projected quality of the proposed work item. (3) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (4) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (5) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Milestones: Dec 2009 Submission of IPID document to the IESG as PS Mar 2010 Submission of tunneling issues document to the IESG as Info _______________________________________________ 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 From secdir-bounces@mit.edu Tue Oct 27 14:00:29 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 8BC993A6914 for ; Tue, 27 Oct 2009 14:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60ZlhwjYkBMr for ; Tue, 27 Oct 2009 14:00:28 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8D3C828C108 for ; Tue, 27 Oct 2009 14:00: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 n9RL0fkW013475 for ; Tue, 27 Oct 2009 17:00:41 -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 n9RL0e04013467 for ; Tue, 27 Oct 2009 17:00:40 -0400 Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n9RKns6n013174 for ; Tue, 27 Oct 2009 17:00:29 -0400 (EDT) X-AuditID: 12074422-b7b60ae000006d0d-3a-4ae75f66da55 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by (Symantec Brightmail Gateway) with SMTP id CE.0D.27917.66F57EA4; Tue, 27 Oct 2009 17:00:23 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000A028C18C; Tue, 27 Oct 2009 14:00:05 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8B4FB3A6914; Tue, 27 Oct 2009 14:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20091027210001.8B4FB3A6914@core3.amsl.com> Date: Tue, 27 Oct 2009 14:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Brightmail-Tracker: AAAAARFf+IA= X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 27 Oct 2009 23:36:20 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Handover Keying (hokey) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 21:00:29 -0000 A modified charter has been submitted for the Handover Keying (hokey) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 3, 2009. Handover Keying (hokey) ------------------------ Last Modified: 2009-10-19 Chair(s): Glen Zorn Tina Tsou (Ting ZOU) Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion: hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/current/maillist.html Description of Working Group: A mobile device has to re-authenticate each time it changes its point of attachment to the network. When it goes through the full procedure of authentication it creates a series of ruptures, during which the medium cannot flow. This results in a poor user experience during handover. However, it is possible to shorten the time it takes to re-authenticate by reusing the key information developed during the initial authentication. The Handover Keying Working Group is concerned with developing procedures for key reuse and delivery, while respecting good security practice. The Handover Keying Working Group has already done work on this subject, but it has not yet developed the complete set of procedures, protocols, and changes needed for different security environment scenarios and situations. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exchanges. This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication" or "early authentication". All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in RFC 4962 and RFC 5247. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) Not require changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables ===================== 1) A specification of Local Domain Name Discovery for ERP. Currently the use of DHCP mechanisms to request the local domain name is unspecified. There are other useful scenarios that need to be addressed. Lower layer announcement for local domain name is unspecified. Ambiguity with using initial full EAP exchange for re-authentication needs to be clarified. Additional re-authentication scenarios, for which there is interest, need to be addressed. 2) A specification of Early Authentication solutions. These include use of EAP to pre-establish authenticated keying material on a target authenticator prior to arrival of the peer. 3) A specification for a Hokey architecture Document. It includes deployment of ERP and EAP early authentication protocol in the mobile environment. There are various useful scenarios that need to be addressed. This specification and the revision of RFC5296 should be conducted in parallel. 4) Assistance to the 802.21a group in specifying the integration of EAP pre-authentication with IEEE 802.21a. The Hokey Working Group shall perform tasks that are complementary to and do not duplicate work being done in IEEE 802.21a. 6) A specification for NAS-Authenticator interaction. NAS interaction can be used to release resources in the old NAS and achieve faster initiation of authentication. Related work in external SDOs on authenticator/NAS interaction for re-authentication may be taken into consideration. 7) A revision of RFC 5296 to eliminate unnecessary references to the home server. 8) Assistance to the radext and dime Working Groups in developing AAA support for handoff keying. Goals and Milestones: Nov 2009 First draft on Local Domain Name Discovery for ERP Nov 2009 First draft on Early Authentication solutions Mar 2010 First draft on Hokey architecture Mar 2010 First draft on NAS-Authenticator Interaction Jul 2010 First draft on revision of RFC 5296 Mar 2011 Submit the Local Domain Name Discovery for ERP draft to IESG Mar 2011 Submit the Early Authentication solutions draft to IESG Jul 2011 Submit the NAS-Authenticator Interaction draft to IESG Nov 2011 Submit the Hokey architecture draft to IESG Nov 2011 Submit the revision of RFC 5296 to IESG Mar 2012 Re-charter or shut down WG _______________________________________________ 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 From kent@bbn.com Wed Oct 28 06:41: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 16DE23A698B for ; Wed, 28 Oct 2009 06:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.203, 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 gfi-k6Bhg28E for ; Wed, 28 Oct 2009 06:41:38 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 89CC63A69E7 for ; Wed, 28 Oct 2009 06:41:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.130.252]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N38me-0003Xv-BV; Wed, 28 Oct 2009 09:41:52 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 28 Oct 2009 09:40:19 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-955385184==_ma============" Cc: fandreas@cisco.com, fluffy@cisco.com, oran@cisco.com, dwing@cisco.com, rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:41:40 -0000 --============_-955385184==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I re-reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. In the re-review I examined only on the text that the authors said was changed in response to my comments. In my initial review I said that the text about using suitable authentication and integrity mechanisms in this context was too vague to be useful and hat it should cite specific recommendations (via RFCs). The authors have revised the relevant text and it is better. The revised text elicited a comment from Sam Hartman that SIP Identity (RFC 4474) should be cited. I agree with this suggestion, but believe that the current cite for using S/MIME with SDP [RFC 3261] also should be retained, until such time as the RAI area decides to move it to historical. I think the expanded discussion of DoS concerns is better as well, even though no explicit threat model has been provided. I did note a grammatical error: "This attack would result in a poor user's experience ..." -> "This attack would result in a poor user experience ..." Steve --============_-955385184==_ma============ Content-Type: text/html; charset="us-ascii" Re: review of draft-ietf-mmusic-connectivity-precon-06
I re-reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  In the re-review I examined only on the text that the authors said was changed in response to my comments.

In my initial review I said that the text about using suitable authentication and integrity mechanisms in this context was too vague to be useful and hat it should cite specific recommendations (via RFCs).

The authors have revised the relevant text and it is better. The revised text elicited a comment from Sam Hartman that SIP Identity (RFC 4474) should be cited. I agree with this suggestion, but believe that the current cite for using S/MIME with SDP [RFC 3261] also should be retained, until such time as the RAI area decides to move it to historical.

I think the expanded discussion of DoS concerns is better as well, even though no explicit threat model has been provided.

I did note a grammatical error:

"This attack would result in a poor user's experience ..."  ->

"This attack would result in a poor user experience ..."

Steve
--============_-955385184==_ma============-- From aland@deployingradius.com Wed Oct 28 08:17: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 7810F3A698A for ; Wed, 28 Oct 2009 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=1.591, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAoI2S-CKr9U for ; Wed, 28 Oct 2009 08:17:37 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id AAB953A672E for ; Wed, 28 Oct 2009 08:17:37 -0700 (PDT) Received: from Thor.local (unknown [74.198.12.5]) by liberty.deployingradius.com (Postfix) with ESMTPSA id EBB30123432F; Wed, 28 Oct 2009 16:17:49 +0100 (CET) Message-ID: <4AE8609A.8060202@deployingradius.com> Date: Wed, 28 Oct 2009 11:17:46 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: secdir@ietf.org, draft-turner-deviceowner-attribute@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Review of draft-turner-deviceowner-attribute 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, 28 Oct 2009 15:17:38 -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. Feel free to forward to any appropriate forum. This document defines a device owner attribute for use in ASN.1 protocols. As it leverages existing ASN.1 specifications, it introduces no new security considerations. The Security Considerations section appears to cover the expected use-cases of the attribute. Alan DeKok. From stephen.farrell@cs.tcd.ie Wed Oct 28 10:57:59 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 99EB63A6A39; Wed, 28 Oct 2009 10:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[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, 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 dxAermcrLf3D; Wed, 28 Oct 2009 10:57:58 -0700 (PDT) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id A1B673A697A; Wed, 28 Oct 2009 10:57:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 549A21004162A; Wed, 28 Oct 2009 17:58:09 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqiEoJ16npZU; Wed, 28 Oct 2009 17:58:08 +0000 (GMT) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id C91EE100415F8; Wed, 28 Oct 2009 17:58:02 +0000 (GMT) Message-ID: <4AE8862B.9040802@cs.tcd.ie> Date: Wed, 28 Oct 2009 17:58:03 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: draft-ietf-tls-rfc4366-bis@tools.ietf.org, tls-chairs@tools.ietf.org, sec-ads@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: [secdir] Secdir review of draft-ietf-tls-4366-bis 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, 28 Oct 2009 17:57:59 -0000 Everyone here knows the drill:-) I reviewed http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-06 Other than the first two points below this is basically fine. Section 5 only allows SHA-1 to be used for certificates referenced by URLs. That seems wrong these days. I assume this was discussed in the WG, but still wonder about it. Perhaps a note as to why a hardcoded hash alg is considered ok here would be good? Section 6 also has a hardcoded SHA-1 hash for a client to indicate root CA information. Same comment/question as above. Section 8 allows a client to nominate an OCSP responder and provide extensions. Seems like this could provide a new covert channel between the client and OCSP responder, via the server. Not sure that's even worth noting though. Not security related but section 3 says that literal IPv4 & IPv6 addresses are not allowed as a HostName, what about in-addr.arpa? (Might be better to say MUST NOT there too rather than "not permitted") From jhutz@cmu.edu Wed Oct 28 14:34: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 3AE453A68C3 for ; Wed, 28 Oct 2009 14:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.753 X-Spam-Level: X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=-1.154, 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 4cfl0tMqgYv1 for ; Wed, 28 Oct 2009 14:34:01 -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 5C1463A67F4 for ; Wed, 28 Oct 2009 14:34:01 -0700 (PDT) Received: from dhcp-18-111-27-30.dyn.mit.edu (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 n9SLYA6R028092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 17:34:11 -0400 (EDT) Date: Wed, 28 Oct 2009 17:34:10 -0400 From: Jeffrey Hutzelman To: Alan DeKok , secdir@ietf.org, draft-turner-deviceowner-attribute@tools.ietf.org Message-ID: In-Reply-To: <2086_1256743076_n9SFHt4Y012009_4AE8609A.8060202@deployingradius.com> References: <2086_1256743076_n9SFHt4Y012009_4AE8609A.8060202@deployingradius.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Subject: Re: [secdir] Review of draft-turner-deviceowner-attribute 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, 28 Oct 2009 21:34:02 -0000 --On Wednesday, October 28, 2009 11:17:46 AM -0400 Alan DeKok wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. Feel free to forward to > any appropriate forum. > > This document defines a device owner attribute for use in ASN.1 > protocols. As it leverages existing ASN.1 specifications, it introduces > no new security considerations. This makes no sense to me. ASN.1 is a syntax notation, not a protocol. The abstract is entirely unclear on what protocol this document extends, though the introduction seems to suggest it extends PKIX and does not extend LDAP. It's not clear to me that it has any bearing on other ASN.1-using protocols, such as SNMP or Kerberos. -- Jeff From Pasi.Eronen@nokia.com Thu Oct 29 00:48: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 C07BC28C0EF for ; Thu, 29 Oct 2009 00:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 WjbHgSt246qN for ; Thu, 29 Oct 2009 00:48:45 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F259F28C0E2 for ; Thu, 29 Oct 2009 00:48:44 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9T7mwPg011515 for ; Thu, 29 Oct 2009 02:49:00 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:48:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:48:51 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 29 Oct 2009 08:48:47 +0100 From: To: Date: Thu, 29 Oct 2009 08:48:46 +0100 Thread-Topic: Security Directorate lunch in IETF76 Thread-Index: AcpL0fS7kzjG7/SAS5i9jLL6XFPFUQMmbbyA Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F660E35@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 Oct 2009 07:48:51.0414 (UTC) FILETIME=[419F1F60:01CA586C] X-Nokia-AV: Clean Subject: Re: [secdir] Security Directorate lunch in IETF76 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, 29 Oct 2009 07:48:45 -0000 The room is Castleview 1. (BTW, it seems ISOC is trying to take over the Tuesday lunch slot for their panels -- at least this time, it's not about security...) Best regards, Pasi=20 > -----Original Message----- > From: Eronen Pasi (Nokia-NRC/Helsinki) > Sent: 13 October, 2009 09:54 > To: secdir@ietf.org > Subject: Security Directorate lunch in IETF76 >=20 > As usual, we're planning to have the Security Directorate > lunch on Tuesday. We'll send the details (such as room number) > when we get them. >=20 > If there's anything special you'd like to discuss, please > drop an email to Tim and me. >=20 > Best regards, > Pasi & Tim From aland@deployingradius.com Thu Oct 29 03:44:56 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 213423A6889 for ; Thu, 29 Oct 2009 03:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.485 X-Spam-Level: X-Spam-Status: No, score=0.485 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIGHP68dkDVE for ; Thu, 29 Oct 2009 03:44:55 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 557C83A6878 for ; Thu, 29 Oct 2009 03:44:55 -0700 (PDT) Received: from Thor.local (unknown [74.198.12.3]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 2E735123432F; Thu, 29 Oct 2009 11:45:10 +0100 (CET) Message-ID: <4AE97235.2070300@deployingradius.com> Date: Thu, 29 Oct 2009 06:45:09 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jeffrey Hutzelman References: <2086_1256743076_n9SFHt4Y012009_4AE8609A.8060202@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-turner-deviceowner-attribute@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-turner-deviceowner-attribute 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, 29 Oct 2009 10:44:56 -0000 Jeffrey Hutzelman wrote: > This makes no sense to me. ASN.1 is a syntax notation, not a protocol. It affects "ASN.1 based protocols". > The abstract is entirely unclear on what protocol this document extends, > though the introduction seems to suggest it extends PKIX and does not > extend LDAP. It's not clear to me that it has any bearing on other > ASN.1-using protocols, such as SNMP or Kerberos. The document covers security implications of its suggested use in PKIX. For other uses, the attribute would appear to be informational, and not introduce any new security issues. Alan DeKok. From turners@ieca.com Thu Oct 29 05:55: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 27A5A3A68D3 for ; Thu, 29 Oct 2009 05:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxgUDIqj1Blz for ; Thu, 29 Oct 2009 05:55:24 -0700 (PDT) Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by core3.amsl.com (Postfix) with SMTP id 154553A65A6 for ; Thu, 29 Oct 2009 05:55:23 -0700 (PDT) Received: (qmail 96744 invoked from network); 29 Oct 2009 12:55:37 -0000 Received: from pool-71-191-6-46.washdc.east.verizon.net (turners@71.191.6.46 with plain) by smtp101.biz.mail.re2.yahoo.com with SMTP; 29 Oct 2009 05:55:36 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE990C9.9040606@ieca.com> Date: Thu, 29 Oct 2009 08:55:37 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jeffrey Hutzelman References: <2086_1256743076_n9SFHt4Y012009_4AE8609A.8060202@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-turner-deviceowner-attribute@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-turner-deviceowner-attribute 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, 29 Oct 2009 12:55:25 -0000 Jeffrey Hutzelman wrote: > --On Wednesday, October 28, 2009 11:17:46 AM -0400 Alan DeKok > wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. Feel free to forward to >> any appropriate forum. >> >> This document defines a device owner attribute for use in ASN.1 >> protocols. As it leverages existing ASN.1 specifications, it introduces >> no new security considerations. > > This makes no sense to me. ASN.1 is a syntax notation, not a protocol. > The abstract is entirely unclear on what protocol this document extends, > though the introduction seems to suggest it extends PKIX and does not > extend LDAP. It's not clear to me that it has any bearing on other > ASN.1-using protocols, such as SNMP or Kerberos. Somebody else recently commented that there really aren't ASN.1 attributes. They suggested changing it to X.500 attributes because that's where the definition came from (I guess technically the attribute definition is from X.501). I agree with the suggested change and will make it in the next revision. spt From magnus.westerlund@ericsson.com Thu Oct 29 08:23:13 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 BFD103A6783; Thu, 29 Oct 2009 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ZhR8QT3Uwh7A; Thu, 29 Oct 2009 08:23:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9DE743A6802; Thu, 29 Oct 2009 08:23:11 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-62-4ae9b36ddad6 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F8.D1.04191.D63B9EA4; Thu, 29 Oct 2009 16:23:26 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 16:23:25 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 16:23:25 +0100 Message-ID: <4AE9B36D.1020403@ericsson.com> Date: Thu, 29 Oct 2009 16:23:25 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Oct 2009 15:23:25.0700 (UTC) FILETIME=[C25CE440:01CA58AB] X-Brightmail-Tracker: AAAAAA== Cc: Gorry Fairhurst , Francois le Faucheur , Bruce Davie , secdir@ietf.org, iesg@ietf.org, Ashok Narayanan , James Polk Subject: Re: [secdir] SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 15:23:13 -0000 Hi Stefan, Are you happy with the new version? I will put this document on the agenda for the IESG call the week after IETF. If you have serious grief then please tell me quickly so that I can pull the document from the agenda. Cheers Magnus Stefan Santesson skrev: > 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 specification define a set of procedures to overcome challenges > with deployment of Resource Reservation Protocols over BGP/MPLS VPNs. > > The BGP/MPLS VPN (RFC 4364) is a VPN technique that doesn't rely > encryption to ensure secrecy or message integrity. The security > properties are instead dependent on the security of the network > infrastructure. > > It appears that this draft makes a serious effort to describe and > analyze relevant security considerations. With my limited expertise in > this particular area I can't find any thing that is obviously missing. > > However, one question that comes to my mind, which might be worth > looking at from a security perspective, is whether the procedures > introduced by this document requires the communication to be unencrypted > and if so, whether deployment of this protocol blocks or prevents > legitimate use of e.g. IPsec based VPN as discussed in RFC 4364 and RFC > 4023. If this is the case, should it be discussed in the security > considerations section? > > > *Stefan Santesson > *AAA-sec.com > > > > > -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Sandra.Murphy@cobham.com Thu Oct 29 08:44: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 1784C3A6ACC for ; Thu, 29 Oct 2009 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 4pZnTAEIMpmj for ; Thu, 29 Oct 2009 08:44:11 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3A5773A6885 for ; Thu, 29 Oct 2009 08:44:11 -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 n9TFiC47003448; Thu, 29 Oct 2009 10:44:12 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9TFiCO1019606; Thu, 29 Oct 2009 10:44:13 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:44:09 -0400 Date: Thu, 29 Oct 2009 11:44:09 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 29 Oct 2009 15:44:09.0370 (UTC) FILETIME=[A7A5DFA0:01CA58AE] Cc: secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 15:44:12 -0000 On Wed, 28 Oct 2009, Stephen Kent wrote: > I re-reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. In the > re-review I examined only on the text that the authors said was changed in > response to my comments. > > In my initial review I said that the text about using suitable authentication > and integrity mechanisms in this context was too vague to be useful and hat > it should cite specific recommendations (via RFCs). > > The authors have revised the relevant text and it is better. The revised text > elicited a comment from Sam Hartman that SIP Identity (RFC 4474) should be > cited. I agree with this suggestion, but believe that the current cite for > using S/MIME with SDP [RFC 3261] also should be retained, until such time as > the RAI area decides to move it to historical. > > I think the expanded discussion of DoS concerns is better as well, even > though no explicit threat model has been provided. > > I did note a grammatical error: > > "This attack would result in a poor user's experience ..." -> > > "This attack would result in a poor user experience ..." Chuckle. One does indeed hope that this is a grammatical error. Finding a source to authenticate the user's poverty could be daunting, not to mention a privacy issue. --Sandy > > Steve From mcgrew@cisco.com Thu Oct 29 09:55:57 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 D5AE93A6836; Thu, 29 Oct 2009 09:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 vqlFulj7r+sb; Thu, 29 Oct 2009 09:55:57 -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 36B9B3A67BD; Thu, 29 Oct 2009 09:55:57 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="420599577" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 16:55:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TGtoTX023115; Thu, 29 Oct 2009 16:55:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:55:50 -0700 Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:55:49 -0700 Message-Id: <61154F7D-A83B-411E-A323-6BAF99F23FE8@cisco.com> From: David McGrew To: secdir@ietf.org, IESG , weiler@tislabs.com, Russ Housley , David Ward Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 09:51:39 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 16:55:49.0951 (UTC) FILETIME=[AAFE74F0:01CA58B8] Subject: [secdir] review of draft-weiler-rsync-uri-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 16:55:57 -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 draft defines a URI for rsync, and it refers the reader to the detailed security considerations of RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax), after pointing out that some of those considerations do not apply. This appears to cover the security issues. David From mcgrew@cisco.com Thu Oct 29 11:03: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 BF50C3A69FE; Thu, 29 Oct 2009 11:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 f4AL0FSUSNcn; Thu, 29 Oct 2009 11:03:11 -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 0BE3F3A697C; Thu, 29 Oct 2009 11:03:11 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="420645471" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 18:03:27 +0000 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.14.3) with ESMTP id n9TI3RUA004751; Thu, 29 Oct 2009 18:03:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:03:27 -0700 Received: from stealth-10-32-254-212.cisco.com ([10.32.254.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:03:26 -0700 Message-Id: <9E8FAA81-5658-4CA7-A1BD-CC3CF0E3C7E5@cisco.com> From: David McGrew To: secdir@ietf.org, IESG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 11:03:25 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 18:03:26.0791 (UTC) FILETIME=[1D0F1D70:01CA58C2] Cc: weiler@tislabs.com, David Ward Subject: [secdir] review of draft-weiler-rsync-uri-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:03: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. The draft defines a URI for rsync, and it refers the reader to the detailed security considerations of RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax), after pointing out that some of those considerations do not apply. This appears to cover the security issues. David From Pasi.Eronen@nokia.com Fri Oct 30 02:37: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 B468F3A6A4D; Fri, 30 Oct 2009 02:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 9jGfriGHwGYR; Fri, 30 Oct 2009 02:37:50 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 823FD3A6948; Fri, 30 Oct 2009 02:37:49 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9U9bnA7032633; Fri, 30 Oct 2009 11:38:03 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 11:37:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 11:37:49 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 30 Oct 2009 10:37:45 +0100 From: To: , Date: Fri, 30 Oct 2009 10:37:44 +0100 Thread-Topic: Pasi's AD Notes for October 2009 Thread-Index: AcpZRKH3PtyqoK+WSZ+18n7M2yaPfQ== Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F6F46A5@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: 30 Oct 2009 09:37:49.0029 (UTC) FILETIME=[A4C1C150:01CA5944] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for October 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, 30 Oct 2009 09:37:51 -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 - Preparing IETF76 SAAG agenda and SecDir lunch with Tim. - Looking into RFC editor errata for security-related AD-sponsored=20 documents with Tim. - Some IODEF/INCH related discussions. - (Not wearing AD hat): Discussions about draft-krawczyk-hkdf on=20 CFRG list. - Tools work: Django 1.x transition, test suite improvements,=20 retiring many old scripts (my lines-of-code-per-day average=20 productivity this month is heavily negative :-). - I've been asked to sponsor draft-marin-eap-frm-fastreauth; waiting for me to take a look and reply to the authors [since 2009-10-26] WORKING GROUPS DKIM - draft-ietf-dkim-deployment: currently in Publication Requested state, waiting for me to read it [since 2009-10-26] - Waiting for Stephen and Barry for new charter text (noting that=20 current work items are completed and adding 4871bis) - I still need to review what to do about errata 1385, 1532, and 1596 - Talking with chairs and others about mailing list (mis)behavior. EMU - EMU WG received a new liaison statement from ITU-T about X.1034;=20 the WG chairs have the token for doing something about it. IPSECME - draft-ietf-ipsecme-ikev2-resumption: was approved by the IESG; waiting for the secretariat to send the announcement. - The IANA registrations for RFC 4543 have now been fixed, and RFC editor errata approved (see email on list for details). - draft-ietf-ipsecme-traffic-visibility: went through IETF last call; waiting for authors to address the comments received [since 2009-10-30] - draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat): went through IESG evaluation, and new version was submitted. Waiting for Tim to remove the RFC Editor Note and Russ to check the=20 new version, and clear his DISCUSS [since 2009-10-30] - draft-kanno-ipsecme-camellia-xcbc (not WG item): the authors have asked if I would sponsor this as individual submission. I've sent some questions to them, and I'm currently waiting for their reply [since 2009-10-14] - draft-ietf-ipsecme-ikev2-redirect (not wearing AD hat; Tim is=20 handling this one): currently in AUTH48, waiting for the authors (I think). - Some discussions about clarifying IKEv2 IANA registries (for encryption algorithms) and fixing a bug in RFC 4307. Waiting for Tero to submit an errata about the latter. - IANA registry entry for PRF_AES128_XCBC was fixed (thanks to=20 Alfred and Paul). - Processed one errata for RFC 2410. ISMS KEYPROV - Apparently waiting for the chairs to send some documents my way... PKIX - draft-ietf-pkix-sha2-dsa-ecdsa: was approved by IESG, now in RFC=20 editor queue. - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for draft-ietf-pkix-sha2-dsa-ecdsa. SASL - draft-ietf-sasl-scram: was approved by IESG; now in RFC editor=20 queue. - draft-ietf-sasl-gs2: currently in IETF last call (ends 2009-11-18); hoping the authors submit a revised ID when submissions re-open. - (not WG item) draft-melnikov-sasl-scram-ldap: waiting for authors=20 to submit a revised ID when submissions re-open; placed on the agenda=20 of the 2009-11-19 IESG telechat. - (not WG item) draft-altman-tls-channel-bindings: currently in=20 IETF last call (ends 2009-11-02); active discussion ongoing. SYSLOG - draft-ietf-syslog-sign: in IESG evaluation; active discussions ongoing; waiting for me to reply to some of the emails; waiting for Alex to reply to some others. TLS - draft-ietf-tls-rfc4366-bis: the document was updated to address IETF last call comments; placed on the agenda of 2009-11-19 IESG telechat. - draft-ietf-tls-extractor: waiting for Eric to reply to email [since 2009-10-05]; also in AUTH48. - Processed two errata for RFC 4346. - (not WG item) see SASL WG for draft-altman-tls-channel-bindings OTHER DOCUMENTS DISCUSSES (active -- something happened within last month) - draft-ietf-bmwg-ipsec-meth: waiting for authors to reply to my comments [since 2009-10-22] - draft-ietf-bmwg-ipsec-term: waiting for authors to reply to my comments [since 2009-10-22] - draft-ietf-eai-downgraded-display: discussion ongoing; currently waiting for the authors to reply [since 2009-10-26] - draft-ietf-mipshop-pfmipv6: discussion ongoing; currently waiting for the authors to reply [since 2009-10-29] - draft-ietf-ntp-autokey: waiting for Ralph's proposal on how to proceed [since 2009-10-19] - draft-ietf-roll-home-routing-reqs: text agreed, waiting for the authors to submit a revised ID [sincer 2009-10-29] - draft-ietf-sip-certs: discussion ongoing; currently waiting for the authors to reply [since 2009-10-26] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-cain-post-inch-phishingextns: waiting for authors to submit a revised ID [since 2009-09-04] - draft-solinas-rfc4753bis: waiting for authors to reply to my comments [since 2009-09-24] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30, 2009-06-09, 2009-10-29) - 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, 2009-06-09, 2009-10-29) - draft-ietf-dime-diameter-api: waiting for Dan to get WG's opinion=20 on whether this will be useful and if yes, why [since 2009-06-18] - 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 petithug@acm.org Fri Oct 30 07:32:04 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 431903A69B9; Fri, 30 Oct 2009 07:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.055 X-Spam-Level: X-Spam-Status: No, score=-102.055 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Trck1MpHvspA; Fri, 30 Oct 2009 07:32:03 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 725DC3A67B6; Fri, 30 Oct 2009 07:32:03 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 0DFC96C984CA; Fri, 30 Oct 2009 14:32:19 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 3D33E6C984B2; Fri, 30 Oct 2009 14:32:17 +0000 (UTC) Message-ID: <4AEAF8F0.30201@acm.org> Date: Fri, 30 Oct 2009 07:32:16 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> <808FD6E27AD4884E94820BC333B2DB773C09B0BC50@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C09B0BC50@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 31 Oct 2009 08:42:58 -0700 Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 14:32:04 -0000 Hi Pasi, Sorry for the delay in responding to this. See my answer inline. Pasi.Eronen@nokia.com wrote: > Marc Petit-Huguenin wrote: > >> I propose to replace the second paragraph of section 6 by the >> following text. Let me know if it addresses your comment: >> >> "The Application Service Tag and Application Protocol Tags defined in >> this document do not introduce any specific security issues beyond >> the security considerations discussed in [RFC3958]. [RFC3958] >> requests that an S-NAPTR application defines some form of end-to-end >> authentication to ensure that the correct destination has been >> reached. This is achieved by the mandatory Long-Term Credential >> Mechanism defined by [RFC5389] and additionally for a "turns" URI by >> the usage of TLS." > > We probably need some additional text about TLS here. > > The text in RFC 3958 asks for a very specific kind of "end-to-end" > authentication: the authenticated identity of the server must be the > same as the *input* to the S-NAPTR processing. > > So if the URI was "turns:example.com", and the DNS records are as > follows: > > example.com. IN NAPTR 100 10 "S" "RELAY" "" turn.example.net. > turn.example.net. IN SRV 10 0 10001 turnserver1.example.org. > turnserver1.example.org. IN A 192.0.2.1 > > Then the server needs to present a certificate with name "example.com" > (NOT "turn.example.net" or "turnserver1.example.org"). > > Is this the intent here? > > The reason behind this text in RFC 3958 is that otherwise an attacker > could just spoof DNS reply "example.com. IN NAPTR 100 10 "S" "RELAY" > "" turn.attacker.org.", and TLS wouldn't catch this. > > (Basically the same thing occurs in HTTPS, of course. If the URI is > "https://www.example.com/", then the certificate must contain name > "www.example.com", even if DNS replies with "www.example.com. IN > CNAME foo.attacker.org.") Here's the new proposed text. Let me know if this is OK for you: "The Application Service Tag and Application Protocol Tags defined in this document do not introduce any specific security issues beyond the security considerations discussed in [RFC3958]. [RFC3958] requests that an S-NAPTR application defines some form of end-to-end authentication to ensure that the correct destination has been reached. This is achieved for "turn" and "turns" URIs by the Long- Term Credential Mechanism defined in [RFC5389], which is mandatory for TURN [I-D.ietf-behave-turn]. Additionally for a "turns" URI, the usage of TLS has the capability to address the requirement. In this case the client MUST verify the identity of the server by following the identification procedure in section 7.2.2 of [RFC5389]." Thanks. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From alexey.melnikov@isode.com Sat Oct 31 11:28: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 0CB3E3A6836; Sat, 31 Oct 2009 11:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 O+IbtM2ePLmV; Sat, 31 Oct 2009 11:28:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 123B93A67F1; Sat, 31 Oct 2009 11:28:14 -0700 (PDT) Received: from [94.197.211.97] (94.197.211.97.threembb.co.uk [94.197.211.97]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 31 Oct 2009 18:28:30 +0000 Message-ID: <4AEC81B9.20204@isode.com> Date: Sat, 31 Oct 2009 18:28:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: barryleiba@computer.org, Chris Lonvick References: <6c9fcc2a0910151344o41516489ufd9b132d398f94d2@mail.gmail.com> In-Reply-To: <6c9fcc2a0910151344o41516489ufd9b132d398f94d2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-melnikov-sasl-scram-ldap-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 18:28:15 -0000 Barry Leiba wrote: >On Tue, Oct 13, 2009 at 5:57 PM, Chris Lonvick wrote: > > >>I'd also recommend that you revise the abstract a bit for clarity. >>CURRENT: >> This memo describes how authPassword LDAP attribute can be used for >> storing secrets used by Salted Challenge Response (SCRAM) Simple >> Authentication and Security Layer (SASL) Mechanism. >>SUGGESTED: >> This memo describes how the LDAP attribute of authPassword can be used >> for storing secrets used by the Salted Challenge Response (SCRAM) >> mechanism in the Simple Authentication and Security Layer (SASL) >> framework. >> >> >I agree that strings of attributive nouns and noun-phrases can be >confusing, especially when they're long and also shown as acronyms. I >think the second half of your suggested change is good. But I think >the first half actually makes it worse, by making it look like there's >some attribute of authPassword that's called "LDAP". The best way to >clarify that part is just to put the attribute name in quotes: >SUGGESTED++: > This memo describes how the "authPassword" LDAP attribute can be used > for storing secrets used by the Salted Challenge Response (SCRAM) > mechanism in the Simple Authentication and Security Layer (SASL) > framework. > > Ok, I've done this change in my copy. > > From alexey.melnikov@isode.com Sat Oct 31 12:10: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 D304E3A6782; Sat, 31 Oct 2009 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_23=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 r0WxzL6Y0rN1; Sat, 31 Oct 2009 12:10:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A61C13A6768; Sat, 31 Oct 2009 12:10:41 -0700 (PDT) Received: from [94.197.211.97] (94.197.211.97.threembb.co.uk [94.197.211.97]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 31 Oct 2009 19:10:58 +0000 Message-ID: <4AEC8BA9.3040202@isode.com> Date: Sat, 31 Oct 2009 19:10:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Chris Lonvick References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-melnikov-sasl-scram-ldap-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 19:10:42 -0000 Chris Lonvick wrote: > Hi, Hi Chris, Thank you for the review. > 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. > > Althought this isn't a WG document, it does state that discussion may > take place on the sasl WG list, so I'm cc'ing the Chairs of that WG. > > Overall, the concept is pretty straightforward and the description is > succinct. However, I do have some items that I would like to see > addressed before I would recommend that this become an RFC. > > Your ABNF is not complete. You are using values taken from the > complete ABNF in RFC 3112 so your ABNF is not going to properly parse. I've updated comments in the ABNF to clearly indicate where various productions are coming from. > I think that mostly all you need to do there is to copy the ABNF from > RFC 3112 and insert your values. I don't think copying all productions defined elsewhere into this document is a good idea. > You'll also need to define iter-count in the document somewhere. > (draft-ietf-sasl-scram-07 doesn't reference "iter-count"; only > iteration count.) Ok, I've added a clarifying comment. > Perhaps: > CURRENT: > The "authInfo" part of the authPassword attribute is the iteration > count, followed by ":" and base-64 [BASE64] encoded salt. > SUGGESTED: > The "authInfo" part of the authPassword attribute is the iteration > count [SCRAM] (identified here as the iter-count), followed by ":" > and base-64 [BASE64] encoded salt [SCRAM]. > > An example is needed and I see that you have an anchor for that. > Please complete that. > > Your Security Considerations section needs some work. Each sentence > you have there is actually a separate paragraph. I thought all three sentences are related to each other. > Rather than reworking that, I'd suggest that you start the section by > stating that this specification utilizes the framework of RFC 4422 and > the security concerns expressed there apply. If needed, you could > call out individual concerns from that Section 6. Then you could call > out any specific concerns that apply specifically to this document. Ok, I will try to rework this. > Just as a nit, you're mixing reference types. RFC 3112 is referenced > as [AUTHTYPE] whereas RFC 2119 is referenced as [RFC2119]. These > should be consistent. Right. I will let RFC Editor handle that. I would like to use symbolic references, but xml2rfc doesn't make it easier without cut and pasting reference descriptions.