From secdir-bounces@ietf.org Wed Oct 1 08:03:30 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2B128C1E1; Wed, 1 Oct 2008 08:03:30 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA673A6C14 for ; Wed, 1 Oct 2008 05:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.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 K-1JCJdEWsUq for ; Wed, 1 Oct 2008 05:41:08 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8F92828C0F5 for ; Wed, 1 Oct 2008 05:37:12 -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 m91CabSh030979 for ; Wed, 1 Oct 2008 08:36:37 -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 m8UIS9ep022060 for ; Tue, 30 Sep 2008 14:28:09 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m8UIS0AB024957 for ; Tue, 30 Sep 2008 14:28:00 -0400 (EDT) Received: from web31809.mail.mud.yahoo.com (web31809.mail.mud.yahoo.com [68.142.207.72]) by mit.edu (Spam Firewall) with SMTP id CC9301053429 for ; Tue, 30 Sep 2008 14:27:35 -0400 (EDT) Received: (qmail 97169 invoked by uid 60001); 30 Sep 2008 18:27:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Pa0Hwjos8oAL/e6hkfXIlXvxkB1K3NnjvdV9XJfmsqgsVxe4DnYICfz8PSWGjU8Zk/xfcSx+mCvpnlewx9rJJf/DUBYSJ5ddECueIkq39lzAAcI01sxurEJdV1A/WLC3MbV6e2fG+wUZL8zQasLO1lDgA8UyJ0hXrCKgFyyYUQg= ; Message-ID: <224856.81582.qm@web31809.mail.mud.yahoo.com> Received: from [65.197.200.82] by web31809.mail.mud.yahoo.com via HTTP; Tue, 30 Sep 2008 11:27:36 PDT X-Mailer: YahooMailWebService/0.7.247.3 Date: Tue, 30 Sep 2008 11:27:36 -0700 (PDT) From: Thomas Hardjono To: saag@ietf.org, secdir@mit.edu, Pasi.Eronen@nokia.com MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m8UIS9ep022060 X-Mailman-Approved-At: Wed, 01 Oct 2008 08:36:35 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Wed, 01 Oct 2008 08:03:30 -0700 Cc: Mark Baugher , thardjono@yahoo.com Subject: Re: [secdir] [saag] Pasi's AD notes for September 2008 X-BeenThere: secdir@ietf.org Reply-To: thardjono@yahoo.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Pasi, Tim, Apologies for asking, but I was wondering about the proposed Content Rights= Management (ie. DRM) BOF. More specifically, I was wondering if the IETF i= s now open to discussing such a "DRM standard". Back in 2001, Mark Baugher and myself went through two (2) BOFs proposing t= he creation of an IETF open standards for a DRM protocol. If my memory ser= ves me right the presiding ADs was Steve Bellovin and Russ Housley. The spe= cific protocol was called PERM, and the slides can be found here: http://hardjono.net/idrm/ At that time the outcry against this effort was deafening. I was arguing th= at it was better for the IETF to own such a protocol and made it it "open" = (ie. not proprietary and no need to sign consortium legal paperwork). Since= that time there has been a plethora of DRM related products and standards = (eg. Apple, MSFT RM, OMA-download, CableLabs, 5C, etc, etc). In a sense, th= e IETF missed the boat on this one. Not that I'm unsupportive, but I was wondering what is motivating the IETF = to propose such a BOF again at this time :) Thanks. Regards. /thomas/ --- On Tue, 9/30/08, Pasi.Eronen@nokia.com wrote: > From: Pasi.Eronen@nokia.com > Subject: [saag] Pasi's AD notes for September 2008 > To: saag@ietf.org, secdir@mit.edu > Date: Tuesday, September 30, 2008, 3:21 AM > Hi all, > = > 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 > = > - There have been two security-related BoF requests for > IETF73: > OAuth (in the applications area), and Content Rights > Management > (in the security area). For the latter, Tim and I have > recommended = > having a bar BoF first. = > - SecDir mailing list is in the process of being moved from > mit.edu = > to ietf.org servers. > - I've spent some time this month on tools development > and IESG > process improvements -- nothing is ready yet, but > hopefully soon.. > = > WORKING GROUPS > = > DKIM > - draft-ietf-dkim-ssp: in Publication Requested, waiting > for = > me to read it. > - Waiting for WG to send list of RFC errata IDs the WG > agrees on. > = > EMU > - draft-ietf-emu-gpsk: in AD Evaluation -- waiting for > revised = > ID that reflects the new WG consensus on MAC length/key > size = > issue before going to IETF last call (since 2008-08-25) > - A liaison statement reply was sent to ITU-T SG 17 > regarding X.1034, = > "Guidelines on EAP-based authentication and key > management in a = > data communication network". > - IESG appointed Joe Salowey as the designated expert for > IANA = > allocation of EAP Type Codes > - (not WG item) draft-arkko-eap-aka-kdf =EDs now in IETF > Last Call > = > IPSECME > - Lots of emails that I need to read (but haven't done > so yet) > - (not wearing AD hat) I sent my "things that need to > be looked at" = > list about IKEv2bis to the mailing list; I need to check > that = > they got entered in the issue tracker, too. > = > ISMS > - It seems the discussion has largely converged; I'm > waiting for > revised IDs to read and review. > = > KEYPROV > - I sent more comments regarding PSKC; I need to read the > replies > and participate in discussion. > - I need to review and comment DSKPP, too. > = > SASL > - I replied to Frank Ellermann's appeal about WG > chairs' handling = > of draft-ietf-sasl-crammd5. > - Waiting for charter update text from the chairs (>6 > months) > = > SYSLOG > - draft-ietf-syslog-transport-tls: a revised version > addressing > Chris Newman's DISCUSS should be posted in a couple > of days. > - draft-ietf-syslog-sign: there has been a bunch of replies > to my > AD evaluation comments that I need to read and process, > but I = > haven't done so yet. > = > TLS > - (not WG item) draft-rescorla-tls-suiteb is now in IETF > Last Call. > - (not WG item) draft-hajjeh-tls-identity-protection: IESG > reviewed > this independent submission to the RFC Editor, and > recommended > not publishing it. > = > OTHER DOCUMENTS > = > - draft-ietf-capwap-*: I've been working with Pat and > others, > and I think we're done (except that agreed text needs > to be = > edited in, and some editorial nits fixed). > - draft-ietf-avt-rtcpssm: no news; waiting for Joerg to > explore > "feedback debug" messages. > - draft-santesson-digestbind: I read this and sent comments > to > Stefan. > - PKCS #1/RFC 3447 update: waiting for James Randall to > post an > update including the various errata. > - draft-mattsson-srtp-store-and-forward: I've promised > to read = > this and send comments, but haven't done so yet. > - draft-ietf-mpls-mpls-and-gmpls-security-framework: > I've promised = > to read this once there's a new version. > - "Security roadmap for routing protocols": > I've promised to read > and comment this once Gregory sends something. > = > DISCUSSES (active -- something happened within last month) > = > - draft-ietf-capwap-protocol-binding-ieee80211: text > agreed, > waiting for authors to submit a revised ID [since > 2008-09-26] > - draft-ietf-lemonade-msgevent: waiting for authors to > submit > a revised ID [since 2008-09-08] > - draft-ietf-mip6-whyauthdataoption: waiting for authors to > submit = > a revised ID [since 2008-09-08] > - draft-ietf-mipshop-mstp-solution: the authors have > replied to = > my comments; I need to read the replies [since > 2008-09-26] > - draft-ietf-nfsv4-rpcsec-gss-v2: waiting for authors to > reply to my comments [since 2008-09-25] > - draft-ietf-sieve-refuse-reject: waiting for authors to > reply > to my comments [since 2008-09-11] > - draft-ietf-sipping-race-examples: waiting for document > shepherd > or Jon to comment the "Updates" issue [since > 2008-09-26] > - draft-ietf-v6ops-addcon: the changes in version -10 were > sent > to 6MAN WG for review; I'll clear once this has > happened = > [expected to happen on 2008-10-01] > - draft-mraihi-inch-thraud: version -07 addressed almost > all of = > my comments; waiting for authors to send RFC Editor Note > text > fixing the IANA issue, too [since 2008-09-02] > = > 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 reply = > to my comments or submit a revised ID [since 2008-08-28] > - draft-cam-winget-eap-fast-provisioning: waiting for > authors to = > reply to my comments or submit a revised ID [since > 2008-08-28] > - draft-hautakorpi-sipping-uri-list-handling-refused: text > agreed, = > waiting for authors to submit a revised ID [since > 2008-07-03] > - draft-ietf-enum-experiences: talked briefly with Jon > Peterson = > in Dublin -- waiting to hear more from the authors and/or > Jon > [since 2008-07-31] > - draft-ietf-pce-pcep: new version -15 addressed some > comments from > other ADs; some discussions about my comments has > occured; > waiting for proposed text or revised ID [since > 2008-06-16] > - draft-ietf-pwe3-pw-atm-mib: waiting for authors to reply > to > my comments or submit a revised ID [since 2008-07-02] > - draft-zhou-emu-fast-gtc: changes probably agreed, waiting > for authors > to submit a revised ID to see exact text [since > 2008-08-28] > = > DISCUSSES (presumed dead -- I haven't heard anything > from the authors > or document shepherd for over three months) > = > - draft-ietf-bfd-base: waiting for authors to reply to my = > comments or submit a revised ID [since 2008-06-05] > - draft-ietf-bfd-multihop: waiting for authors to reply to = > my comments or submit a revised ID [since 2008-06-05] > - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to > = > my comments or submit a revised ID [since 2008-06-05] > - draft-ietf-shim6-proto: waiting for Erik to propose > something = > to solve IPsec interaction issue [since 2008-06-18] > - draft-ietf-simple-imdn: waiting for authors to reply to > my = > comments or submit a revised ID [since 2008-05-14] > - draft-ietf-sipping-sbc-funcs: new version (-06) addressed > all comments except one; text agreed for the remaining > one, > waiting for RFC editor note or revised ID [since > 2008-06-17] > - draft-ietf-tsvwg-emergency-rsvp: this document has large = > number of discusses/abstains; waiting for Magnus to > figure > out next steps [since 2008-06-03] > = > --end-- > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 1 09:20:12 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AEC828C1AD; Wed, 1 Oct 2008 09:20:12 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B580728C1AD for ; Wed, 1 Oct 2008 09:20:10 -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 YqIaYO6Ulb-7 for ; Wed, 1 Oct 2008 09:20:10 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id C89A03A6A4E for ; Wed, 1 Oct 2008 09:20:09 -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 m91GJrox017115 for ; Wed, 1 Oct 2008 12:19:53 -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 m91GJqUL017105 for ; Wed, 1 Oct 2008 12:19:52 -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 m91GJiEH009913 for ; Wed, 1 Oct 2008 12:19:45 -0400 (EDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 1D72F1114D17 for ; Wed, 1 Oct 2008 12:19:23 -0400 (EDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91GJK5C004197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 09:19:21 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 1 Oct 2008 09:19:18 -0700 To: secdir@mit.edu From: Paul Hoffman X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-avt-dtls-srtp-05@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-avt-dtls-srtp-05.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 proposed an extension to DTLS to handle the keying for SRTP. The protocol seems simple and complete. Unsurprisingly, the Security Considerations section is well-written. I have a bit of concern about section 6 on multi-party RTP. It talks about mixers that encrypt and decrypt, as if this is acceptable. It might be acceptable, but it sounds dangerous from a security standpoint. Also, this section says: A future specification may describe methods for sharing a single key between multiple DTLS-SRTP associations which would allow conferencing systems to avoid the decrypt/reencrypt stage. But there is nothing that says that you MUST NOT / SHOULD NOT use the extension in this document to do that today. I don't know if that is needed, but it stuck out that there was no advice or mandate about this. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 1 10:48:36 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0A83A6C3C; Wed, 1 Oct 2008 10:48:36 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF623A6C3C for ; Wed, 1 Oct 2008 10:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.581 X-Spam-Level: X-Spam-Status: No, score=-4.581 tagged_above=-999 required=5 tests=[AWL=2.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 1Ok0SVvZS6KX for ; Wed, 1 Oct 2008 10:48:34 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 184A03A67B3 for ; Wed, 1 Oct 2008 10:48:33 -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 m91HaSDK011773 for ; Wed, 1 Oct 2008 13:36:28 -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 m91HaQiG011766 for ; Wed, 1 Oct 2008 13:36:27 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m91HaJhc023906 for ; Wed, 1 Oct 2008 13:36:19 -0400 (EDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 66B131187BE1 for ; Wed, 1 Oct 2008 13:35:58 -0400 (EDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91HZsiS010901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Oct 2008 10:35:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 1 Oct 2008 10:35:53 -0700 To: secdir@mit.edu From: Paul Hoffman X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: [secdir] A note on addresses for reviews X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi again. On my last review, I duplicated Sam Hartman's template and changed the addresses. As it turns out, the IETF tools have addresses for each draft, but not if it includes the draft number. That is, "draft-ietf-avt-dtls-srtp-05@tools.ietf.org" fails, but "draft-ietf-avt-dtls-srtp@tools.ietf.org" works. --Paul Hoffman, Director --VPN Consortium _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 1 19:13:13 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1013A6AEC; Wed, 1 Oct 2008 19:13:13 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1364B3A696A for ; Wed, 1 Oct 2008 19:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MANGLED_SHOP=2.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 PQfWG0hKofPF for ; Wed, 1 Oct 2008 19:13:11 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 7ADCF3A6AEC for ; Wed, 1 Oct 2008 19:13:11 -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 m922DRmK024158 for ; Wed, 1 Oct 2008 22:13:27 -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 m922DNlG024135 for ; Wed, 1 Oct 2008 22:13:23 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m922CiT6018840 for ; Wed, 1 Oct 2008 22:12:44 -0400 (EDT) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 69375B73451; Wed, 1 Oct 2008 22:12:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D1FB5AF67A; Thu, 2 Oct 2008 02:12:19 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D0EE1AF65E; Thu, 2 Oct 2008 02:12:18 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id C93D583861D; Wed, 1 Oct 2008 22:12:17 -0400 (EDT) Date: Wed, 1 Oct 2008 22:12:17 -0400 From: "Steven M. Bellovin" To: Sam Hartman Message-ID: <20081001221217.3921b69e@cs.columbia.edu> In-Reply-To: References: <20080929170305.4740f779@cs.columbia.edu> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Tue, 30 Sep 2008 06:44:45 -0400 Sam Hartman wrote: > >>>>> "Steven" == Steven M Bellovin writes: > > Steven> On Mon, 29 Sep 2008 15:20:23 -0400 > Steven> Sam Hartman wrote: > > > >> Section 8 proposes that AH is the mandatory-to-implement > >> security mechanism for this option. Do we still believe that > >> is appropriate given RFC 4301's move away from AH as a > >> mandatory-to-implement service? > > Steven> As discussed way back when, when we'd agreed on what > Steven> became 2401 et seq., the IETF preferred that security > Steven> labels be part of the credential, and hence implicit in > Steven> the security association, rather than being part of the > Steven> IPsec header. Now -- here, the use of IPsec is to protect > Steven> the security label, rather than the data -- but does it > Steven> actually do that in any useful way? If the security > Steven> option is really end-to-end, we don't need it, per the > Steven> above. If it's hop-by-hop -- and it's using a v6 > Steven> hop-by-hop option -- AH doesn't provide useful protection > Steven> unless packets are digitally signed rather than MACed. > > Doesn't that sort of depend on > 1) who the attackers are > 2) who the endpoints of the SA are? I'm not sure what you mean here. I think it's reasonable to postulate an active or semi-active attacker on a nominally-secure link -- think Operation Ivy Bell, or any of a number of CIA attacks on Soviet communications systems described in a new book "Spymaster". Such an attack could record packets and resend them with a different security label; in the absence of digital signatures, this could not be detected until the receiving site, which of course will never see it -- the destination address would be changed, too. > > As far as I can tell AH would be fine for hop-by-hop SAs to protect > packets flowing over a link that cannot be trusted to preserve > integrity between two intermediate systems. > > You could potentially have both an end-to-end SA and a hop-by-hop SA. > That says that you trust intermediate systems less than you do the > endpoints, but somehow you're still trusting them not to disclose > traffic. I'd like to understand the threat model that leads to this > better. "Need to know" -- intermediate systems may be cleared very high, but they have no need to see the packet contents. > > However, I agree with you that the draft is broken. It seems clearly > like it is talking about end-to-end AH, and I agree that doesn't fit > the model well at all without digital signatures. > That's my main point. > > >> As we know, BCP 61 requires a strong mandatory-to-implement > >> security mechanism for Internet protocols. That mechanism > >> needs to be sufficient for use over the open Internet. We have > >> been very reluctant to accept weaker security mechanisms > >> because some standards-track protocol is not intended for use > >> on the open Internet; BCP 61 says we have consensus that is not > >> how we do things. I question whether AH is sufficient as a BCP > >> 61 mandatory-to-implement mechanism. The entire point of this > >> IPV6 option is to limit disclosure of confidential and > >> classified information. In order to meet that security > >> objective on the open Internet, some confidentiality mechanism > >> is required. I strongly recommend that if this TS is published > >> on the standards track,ESP with confidentially be required. > > Steven> I don't agree. The purpose of AH in this spec is to > Steven> protect certain information that's in the clear. (As > Steven> noted, though, I don't think it does it properly.) > Steven> Protection of the underlying data is the business of a > Steven> separate layer or sublayer. > > I made a number of statements and I'd like to explore our > disagreement. I'm assuming that we agree about what BCP 61 is trying > to do: it's trying to require that IETF protocols have adequate > security for the open Internet, because networks will get connected. > I seem to recall you buy into that argument:-) Yes... > > Do you disagree with my assertion that from a overall architecture > view, anyone who implements this mechanism needs confidentiality to > run their packets over the open Internet? Yes. > > If you agree confidentiality is needed somewhere, how do we get > interoperability if we don't mandate a confidentiality mechanism here? It's a different layer. The security label doesn't require confidentiality; it does require integrity. > >> The document requires that if there is a label inside and > >> outside an AH header, that these labels must be the same. Why > >> is this a valid use of a 2119 MUST? What security or > >> interoperability problem results if for example the outer label > >> dominates the inner label? As far as I can tell this > >> requirement gets in the way of tunneling arbitrary IP traffic. > > Steven> It guards against someone tampering with the outer label, > Steven> causing the packet to be misrouted perhaps. > I guess I'm having a hard time seeing why you would have both labels > if they serve the same purpose. However I think I was misreading the > text. I thought the text was intended to apply to IP within IP--for > example an inner label in a ip-in-ip tunnel. If the text is only > intended to apply to two copies of the option at the same IP layer, > then I agree they need to be the same, although I'd also like an > explanation of why you ever do that. > The model is you send a packet over some secure internal networks. It reaches a site boundary, where it's encapsulated -- say, via IPsec. The security label should be preserved. Why? I always get nervous when there are two fields describing the same data; it's too easy to sneak something past if a filter checks one but the end system relies on the other. In this case, it might be the receiving TCP which uses the inner label, but the routers that use the outer label. Of course, thinking more, an encrypted packet can often have a different label, though for traffic analysis protection one still might want an outer label that selected, say, paths that used link encryptors. I think the conclusion is your point: the document needs to be clearer on this point. > > Steven> Note 7.3.1 on > Steven> TCP considerations. (Also note that 7.3.1 disagrees with > Steven> 793 on the treatment of security labels in section 3.6 of > Steven> 793. At the least, this shoudl be noted. > > I had completely missed this. I'll call out the section to the > transport ADs > I should have added: I think the new document is in fact more correct than 793 -- the 793 scheme would permit various forms of high-bandwidth covert channels to be set up. This is an issue that was not nearly that well understood when 793 was written. That said, it is a change to TCP, and needs to be treated as such. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 06:32:30 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453F83A6CD5; Thu, 2 Oct 2008 06:32:30 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C8A3A6CD5 for ; Thu, 2 Oct 2008 06:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=1.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+K8-k6zs4zy for ; Thu, 2 Oct 2008 06:32:27 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A7FC53A69A1 for ; Thu, 2 Oct 2008 06:32:27 -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 m92DWAr8011967 for ; Thu, 2 Oct 2008 09:32:10 -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 m92DW9iM011944 for ; Thu, 2 Oct 2008 09:32:09 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92DVxve024972 for ; Thu, 2 Oct 2008 09:32:00 -0400 (EDT) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 5C8AE10317CA; Thu, 2 Oct 2008 09:31:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D3BB7AF68D; Thu, 2 Oct 2008 13:31:34 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 82852AF650; Thu, 2 Oct 2008 13:31:33 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id F0CDF838770; Thu, 2 Oct 2008 09:31:29 -0400 (EDT) Date: Thu, 2 Oct 2008 09:31:29 -0400 From: "Steven M. Bellovin" To: "Steven M. Bellovin" Message-ID: <20081002093129.5bb80658@cs.columbia.edu> In-Reply-To: <20081001221217.3921b69e@cs.columbia.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Wed, 1 Oct 2008 22:12:17 -0400 "Steven M. Bellovin" wrote: > > Steven> Note 7.3.1 on > > Steven> TCP considerations. (Also note that 7.3.1 disagrees > > Steven> with 793 on the treatment of security labels in section > > Steven> 3.6 of 793. At the least, this shoudl be noted. > > > > I had completely missed this. I'll call out the section to the > > transport ADs > > > I should have added: I think the new document is in fact more correct > than 793 -- the 793 scheme would permit various forms of > high-bandwidth covert channels to be set up. This is an issue that > was not nearly that well understood when 793 was written. That said, > it is a change to TCP, and needs to be treated as such. > Thinking further -- I suspect that the right thing to do here is for someone to write a short, simple draft amending 793 -- it's handling of the security option is simply wrong, independent of this draft. I wonder -- what TCPs actually implement even 793? NetBSD doesn't; I strongly suspect that no BSDs do. Does Solaris? Linux? --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 08:49:40 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5554428C23B; Thu, 2 Oct 2008 08:49:40 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850D928C20B for ; Thu, 2 Oct 2008 08:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.712 X-Spam-Level: X-Spam-Status: No, score=-4.712 tagged_above=-999 required=5 tests=[AWL=1.887, 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 kar8Xy1iuuf0 for ; Thu, 2 Oct 2008 08:49:34 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5D31D3A6AAE for ; Thu, 2 Oct 2008 08:49:33 -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 m92FnqGp027192 for ; Thu, 2 Oct 2008 11:49:53 -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 m92Fnhem027173 for ; Thu, 2 Oct 2008 11:49:43 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92FnTtj012979 for ; Thu, 2 Oct 2008 11:49:29 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id D032F130A9FC for ; Thu, 2 Oct 2008 11:49:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E9A89422F; Thu, 2 Oct 2008 11:49:06 -0400 (EDT) From: Sam Hartman To: "Steven M. Bellovin" References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> Date: Thu, 02 Oct 2008 11:49:06 -0400 In-Reply-To: <20081001221217.3921b69e@cs.columbia.edu> (Steven M. Bellovin's message of "Wed, 1 Oct 2008 22:12:17 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Steven" == Steven M Bellovin writes: >> >> You could potentially have both an end-to-end SA and a >> hop-by-hop SA. That says that you trust intermediate systems >> less than you do the endpoints, but somehow you're still >> trusting them not to disclose traffic. I'd like to understand >> the threat model that leads to this better. Steven> "Need to know" -- intermediate systems may be cleared very Steven> high, but they have no need to see the packet contents. If we were talking about ESP, I think this would apply. I don't see how it applies to integrity protection without confidentiality though. >> Do you disagree with my assertion that from a overall >> architecture view, anyone who implements this mechanism needs >> confidentiality to run their packets over the open Internet? Steven> Yes. OK, I'm not seeing this. Can you give me an example of a system that would use this mechanism over the open internet but not need confidentiality at some layer? The draft asserts that you would need confidentiality protection to run this over the Internet and as best I can tell, the draft authors are correct. >> If you agree confidentiality is needed somewhere, how do we >> get interoperability if we don't mandate a confidentiality >> mechanism here? Steven> It's a different layer. The security label doesn't Steven> require confidentiality; it does require integrity. That's true. However, I'm claiming that to be useful, confidentiality needs to be provided at some layer. If we have two implementations of this spec, one of which uses confidentiality mechanism a and one of which uses confidentiality mechanism b, even though they both implement the mandatory-to-implement security mechanism for this spec, they cannot interoperate in a secure manner. Traditionally, we've fixed that sort of interoperability problem by requiring a specific mechanism at the other layer be mandatory to implement. I don't think the argument that something happens at another layer has been a sufficient reason to avoid interoperability. At least while I was on the IESG, we tended to address this problem by requiring a specific other layer be a mandatory-to-implement layer. Now, if you are saying that there are situations where confidentiality is not needed in the system as a whole, then I'd like to understand those systems. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 09:14:34 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6913A69C4; Thu, 2 Oct 2008 09:14:34 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDC228C102 for ; Thu, 2 Oct 2008 09:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.571 X-Spam-Level: X-Spam-Status: No, score=-4.571 tagged_above=-999 required=5 tests=[AWL=2.029, 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 T-4iSoYJOLR4 for ; Thu, 2 Oct 2008 09:14:32 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A117C3A6A27 for ; Thu, 2 Oct 2008 09:14:32 -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 m92G9Ikb002707 for ; Thu, 2 Oct 2008 12:09:18 -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 m92G91C9002556 for ; Thu, 2 Oct 2008 12:09:01 -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 m92G8svG027909 for ; Thu, 2 Oct 2008 12:08:54 -0400 (EDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id C49CF1101CA5 for ; Thu, 2 Oct 2008 12:08:33 -0400 (EDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KlQj8-00079C-DE; Thu, 02 Oct 2008 12:08:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Date: Thu, 2 Oct 2008 12:08:12 -0400 To: Acee Lindem From: Stephen Kent X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: msec@ietf.org, tsvwg@ietf.org, OSPF List , Ronald Bonica , secdir@mit.edu, Vishwas Manral , rpsec@ietf.org, David Ward , sidr@ietf.org, Ross Callon Subject: Re: [secdir] [OSPF] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org At 11:08 AM -0400 9/30/08, Acee Lindem wrote: >One thing to take into consideration is that the outcome of our KMART >BOF was that nobody deploying networks wanted routing infra-structure >based on a third-part verified certificates. >Thanks, >Acee Acee, The wording you used here "third-part[y] verified certificates" is ambiguous. A cert is validated (or verified) by a relying party, so third-party verification could imply having some entity verify a cert on behalf of a relying party, e.g, what SCVP permits. If, on the other hand, you were referring to cert issuance (not verification), then it is commonly the case that the cert issuer (certification authority) in a PKI is a "third party" in that it is not a participant in a communication between two relying parties. In either case, I don't recall hearing specific comments of the form you mention. Steve _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 12:10:51 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5633A69C4; Thu, 2 Oct 2008 12:10:51 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516763A69C4 for ; Thu, 2 Oct 2008 12:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.758 X-Spam-Level: X-Spam-Status: No, score=-4.758 tagged_above=-999 required=5 tests=[AWL=1.841, 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 L+HyU3DzkwNx for ; Thu, 2 Oct 2008 12:10:49 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 3E9723A67DB for ; Thu, 2 Oct 2008 12:10:49 -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 m92JA40v016737 for ; Thu, 2 Oct 2008 15:10:04 -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 m92JA117016698 for ; Thu, 2 Oct 2008 15:10:01 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92J9sSW006112 for ; Thu, 2 Oct 2008 15:09:54 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id D68081116BF7 for ; Thu, 2 Oct 2008 15:09:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 36767422F; Thu, 2 Oct 2008 15:09:32 -0400 (EDT) From: Sam Hartman To: Joe Touch References: <48E51018.4080308@isi.edu> Date: Thu, 02 Oct 2008 15:09:32 -0400 In-Reply-To: <48E51018.4080308@isi.edu> (Joe Touch's message of "Thu, 02 Oct 2008 11:16:56 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso@tools.ietf.org, secdir@MIT.EDU, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Joe" == Joe Touch writes: Joe> I was wondering about that; it seems inconsistent to have Joe> this document require something that is optional in RFC 4301. I suspect you realize this, but some people following the discussion may not. It's critical to this mechanism that intermediate systems be able to read the sensitivity level. You can either do hop-by-hop SAs using either ESP-null or AH, or end-to-end SAs using AH or ESP/null plus one of the fixes so you can determine that a packet is ESP-null rather than ESP-encrypted. Note that if you are talking about end-to-end SAs you need to either explain why the intermediate systems don't need to be able to confirm the integrity of the label, or you need to address Steve Bellovin's concerns. --Sam _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 12:31:54 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E457328C26D; Thu, 2 Oct 2008 12:31:54 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6773828C25C for ; Thu, 2 Oct 2008 12:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.800, 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 hvkApjtW3K4F for ; Thu, 2 Oct 2008 12:31:51 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 9699F28C275 for ; Thu, 2 Oct 2008 12:31:12 -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 m92JV1gM025627 for ; Thu, 2 Oct 2008 15:31:01 -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 m92JUxRA025579 for ; Thu, 2 Oct 2008 15:30:59 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92JUo9S024532 for ; Thu, 2 Oct 2008 15:30:50 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id A44391182C8F for ; Thu, 2 Oct 2008 15:30:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 97AE9422F; Thu, 2 Oct 2008 15:30:27 -0400 (EDT) From: Sam Hartman To: Michael StJohns References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <20081002185744.EA1CA3A6AD0@core3.amsl.com> Date: Thu, 02 Oct 2008 15:30:27 -0400 In-Reply-To: <20081002185744.EA1CA3A6AD0@core3.amsl.com> (Michael StJohns's message of "Thu, 02 Oct 2008 14:57:18 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Joe Touch , secdir@MIT.EDU, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Michael" == Michael StJohns writes: Michael> Hi Joe - A quick disclaimer - although I was complicit in Michael> allowing this draft to be resurrected from 1992, I have Michael> had very little to do with it on this cycle. Michael> At 02:18 PM 10/2/2008, Joe Touch wrote: >> First, I don't agree with this document's recommendation in >> section 7.3.1. >> >> TCP's current definition of a connection is: >> >> local IP address remote IP address local port remote port >> protocol (e.g., TCP) >> >> I don't agree that treating each sensitivity level as a >> separate virtual network (Sec 3 of this ID) is the appropriate >> analogy. If that were the case, we'd need to redefine every >> Internet protocol to understand the pair [address, sensitivity >> level] as an identifier, and that is not realistic. Further, if >> we did need to do such an extension, there are other equally >> (or arguably more) worthy candidates, notably VPN-ID. Michael> A single level process at TOP SECRET does a passive open Michael> of the port (call it 666) and waits for connections. A Michael> second single level process at SECRET also attempts to do Michael> a passive open to the same port - but gets blocked Michael> because the port resource is being held by the TOP SECRET Michael> process. The SECRET process now has one bit of Michael> information about the TOP SECRET part of the host. By Michael> grabbing and releasing port resources, the TS process can Michael> signal data to processes at lower security levels. You're proposing a huge complexity increase for the TCP stack in order to get this covert channel protection. Now, I do understand the value of covert channel avoidance in these environments. However, I wonder what other ways have been explored. In particular, this draft focuses on V6. It's easy to create a new address on a V6 link. Have people looked at separating each virtual network interface onto its own address? I think you'd still need label options so that intermediate systems could enforce mandatory access control, but this might allow you to escape doing so much damage to the TCP implementation. If using multiple addresses doesn't work, what other mechanisms have people looked at? Are there other ways to decrease the bandwith of the covert channel to an acceptable level? _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 13:19:31 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852C23A6ACC; Thu, 2 Oct 2008 13:19:31 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DC83A6ACC for ; Thu, 2 Oct 2008 13:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=1.763, 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 597fD+lCg+g5 for ; Thu, 2 Oct 2008 13:19:29 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 56EEB3A6A5D for ; Thu, 2 Oct 2008 13:19:29 -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 m92KJdln008136 for ; Thu, 2 Oct 2008 16:19:39 -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 m92KJbrF008130 for ; Thu, 2 Oct 2008 16:19:37 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92KJ5Ld028188 for ; Thu, 2 Oct 2008 16:19:06 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id 78A76102B546 for ; Thu, 2 Oct 2008 16:18:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8F9AD422F; Thu, 2 Oct 2008 16:18:36 -0400 (EDT) From: Sam Hartman To: Michael StJohns References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <20081002185744.EA1CA3A6AD0@core3.amsl.com> <20081002194921.E2E2F3A69A1@core3.amsl.com> Date: Thu, 02 Oct 2008 16:18:36 -0400 In-Reply-To: <20081002194921.E2E2F3A69A1@core3.amsl.com> (Michael StJohns's message of "Thu, 02 Oct 2008 15:49:38 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso@tools.ietf.org, secdir@mit.edu, ietf@ietf.org, Joe Touch Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Michael" == Michael StJohns writes: Michael> At 03:30 PM 10/2/2008, Sam Hartman wrote: >> You're proposing a huge complexity increase for the TCP stack >> in order to get this covert channel protection. Michael> Hi Sam - Michael> The guys at Honeywell who did the fix for Multics back in Michael> '87 took about 2 days to do the fix. The complexity was Michael> pretty much limited to a single module and a few internal Michael> structures which described the TCP context. Basically Michael> tagging the TCP connection structure with the security Michael> level of the process and changing the matching logic Michael> already in place to do the right thing with respect to Michael> security. I consider that a huge change to what is a fairly public interface. >From an implementation standpoint I expect you will find that is more work on a modern TCP implementation as well. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 13:28:07 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A2128C240; Thu, 2 Oct 2008 13:28:07 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4B728C240 for ; Thu, 2 Oct 2008 13:28: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 9hLYPDkjqsdq for ; Thu, 2 Oct 2008 13:28:05 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id DD3303A6869 for ; Thu, 2 Oct 2008 13:28:04 -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 m92KRj6l010943 for ; Thu, 2 Oct 2008 16:27:45 -0400 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m92KRik1010932 for ; Thu, 2 Oct 2008 16:27:44 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92KRaba015924; Thu, 2 Oct 2008 16:27:37 -0400 (EDT) Received: from morannon (ool-43501d19.dyn.optonline.net [67.80.29.25]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m92KRZ8v008521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Oct 2008 16:27:35 -0400 (EDT) From: "Uri Blumenthal" To: "'Barry Leiba'" , "'Lisa Dusseault'" , References: <623ED7C1-9251-4DB4-B95F-BFEC6EB2ABE1@commerce.net> <362BD00981F367CEDD5CF81C@Uranus-009002042072.watson.ibm.com> Date: Thu, 2 Oct 2008 16:27:35 -0400 Organization: Massachusetts Institute of Technology Message-ID: <4BE5ADF4FAA04CFCA3ED1FC8103515F3@morannon> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <362BD00981F367CEDD5CF81C@Uranus-009002042072.watson.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AckjENzwHMRmRXyVTQGE8MRAFjLvzgBnyuUQ X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: 'Anthony Bryan' Subject: Re: [secdir] Digital signature advice and review for content delivery application X-BeenThere: secdir@ietf.org Reply-To: uri@MIT.EDU List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org In agreement with Barry, and emphasizing some points. This document seems unclear, leaving some serious qustions unanswered. For example, since it deals with XML documents - why not just use straight XML-DSig standard (which allows signing the entire document OR a part of it)? Allowing pgp for signature is good - but limiting to ONLY pgp is bad. I agree with Barry that adding requirement for RSA suport is good - but encouraging violating XML-DSig and dropping DSA support doesn't look smart to me. Etc. etc. In short: IMHO digital signature approach in this document is not satisfactory. -----Original Message----- From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Tuesday, September 30, 2008 11:25 To: Lisa Dusseault; secdir@mit.edu Cc: Anthony Bryan Subject: Re: [secdir] Digital signature advice and review for content delivery application > Is there somebody on secdir who could volunteer to review and provide > advice on the digital signature functionality in this proposal? > > http://tools.ietf.org/html/draft-bryan-metalink-03 I've given it a brief reading, and here are my initial thoughts: First, I find quite a bit of the document to be sketchy and unclear. That's certainly because I haven't been involved in any of the discussions, but neither will most future readers of it have been. In particular, the descriptions of the elements don't seem to be adequate. For example: > 4.1.6. The "metalink:pieces" Element > > The "metalink:pieces" element is a Text construct that conveys a > human-readable piece information for a file. > I don't know what "human-readable piece information" is, why it's put there, what anyone will do with it, nor whether there'd be value in any particular format for the information. I also don't know whether there's any corresponding machine-readable piece information. For signatures, in particular: > 4.2.14. The "metalink:signature" Element > > The "metalink:signature" element is a Text construct that conveys a > digital signature for a file described in a Metalink Document. > > metalinkSignature = > element metalink:signature { > attribute type { "pgp" }, > metalinkTextConstruct > } I gather from that that "pgp" is the only signature type supported; that's unfortunate. Are there no other attributes that will be needed in order to support different signature types? Planning that now will help extensibility later. >From section 6: > Producers of Metalinks may have sound reasons for signing and/or > encrypting otherwise-unprotected content. I think this downplays the importance of signing these things; I rather think that signing them should become the norm, not the exceptional case that's only used if there are "sound reasons". > Metalink Processors MUST NOT reject an Metalink Document containing > such a signature because they are not capable of verifying it; they > MUST continue processing and MAY inform the user of their failure to > validate the signature. Ooh. I'd want to know why. This is certainly a MUST that I would violate if I had a system that decided it would only accept metalink documents that were signed. And I can definitely see sound reasons for having such a system. > Other elements in an Metalink Document MUST NOT be signed unless > their definitions explicitly specify such a capability. I don't understand this. What is the scope of a signature on a metalink document, then? I should think it would protect the whole document. Is this trying to say that there must not be embedded signatures inside a signed document? If so, then it should be clearer. If it means something else, I don't understand. > Section 4.4.2 of [REC-xmldsig-core] requires support for DSA > signatures and recommends support for RSA signatures. However, > because of the much greater popularity in the market of RSA versus > DSA Yeh, that's odd. I initially thought it was because of the RSA patent, but that expired in 2000, and the W3C document is from 2002. [shrug] I do think it's reasonable for this document to reverse the requirements for RSA and DSA, as it does. Section 9, Security Considerations, seems inadequate. The base section says, essentially, "you're encouraged to use authenticated HTTP under TLS, and you're encouraged to sign the files you're going to transfer" (but not the metalink documnts). There are perfectly good reasons not to use authenticated HTTP (distributing public documents, for instance), but TLS will often still make sense (to confirm the server's identity), signatures on the metadata are still important (preventing attacks that present spurious documents), and so on. Section 9.2 does address that last point somewhat, but (1) I disagree with the "at best" and "at worst" cases there, and (2) there's no recommendation about what to do. I think the severity of potential attacks is greater than what's presented here. I see no reason there shouldn't be a SHOULD here for signing the metalink document, and that would address the broader spoofing issue. Section 9.3 says they "can" be signed, but makes no recommendation. Those are comments from an first look. Barry Leiba IAB member, and DKIM working group chair _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 18:07:16 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F338F28C172; Thu, 2 Oct 2008 18:07:15 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEFA528C113 for ; Thu, 2 Oct 2008 18:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.77 X-Spam-Level: X-Spam-Status: No, score=-5.77 tagged_above=-999 required=5 tests=[AWL=0.829, 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 EPxEcteGSDPz for ; Thu, 2 Oct 2008 18:07:14 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id B763A28C107 for ; Thu, 2 Oct 2008 18:07:14 -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 m9317blu014868 for ; Thu, 2 Oct 2008 21:07:37 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9317Ylr014865 for ; Thu, 2 Oct 2008 21:07:34 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9317Q70025065 for ; Thu, 2 Oct 2008 21:07:26 -0400 (EDT) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 84F75B98050; Thu, 2 Oct 2008 21:07:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 11009AF69D; Fri, 3 Oct 2008 01:07:02 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1ECA7AF687; Fri, 3 Oct 2008 01:07:01 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 02EBD838722; Thu, 2 Oct 2008 21:07:00 -0400 (EDT) Date: Thu, 2 Oct 2008 21:06:59 -0400 From: "Steven M. Bellovin" To: Joe Touch Message-ID: <20081002210659.23e96035@cs.columbia.edu> In-Reply-To: <48E56BC7.4020302@isi.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Michael StJohns , Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Thu, 02 Oct 2008 17:48:07 -0700 Joe Touch wrote: > > The point I'm making is that there seems like there should be a way to > prevent the covert channel without mucking up TCP's definition of what > an endpoint is. I think this belongs elsewhere than either the secdir list or the main IETF list, but I think you're wrong -- there doesn't have to be a way. Certainly, I don't think your suggestion of filtering SYNs will do it. MLS security is a very different creature than regular security. We've seen very little of MLS in the IETF (and for that matter, it's not used all that much even in the DoD world), but there's a lot of literature on the subject. The questions for the IETF are (a) is this TCP issue worth doing at all in the IETF, given the limited market, and (b) if it is, how is it best done? I don't think a WG is needed -- the subject is too narrow -- but I do think we need one or more I-Ds, and probably a mls-tcp mailing list. Clearly, any resulting document will have to pass muster by TSV as well as SEC; probably, that means TCPM and SAAG. It might pay for someone to write an assumptions and threat model I-D first -- to give just one example of what might be discussed in it, should we assume that the OS has any role at all? Given how few operating systems are even MLS-capable these days (let alone evaluated for that purpose), perhaps all of the MLS processing will be done (in the real world) on outboard NICs or IPsec boxes. What is the scope, then, of host MLS processing? --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 18:42:06 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED18228C103; Thu, 2 Oct 2008 18:42:06 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB7C3A68C0 for ; Thu, 2 Oct 2008 18:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.644, 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 pb8u4n1i3iG4 for ; Thu, 2 Oct 2008 18:42:05 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E551228C103 for ; Thu, 2 Oct 2008 18:42:04 -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 m931fV3S023981 for ; Thu, 2 Oct 2008 21:41:31 -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 m931fTQp023975 for ; Thu, 2 Oct 2008 21:41:29 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m931fKiE007738 for ; Thu, 2 Oct 2008 21:41:20 -0400 (EDT) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 2EBB612ADDE1; Thu, 2 Oct 2008 21:40:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D572AAF69D; Fri, 3 Oct 2008 01:40:55 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6BB28AF687; Fri, 3 Oct 2008 01:40:55 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 58C1E838722; Thu, 2 Oct 2008 21:40:54 -0400 (EDT) Date: Thu, 2 Oct 2008 21:40:54 -0400 From: "Steven M. Bellovin" To: Joe Touch Message-ID: <20081002214054.3d99ab22@cs.columbia.edu> In-Reply-To: <48E5712B.8020305@isi.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Michael StJohns , Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Thu, 02 Oct 2008 18:11:07 -0700 Joe Touch wrote: > Steven M. Bellovin wrote: > > On Thu, 02 Oct 2008 17:48:07 -0700 > > Joe Touch wrote: > > > >> The point I'm making is that there seems like there should be a > >> way to prevent the covert channel without mucking up TCP's > >> definition of what an endpoint is. > > > > I think this belongs elsewhere than either the secdir list or the > > main IETF list, > > Agreed; I propose to take this over to TSVWG. It's more general than > just TCP... > Don't forget to include SAAG... --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 2 18:49:15 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E353A6B40; Thu, 2 Oct 2008 18:49:15 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3E23A6B12 for ; Thu, 2 Oct 2008 18:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.527, 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 r6KtQ51rErS0 for ; Thu, 2 Oct 2008 18:49:13 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 2F0E23A6A16 for ; Thu, 2 Oct 2008 18:49:13 -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 m931nTZM026042 for ; Thu, 2 Oct 2008 21:49:29 -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 m931nSlD026014 for ; Thu, 2 Oct 2008 21:49:28 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m931nJvq019020 for ; Thu, 2 Oct 2008 21:49:19 -0400 (EDT) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 502D7117610A; Thu, 2 Oct 2008 21:48:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1904BAF69D; Fri, 3 Oct 2008 01:48:55 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 701C8AF687; Fri, 3 Oct 2008 01:48:54 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 6662C838722; Thu, 2 Oct 2008 21:48:53 -0400 (EDT) Date: Thu, 2 Oct 2008 21:48:53 -0400 From: "Steven M. Bellovin" To: Sam Hartman Message-ID: <20081002214853.208a78ff@cs.columbia.edu> In-Reply-To: References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: rpsec@ietf.org, Ronald Bonica , secdir@mit.edu, sidr@ietf.org, Vishwas Manral , OSPF List , David Ward , Acee Lindem , Ross Callon Subject: Re: [secdir] [OSPF] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Tue, 30 Sep 2008 12:05:28 -0400 Sam Hartman wrote: > It's certainly true that some people in the room spoke out against > certificates. At least some of the reasons given did not actually > inherently apply to certificates as a whole although they did create > some significant constraints for what would not create operational > problems. > Right. There's a big misconception in the world that using certificates inherently requires a massive, complex infrastructure that's best handled by third parties. In reality, using certificates within an enterprise need be no more complex than handing out or accepting passwords. All you need is a simple wrapper around something like OpenSSL. You don't need formal root certificate ceremonies, you don't need court-certified videographers, you don't need high priests waving incense and anointing the certificate-signer machine with a mixture of cow innards and ground-up prime numbers. (That's what OCSP is about: Offal of Cow Sprinkled with Primes....) Whoever hands out address blocks within the company can sign the certificates -- it's that simple. I sometimes refer to this as the difference between "PKI" and "pki" -- for enterprises, you need the latter. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:12:44 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E463A6AD8; Fri, 3 Oct 2008 00:12:44 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75AC93A6359 for ; Thu, 2 Oct 2008 23:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=1.966, 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 Y8wCXzYdw-X9 for ; Thu, 2 Oct 2008 23:50:33 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 665113A68A4 for ; Thu, 2 Oct 2008 23:50:33 -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 m936owLc003826 for ; Fri, 3 Oct 2008 02:51:00 -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 m930meo7011358 for ; Thu, 2 Oct 2008 20:48:40 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m930mWxQ002138 for ; Thu, 2 Oct 2008 20:48:32 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 18D5E12D32A1; Thu, 2 Oct 2008 20:48:31 -0400 (EDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m930m7Rr026705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 17:48:09 -0700 (PDT) Message-ID: <48E56BC7.4020302@isi.edu> Date: Thu, 02 Oct 2008 17:48:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Michael StJohns References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> In-Reply-To: <200810030016.m930GgJM015855@vapor.isi.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Fri, 03 Oct 2008 00:12:44 -0700 Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@mit.edu Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael StJohns wrote: > At 07:01 PM 10/2/2008, Joe Touch wrote: >> ... >>> The fix was to virtualize TCP so that there was a complete set of TCP >>> ports per distinct security domain. >> I agree that this fixes your problem, but what it does is create a new >> naming dimension to the entire Internet, and I don't think that this is >> feasible. > > Naming? Not really. Addressing maybe - but that's - as I said before > - pretty local to only those hosts that implement MLS. In TCP, endpoint names are composed of the 4-tuple (localIP, remoteIP, localPort, remotePort). You'd first need to extend that to include MLS as part of the endpoint name. I'm not sure how this works with IPsec, since transport mode wants to filter on ports, and you now can have only one transport mode association for all MLS levels for a given port. For ICMP to work, you need to care about intermediate devices sending back enough of the IP and TCP header - including the MLS option - to demux the info back to the correct TCP. Since TCP connections are currently defined by the 4-tuple, you also need to extend ICMP processing to send the ICMP payload to the right TCP connection. This means, at least, extending IPsec, TCP (UDP, SCTP, RTP, ...), and ICMP processing on the end host to support your extending notion of an endpoint name. >> Perhaps you'd prefer to black-hole the SYNs at the wrong security level, >> which would still modify 793, but would not create the naming dimension >> problem that concerns me... > > Define "wrong security level" - both the attacker and victim are operating > at their own security levels, its just the resource interactions that lead > to the covert channel. "wrong security level" means that when segment with a SYN set arrives to a TCB set for a given level, the segment's level must match that of the TCB. That's as defined in 793. > Which SYN's - (need an exact filter definition here please) would you > black hole, and how would that solve anything? I'm focusing on the behavior of TCP on the wire (and explained the SYN issue above); there is also the issue of port binding, which is different. The port issue is really an OS problem. IMO, a process at level A that wants to bind to port X might silently return a "sure, you're bound" response if the port is bound to a different process at a different level. The OS should accept the connection only for a specific process, though - i.e., the first one to bind to the port, or the highest one to bind to the port. The point I'm making is that there seems like there should be a way to prevent the covert channel without mucking up TCP's definition of what an endpoint is. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjla8cACgkQE5f5cImnZrtL7QCfcA/xQe1nJa0UaXd6+GNs3m6c KQkAoJIQfEHevT0IDim5iWREuJ+Dui/Y =Fwxy -----END PGP SIGNATURE----- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:12:44 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602DC28C113; Fri, 3 Oct 2008 00:12:44 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B4B3A68A4 for ; Thu, 2 Oct 2008 23:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.592 X-Spam-Level: X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=2.007, 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 M3gb2gc1BDRM for ; Thu, 2 Oct 2008 23:52:57 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id DD5363A6359 for ; Thu, 2 Oct 2008 23:52:56 -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 m936p16R003892 for ; Fri, 3 Oct 2008 02:51:01 -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 m92N1tgK017725 for ; Thu, 2 Oct 2008 19:01:55 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m92N1jBj006582 for ; Thu, 2 Oct 2008 19:01:45 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B32EF1165134; Thu, 2 Oct 2008 19:01:44 -0400 (EDT) Received: from [128.9.176.35] (c1-vpn5.isi.edu [128.9.176.35]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92N11Jk016380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 16:01:05 -0700 (PDT) Message-ID: <48E552AD.2080209@isi.edu> Date: Thu, 02 Oct 2008 16:01:01 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Michael StJohns References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> In-Reply-To: <200810021857.m92IvIYY027621@vapor.isi.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Fri, 03 Oct 2008 00:12:44 -0700 Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@mit.edu Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Mike (et al.), Michael StJohns wrote: > Hi Joe - ... > At 02:18 PM 10/2/2008, Joe Touch wrote: > >> First, I don't agree with this document's recommendation in section 7.3.1. >> >> TCP's current definition of a connection is: >> >> local IP address >> remote IP address >> local port >> remote port >> protocol (e.g., TCP) >> >> I don't agree that treating each sensitivity level as a separate virtual >> network (Sec 3 of this ID) is the appropriate analogy. If that were the >> case, we'd need to redefine every Internet protocol to understand the >> pair [address, sensitivity level] as an identifier, and that is not >> realistic. Further, if we did need to do such an extension, there are >> other equally (or arguably more) worthy candidates, notably VPN-ID. > > The issue isn't so much the network, but how the host views it and > deals with resources that might otherwise be in multiple sensitivity > domains. > > Consider a multi-level host that runs at both SECRET and TOP SECRET. > Consider that it wants to run some protocol to send and receive data > from other hosts, some multi level, some single level SECRET and some > single level TOP SECRET. > > A single level process at TOP SECRET does a passive open of the port > (call it 666) and waits for connections. > A second single level process at SECRET also attempts to do a passive > open to the same port - but gets blocked because the port resource is > being held by the TOP SECRET process. The SECRET process now has one bit > of information about the TOP SECRET part of the host. By grabbing and > releasing port resources, the TS process can signal data to processes at > lower security levels. Understood. However, the lower security process can't know whether it's the TS process doing this or some other reason (port blocked, e.g.); all it knows is that it can't connect at the level it wants on the port it wants. ... > The fix was to virtualize TCP so that there was a complete set of TCP > ports per distinct security domain. I agree that this fixes your problem, but what it does is create a new naming dimension to the entire Internet, and I don't think that this is feasible. Perhaps you'd prefer to black-hole the SYNs at the wrong security level, which would still modify 793, but would not create the naming dimension problem that concerns me... >> I.e., I don't think this needs to update 793 - it needs to redefine the >> Internet architecture in places like 1122, 1123, and 1812, and flow down >> through all protocols they impact to make this sort of change, and I >> don't see a reason to do so solely for this issue. >> >> Overall, I see no reason why 793's current rules aren't sufficient to >> emulate the desirable separation of sensitivity levels without extending >> this to true virtualization. I.e., the current rule (in 793, sec 3.6, >> paraphrased): >> >> - match the levels proposed by both ends of the connection >> where there is a mismatch, terminate the connection >> >> I.e., I don't see how to extend TCP to support concurrent connections >> with matching connection identifiers on different sensitivity levels >> without rearchitecting the entire Internet. AFAICT, it's sufficient to >> allow each TCP connection to have exactly one sensitivity level, as is >> already currently required. > > Not quite the point. If you have a single level process reserving a > TCP port, then the port has sensitivity level of the process. If you > have a multi-level process reserving a port then the port can have > one, some or all of the sensitivity levels of the process. Each > instantiation of a connection does have one and only one sensitivity > level. I understand that this wasn't your point (or goal), but I'm claiming it's the effect of your goal - and that it's untenable. > The changes don't have to happen on the entire internet, just those > hosts and routers that are CIPSO aware AND multi-level. If the host is > CIPSO aware (or for that matter IPSO aware), but not multi-level, it's > just looking for the specific label and doesn't have to deal with the > multiple virtual network cruft. The changes need to happen for all RFCs that are affected by naming - you're adding a dimension to naming by expecting different TCP connections to occur where the only difference is security level. At that point, the same has to happen for ICMP (so PMTUD works for each TCP separately), which means you modify 1122. The same has to happen for user apps, which now need to be able to connect to different sockets for the same socket-pair - which modifies 1123. The same happens for 1812, ... That's the problem. Naming dimension extensions creep into the architecture. Joe >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkjlEGkACgkQE5f5cImnZruKoQCfZ9qnOBIRZTCNzsUWzfB39HdL >> AicAn1kLwAQdQ087x9H32tbdVK26t1Hq >> =8u6k >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlUFMACgkQE5f5cImnZrtk+gCghuu9R1AYnhNaaHZ/72Rfv4WC EVQAoNV2aDQE3gYsl6+T9lWDbcqNbAaL =KKNw -----END PGP SIGNATURE----- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:12:44 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5F228C197; Fri, 3 Oct 2008 00:12:44 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536FF3A69D2 for ; Thu, 2 Oct 2008 23:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=1.533, 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 GdjRjdO6AN67 for ; Thu, 2 Oct 2008 23:58:07 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 0720F3A69D6 for ; Thu, 2 Oct 2008 23:58:06 -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 m936p199003880 for ; Fri, 3 Oct 2008 02:51:01 -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 m92JdOej028143 for ; Thu, 2 Oct 2008 15:39:24 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m92JdBWt009907 for ; Thu, 2 Oct 2008 15:39:11 -0400 (EDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by mit.edu (Spam Firewall) with ESMTP id 3AADB10451EA; Thu, 2 Oct 2008 15:38:46 -0400 (EDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m92JcXk4003122; Thu, 2 Oct 2008 12:38:33 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 12:38:32 -0700 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 12:38:32 -0700 Message-Id: <23642C75-0F61-4EFE-B35D-AABD6A73FBE0@windriver.com> From: David Borman To: Michael StJohns In-Reply-To: <20081002185744.EA1CA3A6AD0@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 2 Oct 2008 14:38:30 -0500 References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <20081002185744.EA1CA3A6AD0@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 02 Oct 2008 19:38:32.0764 (UTC) FILETIME=[74277FC0:01C924C6] X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Fri, 03 Oct 2008 00:12:44 -0700 Cc: draft-stjohns-sipso-05@tools.ietf.org, ietf@ietf.org, Joe Touch , secdir@mit.edu, Sam Hartman Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I totally agree with Mike. If you've never dealt with a multi-level security (MLS) system, let's just say they are non-trivial, and this issue with TCP ports is only one part of the overall system. Just the act of labeling the IP packets effectively creates multiple virtual networks, and the place where they clash is in the MLS host. As Mike said, those that aren't MLS aware don't have to do anything different. But explicitly calling this out for MLS hosts, as this draft does, seems to me to be perfectly reasonable. -David Borman On Oct 2, 2008, at 1:57 PM, Michael StJohns wrote: > Hi Joe - > > A quick disclaimer - although I was complicit in allowing this draft > to be resurrected from 1992, I have had very little to do with it on > this cycle. > > > At 02:18 PM 10/2/2008, Joe Touch wrote: > >> First, I don't agree with this document's recommendation in section >> 7.3.1. >> >> TCP's current definition of a connection is: >> >> local IP address >> remote IP address >> local port >> remote port >> protocol (e.g., TCP) >> >> I don't agree that treating each sensitivity level as a separate >> virtual >> network (Sec 3 of this ID) is the appropriate analogy. If that were >> the >> case, we'd need to redefine every Internet protocol to understand the >> pair [address, sensitivity level] as an identifier, and that is not >> realistic. Further, if we did need to do such an extension, there are >> other equally (or arguably more) worthy candidates, notably VPN-ID. > > The issue isn't so much the network, but how the host views it and > deals with resources that might otherwise be in multiple sensitivity > domains. > > Consider a multi-level host that runs at both SECRET and TOP > SECRET. Consider that it wants to run some protocol to send and > receive data from other hosts, some multi level, some single level > SECRET and some single level TOP SECRET. > > A single level process at TOP SECRET does a passive open of the port > (call it 666) and waits for connections. > A second single level process at SECRET also attempts to do a > passive open to the same port - but gets blocked because the port > resource is being held by the TOP SECRET process. The SECRET > process now has one bit of information about the TOP SECRET part of > the host. By grabbing and releasing port resources, the TS process > can signal data to processes at lower security levels. > > In 1987 I used a rough analog of the old 1822 protocol using TCP > ports to build a fairly fast covert channel between two processes at > different security levels on the same host. > > The fix was to virtualize TCP so that there was a complete set of > TCP ports per distinct security domain. > > You could try doing this by writing the processes as multi-level, > but that means you can't use off the shelf code for things like a > mail server that only wants to handle mail of a specific security > level. > > Mostly, this only applies to protocols just above IP which have > distinguishable host resources. In other words, TCP, UDP and their > ilk. > > > >> I.e., I don't think this needs to update 793 - it needs to redefine >> the >> Internet architecture in places like 1122, 1123, and 1812, and flow >> down >> through all protocols they impact to make this sort of change, and I >> don't see a reason to do so solely for this issue. >> >> Overall, I see no reason why 793's current rules aren't sufficient to >> emulate the desirable separation of sensitivity levels without >> extending >> this to true virtualization. I.e., the current rule (in 793, sec 3.6, >> paraphrased): >> >> - match the levels proposed by both ends of the connection >> where there is a mismatch, terminate the connection >> >> I.e., I don't see how to extend TCP to support concurrent connections >> with matching connection identifiers on different sensitivity levels >> without rearchitecting the entire Internet. AFAICT, it's sufficient >> to >> allow each TCP connection to have exactly one sensitivity level, as >> is >> already currently required. > > Not quite the point. If you have a single level process reserving a > TCP port, then the port has sensitivity level of the process. If > you have a multi-level process reserving a port then the port can > have one, some or all of the sensitivity levels of the process. > Each instantiation of a connection does have one and only one > sensitivity level. > > The changes don't have to happen on the entire internet, just those > hosts and routers that are CIPSO aware AND multi-level. If the host > is CIPSO aware (or for that matter IPSO aware), but not multi-level, > it's just looking for the specific label and doesn't have to deal > with the multiple virtual network cruft. > > >> Joe >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkjlEGkACgkQE5f5cImnZruKoQCfZ9qnOBIRZTCNzsUWzfB39HdL >> AicAn1kLwAQdQ087x9H32tbdVK26t1Hq >> =8u6k >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:12:44 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7641628C1C8; Fri, 3 Oct 2008 00:12:44 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6F73A6AAC for ; Fri, 3 Oct 2008 00:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.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 Si1Z2Slvl8L0 for ; Fri, 3 Oct 2008 00:03:17 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D199E3A686A for ; Fri, 3 Oct 2008 00:03:16 -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 m936p1u8003863 for ; Fri, 3 Oct 2008 02:51:01 -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 m92ILAjm024921 for ; Thu, 2 Oct 2008 14:21:10 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92IL1vi009582 for ; Thu, 2 Oct 2008 14:21:01 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id EC5CFB85FDA; Thu, 2 Oct 2008 14:18:13 -0400 (EDT) Received: from [75.215.151.23] (23.sub-75-215-151.myvzw.com [75.215.151.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92IGud4013368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 11:17:00 -0700 (PDT) Message-ID: <48E51018.4080308@isi.edu> Date: Thu, 02 Oct 2008 11:16:56 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Fri, 03 Oct 2008 00:12:44 -0700 Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Sam, Sam Hartman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > ... > Section 8 proposes that AH is the mandatory-to-implement security > mechanism for this option. Do we still believe that is > appropriate given RFC 4301's move away from AH as a > mandatory-to-implement service? I was wondering about that; it seems inconsistent to have this document require something that is optional in RFC 4301. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlBj0ACgkQE5f5cImnZrt/3gCdH5b4r0ClHZYPrIrHoWO4znVT Kk4AnReHumU/rH+cxvA/+7gTdpNxncgK =/GpO -----END PGP SIGNATURE----- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:12:51 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89EDF3A6AEB; Fri, 3 Oct 2008 00:12:51 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076693A6AD6 for ; Fri, 3 Oct 2008 00:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.692 X-Spam-Level: X-Spam-Status: No, score=-7.692 tagged_above=-999 required=5 tests=[AWL=-1.093, 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 8wamnpZn6dny for ; Fri, 3 Oct 2008 00:11:37 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 58F753A6AD8 for ; Fri, 3 Oct 2008 00:10:17 -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 m936p1F6003856 for ; Fri, 3 Oct 2008 02:51:01 -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 m92F5HiN011827 for ; Thu, 2 Oct 2008 11:05:20 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m92F59Cs008864 for ; Thu, 2 Oct 2008 11:05:09 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id D830AB8967B for ; Thu, 2 Oct 2008 11:04:42 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39ADA3A67E4; Thu, 2 Oct 2008 08:04:15 -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 82A003A6B83 for ; Tue, 30 Sep 2008 07:53:06 -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 Y4NSFCyAJZXH for ; Tue, 30 Sep 2008 07:53:05 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 84DFF3A6B73 for ; Tue, 30 Sep 2008 07:53:05 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KkgbG-0008PC-PN for public-new-work-dist@listhub.w3.org; Tue, 30 Sep 2008 14:53:18 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KkgbF-0008Nf-JH for public-new-work@listhub.w3.org; Tue, 30 Sep 2008 14:53:17 +0000 Received: from ssh.w3.org ([128.30.52.60] helo=homer.w3.org) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Kkgb6-0000YZ-OS; Tue, 30 Sep 2008 14:53:17 +0000 Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 0489F4F32E; Tue, 30 Sep 2008 10:52:42 -0400 (EDT) From: "Ian B. Jacobs" To: public-new-work@w3.org Organization: W3C Date: Tue, 30 Sep 2008 14:51:53 +0000 Message-Id: <1222786313.3933.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 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 1Kkgb6-0000YZ-OS c7bf9af37e08fd61bf9b3553c495aa06 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/28 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Tue, 30 Sep 2008 14:53:18 +0000 X-Mailman-Approved-At: Thu, 02 Oct 2008 08:04:14 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from base64 to 8bit by pch.mit.edu id m92F5HiN011827 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Fri, 03 Oct 2008 00:12:51 -0700 Subject: [secdir] [New-work] W3C Workshop on Security for Access to Device APIs from the Web X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org CkhlbGxvLAoKSSBhbSBwbGVhc2VkIHRvIGFubm91bmNlIHRoZToKCiAgVzNDIFdvcmtzaG9wIG9u IFNlY3VyaXR5IGZvciBBY2Nlc3MgdG8gRGV2aWNlIEFQSXMgZnJvbSB0aGUgV2ViCiAgMTAtMTEg RGVjZW1iZXIgMjAwOCBpbiBMb25kb24sIFVLCiAgSG9zdGVkIGJ5IFZvZGFmb25lCgogIENhbGwg Zm9yIFBhcnRpY2lwYXRpb246IAogIGh0dHA6Ly93d3cudzMub3JnLzIwMDgvc2VjdXJpdHktd3Mv CgpUaGUgZ29hbCBvZiB0aGlzIHdvcmtzaG9wIGlzIHRvIGJyaW5nIHRvZ2V0aGVyIHBlb3BsZSBm cm9tIGEgd2lkZQp2YXJpZXR5IG9mIGJhY2tncm91bmRzIChBUEkgZGVzaWduZXJzLCBzZWN1cml0 eSBleHBlcnRzLCB1c2FiaWxpdHkKZXhwZXJ0cywgLi4uKSB0byBkaXNjdXNzIHRoZSBzZWN1cml0 eSBjaGFsbGVuZ2VzIGludm9sdmVkIGluIGFsbG93aW5nCldlYiBhcHBsaWNhdGlvbnMgYW5kIHdp Z2V0cyB0byBhY2Nlc3MgdGhlIEFQSXMgdGhhdCBhbGxvdyB0byBjb250cm9sCnRoZXNlIGZlYXR1 cmVzLCBhbmQgdG8gYWR2aXNlIHRoZSBXM0Mgb24gYXBwcm9wcmlhdGUgbmV4dCBzdGVwcyBmb3Ig YW55CmdhcCB0aGF0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCB3aXRoIG5ldyB0ZWNobmljYWwgd29y ay4KClRoZSBXb3Jrc2hvcCBpcyBiZWluZyBjaGFpcmVkIGJ5IE5pY2sgQWxsb3QgKE9NVFApLCBh bmQgVGhvbWFzIFJvZXNzbGVyCihXM0MpLiBJZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gc2Vydmlu ZyBvbiB0aGUgUHJvZ3JhbSBDb21taXR0ZWUsIHBsZWFzZQpjb250YWN0IERvbWluaXF1ZSBIYXph w6tsLU1hc3NpZXV4IDxkb21AdzMub3JnPi4KCgo9PT09PT09PT09PT09PT0KSW1wb3J0YW50IERh dGVzCj09PT09PT09PT09PT09PQoKIDMwIFNlcHRlbWJlcjogICBDYWxsIGZvciBQYXJ0aWNpcGF0 aW9uIGlzc3VlZAogMzAgT2N0b2JlcjogICAgIERlYWRsaW5lIGZvciBwb3NpdGlvbiBwYXBlcnMg CiAxNyBOb3ZlbWJlcjogICAgQWNjZXB0YW5jZSBub3RpZmljYXRpb24gc2VudAogMjAgTm92ZW1i ZXI6ICAgIFByb2dyYW0gcmVsZWFzZWQKIDI1IE5vdmVtYmVyOiAgICBEZWFkbGluZSBmb3IgUmVn aXN0cmF0aW9uCiAxMC0xMSBEZWNlbWJlcjogV29ya3Nob3AgCgpSZWdpc3RyYXRpb24gZGV0YWls cyBhbmQgaW5mb3JtYXRpb24gYWJvdXQgZXhwZWN0ZWQgYXVkaWVuY2UgYXJlCmluIHRoZSBDYWxs IGZvciBQYXJ0aWNpcGF0aW9uLiBQbGVhc2Ugbm90ZSB0aGF0OgoKIC0gQXR0ZW5kYW5jZSBpcyBv cGVuIHRvIGV2ZXJ5b25lLCBpbmNsdWRpbmcgbm9uLVczQyBNZW1iZXJzLCBidXQKICAgZWFjaCBv cmdhbml6YXRpb24gb3IgaW5kaXZpZHVhbCB3aXNoaW5nIHRvIHBhcnRpY2lwYXRlIG11c3Qgc3Vi bWl0CiAgIGEgcG9zaXRpb24gcGFwZXIuCiAtIFRvIGVuc3VyZSBtYXhpbXVtIGRpdmVyc2l0eSBh bW9uZyBwYXJ0aWNpcGFudHMsIGEgbGltaXQgbWF5IGJlCiAgIGltcG9zZWQgb24gdGhlIG1heGlt dW0gbnVtYmVyIG9mIHBhcnRpY2lwYW50cyBwZXIgb3JnYW5pemF0aW9uLgogLSBUaGVyZSBpcyBu byByZWdpc3RyYXRpb24gZmVlLgoKPT09PT09PT09PT09PT09PT09PT09ClNjb3BlIG9mIHRoZSBX b3Jrc2hvcAo9PT09PT09PT09PT09PT09PT09PT0KClRoZSBXb3Jrc2hvcCB3aWxsIGZvY3VzIG9u IHRoZXNlIGFyZWFzOgoKICAqIEV4aXN0aW5nIGZyYW1ld29ya3Mgb24gZGVza3RvcCBhbmQgbW9i aWxlIHBsYXRmb3JtcyB0byByZWd1bGF0ZQpzZWN1cml0eSBwb2xpY2llcyBmb3Igc3BlY2lmaWMg QVBJcywKICAgICAgKiBTaW1pbGFyaXRpZXMgYW5kIGRpZmZlcmVuY2VzIG9mIHRoZSBzZWN1cml0 eSBhcHByb2FjaGVzIGluCiAgICAgICAgZGVza3RvcCBhbmQgbW9iaWxlIHBsYXRmb3JtcywgaW4g YSBicm93c2VyIGFuZCBpbiBhIHdpZGdldHMKICAgICAgICBlbnZpcm9ubWVudCwKICAgICAgKiBV c2FiaWxpdHkgb2Ygc2VjdXJpdHkgcmVsZXZhbnQgdXNlciBpbnRlcmFjdGlvbnM7IGlzc3VlcyBh bmQKICAgICAgICBvcHBvcnR1bml0aWVzIGluIHRoZSBtb2JpbGUgZW52aXJvbm1lbnQsCiAgICAg ICogU2FmZSBsYW5ndWFnZSBhbmQgQVBJIHN1YnNldHMsIGFuZCBtb2RlbHMgZm9yIGFwcGxpY2F0 aW9uIHVzZSBvZgogICAgICAgIHN1Y2ggc3Vic2V0cywKICAgICAgKiBQb2xpY3kgYmFzZWQgdHJ1 c3QgZGVsZWdhdGlvbiBtZWNoYW5pc21zLAogICAgICAqIFJlZHVjaW5nIHRoZSBhdHRhY2sgc3Vy ZmFjZSBleHBvc2VkIGJ5IFdlYiBwYWdlIHNjcmlwdHMKICAgICAgKiBSb2xlIG9mIGF1dGhlbnRp Y2F0aW9uIG9mIHVzZXJzIGFuZCBhcHBsaWNhdGlvbnMgaW4gc2VjdXJpbmcgQVBJCiAgICAgICAg YWNjZXNzLAogICAgICAqIEluY3JlYXNpbmcgYXdhcmVuZXNzIG9mIGdvb2Qgc2VjdXJpdHkgcHJh Y3RpY2VzIGZvciBXZWIKICAgICAgICBhcHBsaWNhdGlvbnMsCiAgICAgICogVXNhYmlsaXR5IG9m IHNlY3VyaXR5IGFuZCBwcml2YWN5IHBvbGljaWVzLAoKV2UgZXhwZWN0IHRoZSBkaXNjdXNzaW9u cyBhdCB0aGlzIHdvcmtzaG9wIHRvIGJlIHJlbGV2YW50IHRvIHRoZQpmb2xsb3dpbmcgV29ya2lu ZyBHcm91cHM6CgogICAgICAqIFdlYiBBcHBsaWNhdGlvbnMgV29ya2luZyBHcm91cAogICAgICAq IEdlb2xvY2F0aW9uIFdvcmtpbmcgR3JvdXAKICAgICAgKiBVYmlxdWl0b3VzIFdlYiBBcHBsaWNh dGlvbnMgV29ya2luZyBHcm91cAogICAgICAqIEhUTUwgV29ya2luZyBHcm91cAogICAgICAqIFdl YiBTZWN1cml0eSBDb250ZXh0IFdvcmtpbmcgR3JvdXAKLS0gCklhbiBKYWNvYnMgKGlqQHczLm9y ZykgICBodHRwOi8vd3d3LnczLm9yZy9QZW9wbGUvSmFjb2JzLwpUZWw6ICAgICAgICAgICAgICAg ICAgICAgKzEgNzE4IDI2MC05NDQ3CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KTmV3LXdvcmsgbWFpbGluZyBsaXN0Ck5ldy13b3JrQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnNlY2RpciBtYWlsaW5nIGxpc3QK c2VjZGlyQG1pdC5lZHUKaHR0cHM6Ly9tYWlsbWFuLm1pdC5lZHUvbWFpbG1hbi9saXN0aW5mby9z ZWNkaXIKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2Vj ZGlyIG1haWxpbmcgbGlzdApzZWNkaXJAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZWNkaXIK From secdir-bounces@ietf.org Fri Oct 3 00:13:49 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF893A69D8; Fri, 3 Oct 2008 00:13:49 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2F13A686A for ; Fri, 3 Oct 2008 00:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=1.850, 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 Q8sRTBIwD+PQ for ; Fri, 3 Oct 2008 00:13:48 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D086C3A69D8 for ; Fri, 3 Oct 2008 00:13:47 -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 m936p1pO003897 for ; Fri, 3 Oct 2008 02:51:01 -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 m931C4BF015776 for ; Thu, 2 Oct 2008 21:12:04 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m931BsRR029573 for ; Thu, 2 Oct 2008 21:11:54 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3EFA51113E60; Thu, 2 Oct 2008 21:11:54 -0400 (EDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m931B8XV003698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 18:11:10 -0700 (PDT) Message-ID: <48E5712B.8020305@isi.edu> Date: Thu, 02 Oct 2008 18:11:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Steven M. Bellovin" References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> In-Reply-To: <20081002210659.23e96035@cs.columbia.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Michael StJohns , Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Thu, 02 Oct 2008 17:48:07 -0700 > Joe Touch wrote: > >> The point I'm making is that there seems like there should be a way to >> prevent the covert channel without mucking up TCP's definition of what >> an endpoint is. > > I think this belongs elsewhere than either the secdir list or the main > IETF list, Agreed; I propose to take this over to TSVWG. It's more general than just TCP... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlcSsACgkQE5f5cImnZrtQJgCfVlcoaA/2rMVhxwWGq5EPDfbP 1F4An25RwJZZRHqcvsUcmzI4CrXG5fQW =4qBz -----END PGP SIGNATURE----- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:17:25 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61013A6AAC; Fri, 3 Oct 2008 00:17:25 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4633A6AF4 for ; Fri, 3 Oct 2008 00:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.743 X-Spam-Level: X-Spam-Status: No, score=-3.743 tagged_above=-999 required=5 tests=[AWL=2.856, 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 n9S6SE4ve0Vk for ; Fri, 3 Oct 2008 00:13:51 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 043AF3A6AD7 for ; Fri, 3 Oct 2008 00:13:50 -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 m936p1nC003887 for ; Fri, 3 Oct 2008 02:51:01 -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 m92KOSiN009742 for ; Thu, 2 Oct 2008 16:24:28 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m92KOM2B010522 for ; Thu, 2 Oct 2008 16:24:22 -0400 (EDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mit.edu (Spam Firewall) with ESMTP id 508E9B91702 for ; Thu, 2 Oct 2008 16:23:16 -0400 (EDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA09.westchester.pa.mail.comcast.net with comcast id MvR71a00H0SCNGk59wPE09; Thu, 02 Oct 2008 20:23:14 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA09.westchester.pa.mail.comcast.net with comcast id MwPE1a0032P9w053VwPEe3; Thu, 02 Oct 2008 20:23:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=eBNOf6ryCRIA:10 a=fKVHrc5Tc7QA:10 a=IBPUgPSuw9BOl9gC7kgA:9 a=dULODV96v9Ic4gbU9WPC8GvhBEkA:4 a=oqs56FR1YJwA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Oct 2008 16:23:15 -0400 To: Sam Hartman From: Michael StJohns In-Reply-To: <7.1.0.9.2.20081002154130.04054df0@comcast.net> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <20081002185744.EA1CA3A6AD0@core3.amsl.com> <7.1.0.9.2.20081002154130.04054df0@comcast.net> Mime-Version: 1.0 Message-Id: <20081002202316.508E9B91702@mit.edu> X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Fri, 03 Oct 2008 00:17:25 -0700 Cc: secdir@mit.edu, draft-stjohns-sipso-05@tools.ietf.org, Joe Touch , ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Sorry - for both of these - the date was '83, not '87.... Mike At 03:49 PM 10/2/2008, Michael StJohns wrote: >At 03:30 PM 10/2/2008, Sam Hartman wrote: >>You're proposing a huge complexity increase for the TCP stack in order >>to get this covert channel protection. > >Hi Sam - > >The guys at Honeywell who did the fix for Multics back in '87 took about 2 days to do the fix. The complexity was pretty much limited to a single module and a few internal structures which described the TCP context. Basically tagging the TCP connection structure with the security level of the process and changing the matching logic already in place to do the right thing with respect to security. > >Note that this treatment of multiple networks only has to happen on hosts which are multi-level. And the multi-level stuff is already a bit of cruft and complexity. This just gets thrown in to the other stuff you have to do to have a secure multi-level system. > >For your suggestions with multiple addresses... its possible, but all you're doing is moving the complexity from implementation (where you do it once and test the hell out of it) to administration (where you have to do it for each system and hope you get it right). I know what I'd choose... :-) > >Mike _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:19:37 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013533A6A9E; Fri, 3 Oct 2008 00:19:37 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2913A685F for ; Fri, 3 Oct 2008 00:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.753 X-Spam-Level: X-Spam-Status: No, score=-4.753 tagged_above=-999 required=5 tests=[AWL=1.846, 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 EMrdjqh-55ky for ; Fri, 3 Oct 2008 00:19:35 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 601933A6AAC for ; Fri, 3 Oct 2008 00:19:35 -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 m936oxnh003828 for ; Fri, 3 Oct 2008 02:51:00 -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 m92IK2to024269 for ; Thu, 2 Oct 2008 14:20:02 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m92IJpVk024602 for ; Thu, 2 Oct 2008 14:19:51 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 0DD9E1181A8F; Thu, 2 Oct 2008 14:19:50 -0400 (EDT) Received: from [75.215.151.23] (23.sub-75-215-151.myvzw.com [75.215.151.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92IIHgC013898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 11:18:21 -0700 (PDT) Message-ID: <48E51069.1040403@isi.edu> Date: Thu, 02 Oct 2008 11:18:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Steven M. Bellovin" References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> In-Reply-To: <20081002093129.5bb80658@cs.columbia.edu> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Wed, 1 Oct 2008 22:12:17 -0400 > "Steven M. Bellovin" wrote: > >>> Steven> Note 7.3.1 on >>> Steven> TCP considerations. (Also note that 7.3.1 disagrees >>> Steven> with 793 on the treatment of security labels in section >>> Steven> 3.6 of 793. At the least, this shoudl be noted. >>> >>> I had completely missed this. I'll call out the section to the >>> transport ADs >>> >> I should have added: I think the new document is in fact more correct >> than 793 -- the 793 scheme would permit various forms of >> high-bandwidth covert channels to be set up. This is an issue that >> was not nearly that well understood when 793 was written. That said, >> it is a change to TCP, and needs to be treated as such. >> > Thinking further -- I suspect that the right thing to do here is for > someone to write a short, simple draft amending 793 -- it's handling of > the security option is simply wrong, independent of this draft. I > wonder -- what TCPs actually implement even 793? NetBSD doesn't; I > strongly suspect that no BSDs do. Does Solaris? Linux? First, I don't agree with this document's recommendation in section 7.3.1. TCP's current definition of a connection is: local IP address remote IP address local port remote port protocol (e.g., TCP) I don't agree that treating each sensitivity level as a separate virtual network (Sec 3 of this ID) is the appropriate analogy. If that were the case, we'd need to redefine every Internet protocol to understand the pair [address, sensitivity level] as an identifier, and that is not realistic. Further, if we did need to do such an extension, there are other equally (or arguably more) worthy candidates, notably VPN-ID. I.e., I don't think this needs to update 793 - it needs to redefine the Internet architecture in places like 1122, 1123, and 1812, and flow down through all protocols they impact to make this sort of change, and I don't see a reason to do so solely for this issue. Overall, I see no reason why 793's current rules aren't sufficient to emulate the desirable separation of sensitivity levels without extending this to true virtualization. I.e., the current rule (in 793, sec 3.6, paraphrased): - match the levels proposed by both ends of the connection where there is a mismatch, terminate the connection I.e., I don't see how to extend TCP to support concurrent connections with matching connection identifiers on different sensitivity levels without rearchitecting the entire Internet. AFAICT, it's sufficient to allow each TCP connection to have exactly one sensitivity level, as is already currently required. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlEGkACgkQE5f5cImnZruKoQCfZ9qnOBIRZTCNzsUWzfB39HdL AicAn1kLwAQdQ087x9H32tbdVK26t1Hq =8u6k -----END PGP SIGNATURE----- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:28:09 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25ED3A6AF2; Fri, 3 Oct 2008 00:28:08 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CF73A6AE9 for ; Fri, 3 Oct 2008 00:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.963 X-Spam-Level: X-Spam-Status: No, score=-3.963 tagged_above=-999 required=5 tests=[AWL=2.636, 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 nftNDh8hr5Ir for ; Fri, 3 Oct 2008 00:28:07 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id B74843A6AF2 for ; Fri, 3 Oct 2008 00:28:06 -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 m936p1ss003872 for ; Fri, 3 Oct 2008 02:51:01 -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 m92Ivp03011148 for ; Thu, 2 Oct 2008 14:57:51 -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 m92Ivgaq006899 for ; Thu, 2 Oct 2008 14:57:42 -0400 (EDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mit.edu (Spam Firewall) with ESMTP id 88C531116870 for ; Thu, 2 Oct 2008 14:57:18 -0400 (EDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA01.westchester.pa.mail.comcast.net with comcast id MraC1a0010xGWP851uxJtq; Thu, 02 Oct 2008 18:57:18 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA12.westchester.pa.mail.comcast.net with comcast id MuxG1a00b2P9w053YuxHqL; Thu, 02 Oct 2008 18:57:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=eBNOf6ryCRIA:10 a=fKVHrc5Tc7QA:10 a=xe8BsctaAAAA:8 a=48vgC7mUAAAA:8 a=-AToH7HKNB6tsKhUq_cA:9 a=_A2SDuBTrXW6BhT9aDEA:7 a=mJeZcg0sHrfRk8YGKyupoThvUXcA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Oct 2008 14:57:18 -0400 To: Joe Touch , "Steven M. Bellovin" From: Michael StJohns In-Reply-To: <48E51069.1040403@isi.edu> References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> Mime-Version: 1.0 Message-Id: <20081002185718.88C531116870@mit.edu> X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Joe - A quick disclaimer - although I was complicit in allowing this draft to be resurrected from 1992, I have had very little to do with it on this cycle. At 02:18 PM 10/2/2008, Joe Touch wrote: >First, I don't agree with this document's recommendation in section 7.3.1. > >TCP's current definition of a connection is: > > local IP address > remote IP address > local port > remote port > protocol (e.g., TCP) > >I don't agree that treating each sensitivity level as a separate virtual >network (Sec 3 of this ID) is the appropriate analogy. If that were the >case, we'd need to redefine every Internet protocol to understand the >pair [address, sensitivity level] as an identifier, and that is not >realistic. Further, if we did need to do such an extension, there are >other equally (or arguably more) worthy candidates, notably VPN-ID. The issue isn't so much the network, but how the host views it and deals with resources that might otherwise be in multiple sensitivity domains. Consider a multi-level host that runs at both SECRET and TOP SECRET. Consider that it wants to run some protocol to send and receive data from other hosts, some multi level, some single level SECRET and some single level TOP SECRET. A single level process at TOP SECRET does a passive open of the port (call it 666) and waits for connections. A second single level process at SECRET also attempts to do a passive open to the same port - but gets blocked because the port resource is being held by the TOP SECRET process. The SECRET process now has one bit of information about the TOP SECRET part of the host. By grabbing and releasing port resources, the TS process can signal data to processes at lower security levels. In 1987 I used a rough analog of the old 1822 protocol using TCP ports to build a fairly fast covert channel between two processes at different security levels on the same host. The fix was to virtualize TCP so that there was a complete set of TCP ports per distinct security domain. You could try doing this by writing the processes as multi-level, but that means you can't use off the shelf code for things like a mail server that only wants to handle mail of a specific security level. Mostly, this only applies to protocols just above IP which have distinguishable host resources. In other words, TCP, UDP and their ilk. >I.e., I don't think this needs to update 793 - it needs to redefine the >Internet architecture in places like 1122, 1123, and 1812, and flow down >through all protocols they impact to make this sort of change, and I >don't see a reason to do so solely for this issue. > >Overall, I see no reason why 793's current rules aren't sufficient to >emulate the desirable separation of sensitivity levels without extending >this to true virtualization. I.e., the current rule (in 793, sec 3.6, >paraphrased): > > - match the levels proposed by both ends of the connection > where there is a mismatch, terminate the connection > >I.e., I don't see how to extend TCP to support concurrent connections >with matching connection identifiers on different sensitivity levels >without rearchitecting the entire Internet. AFAICT, it's sufficient to >allow each TCP connection to have exactly one sensitivity level, as is >already currently required. Not quite the point. If you have a single level process reserving a TCP port, then the port has sensitivity level of the process. If you have a multi-level process reserving a port then the port can have one, some or all of the sensitivity levels of the process. Each instantiation of a connection does have one and only one sensitivity level. The changes don't have to happen on the entire internet, just those hosts and routers that are CIPSO aware AND multi-level. If the host is CIPSO aware (or for that matter IPSO aware), but not multi-level, it's just looking for the specific label and doesn't have to deal with the multiple virtual network cruft. >Joe > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iEYEARECAAYFAkjlEGkACgkQE5f5cImnZruKoQCfZ9qnOBIRZTCNzsUWzfB39HdL >AicAn1kLwAQdQ087x9H32tbdVK26t1Hq >=8u6k >-----END PGP SIGNATURE----- >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:34:49 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598683A6B07; Fri, 3 Oct 2008 00:34:49 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C223A6B07 for ; Fri, 3 Oct 2008 00:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.793 X-Spam-Level: X-Spam-Status: No, score=-4.793 tagged_above=-999 required=5 tests=[AWL=1.807, 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 N0RcIhLMQggy for ; Fri, 3 Oct 2008 00:34:47 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 4C3B13A6B04 for ; Fri, 3 Oct 2008 00:34:47 -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 m936p1Vb003858 for ; Fri, 3 Oct 2008 02:51:01 -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 m92N1E71017574 for ; Thu, 2 Oct 2008 19:01:14 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m92N12v3005821 for ; Thu, 2 Oct 2008 19:01:02 -0400 (EDT) X-ASG-Whitelist: Client Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C905FB87B45; Thu, 2 Oct 2008 19:01:01 -0400 (EDT) Received: from [128.9.176.35] (c1-vpn5.isi.edu [128.9.176.35]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92N0g96016154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 16:00:45 -0700 (PDT) Message-ID: <48E55296.20208@isi.edu> Date: Thu, 02 Oct 2008 16:00:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Sam Hartman References: <48E51018.4080308@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Hartman wrote: >>>>>> "Joe" == Joe Touch writes: > > > Joe> I was wondering about that; it seems inconsistent to have > Joe> this document require something that is optional in RFC 4301. > > I suspect you realize this, but some people following the discussion > may not. It's critical to this mechanism that intermediate systems be > able to read the sensitivity level. You can either do hop-by-hop SAs > using either ESP-null or AH, or end-to-end SAs using AH or ESP/null > plus one of the fixes so you can determine that a packet is ESP-null > rather than ESP-encrypted. Note that if you are talking about > end-to-end SAs you need to either explain why the intermediate systems > don't need to be able to confirm the integrity of the label, or you > need to address Steve Bellovin's concerns. Hi, Sam, Thanks for pointing that out. The issue, AFAICT, is how to achieve the required transparency while relying on (as much as possible) only protocols that are MUSTs, rather than MAYs. Perhaps that's less of an issue for this system, but I would hate to have it depend on IPsec devices that implemented a MAY. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlUNMACgkQE5f5cImnZrtJEgCghWYeCC7flc8lHvjh4r+j963A 3CsAnRAOyGF7jSYVzoGV5h9WMIMQtao+ =pogB -----END PGP SIGNATURE----- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 00:43:02 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B7D3A6A3C; Fri, 3 Oct 2008 00:43:02 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497013A6A3C for ; Fri, 3 Oct 2008 00:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.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 j5SOsnRyVTkt for ; Fri, 3 Oct 2008 00:42:55 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 669C73A6452 for ; Fri, 3 Oct 2008 00:42:55 -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 m9371npj006668 for ; Fri, 3 Oct 2008 03:01:49 -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 m9371lb1006638 for ; Fri, 3 Oct 2008 03:01:47 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9371dxq012947 for ; Fri, 3 Oct 2008 03:01:40 -0400 (EDT) Received: from mail.fit.nokia.com (host-39.nrln.net [212.213.221.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id CFD94117FC9B; Fri, 3 Oct 2008 03:01:18 -0400 (EDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m9370tZU026151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Oct 2008 10:00:56 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: ext Joe Touch In-Reply-To: <48E5712B.8020305@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 3 Oct 2008 10:00:55 +0300 References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <200810021857.m92IvIYY027621@vapor.isi.edu> <48E552AD.2080209@isi.edu> <200810030016.m930GgJM015855@vapor.isi.edu> <48E56BC7.4020302@isi.edu> <20081002210659.23e96035@cs.columbia.edu> <48E5712B.8020305@isi.edu> X-Mailer: Apple Mail (2.929.2) X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Fri, 03 Oct 2008 10:01:00 +0300 (EEST) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: multipart/mixed; boundary="===============0384725310==" Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@mit.edu Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============0384725310== Content-Type: multipart/signed; boundary=Apple-Mail-10--103080453; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-10--103080453 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2008-10-3, at 4:11, ext Joe Touch wrote: > Agreed; I propose to take this over to TSVWG. It's more general than > just TCP... I agree that the intersection of TSVWG and SAAG will probably more or less capture the correct set of folks, let's move the discussion there. I'll send another followup to only those lists, please use that thread as a starting point for the discussion. Thanks, Lars --Apple-Mail-10--103080453 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAwMzA3MDA1NVowIwYJKoZI hvcNAQkEMRYEFMFaMMCyqdkbfGbbSEwZHK801PwrMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQCY+YEsLhqc3yBmgPoGc1fp/5vy AEbQ2lo6LVvCed7vOBSXLOaQ03OK8TJ8CpaRafOvseyoImnd7klzC+FuLBENNFOr0OXNUS1Vd1Sm wmYLdZvG32Dvq+rQUbAcScalVHzJY3kYqLVl+2CR2MA7jWJeXW+7sypwQ7q2pt9X8ypL5iCzJy22 k6Nbpz2jQSkYHvGJAODBI3tc6ObGTdB3YQHaXbpYRCQzmQwTFqJcMWNNQC1wPbEDVJTrAcyyVATz uGOvpdQuUcyBcehMd260KtYgV3OMdfuCy+h5PEIv2a26eRId8Dm0ZJjBoJ5ZzCvt7dEMcRmQo8SO vfuH1boH2KBsAAAAAAAA --Apple-Mail-10--103080453-- --===============0384725310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir --===============0384725310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============0384725310==-- From secdir-bounces@ietf.org Fri Oct 3 00:44:30 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402033A6A9E; Fri, 3 Oct 2008 00:44:30 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215373A6A9E for ; Fri, 3 Oct 2008 00:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.151 X-Spam-Level: X-Spam-Status: No, score=-4.151 tagged_above=-999 required=5 tests=[AWL=2.448, 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 ilsMc2Q1wYMG for ; Fri, 3 Oct 2008 00:44:28 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 4445C3A6A3C for ; Fri, 3 Oct 2008 00:44:28 -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 m936oxuN003830 for ; Fri, 3 Oct 2008 02:51:00 -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 m92Jnm5L031287 for ; Thu, 2 Oct 2008 15:49:48 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92JneFm002881 for ; Thu, 2 Oct 2008 15:49:40 -0400 (EDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mit.edu (Spam Firewall) with ESMTP id 31FB9B6ADC7 for ; Thu, 2 Oct 2008 15:49:38 -0400 (EDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA01.westchester.pa.mail.comcast.net with comcast id MutC1a00B1HzFnQ51vpeHx; Thu, 02 Oct 2008 19:49:38 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA14.westchester.pa.mail.comcast.net with comcast id Mvpd1a00G2P9w053avpdxx; Thu, 02 Oct 2008 19:49:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=eBNOf6ryCRIA:10 a=fKVHrc5Tc7QA:10 a=IBPUgPSuw9BOl9gC7kgA:9 a=d1p8HTUeaIpz2K5hSxPDqABQ_w8A:4 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Oct 2008 15:49:38 -0400 To: Sam Hartman From: Michael StJohns In-Reply-To: References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> <48E51069.1040403@isi.edu> <20081002185744.EA1CA3A6AD0@core3.amsl.com> Mime-Version: 1.0 Message-Id: <20081002194938.31FB9B6ADC7@mit.edu> X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: secdir@mit.edu, draft-stjohns-sipso-05@tools.ietf.org, Joe Touch , ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org At 03:30 PM 10/2/2008, Sam Hartman wrote: >You're proposing a huge complexity increase for the TCP stack in order >to get this covert channel protection. Hi Sam - The guys at Honeywell who did the fix for Multics back in '87 took about 2 days to do the fix. The complexity was pretty much limited to a single module and a few internal structures which described the TCP context. Basically tagging the TCP connection structure with the security level of the process and changing the matching logic already in place to do the right thing with respect to security. Note that this treatment of multiple networks only has to happen on hosts which are multi-level. And the multi-level stuff is already a bit of cruft and complexity. This just gets thrown in to the other stuff you have to do to have a secure multi-level system. For your suggestions with multiple addresses... its possible, but all you're doing is moving the complexity from implementation (where you do it once and test the hell out of it) to administration (where you have to do it for each system and hope you get it right). I know what I'd choose... :-) Mike _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 10:39:18 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3AC3A6B36; Fri, 3 Oct 2008 10:39:18 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFCD28C149 for ; Fri, 3 Oct 2008 10:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=-0.548, 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 bQ9SybcugY-N for ; Fri, 3 Oct 2008 10:39:17 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 3F00028C104 for ; Fri, 3 Oct 2008 10:39:17 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id m93HdjAO056698 for ; Fri, 3 Oct 2008 13:39:45 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id m93Hdjqs056695 for ; Fri, 3 Oct 2008 13:39:45 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 3 Oct 2008 13:39:45 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Fri, 03 Oct 2008 13:39:45 -0400 (EDT) Subject: [secdir] Assignments for October 7th and 10th 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org The secdir list successfully moved to ietf.org. Chris Lonvick is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2008-10-07 Shawn Emery T draft-ietf-avt-rtp-toffset-07 Barry Leiba T draft-bryant-mpls-tp-jwt-report-00 Larry Zhu T draft-ietf-sipping-race-examples-06 Last calls and special requests: Lakshminath Dondeti draft-ietf-enum-combined-08 Lakshminath Dondeti draft-ietf-avt-rfc4749-dtx-update-02 Phillip Hallam-Baker draft-ietf-psamp-info-10 Steve Hanna draft-rescorla-tls-suiteb-07 David Harrington draft-ietf-sip-xcapevent-04 Love Hornquist-Astrand draft-ietf-sip-sips-08 Jeffrey Hutzelman draft-ietf-sip-rph-new-namespaces-03 Charlie Kaufman draft-ietf-sip-hitchhikers-guide-05 Scott Kelly draft-ietf-ccamp-rfc4420bis-03 Stephen Kent draft-ietf-mmusic-sdp-capability-negotiation-09 Tero Kivinen draft-ietf-sip-media-security-requirements-07 Julien Laganier draft-ietf-softwire-mesh-framework-05 Julien Laganier draft-ietf-softwire-encaps-ipsec-01 Julien Laganier draft-ietf-sipping-cc-transfer-10 Marcus Leech draft-ietf-dnsext-forgery-resilience-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-16 Alexey Melnikov draft-ietf-pce-pcep-xro-06 Sandy Murphy draft-ietf-mpls-mpls-and-gmpls-security-framework-03 Carl Wallace R draft-hartman-webauth-phishing-09 Sam Weiler draft-chown-v6ops-rogue-ra-01 Brian Weis draft-ietf-mediactrl-sip-control-framework-04 Nico Williams draft-ietf-v6ops-ra-guard-01 Larry Zhu draft-thaler-v6ops-teredo-extensions-01 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 3 20:23:04 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA303A6A08; Fri, 3 Oct 2008 20:23:04 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FBE63A6828; Fri, 3 Oct 2008 20:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 sFHtf8YCc3IN; Fri, 3 Oct 2008 20:23:02 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id F1CD73A67F8; Fri, 3 Oct 2008 20:22:51 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Fri, 03 Oct 2008 20:23:20 PDT Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Oct 2008 20:20:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Oct 2008 23:20:04 -0400 Message-ID: <3525C9833C09ED418C6FD6CD9514668C04D247F8@emailwf1.jnpr.net> In-Reply-To: <28749984.1223071265647.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-ccamp-rfc4420bis-03 Thread-Index: Acklo4z5zvRZxQRRSOik0ZPxrUy/DAAKWztw References: <28749984.1223071265647.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> From: "Ross Callon" To: "Scott G. Kelly" , , , , "Arthi Ayyangar" X-OriginalArrivalTime: 04 Oct 2008 03:20:07.0009 (UTC) FILETIME=[199FAD10:01C925D0] Cc: Ross Callon , dward@cisco.com, iesg@ietf.org, dbrungard@att.com, secdir Subject: Re: [secdir] secdir review of draft-ietf-ccamp-rfc4420bis-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org The way that the original draft defines the length field in TLV's is different from pretty much every other related protocol. As a result many implementers implemented the length field the same way as every other length field in every other TLV in related protocols, rather than the way that the old draft specified it. This caused interoperability problems and was quickly flagged as a bug. The way that the new updated draft defines / uses the length field is consistent with a very large number of other routing protocol specifications. Implementations have been consistent with the updated draft (and therefore inconsistent with the old RFC) for quite a while. Ross -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: 03 October 2008 18:01 To: adrian@olddog.co.uk; dimitri.papadimitriou@alcatel.be; jpv@cisco.com; Arthi Ayyangar Cc: iesg@ietf.org; secdir; dbrungard@att.com; Ross Callon; dward@cisco.com Subject: secdir review of draft-ietf-ccamp-rfc4420bis-03 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is a very limited update to RFC4420. In particular, it changes only one thing: the length field in the TLV defined by 4420 is changed such that it now includes the Type and Length in the length calculation, whereas before, it contained the length of only the Value portion. This introduces no new security concerns that I can think of. My only question is, how do implementations distinguish between this encoding and the old one? The doc says nothing about a protocol version number change corresponding to the change in the bits on the wire. I assume the draft wouldn't be in last call if this were a real concern, but still, I'm curious about this. --Scott _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sat Oct 4 00:27:23 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E2D3A6992; Sat, 4 Oct 2008 00:27:22 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F7B3A6992; Sat, 4 Oct 2008 00:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGFPN3Somcm3; Sat, 4 Oct 2008 00:27:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 6ECF43A687F; Sat, 4 Oct 2008 00:27:18 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m947Rcqw006791; Sat, 4 Oct 2008 08:27:38 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m947RaA8006785; Sat, 4 Oct 2008 08:27:37 +0100 Message-ID: <03ef01c925f2$ae1bf170$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: "Scott G. Kelly" , , , References: <28749984.1223071265647.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Sat, 4 Oct 2008 08:17:28 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: rcallon@juniper.net, dward@cisco.com, iesg@ietf.org, dbrungard@att.com, secdir Subject: Re: [secdir] secdir review of draft-ietf-ccamp-rfc4420bis-03 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Scott, An survey in CCAMP found that deployable implementations had "done the right thing" (i.e. coded according to the bis - presumably by accident) other implementations were pre-deployment. Hence the bis can safely obsolete the previous RFC. Cheers, Adrian ----- Original Message ----- From: "Scott G. Kelly" To: ; ; ; Cc: ; "secdir" ; ; ; Sent: Friday, October 03, 2008 11:01 PM Subject: secdir review of draft-ietf-ccamp-rfc4420bis-03 >I have reviewed this document as part of the security directorate's ongoing >effort to review all IETF documents being processed by the IESG. These >comments were written primarily for the benefit of the security area >directors. Document editors and WG chairs should treat these comments just >like any other last call comments. > > This document is a very limited update to RFC4420. In particular, it > changes only one thing: the length field in the TLV defined by 4420 is > changed such that it now includes the Type and Length in the length > calculation, whereas before, it contained the length of only the Value > portion. > > This introduces no new security concerns that I can think of. My only > question is, how do implementations distinguish between this encoding and > the old one? The doc says nothing about a protocol version number change > corresponding to the change in the bits on the wire. I assume the draft > wouldn't be in last call if this were a real concern, but still, I'm > curious about this. > > --Scott > > > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sat Oct 4 18:56:48 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3CC3A67AE; Sat, 4 Oct 2008 18:56:48 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49603A67AE for ; Sat, 4 Oct 2008 18:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8a1pj8z9HrW for ; Sat, 4 Oct 2008 18:56:46 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 7B5A53A6780 for ; Sat, 4 Oct 2008 18:56:46 -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 m951upVp007508 for ; Sat, 4 Oct 2008 21:56:55 -0400 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m951unhN007505 for ; Sat, 4 Oct 2008 21:56:49 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m951ufIB024131; Sat, 4 Oct 2008 21:56:41 -0400 (EDT) Received: from morannon (ool-43501d19.dyn.optonline.net [67.80.29.25]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m951udWl020644 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 4 Oct 2008 21:56:40 -0400 (EDT) From: "Uri Blumenthal" To: "'Barry Leiba'" , "'Lisa Dusseault'" , References: <623ED7C1-9251-4DB4-B95F-BFEC6EB2ABE1@commerce.net> <362BD00981F367CEDD5CF81C@Uranus-009002042072.watson.ibm.com> Date: Sat, 4 Oct 2008 21:56:39 -0400 Organization: Massachusetts Institute of Technology Message-ID: <011DFBB970834433ADCC9DE35C45C894@morannon> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <362BD00981F367CEDD5CF81C@Uranus-009002042072.watson.ibm.com> Thread-Index: AckjENzwHMRmRXyVTQGE8MRAFjLvzgDexguw X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: 'Anthony Bryan' Subject: Re: [secdir] Digital signature advice and review for content delivery application X-BeenThere: secdir@ietf.org Reply-To: uri@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I looked at RFC 4287 (Atom Syndication Format, circa 2005) and find that many of this draft's "offensive" security issues came directly from it. They look equally bad in RFC 4287. I know we're in year 2008, not 2005, and Atom is a published RFC. But it contains security glitches, illustrated by quotations in this draft. Maybe it's not too late todo anything about it (or maybe it is). -----Original Message----- From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of Barry Leiba Sent: Tuesday, September 30, 2008 11:25 To: Lisa Dusseault; secdir@mit.edu Cc: Anthony Bryan Subject: Re: [secdir] Digital signature advice and review for content delivery application > Is there somebody on secdir who could volunteer to review and provide > advice on the digital signature functionality in this proposal? > > http://tools.ietf.org/html/draft-bryan-metalink-03 I've given it a brief reading, and here are my initial thoughts: First, I find quite a bit of the document to be sketchy and unclear. That's certainly because I haven't been involved in any of the discussions, but neither will most future readers of it have been. In particular, the descriptions of the elements don't seem to be adequate. For example: > 4.1.6. The "metalink:pieces" Element > > The "metalink:pieces" element is a Text construct that conveys a > human-readable piece information for a file. > I don't know what "human-readable piece information" is, why it's put there, what anyone will do with it, nor whether there'd be value in any particular format for the information. I also don't know whether there's any corresponding machine-readable piece information. For signatures, in particular: > 4.2.14. The "metalink:signature" Element > > The "metalink:signature" element is a Text construct that conveys a > digital signature for a file described in a Metalink Document. > > metalinkSignature = > element metalink:signature { > attribute type { "pgp" }, > metalinkTextConstruct > } I gather from that that "pgp" is the only signature type supported; that's unfortunate. Are there no other attributes that will be needed in order to support different signature types? Planning that now will help extensibility later. >From section 6: > Producers of Metalinks may have sound reasons for signing and/or > encrypting otherwise-unprotected content. I think this downplays the importance of signing these things; I rather think that signing them should become the norm, not the exceptional case that's only used if there are "sound reasons". > Metalink Processors MUST NOT reject an Metalink Document containing > such a signature because they are not capable of verifying it; they > MUST continue processing and MAY inform the user of their failure to > validate the signature. Ooh. I'd want to know why. This is certainly a MUST that I would violate if I had a system that decided it would only accept metalink documents that were signed. And I can definitely see sound reasons for having such a system. > Other elements in an Metalink Document MUST NOT be signed unless > their definitions explicitly specify such a capability. I don't understand this. What is the scope of a signature on a metalink document, then? I should think it would protect the whole document. Is this trying to say that there must not be embedded signatures inside a signed document? If so, then it should be clearer. If it means something else, I don't understand. > Section 4.4.2 of [REC-xmldsig-core] requires support for DSA > signatures and recommends support for RSA signatures. However, > because of the much greater popularity in the market of RSA versus > DSA Yeh, that's odd. I initially thought it was because of the RSA patent, but that expired in 2000, and the W3C document is from 2002. [shrug] I do think it's reasonable for this document to reverse the requirements for RSA and DSA, as it does. Section 9, Security Considerations, seems inadequate. The base section says, essentially, "you're encouraged to use authenticated HTTP under TLS, and you're encouraged to sign the files you're going to transfer" (but not the metalink documnts). There are perfectly good reasons not to use authenticated HTTP (distributing public documents, for instance), but TLS will often still make sense (to confirm the server's identity), signatures on the metadata are still important (preventing attacks that present spurious documents), and so on. Section 9.2 does address that last point somewhat, but (1) I disagree with the "at best" and "at worst" cases there, and (2) there's no recommendation about what to do. I think the severity of potential attacks is greater than what's presented here. I see no reason there shouldn't be a SHOULD here for signing the metalink document, and that would address the broader spoofing issue. Section 9.3 says they "can" be signed, but makes no recommendation. Those are comments from an first look. Barry Leiba IAB member, and DKIM working group chair _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Oct 5 23:12:30 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2769628C128; Sun, 5 Oct 2008 23:12:30 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C398E3A6A3C for ; Fri, 3 Oct 2008 00:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.473 X-Spam-Level: X-Spam-Status: No, score=-7.473 tagged_above=-999 required=5 tests=[AWL=-0.874, 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 71-PpEe8bLQN for ; Fri, 3 Oct 2008 00:48:04 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D64BC3A685F for ; Fri, 3 Oct 2008 00:48:03 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m936ow0e003827 for ; Fri, 3 Oct 2008 02:51:00 -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 m92F5GQb011825 for ; Thu, 2 Oct 2008 11:05:20 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m92F56ZK011741 for ; Thu, 2 Oct 2008 11:05:07 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 980CF115B92E for ; Thu, 2 Oct 2008 11:04:42 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B553A6C54; Thu, 2 Oct 2008 08:04:15 -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 2F1903A67E4 for ; Thu, 2 Oct 2008 06:51:08 -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 GF0xf6FOj5K3 for ; Thu, 2 Oct 2008 06:51:07 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2EAB53A6AE2 for ; Thu, 2 Oct 2008 06:50:24 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KlOY5-0008CO-1k for public-new-work-dist@listhub.w3.org; Thu, 02 Oct 2008 13:48:57 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KlOY4-0008Bk-1I for public-new-work@listhub.w3.org; Thu, 02 Oct 2008 13:48:56 +0000 Received: from homer.w3.org ([128.30.52.30]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KlOXv-0001U8-OK; Thu, 02 Oct 2008 09:48:55 -0400 Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 63B9D4EECE; Thu, 2 Oct 2008 09:48:22 -0400 (EDT) From: "Ian B. Jacobs" To: public-new-work@w3.org Organization: W3C Date: Thu, 02 Oct 2008 13:48:16 +0000 Message-Id: <1222955296.25643.53.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1KlOXv-0001U8-OK 126fae045418a15d41f0d5d852555aa3 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/29 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Thu, 02 Oct 2008 13:48:57 +0000 X-Mailman-Approved-At: Thu, 02 Oct 2008 08:04:14 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 03 Oct 2008 02:50:57 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Sun, 05 Oct 2008 23:12:28 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: Fonts Working Group (until 2008-10-30) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hello, Today W3C Advisory Committee Representatives received a Proposal for a new Fonts Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Fonts Working Group: http://www.w3.org/Fonts/Misc/charter-2008 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 2008-10-30 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 Bert Bos . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2008/09/fonts-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 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Oct 5 23:15:01 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873F028C132; Sun, 5 Oct 2008 23:15:01 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E5F3A6A36 for ; Sun, 5 Oct 2008 23:13:42 -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 Z6mOYr41cvb2 for ; Sun, 5 Oct 2008 23:13:41 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id C4A203A6A33 for ; Sun, 5 Oct 2008 23:13:40 -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 m966EFr6011047 for ; Mon, 6 Oct 2008 02:14:16 -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 m93NKLJR014772 for ; Fri, 3 Oct 2008 19:20:21 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m93NKBLg012801 for ; Fri, 3 Oct 2008 19:20:11 -0400 (EDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mit.edu (Spam Firewall) with ESMTP id 1B6C41124024 for ; Fri, 3 Oct 2008 19:17:50 -0400 (EDT) Received: by wf-out-1314.google.com with SMTP id 27so2024902wfd.21 for ; Fri, 03 Oct 2008 16:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ur5xH2T+swOirUn3lnQnsn7nwPEJ4UFcJ3nsrKuB8xE=; b=wwJvzV131yUB16zEerKPKgHLTjFATTBCXE/iuDgQbmwijxgSaZFrZfHRDnp0QsCymo /Is2XY1Ug+dAf9218u6isQ5oiE38qXnRP+CAQ52gbj3TyUeXk6eC6T6BADs61jwsST/Y wN5zHkxVOYcN4hYC3STl4onGP5NnA8qJ28iDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=eDpB9sr5pc3X3ZkXy16Ujl6nH8wF8lFvJ3DvvINuKkPzP101IfCcLpK4aBEuSTjKy9 P0mJWBhhwLilzu8ZVA+UiRIAPN5aaHA2SoWv9kVinYqdRRFbZbJUxVz1s2kYuX85c2au N+vvlZGaI1etul9rtl3VDVmrha64Nk7pcb8lQ= Received: by 10.142.212.19 with SMTP id k19mr588487wfg.142.1223075869238; Fri, 03 Oct 2008 16:17:49 -0700 (PDT) Received: by 10.142.246.18 with HTTP; Fri, 3 Oct 2008 16:17:49 -0700 (PDT) Message-ID: Date: Fri, 3 Oct 2008 19:17:49 -0400 From: "Anthony Bryan" To: "Barry Leiba" In-Reply-To: <362BD00981F367CEDD5CF81C@Uranus-009002042072.watson.ibm.com> MIME-Version: 1.0 Content-Disposition: inline References: <623ED7C1-9251-4DB4-B95F-BFEC6EB2ABE1@commerce.net> <362BD00981F367CEDD5CF81C@Uranus-009002042072.watson.ibm.com> X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Mon, 06 Oct 2008 02:14:13 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Sun, 05 Oct 2008 23:15:00 -0700 Cc: secdir@mit.edu, Lisa Dusseault Subject: Re: [secdir] Digital signature advice and review for content delivery application X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Barry, thank you for taking the time to review and comments. As you can see, it needed it. On Tue, Sep 30, 2008 at 11:24 AM, Barry Leiba wrote: >> Is there somebody on secdir who could volunteer to review and provide >> advice on the digital signature functionality in this proposal? >> >> http://tools.ietf.org/html/draft-bryan-metalink-03 > > I've given it a brief reading, and here are my initial thoughts: > > First, I find quite a bit of the document to be sketchy and unclear. That's > certainly because I haven't been involved in any of the discussions, but > neither will most future readers of it have been. In particular, the > descriptions of the elements don't seem to be adequate. > > For example: >> >> 4.1.6. The "metalink:pieces" Element >> >> The "metalink:pieces" element is a Text construct that conveys a >> human-readable piece information for a file. >> > > I don't know what "human-readable piece information" is, why it's put there, > what anyone will do with it, nor whether there'd be value in any particular > format for the information. I also don't know whether there's any > corresponding machine-readable piece information. Thanks for catching that. I was using it as placeholder text. I've updated it & the next version will have the description, it's where partial file hashes are contained. I'll try to catch other sketchy and unclear sections. > For signatures, in particular: >> >> 4.2.14. The "metalink:signature" Element >> >> The "metalink:signature" element is a Text construct that conveys a >> digital signature for a file described in a Metalink Document. >> >> metalinkSignature = >> element metalink:signature { >> attribute type { "pgp" }, >> metalinkTextConstruct >> } > > I gather from that that "pgp" is the only signature type supported; that's > unfortunate. > > Are there no other attributes that will be needed in order to support > different signature types? Planning that now will help extensibility later. Actually, this is why we were requesting review. Only PGP signatures of files listed in metalinks are used and included now, but we want to support different signature types. I have already documented what is in use that I have experience with (PGP). Can you list, or point me to the other types of signatures and how we can include them in the metalink? The text from you commented on in your next four comments is from RFC 4287, Atom. I have used the text from the Atom RFC because I have no experience with this section and have not come across any signed Metalinks in the wild. I assumed since Atom documents and Metalink documents are both XML, they would be the same or relatively similar. I want my draft to be correct and need to rely on others for this section. Are these suggestions that have been learned since the publication of RFC 4287 or should have been included? Because of my lack of knowledge and experience, it might even be rude for me to reply to your comments. I will certainly accept corrections and changes to the text. Perhaps someone more familiar with these matters could shepherd this part of the draft, if interested. >> From section 6: >> Producers of Metalinks may have sound reasons for signing and/or >> encrypting otherwise-unprotected content. > > I think this downplays the importance of signing these things; I rather > think that signing them should become the norm, not the exceptional case > that's only used if there are "sound reasons". > >> Metalink Processors MUST NOT reject an Metalink Document containing >> such a signature because they are not capable of verifying it; they >> MUST continue processing and MAY inform the user of their failure to >> validate the signature. > > Ooh. I'd want to know why. This is certainly a MUST that I would violate > if I had a system that decided it would only accept metalink documents that > were signed. And I can definitely see sound reasons for having such a > system. > >> Other elements in an Metalink Document MUST NOT be signed unless >> their definitions explicitly specify such a capability. > > I don't understand this. What is the scope of a signature on a metalink > document, then? I should think it would protect the whole document. Is > this trying to say that there must not be embedded signatures inside a > signed document? If so, then it should be clearer. If it means something > else, I don't understand. > >> Section 4.4.2 of [REC-xmldsig-core] requires support for DSA >> signatures and recommends support for RSA signatures. However, >> because of the much greater popularity in the market of RSA versus >> DSA > > Yeh, that's odd. I initially thought it was because of the RSA patent, but > that expired in 2000, and the W3C document is from 2002. [shrug] I do > think it's reasonable for this document to reverse the requirements for RSA > and DSA, as it does. > Section 9, Security Considerations, seems inadequate. The base section > says, essentially, "you're encouraged to use authenticated HTTP under TLS, > and you're encouraged to sign the files you're going to transfer" (but not > the metalink documnts). There are perfectly good reasons not to use > authenticated HTTP (distributing public documents, for instance), but TLS > will often still make sense (to confirm the server's identity), signatures > on the metadata are still important (preventing attacks that present > spurious documents), and so on. Section 9.2 does address that last point > somewhat, but (1) I disagree with the "at best" and "at worst" cases there, > and (2) there's no recommendation about what to do. I think the severity of > potential attacks is greater than what's presented here. Should I remove the "at best/worst" cases (or rephrase them?) and recommend signing the metalinks? > I see no reason there shouldn't be a SHOULD here for signing the metalink > document, and that would address the broader spoofing issue. Section 9.3 > says they "can" be signed, but makes no recommendation. > > Those are comments from an first look. Thank you again. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 6 12:19:42 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137C73A6AFD; Mon, 6 Oct 2008 12:19:42 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D1628C135; Mon, 6 Oct 2008 12:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.385, 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 2Qs73EaUdffM; Mon, 6 Oct 2008 12:19:40 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 05BF03A69C1; Mon, 6 Oct 2008 12:19:39 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m96JJV7a023313; Mon, 6 Oct 2008 15:19:31 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m96JJUI0090060; Mon, 6 Oct 2008 15:19:30 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m96JJJZa014769; Mon, 6 Oct 2008 15:19:20 -0400 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m96JJHlO013680; Mon, 6 Oct 2008 15:19:18 -0400 Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1223320726.564; Mon, 06 Oct 2008 15:18:46 -0400 Date: Mon, 06 Oct 2008 15:18:44 -0400 From: Barry Leiba To: secdir@ietf.org, iesg@ietf.org Message-ID: <3E3F3A8CB72E39B776828882@Uranus-009002042072.watson.ibm.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: draft-bryant-mpls-tp-jwt-report@tools.ietf.org Subject: [secdir] secdir review of draft-bryant-mpls-tp-jwt-report-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 should treat these comments just like any other last call comments. OK, well, that said: this is really a <> review. The subject document is a report of the work the IETF did with ITU-T to sort out some architectural conflicts between the IETF's MPLS spec and ITU-T's T-MPLS. As an IAB member, I followed the work as we met with the ITU-T folks in Chicago, and as Loa, Stewat, and Monique reported progress to us. This draft accurately summarizes things, and has no further security issues. No problem: this draft should be published as an Informational RFC. Barry _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 7 01:21:24 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C8A3A6A8C; Tue, 7 Oct 2008 01:21:24 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00FD3A6A8C for ; Tue, 7 Oct 2008 01:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.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 dRsP+LK1G8pC for ; Tue, 7 Oct 2008 01:21:21 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A93C63A69E3 for ; Tue, 7 Oct 2008 01:21:21 -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 m978Lv12027504 for ; Tue, 7 Oct 2008 04:21:57 -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 m978Ls3f027495 for ; Tue, 7 Oct 2008 04:21:54 -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 m978Lj1H009786 for ; Tue, 7 Oct 2008 04:21:45 -0400 (EDT) X-ASG-Whitelist: Barracuda Reputation Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 5EDEE1108511 for ; Tue, 7 Oct 2008 04:21:45 -0400 (EDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 7 Oct 2008 01:21:44 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.1.291.1; Tue, 7 Oct 2008 01:21:43 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Tue, 7 Oct 2008 01:21:59 -0700 From: Larry Zhu To: "pkyzivat@cisco.com" , "tomoyuki.yoshikawa@east.ntt.co.jp" , "suzuki.yasushi@lab.ntt.co.jp" , "j.koshiko@east.ntt.co.jp" , "hasebe.miki@east.ntt.co.jp" , "dean.willis@softarmor.com" , "drage@alcatel-lucent.com" Date: Tue, 7 Oct 2008 01:21:43 -0700 Thread-Topic: SECDIR review of draft-ietf-sipping-race-examples-06 Thread-Index: AckoVbrrPGwtW5PySu+DRo6YbYlfDg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m978Ls3f027495 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: "secdir@mit.edu" , "iesg@ietf.org" Subject: [secdir] SECDIR review of draft-ietf-sipping-race-examples-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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. Overall the document is clear. I have the following comments: 1. The title of the document does not seem to reflect the content of the document. The document seems to describe implementation pitfalls in SIP, not racing conditions. See http://en.wikipedia.org/wiki/Race_condition, a race condition is perceived as a flaw. Throughout the document I am not convinced the SIP protocol is flawed. Rather, the document seems to suggest that implementations flaws can be avoided if the asynchronous nature of the SIP message processing is taken into considerations. The body of the document at various places suggests this document contains just clarifications to RFC3261. I suspect that the word "clarifications" might be used to better describe what the document is about. 2. Section 1, paragraph 3, the word "UA". This should be expanded on the first use. 3. Section 1, paragraph 5, the word "SDP". This should be expanded on the first use. 4. Section 1, paragraph 4, last sentence. Consider s/standard/robust/. I suspect the later word is intended. 5. section 1.3, there is line with just "actors", I do not understand why the extra line is there. 6. Section 1.3, " (Which differs somewhat from the definition of the term in RFC 3261.)". This sentence is confusing and not substantiated. I am not sure why the session definition is "somewhat" different. This could be expanded or just removed since it adds confusions for the reader (as least for me). 7. Section 2, under figure 1, "Where (r) is not used as an indicator, "response" means receive, and "request" means send." I do not understand what this sentence because I could not find either the word "response" or the word "request" in the diagram. 8. Section 2, under figure 2. Ditto. 9. There are over 10 pages of text in the appendix portion of the document. If this document were titled as "clarifications to RFC3261", these appendices probably should be moved into the main body of the document. --Larry _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 7 20:58:22 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97013A6B3B; Tue, 7 Oct 2008 20:58:22 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02D028C1BA for ; Mon, 6 Oct 2008 13:37:55 -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 QzD2VBIGKoMQ for ; Mon, 6 Oct 2008 13:37:54 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 7CA123A6AA5 for ; Mon, 6 Oct 2008 13:37:54 -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 m96KcV1v014448 for ; Mon, 6 Oct 2008 16:38:31 -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 m96KcTQb014445 for ; Mon, 6 Oct 2008 16:38:29 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m96KcJMg021785 for ; Mon, 6 Oct 2008 16:38:19 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 4A7FB1199443 for ; Mon, 6 Oct 2008 16:37:55 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2162328C214; Mon, 6 Oct 2008 13:37:17 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7DB8D3A6B30; Mon, 6 Oct 2008 13:37:15 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20081006203715.7DB8D3A6B30@core3.amsl.com> Date: Mon, 6 Oct 2008 13:37:15 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Tue, 07 Oct 2008 20:58:21 -0700 Subject: [secdir] [New-work] WG Review: Application-Layer Traffic Optimization (alto) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org A new IETF working group has been proposed in the Applications 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 Monday, October 13, 2008. Application-Layer Traffic Optimization (alto) ============================================= Last Modified: 2008-09-29 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Lisa Dusseault (lisa at osafoundation.org) Chris Newman (Chris.Newman at sun.com) Applications Area Advisor: Lisa Dusseault (lisa at osafoundation.org) Mailing List: General Discussion: p2pi at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/p2pi Archive: http://www.ietf.org/pipermail/p2pi/ Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often have a selection of peers and must choose. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among download locations, yet applications have at best incomplete information about the topology of the network. Applications can sometimes make empirical measurements of link performance, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus causing at least temporary reduced performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors including maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, what kind of information P2P applications will need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses. The WG does not require intermediaries between the ALTO server and the peer querying it. If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as extensions to the charter once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. - Can the ALTO service technically provide that information? - Is the ALTO service willing to obtain and divulge that information? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the generality of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO servers (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Goals and Milestones (very tentative dates): Apr 2009: Working Group Last Call for problem statement Jun 2009: Submit problem statement to IESG as Informational Aug 2009: Working Group Last Call for requirements document Oct 2009: Submit requirements document to IESG as Informational Jan 2010: Working Group Last Call for request/response protocol Jan 2010: Working Group Last Call for usage document for communicating network preferences Mar 2010: Submit request/response protocol to IESG as Proposed Standard Mar 2010: Submit usage document to IESG as Proposed Standard May 2010: Working Group Last Call of discovery mechanism Jul 2010: Submit discovery mechanism to IESG as Proposed Standard Aug 2010: Dissolve or re-charter Initial Drafts for Consideration - draft-marocco-alto-problem-statement-02 -- Application-Layer Traffic Optimization (ALTO) Problem Statement - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic Optimization (ALTO) Requirements _______________________________________________ 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 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 8 01:03:48 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C198A28C175; Wed, 8 Oct 2008 01:03:48 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E48E3A6BCB for ; Wed, 8 Oct 2008 01:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.276, 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 Pz85c85Nctjv for ; Wed, 8 Oct 2008 01:03:43 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A42733A68A9 for ; Wed, 8 Oct 2008 01:03:43 -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 m98843Tb003044 for ; Wed, 8 Oct 2008 04:04:03 -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 m9883rP6003032 for ; Wed, 8 Oct 2008 04:03:53 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9883jHV003920 for ; Wed, 8 Oct 2008 04:03:46 -0400 (EDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mit.edu (Spam Firewall) with ESMTP id 58AF31121DFF for ; Wed, 8 Oct 2008 04:03:24 -0400 (EDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9883NB5012111 for ; Wed, 8 Oct 2008 08:03:23 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8E00F01UDHSI00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for secdir@mit.edu; Wed, 08 Oct 2008 02:03:23 -0600 (MDT) Received: from [10.0.0.5] ([206.124.6.145]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8E007YUUDM8KD0@mail-amer.sun.com>; Wed, 08 Oct 2008 02:03:23 -0600 (MDT) Date: Wed, 08 Oct 2008 02:03:56 -0600 From: Shawn M Emery To: secdir@mit.edu Message-id: <48EC696C.4010105@sun.com> MIME-version: 1.0 User-Agent: Thunderbird 2.0.0.16 (X11/20080808) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-ietf-avt-rtp-toffset@tools.ietf.org, iesg@ietf.org, avt-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-avt-rtp-toffset-07 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 way to inference information between transmission of a packet vs RTP timestamp data. This could be used to determine actual network jitter and the draft describes a new packet for reporting this data. The security consideration section does exist and consists of one sentence: The given transmission offsets are only informative and it is hard to see security considerations from associating them with media streams. I believe more guidance would help here. For instance; security considerations should be made based on how applications act upon network jitter information and if the attribute is determined to be sensitive to a DoS attack, for instance, then protecting this information should be made. Referring to recommendations outlined in the RTP RFC or better. Other than that, I see no additional security concerns from that of RTP. Editorial comment(s): None. Shawn. -- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 8 08:20:41 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BAD3A6B47; Wed, 8 Oct 2008 08:20:41 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5553A6B47 for ; Wed, 8 Oct 2008 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=-0.146, 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 SCxePt-jsA6q for ; Wed, 8 Oct 2008 08:20:39 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6CCE03A691A for ; Wed, 8 Oct 2008 08:20:10 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Knape-0000aU-Ad; Wed, 08 Oct 2008 11:20:11 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 8 Oct 2008 11:20:52 -0400 To: secdir@core3.amsl.com From: Stephen Kent Cc: fluffy@cisco.com, tim.polk@nist.gov, Pasi.Eronen@nokia.com, jo@acm.org, fandreas@cisco.com, jf.mule@cablelabs.com Subject: [secdir] review of draft-ietf-mmusic-sdp-capability-negotiation-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1492250325==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============1492250325== Content-Type: multipart/alternative; boundary="============_-988643238==_ma============" --============_-988643238==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I have reviewed this I-D as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. General note: The I-D requires a separate copy editing review; I encountered several grammatical errors and several instances where a blank line appears in the middle of a paragraph. Also the number of lines per page seem to be too large. Finally, given the substantial complexity of the offer structuring mechanism defined here, I'd like to see more attention paid to proper placement of the word "only" in the text. I have been told that this I-D was initially motivated by the need to provide a capability negotiation for MIKEY, when that protocol was a leading candidate for SRTP key management. The I-D defines a more general negotiation capability for SDP, one that has broader applicability, but which still aims to be backward compatible with existing SIP implementations. This is motivated by more instances in which the basic offer/answer model of SDP is perceived as not adequate. In extending the semantics of this model, this I-D defines ways in which an offerer can describe capabilities and potential vs. actual configurations, and then the answerer will select a compatible set of capabilities or configurations from the offerer. The I-D defines six new attributes that allow an offerer to structure an SDP payload to convey the desired semantics to the answerer, and procedures that allow the answerer to interpret the structured payload. This functionality might be achieved more elegantly via the use of the multipart MIME construct, but support for that construct is not perceived as being ubiquitous. There also is a desire to achieve a compact encoding for a potentially large number of alternative offers. I am a bit surprised that many of the examples in this I-D use inline keying for SRTP as a major motivator. I thought there was a decision in RAI to encourage use of DTLS-based key exchange for SRTP, which makes this sort of example less relevant. Moreover, inline transmission of a plaintext key is not something the security areas wants to encourage, so use of this means of key transport in examples also sends a questionable message. (Yes, I know this is consistent with RFC 4568, but that RFC is over 2 years old.) There are other examples that use MIKEY as the key management mechanism, which also seems a bit odd, if MIKEY has been deprecated now. The I-D notes (in Section 3.5.1) that there can be complex interactions between session level attributes and (subordinate) combinations of media-stream attributes, which could result in unanticipated results. The authors observe that this potential problem (which was already present in SDP but which may be exacerbated by this extended functionality) rarely occurs in practice. As a security guy, this is a worrisome observation. The inclusion of a MIKEY-specific discussion in Sections 4.2 and 4.3 are a concern, for the reasons already stated above, i.e., I thought that MIKEY has been superceded by DTLS-based key exchange. The security considerations section is about 2 pages long. It begins by incorporating (by reference) the security considerations for SIP and SDP, but does not provide cites for RFCs that contain the discussions of these security considerations. I think such cites should be inserted here. The authors correctly note that SDP capability negotiation introduces new security considerations and they try to address those in subsequent paragraphs. The primary observation here is that if an offerer indicates a willingness to create either secure or insecure (or more or less secure) media streams, then attacks that violate the integrity of the SDP traffic can undermine the security of the media stream. The recommended solution is to make use of one of the integrity mechanisms that have defined for either end-to-end or hop-by-hop SIP security. The I-D recommends use of the security approach in RFC 4474, arguing that this mechanism does not require a PKI. This characterization is not correct; 4474 calls for a PKI that issues certificates to domains, rather than to end users, but it still assumes the existence of a PKI. The I-D also argues that the 4474 approach is more secure than hop-by-hop use of TLS or IPsec (IPsec is misspelled in the I-D). However, if the typical path for a call traverses just two proxies (Alice's home domain, outbound proxy and Bob's home domain inbound proxy) this assertion also seems questionable, for several reasons. The 4474 approach provides authentication form the home domain SIP proxy to subsequent proxies. (Nominally this authentication extends to the callee, but it seems unlikely that an end user will be prepared to validate certificates in s system that works hard to minimize the need for a PKI that encompasses end users in the first place.) More to the point, the 4474 mechanism provides assurance with regard to the identity of the caller, and the integrity of some SIP header fields. It does not appear to provide integrity for the SDP payload, so it does not counter attacks against the integrity of the SDP. This latter function is what the authors note is needed to prevent a MITM from tampering with the SDP capability negotiation, to cause non-secure media stream options to be selected inappropriately. The authors also note the potential for DoS attacks against an answerer, based on sending a very large set of offers, using a very complex capability negotiation structure. The I-D says that the answerer MUST protect itself against such attacks as indicated in Section 3.10. In fact, the correct reference is to section 3.11. Moreover, that section merely warns implementers about this problem and suggests some heuristics that an answerer could apply when processing an offer. Thus it is questionable to have a MUST in the security considerations sections that refers to text that offers such high level implementation advice. The security considerations section ends with a similar requirement "Still, the answerer MUST ensure that it does not needlessly consume large amounts of memory or CPU resources when processing those as well as be prepared to handle the case where a large number of potential configurations still need to be processed." I don't know how one would objectively verify that an implementation meets this requirement. That will make it hard to progress this document later, when folks have to demonstrate that implementations meet all the MUSTs. --============_-988643238==_ma============ Content-Type: text/html; charset="us-ascii" review of draft-ietf-mmusic-sdp-capability-negotiation-09.
I have reviewed this I-D as part of the security directorate's ongoing effort to review all IETF documents being processed by the  IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

General note: The I-D requires a separate copy editing review; I encountered several grammatical errors and several instances where a blank line appears in the middle of a paragraph. Also the number of lines per page seem to be too large. Finally, given the substantial complexity of the offer structuring mechanism defined here, I'd like to see more attention paid to proper placement of the word "only" in the text.
I have been told that this I-D was initially motivated by the need to provide a capability negotiation for MIKEY, when that protocol was a leading candidate for SRTP key management. The I-D defines a more general negotiation capability for SDP, one that has broader applicability, but which still aims to be backward compatible with existing SIP implementations. This is motivated by more instances in which the basic offer/answer model of SDP is perceived as not adequate.

In extending the semantics of this model, this I-D defines ways in which an offerer can describe capabilities and potential vs. actual configurations, and then the answerer will select a compatible set of capabilities or configurations from the offerer. The I-D defines six new attributes that allow an offerer to structure an SDP payload to convey the desired semantics to the answerer, and procedures that allow the answerer to interpret the structured payload. This functionality might be achieved more elegantly via the use of the multipart MIME construct, but support for that construct is not perceived as being ubiquitous. There also is a desire to achieve a compact encoding for a potentially large number of alternative offers.
I am a bit surprised that many of the examples in this I-D use inline keying for SRTP as a major motivator. I thought there was a decision in RAI to encourage use of DTLS-based key exchange for SRTP, which makes this sort of example less relevant.  Moreover, inline transmission of a plaintext key is not something the security areas wants to encourage, so use of this means of key transport in examples also sends a questionable message. (Yes, I know this is consistent with RFC 4568, but that RFC is over 2 years old.) There are other examples that use MIKEY as the key management mechanism, which also seems a bit odd, if MIKEY has been deprecated now.

The I-D notes (in Section 3.5.1) that there can be complex interactions between session level attributes and (subordinate) combinations of media-stream attributes, which could result in unanticipated results. The authors observe that this potential problem (which was already present in SDP but which may be exacerbated by this extended functionality) rarely occurs in practice. As a security guy, this is a worrisome observation.

The inclusion of a MIKEY-specific discussion in Sections 4.2 and 4.3 are a concern, for the reasons already stated above, i.e., I thought that MIKEY has been superceded by DTLS-based key exchange.
The security considerations section is about 2 pages long. It begins by incorporating (by reference) the security considerations for SIP and SDP, but does not provide cites for RFCs that contain the discussions of these security considerations. I think such cites should be inserted here. The authors correctly note that SDP capability negotiation introduces new security considerations and they try to address those in subsequent paragraphs.

The primary observation here is that if an offerer indicates a willingness to create either secure or insecure (or more or less secure) media streams, then attacks that violate the integrity of the SDP traffic can undermine the security of the media stream. The recommended solution is to make use of one of the integrity mechanisms that have defined for either end-to-end or hop-by-hop SIP security. The I-D recommends use of the security approach in RFC 4474, arguing that this mechanism does not require a PKI. This characterization is not correct; 4474 calls for a PKI that issues certificates to domains, rather than to end users, but it still assumes the existence of a PKI.

The I-D also argues that the 4474 approach is more secure than hop-by-hop use of TLS or IPsec (IPsec is misspelled in the I-D). However, if the typical path for a call traverses just two proxies (Alice's home domain, outbound proxy and Bob's  home domain inbound proxy) this assertion also seems questionable, for several reasons. The 4474 approach provides authentication form the home domain SIP proxy to subsequent proxies. (Nominally this  authentication extends to the callee, but it seems unlikely that an end user will be prepared to validate certificates in s system that works hard to minimize the need for a PKI that encompasses end users in the first place.) More to the point, the 4474 mechanism provides assurance with regard to the identity of the caller, and the integrity of some SIP header fields. It does not appear to provide integrity for the SDP payload, so it does not counter attacks against the integrity of the SDP. This latter function is what the authors note is needed to prevent a MITM from tampering with the SDP capability negotiation, to cause non-secure media stream options to be selected inappropriately.

The authors also note the potential for DoS attacks against an answerer, based on sending a very large set of offers, using a very complex capability negotiation structure. The I-D says that the answerer MUST protect itself against such attacks as indicated in Section 3.10.  In fact, the correct reference is to section 3.11. Moreover, that section merely warns implementers about this problem and suggests some heuristics that an answerer could apply when processing an offer. Thus it is questionable to have a MUST in the security considerations sections that refers to text that offers such high level implementation advice. The security considerations section ends with a similar requirement

"Still, the answerer MUST ensure that it does not needlessly consume large amounts of memory or CPU resources when processing those as well as be prepared to handle the case where a large number of potential configurations still need to be processed."

I don't know how one would objectively verify that an implementation meets this requirement. That will make it hard to progress this document later, when folks have to demonstrate that implementations meet all the MUSTs.
--============_-988643238==_ma============-- --===============1492250325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============1492250325==-- From secdir-bounces@ietf.org Thu Oct 9 14:16:13 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C043A68DB; Thu, 9 Oct 2008 14:16:13 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021F93A68DB for ; Thu, 9 Oct 2008 14:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.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 bqWjmUarQJ7x for ; Thu, 9 Oct 2008 14:16:11 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 03AF53A67D0 for ; Thu, 9 Oct 2008 14:16:10 -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 m99LGoUc006132 for ; Thu, 9 Oct 2008 17:16: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 m99LGlws006106 for ; Thu, 9 Oct 2008 17:16:48 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m99LGegn013046 for ; Thu, 9 Oct 2008 17:16:40 -0400 (EDT) X-ASG-Whitelist: Barracuda Reputation Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 595D4BB30CE for ; Thu, 9 Oct 2008 17:16:40 -0400 (EDT) Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.54.46.187) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 9 Oct 2008 14:16:38 -0700 Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.110.52]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.54.46.187]) with mapi; Thu, 9 Oct 2008 14:16:39 -0700 From: Charlie Kaufman To: "secdir@mit.edu" , "jdrosen@cisco.com" , "dean.willis@softarmor.com" , "drage@alcatel-lucent.com" Date: Thu, 9 Oct 2008 14:16:35 -0700 Thread-Topic: Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt Thread-Index: AckqVE+2+ygG9NRLRcW6u0YXNx2iMQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m99LGlws006106 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: [secdir] Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 lists and categorizes all of the RFCs and Internet Drafts concerning SIP with a goal of helping someone who is trying to find the right document do so. It contains a short paragraph summarizing each document. As such this document raises no new security considerations (and says so, pointing readers at the security considerations sections of the underlying documents). In the context of this document, that seems entirely appropriate. Note to authors and WG chairs: There is a problem with this document in that it will quickly become out of date as RFCs are updated, I-Ds are promoted to RFC or abandoned, and new I-Ds are created. I could imagine the RFC editor blocking its promotion until all of the referenced I-Ds are either promoted or abandoned, by which time it would certainly be obsolete. It might be that this document will need to "permanently" be an I-D unless at some point in the future activity in the SIP space drops off dramatically. I don't know whether there is precedent for such a document. There probably should be such a document for each area or sub-area. Typo: p5 "identifes"-> "identifies" --Charlie _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 9 15:47:13 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FA13A67FD; Thu, 9 Oct 2008 15:47:13 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC09D3A67FD for ; Thu, 9 Oct 2008 15:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-0.456, 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 pnqRHBHhjrF5 for ; Thu, 9 Oct 2008 15:47:11 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id E2C613A67EC for ; Thu, 9 Oct 2008 15:47:10 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id m99Ml944009786 for ; Thu, 9 Oct 2008 18:47:10 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id m99Ml98w009783 for ; Thu, 9 Oct 2008 18:47:09 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 9 Oct 2008 18:47:09 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Thu, 09 Oct 2008 18:47:10 -0400 (EDT) Subject: [secdir] Assignments for October 16th 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org As a reminder, the secdir list is now hosted at ietf.org. Chris Lonvick is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam Last calls & special requests: Lakshminath Dondeti draft-ietf-enum-combined-08 Lakshminath Dondeti draft-ietf-avt-rfc4749-dtx-update-02 Phillip Hallam-Baker draft-ietf-psamp-info-10 Steve Hanna draft-rescorla-tls-suiteb-07 David Harrington draft-ietf-sip-xcapevent-04 Love Hornquist-Astrand draft-ietf-sip-sips-08 Jeffrey Hutzelman draft-ietf-sip-rph-new-namespaces-03 Scott Kelly draft-ietf-ccamp-rfc4420bis-03 Tero Kivinen draft-ietf-sip-media-security-requirements-07 Julien Laganier draft-ietf-softwire-mesh-framework-05 Julien Laganier draft-ietf-softwire-encaps-ipsec-01 Julien Laganier draft-ietf-sipping-cc-transfer-10 Marcus Leech draft-ietf-dnsext-forgery-resilience-07 Chris Lonvick draft-cridland-urlfetch-binary-03 Catherine Meadows draft-ietf-speechsc-mrcpv2-16 Catherine Meadows draft-ietf-behave-dccp-03 Alexey Melnikov draft-ietf-pce-pcep-xro-06 Alexey Melnikov draft-ietf-behave-stun-test-vectors-03 Sandy Murphy draft-ietf-mpls-mpls-and-gmpls-security-framework-03 Sandy Murphy draft-ietf-idr-as-representation-01 Vidya Narayanan draft-ietf-lemonade-imap-notify-07 Magnus Nystrom draft-ietf-vrrp-unified-spec-02 Hilarie Orman draft-ietf-pce-path-key-03 Carl Wallace R draft-hartman-webauth-phishing-09 Sam Weiler draft-chown-v6ops-rogue-ra-01 Brian Weis draft-ietf-mediactrl-sip-control-framework-04 Nico Williams draft-ietf-v6ops-ra-guard-01 Larry Zhu draft-thaler-v6ops-teredo-extensions-01 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 9 23:58:54 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03243A6843; Thu, 9 Oct 2008 23:58:54 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0D428C0E3 for ; Thu, 9 Oct 2008 23:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=2.050, 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 F4f563tk07Xe for ; Thu, 9 Oct 2008 23:58:10 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id EFC383A67D0 for ; Thu, 9 Oct 2008 23:58:05 -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 m9A6wmYD031357 for ; Fri, 10 Oct 2008 02:58:49 -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 m9A1d77T020492 for ; Thu, 9 Oct 2008 21:39:07 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9A1cxkG027918 for ; Thu, 9 Oct 2008 21:38:59 -0400 (EDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 490EDB8FE08 for ; Thu, 9 Oct 2008 21:38:57 -0400 (EDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m9A1clKB003241; Thu, 9 Oct 2008 20:38:51 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 20:38:48 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 03:38:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 03:38:44 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180023B0A13@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt Thread-Index: AckqVE+2+ygG9NRLRcW6u0YXNx2iMQAIhIhg References: From: "DRAGE, Keith (Keith)" To: "Charlie Kaufman" , , , X-OriginalArrivalTime: 10 Oct 2008 01:38:45.0320 (UTC) FILETIME=[EF221480:01C92A78] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9A1d77T020492 X-Mailman-Approved-At: Fri, 10 Oct 2008 02:58:47 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Thu, 09 Oct 2008 23:58:53 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org The agreement in the SIP group was that we would try and update this document every 12 - 18 months. So we certainly do not want the document held by the RFC editor to complete these references. We will always fix that in a revision. Regards Keith > -----Original Message----- > From: Charlie Kaufman [mailto:charliek@microsoft.com] > Sent: Thursday, October 09, 2008 10:17 PM > To: secdir@mit.edu; jdrosen@cisco.com; > dean.willis@softarmor.com; DRAGE, Keith (Keith) > Subject: Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt > > 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 lists and categorizes all of the RFCs and > Internet Drafts concerning SIP with a goal of helping someone > who is trying to find the right document do so. It contains a > short paragraph summarizing each document. > > As such this document raises no new security considerations > (and says so, pointing readers at the security considerations > sections of the underlying documents). In the context of this > document, that seems entirely appropriate. > > Note to authors and WG chairs: There is a problem with this > document in that it will quickly become out of date as RFCs > are updated, I-Ds are promoted to RFC or abandoned, and new > I-Ds are created. I could imagine the RFC editor blocking its > promotion until all of the referenced I-Ds are either > promoted or abandoned, by which time it would certainly be > obsolete. It might be that this document will need to > "permanently" be an I-D unless at some point in the future > activity in the SIP space drops off dramatically. I don't > know whether there is precedent for such a document. There > probably should be such a document for each area or sub-area. > > Typo: p5 "identifes"-> "identifies" > > > --Charlie > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 10 04:44:05 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DB03A6A85; Fri, 10 Oct 2008 04:44:05 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0633A69C5 for ; Fri, 10 Oct 2008 04:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 HPcJRaok5R4X for ; Fri, 10 Oct 2008 04:44:02 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id C57973A6A85 for ; Fri, 10 Oct 2008 04:44:02 -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 m9ABikEu016644 for ; Fri, 10 Oct 2008 07:44:46 -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 m9ABigir016630 for ; Fri, 10 Oct 2008 07:44:43 -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 m9ABiWT3026636 for ; Fri, 10 Oct 2008 07:44:32 -0400 (EDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id BE0A11139A90 for ; Fri, 10 Oct 2008 07:44:08 -0400 (EDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 282C820A6C; Fri, 10 Oct 2008 13:44:07 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-33-48ef4006a2fb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB58320A52; Fri, 10 Oct 2008 13:44:06 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 13:44:02 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 13:44:02 +0200 Received: from [131.160.37.21] (E000FB0F665DD.lmf.ericsson.se [131.160.37.21]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0A0582356; Fri, 10 Oct 2008 14:44:02 +0300 (EEST) Message-ID: <48EF4001.9040308@ericsson.com> Date: Fri, 10 Oct 2008 14:44:01 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Tobias Gondrom References: <48D96350.7030402@gondrom.org> In-Reply-To: <48D96350.7030402@gondrom.org> X-OriginalArrivalTime: 10 Oct 2008 11:44:02.0212 (UTC) FILETIME=[7DB00640:01C92ACD] X-Brightmail-Tracker: AAAAAA== X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: secdir@mit.edu, jmpolk@cisco.com, The IESG , sdhesika@cisco.com Subject: Re: [secdir] SECDIR review of draft-ietf-mmusic-qos-identification-01 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org SGkgVG9iaWFzLAoKdGhhbmtzIGZvciB5b3VyIHJldmlldy4gSSBoYXZlIHJldmlzZWQgdGhlIGRy YWZ0IHBlciB5b3VyIHN1Z2dlc3Rpb25zOgoKaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1tbXVzaWMtcW9zLWlkZW50aWZpY2F0aW9uLTAyLnR4dAoKQ2hlZXJz LAoKR29uemFsbwoKVG9iaWFzIEdvbmRyb20gd3JvdGU6Cj4gSGVsbG8sCj4gCj4gSSBoYXZlIHJl dmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cwo+IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZQo+IElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFy aWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUKPiBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9j dW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdAo+IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLgo+IAo+IE92ZXJhbGwsIHRo ZSBkb2N1bWVudCBpcyBjbGVhciBhbmQgb2suIFRoZSBvbmx5IHNlY3VyaXR5IHJldmlldyBjb21t ZW50Cj4gSSBoYXZlLCBpcyBtaW5vciBhbmQgcmVnYXJkcyB0ZXh0IGluIHRoZSAiU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMiCj4gc2VjdGlvbi4KPiAKPiBTb21lIGFkZGl0aW9uYWwgbm9uLXNlY3Vy aXR5IG1pbm9yIGNvbW1lbnRzIGZpcnN0Ogo+IC0gQ09NTUVOVDogTm90ZTogVGhlIGRvY3VtZW50 IGhhcyBleHBpcmVkIGluIEp1bHkgMjAwOC4KPiAtIENPTU1FTlQ6IHlvdSBzaG91bGQgcmVjb25z aWRlciB0aGUgcmVmZXJlbmNlIHNlY3Rpb24gYXMgaXQncyB1c2luZwo+IG9ic29sZXRlZCBub3Jt YXRpdmUgcmVmZXJlbmNlczoKPiAoU2VlIFJGQ3MgMzk2NyBhbmQgNDg5NyBmb3IgaW5mb3JtYXRp b24gYWJvdXQgdXNpbmcgbm9ybWF0aXZlIHJlZmVyZW5jZXMKPiAgICAgIHRvIGxvd2VyLW1hdHVy aXR5IGRvY3VtZW50cyBpbiBSRkNzKQo+ICAgKiogT2Jzb2xldGUgbm9ybWF0aXZlIHJlZmVyZW5j ZTogUkZDIDI0MzQgKE9ic29sZXRlZCBieSBSRkMgNTIyNikKPiAgICoqIERvd25yZWY6IE5vcm1h dGl2ZSByZWZlcmVuY2UgdG8gYW4gSW5mb3JtYXRpb25hbCBSRkM6IFJGQyA0MDgwCj4gICAqKiBP YnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgNDIzNCAoT2Jzb2xldGVkIGJ5IFJGQyA1 MjM0KQo+IAo+IC0gQ09NTUVOVDoKPiBJbiBBYnN0cmFjdDoKPiB0aGUgZmlyc3Qgc2VudGVuY2Ug aXMgaGFkciB0byB1bmRlcnN0YW5kOgo+IOKAnlRoZSBvZmZlci9hbnN3ZXIgbW9kZWwgZm9yIFNE UCBhc3N1bWVzIHRoYXQgZW5kcG9pbnRzIGVzdGFibGlzaCwKPiAgICBzb21laG93LCB0aGUgUW9T IHJlcXVpcmVkIGZvciB0aGUgbWVkaWEgc3RyZWFtcyB0aGV5IGVzdGFibGlzaC7igJwKPiAgbWF5 YmUgY2hhbmdlIHRvOgo+IOKAnlRoZSBvZmZlci9hbnN3ZXIgbW9kZWwgZm9yIFNEUCBhc3N1bWVz IHRoYXQgZW5kcG9pbnRzIGVzdGFibGlzaCBzb21laG93Cj4gdGhlIFFvUyByZXF1aXJlZCBmb3Ig dGhlIG1lZGlhIHN0cmVhbXMgdGhleSBlc3RhYmxpc2gu4oCcCj4gT3IgcmV3b3JkIHRoaXMgc2Vu dGVuY2UgZm9yIGVhc2llciB1bmRlcnN0YW5kaW5nPwo+IAo+IAo+IEFuZCBmaW5hbGx5IGluIHRo ZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uczoKPiAtIENPTU1FTlQ6Cj4gVGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIFNlY3Rpb24gc3RhdGVzIGNvcnJlY3RseSB0aGUgcmlzayBvZiBhbgo+IGF0 dGFja2VyIHRyeWluZyB0byBhZGQvcmVtb3ZlL21vZGlmeSAncW9zLW1lY2gtc2VuZCcgYW5kL29y Cj4gJ3Fvcy1tZWNoLXJlY3YnIGF0dHJpYnV0ZXMgZnJvbSBhIHNlc3Npb24gZGVzY3JpcHRpb24u Cj4gUHJvdGVjdGVkIHNlc3Npb25zIGFsc28gU0hPVUxEIGJlIGF1dGhlbnRpY2F0ZWQgKGF0IGxl YXN0IHRvIHRoZSBleHRlbmQKPiB0aGF0IHRoZSBtZXNzYWdlIHNlbmRlciBpcyBpZGVudGljYWwg dG8gdGhlIGluaXRpYWwgZW50aXR5IGFuZCBub3QgYW4KPiBhdHRhY2tlciB0cnlpbmcgdG8gaW5q ZWN0IGEgbWVzc2FnZSB3aXRoIGRpZmZlcmVudCBRb1MgcGFyYW1ldGVycy4KPiBVc3VhbCBpbnRl Z3JpdHkgcHJvdGVjdGlvbiBtZWNoYW5pc21zIChpbmNsdWRpbmcgdGhlIG9uZXMgbmFtZWQgYXMK PiBleGFtcGxlcyBpbiB0aGUgZHJhZnQsIGUuZy4gUy9NSU1FKSBhbHNvIHByb3ZpZGUgc29tZSBh dXRoZW50aWNhdGlvbgo+IG1lY2hhbmlzbXMgYW5kIHRoZXJlZm9yZSB1c3VhbGx5IGZ1bGZpbGwg dGhpcyBuZWVkLCBidXQgdGhpcyBtYXkgbm90Cj4gYWx3YXlzIGJlIHRoZSBjYXNlLiBUaGVyZWZv cmUgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBjb3VsZCBiZSBtb2RpZmllZAo+IGFjY29yZGluZ2x5 Ogo+IG9sZDog4oCeQ29uc2VxdWVudGx5LCBpdCBpcyBzdHJvbmdseSBSRUNPTU1FTkRFRCB0aGF0 IGludGVncml0eSBwcm90ZWN0aW9uIGJlCj4gICAgYXBwbGllZCB0byBTRFAgc2Vzc2lvbiBkZXNj cmlwdGlvbnMgY2FycnlpbmcgdGhlc2UgYXR0cmlidXRlcy7igJwKPiA9PiBuZXc6ICJDb25zZXF1 ZW50bHksIGl0IGlzIHN0cm9uZ2x5IFJFQ09NTUVOREVEIHRoYXQgaW50ZWdyaXR5IGFuZAo+IGF1 dGhlbnRpY2l0eSBwcm90ZWN0aW9uIGJlCj4gICAgYXBwbGllZCB0byBTRFAgc2Vzc2lvbiBkZXNj cmlwdGlvbnMgY2FycnlpbmcgdGhlc2UgYXR0cmlidXRlcy4iCj4gCj4gQmVzdCByZWdhcmRzLAo+ IAo+IFRvYmlhcwo+IAo+IAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18Kc2VjZGlyIG1haWxpbmcgbGlzdApzZWNkaXJAbWl0LmVkdQpodHRwczovL21haWxt YW4ubWl0LmVkdS9tYWlsbWFuL2xpc3RpbmZvL3NlY2RpcgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpzZWNkaXIgbWFpbGluZyBsaXN0CnNlY2RpckBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcgo= From secdir-bounces@ietf.org Fri Oct 10 10:50:58 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574B93A698E; Fri, 10 Oct 2008 10:50:58 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4243A697B for ; Fri, 10 Oct 2008 10:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.266 X-Spam-Level: X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 55zMe0qpnzJG for ; Fri, 10 Oct 2008 10:50:56 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 0B2BA3A689F for ; Fri, 10 Oct 2008 10:50:55 -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 m9AHpfrN021643 for ; Fri, 10 Oct 2008 13:51:41 -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 m9AHpaWN021625 for ; Fri, 10 Oct 2008 13:51:36 -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 m9AHpTKV008658 for ; Fri, 10 Oct 2008 13:51:29 -0400 (EDT) X-ASG-Whitelist: Barracuda Reputation Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2946511280EA for ; Fri, 10 Oct 2008 13:51:29 -0400 (EDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 10 Oct 2008 10:51:28 -0700 Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.110.53]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.18.53]) with mapi; Fri, 10 Oct 2008 10:51:26 -0700 From: Charlie Kaufman To: "DRAGE, Keith (Keith)" , "secdir@mit.edu" , "jdrosen@cisco.com" , "dean.willis@softarmor.com" Date: Fri, 10 Oct 2008 10:51:24 -0700 Thread-Topic: Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt Thread-Index: AckqVE+2+ygG9NRLRcW6u0YXNx2iMQAIhIhgACKK9fA= Message-ID: References: <5D1A7985295922448D5550C94DE29180023B0A13@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180023B0A13@DEEXC1U01.de.lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9AHpaWN021625 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: Re: [secdir] Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org That should probably be mentioned in the introduction. Is that concept cleared with the RFC Editor? Generally, RFCs can't reference I-Ds, but clearly in this case that's what you want. --Charlie -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Thursday, October 09, 2008 6:39 PM To: Charlie Kaufman; secdir@mit.edu; jdrosen@cisco.com; dean.willis@softarmor.com Subject: RE: Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt The agreement in the SIP group was that we would try and update this document every 12 - 18 months. So we certainly do not want the document held by the RFC editor to complete these references. We will always fix that in a revision. Regards Keith > -----Original Message----- > From: Charlie Kaufman [mailto:charliek@microsoft.com] > Sent: Thursday, October 09, 2008 10:17 PM > To: secdir@mit.edu; jdrosen@cisco.com; > dean.willis@softarmor.com; DRAGE, Keith (Keith) > Subject: Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt > > 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 lists and categorizes all of the RFCs and > Internet Drafts concerning SIP with a goal of helping someone > who is trying to find the right document do so. It contains a > short paragraph summarizing each document. > > As such this document raises no new security considerations > (and says so, pointing readers at the security considerations > sections of the underlying documents). In the context of this > document, that seems entirely appropriate. > > Note to authors and WG chairs: There is a problem with this > document in that it will quickly become out of date as RFCs > are updated, I-Ds are promoted to RFC or abandoned, and new > I-Ds are created. I could imagine the RFC editor blocking its > promotion until all of the referenced I-Ds are either > promoted or abandoned, by which time it would certainly be > obsolete. It might be that this document will need to > "permanently" be an I-D unless at some point in the future > activity in the SIP space drops off dramatically. I don't > know whether there is precedent for such a document. There > probably should be such a document for each area or sub-area. > > Typo: p5 "identifes"-> "identifies" > > > --Charlie > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 10 11:43:42 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473C73A67F5; Fri, 10 Oct 2008 11:43:42 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27993A684F for ; Fri, 10 Oct 2008 11:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 vpLheP0YG9kc for ; Fri, 10 Oct 2008 11:43:40 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1AB0C3A67F5 for ; Fri, 10 Oct 2008 11:43:39 -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 m9AIiQxU001730 for ; Fri, 10 Oct 2008 14:44:26 -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 m9AIiOD4001726 for ; Fri, 10 Oct 2008 14:44:24 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9AIiG1l017764 for ; Fri, 10 Oct 2008 14:44:16 -0400 (EDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7BF68131E290 for ; Fri, 10 Oct 2008 14:43:55 -0400 (EDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9AIhsDr012434 for ; Fri, 10 Oct 2008 14:43:54 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9AIhrAP202260 for ; Fri, 10 Oct 2008 12:43:53 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9AIhq2I008876 for ; Fri, 10 Oct 2008 12:43:53 -0600 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9AIhpwK008791; Fri, 10 Oct 2008 12:43:52 -0600 Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1223664234.1010; Fri, 10 Oct 2008 14:43:54 -0400 Date: Fri, 10 Oct 2008 14:43:49 -0400 From: Barry Leiba To: Charlie Kaufman , "DRAGE, Keith (Keith)" , secdir@mit.edu, jdrosen@cisco.com, dean.willis@softarmor.com Message-ID: <87A21710058345B08EC77984@Uranus-009002042072.watson.ibm.com> In-Reply-To: References: <5D1A7985295922448D5550C94DE29180023B0A13@DEEXC1U01.de.lucent.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: Re: [secdir] Secdir review of draft-ietf-sip-hitchhikers-guide-05.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org > That should probably be mentioned in the introduction. Is that concept cleared > with the RFC Editor? Generally, RFCs can't reference I-Ds, but clearly in this > case that's what you want. Standards-track RFCs can't mention I-Ds normatively. This is not on the standards track, nor are the references normative. Barry _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 10 13:00:00 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864D23A687C; Fri, 10 Oct 2008 13:00:00 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628E93A68FB for ; Fri, 10 Oct 2008 12:59: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 SPAUHTCmjT2B for ; Fri, 10 Oct 2008 12:59:58 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 310FD3A6844 for ; Fri, 10 Oct 2008 12:59:58 -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 m9AK0hrV019322 for ; Fri, 10 Oct 2008 16:00:43 -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 m9AK0gFd019310 for ; Fri, 10 Oct 2008 16:00:42 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9AK0ZYd008061 for ; Fri, 10 Oct 2008 16:00:35 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 1DDB5BB2310 for ; Fri, 10 Oct 2008 16:00:33 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.33,391,1220227200"; d="scan'208";a="94282972" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2008 20:00:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9AK0W17032026; Fri, 10 Oct 2008 13:00:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9AK0Wcu024296; Fri, 10 Oct 2008 20:00:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 13:00:32 -0700 Received: from [128.107.163.243] ([128.107.163.243]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 13:00:31 -0700 Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <70CAEDA7-B4AB-4947-9522-4D148B5FE28B@cisco.com> From: Brian Weis Date: Fri, 10 Oct 2008 13:02:21 -0700 To: cboulton@avaya.com, tim.melanchuk@gmail.com, scott.mcglashan@hp.com X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 10 Oct 2008 20:00:31.0857 (UTC) FILETIME=[D9B31E10:01C92B12] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3972; t=1223668832; x=1224532832; 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-mediactrl-sip -control-framework-04 |Sender:=20; bh=gntE2awqUT8EvTM6ZTwz+bsXcPAzj/AhfllHYkS77bY=; b=Tjg0eRzjS6AurddwymF7LzR0RdQZhWrwb4SpWmy2Dvw/kh6/OMH6R3o3dD G/47lStxHTvIzkik9HbwvPkfXfdaTDUSON5OSVnF0Fn/j1J6Y76k2KnlszUp R+jRaKqZls; Authentication-Results: sj-dkim-2; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: "secdir@MIT.EDU" , Spencer Dawkins , Eric Burger Subject: [secdir] Secdir review of draft-ietf-mediactrl-sip-control-framework-04 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments. This document details mechanisms for establishing, using, and terminating a reliable transport connection channel using SIP and the Session Description Protocol offer/answer [RFC3264] exchange. The connection channel is setup via a separate SIP session, and the two sessions are bound together via an identifier (cfw-id). Peer authentication and transport security are the primary security considerations for this mechanism. To address these concerns, the document requires an implementation to support TLS and recommends its use. The cfw-id has some security ramifications in that it is used to identify particular sessions, bind sessions together, and is used to identify a particular application session. Specific security related comments on the document follow. Section 4.1. This section mandates an implementation support TLS, but it isn't clear whether this mandate is restricted to the Control Channel or includes the Control SIP Dialog. I would expect that it intends to cover both protocols. Please clarify hear and in Section 11.2. Section 6.1. The first paragraph says "The transaction identifier MUST be globally unique over space and time with at least 64 bits of randomness." This seems to be an important requirement, and it's rationale should be described here or in the security considerations. For example, perhaps the intention was for a purely random number to mitigate one client from spoofing another client within a server application. Maintaining hard-to-guess identities may be especially important given that a "session" consists of two distinct protocols between the client and server, where the server application uses the cfw-id to join their state. Section 10. TLS is recommended by this document. If feasible, the example in this section should include it. Section 11. This paragraph says "Channel Framework is designed to comply with the security-related requirements documented in the control protocol requirements document[RFC5167]." The requirements being referenced should be named (e.g., REQ-MCP-11? REQ-MCP-12?). Section 11.1. Regarding the sentence "the Media Channel Control Framework should make full use of mechanism provided by the SIP protocol", you should state which mechanisms and what protections they provide. Section 11.2. Regarding the phrase "Clients and servers must be properly authenticated ....". This should say "authenticated and authorized". This section lists "both confidentiality and integrity". Replay protection is another important transport level protection that should be added to the list. Section 11.3. Is the text "It should be noted that this document does not specifically carry any specific mechanism to overcome such conflicts but will provide a summary of how it can be achieved." referring to the following paragraph? If so, it would be helpful to say so. One additional policy consideration worth mentioning would be a need for an application to maintain which cfw-id is associated with which socket identifier, and verify that the cfw-id received by a client was correct for that socket. This would protect a server against one client spoofing another client. (Even if mutual TLS authentication is used on the control channel, it does not provide any assurance as to the correctness of the application data carried within the TLS session, including the cfw-id.) -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Oct 12 22:58:58 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7D03A6A27; Sun, 12 Oct 2008 22:58:58 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C631A3A67A7 for ; Fri, 10 Oct 2008 14:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 c97N7ri3W2t6 for ; Fri, 10 Oct 2008 14:52:21 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 985BE3A6A62 for ; Fri, 10 Oct 2008 14:52:21 -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 m9ALr8dm009724 for ; Fri, 10 Oct 2008 17:53:08 -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 m9ALr5fu009721 for ; Fri, 10 Oct 2008 17:53:05 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9ALqrfv001889 for ; Fri, 10 Oct 2008 17:52:54 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 15F89118FEDE for ; Fri, 10 Oct 2008 17:52:32 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.33,391,1220227200"; d="scan'208";a="107922373" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2008 21:52:31 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9ALqVaO031137; Fri, 10 Oct 2008 14:52:31 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m9ALqMrB021861; Fri, 10 Oct 2008 21:52:31 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 17:52:26 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 17:52:26 -0400 Message-ID: <48EFCE98.4000004@cisco.com> Date: Fri, 10 Oct 2008 17:52:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Larry Zhu References: In-Reply-To: X-OriginalArrivalTime: 10 Oct 2008 21:52:26.0397 (UTC) FILETIME=[7BE09CD0:01C92B22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3406; t=1223675551; x=1224539551; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20SECDIR=20review=20of=20draft-ietf-sippi ng-race-examples-06 |Sender:=20; bh=gdD2A0Xl035dF/bpY7FykW7mr3xC6F8BmJZkxsRw2NU=; b=dz1zNwPzHD8oI38PpE6Tg0kzVt93j5bKgKUj1WcHGQRn14T2ZrBeejP/pG sj2Y0mvn8+53ZgYCkc8/moSpFmIgk/5ohpSfs3V8eHezQCTgJ0UbgDs0Q2M5 muOCcfqftM; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Sun, 12 Oct 2008 22:58:57 -0700 Cc: "suzuki.yasushi@lab.ntt.co.jp" , "secdir@mit.edu" , "drage@alcatel-lucent.com" , "tomoyuki.yoshikawa@east.ntt.co.jp" , "hasebe.miki@east.ntt.co.jp" , "j.koshiko@east.ntt.co.jp" , "iesg@ietf.org" , "dean.willis@softarmor.com" Subject: Re: [secdir] SECDIR review of draft-ietf-sipping-race-examples-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Larry Zhu 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. > > Overall the document is clear. I have the following comments: > > 1. The title of the document does not seem to reflect the content of the document. The document seems to describe implementation pitfalls in SIP, not racing conditions. > > See http://en.wikipedia.org/wiki/Race_condition, a race condition is perceived as a flaw. Throughout the document I am not convinced the SIP protocol is flawed. Rather, the document seems to suggest that implementations flaws can be avoided if the asynchronous nature of the SIP message processing is taken into considerations. The body of the document at various places suggests this document contains just clarifications to RFC3261. I suspect that the word "clarifications" might be used to better describe what the document is about. Point taken. I'm struggling to come up with something that is more appropriate and also works as a document title/name. And its hard. Clarifications of race condition handling in the Session Initiation Protocol draft-ietf-sipping-race-condition-clarifications.txt draft-ietf-sipping-race-condition-handling.txt Resolution of race conditions in the Session Initiation Protocol draft-ietf-sipping-race-condition-resolution.txt Neither seems perfect to me, but I guess either would do and be more meaningful than the current name. Of course if we change the file name we will be back to -00. :-( Thanks, Paul > 2. Section 1, paragraph 3, the word "UA". This should be expanded on the first use. > > 3. Section 1, paragraph 5, the word "SDP". This should be expanded on the first use. > > 4. Section 1, paragraph 4, last sentence. Consider s/standard/robust/. I suspect the later word is intended. > > 5. section 1.3, there is line with just "actors", I do not understand why the extra line is there. > > 6. Section 1.3, " (Which differs somewhat from the definition of the term in RFC 3261.)". This sentence is confusing and not substantiated. I am not sure why the session definition is "somewhat" different. This could be expanded or just removed since it adds confusions for the reader (as least for me). > > 7. Section 2, under figure 1, "Where (r) is not used as an indicator, "response" means receive, and "request" means send." I do not understand what this sentence because I could not find either the word "response" or the word "request" in the diagram. > > 8. Section 2, under figure 2. Ditto. We will take care of all these. > 9. There are over 10 pages of text in the appendix portion of the document. If this document were titled as "clarifications to RFC3261", these appendices probably should be moved into the main body of the document. This has been discussed elsewhere. Technically they aren't about race conditions, but they are similar sorts of things that people have had question about. There has been some suggestion to make them another document, but nobody can justify the extra work that would take. We've been hoping we could just get by the way it is. Thanks, Paul _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Oct 12 22:58:58 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5593D3A6B7D; Sun, 12 Oct 2008 22:58:58 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8ECA28B23E for ; Sun, 12 Oct 2008 20:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 dW9yxQ0Op1Pi for ; Sun, 12 Oct 2008 20:37:08 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 04B373A6A6A for ; Sun, 12 Oct 2008 20:37:07 -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 m9D3bNJU023839 for ; Sun, 12 Oct 2008 23:37:23 -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 m9D3b8e0023806 for ; Sun, 12 Oct 2008 23:37:08 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9D3aw9b018769 for ; Sun, 12 Oct 2008 23:36:58 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 8F1341110E5F for ; Sun, 12 Oct 2008 23:36:36 -0400 (EDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m9D3bNtA022006; Sun, 12 Oct 2008 22:37:24 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Oct 2008 22:36:29 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Oct 2008 22:36:28 -0500 Message-ID: <48F2C29B.8090900@ericsson.com> Date: Sun, 12 Oct 2008 23:38:03 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Kurt Zeilenga References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> In-Reply-To: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> X-OriginalArrivalTime: 13 Oct 2008 03:36:28.0869 (UTC) FILETIME=[E0935F50:01C92CE4] X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Sun, 12 Oct 2008 22:58:57 -0700 Cc: Tim Polk , secdir@mit.edu, dthaler@microsoft.com, v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns-00 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Kurt, Thank you very much for your detailed review and sorry for the long delay in our response. We have modified the draft to address some of your concerns. We also had a few questions for you. Please find our responses inline. Kurt Zeilenga wrote: > I have reviewed this document as part of the security directorate's > ongoing review efforts. These comments were written primarily for the > benefit of the security area directors. Document editors and WG chairs > should treat these comments just like they would treat comments from any > other IETF contributor. > > This document discusses "Security Concerns with [IP] Tunnels". > > I suggest the Security AD pay particular attention to this I-D. Given > it purports to discuss security concerns applicable to a wide range of > [IP] tunneling solutions, it may be appropriate for this I-D to be > assigned to additional secdir reviewers. > > Comments: > > The title and abstract apply this document discusses a wide range of > tunnel technologies, but the text seems focused on IP Tunnels (though I > guess some of the concerns might apply to various non-IP network > tunnels). It might be appropriate to change the title to "Security > Concerns with IP Tunneling", and to clarify the abstract. We have changed the title to "Security Concerns With IP Tunneling" as you suggested. > > My comments assume "IP tunneling" was meant. > > It's not clear what track this I-D is targeted for. I will assume > Informational. Yes. This is meant to be informational > The abstract seems a bit short. > The abstract starts off with: >> A number of security concerns with tunnels are documented. > > where? In this document or elsewhere? If elsewhere, I would hope the > body will detail and provide references to where these concerns are > documented. In this document. We have fixed the abstract to say this. The new abstract is attached below > > The abstract ends with: >> The >> primary intent of this document is to raise the awareness regarding >> the security issues with tunnels as deployed today. > > It's not clear who the intended audience is of this document. > Implementors? Network Operators? Deployers? Etc. But it does say "as > deployed today", which I take as meaning that this document focuses on > security issues in existing IP tunneling solutions. The intended audience is network admins and future protocol developers. We have changed the abstract to read: " A number of security concerns with IP tunnels are documented in this document. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness regarding the security issues with IP tunnels as deployed today. " > > The Introduction says: >> The primary intent of this document is to provide information that can >> be used in any new or updated tunnel protocol specification. > > I don't read either of these 'primary intent' statements as being > equivalent to the other. > 2.1.2 says, >> Evasion by tunneling is often a problem for network-based security >> devices such as network firewalls, intrusion detection and prevention >> systems, and router controls. > > which leads to 2.1.3 recommendation: >> Security administrators who do not consider tunneling an acceptable >> risk should disable tunnel functionality unless their network-based >> security controls adequately recognize the tunneled traffic. > > If the network-based security controls don't have adequate ability to > recognize tunneled traffic, how does the security administrator go about > disabling tunneled traffic? Is the administrator to turn off everything > that might carry a tunnel? If so, wouldn't that be just about everything? One way to go about doing this is to disable the specific tunneling method on the end-hosts. We have added the following text " Security administrators who do not consider tunneling an acceptable risk should disable tunnel functionality either on the end-nodes (hosts) or on the network nodes." to mention this possibility. > In 2.1.3 says: >> To minimize security exposure due to tunnels, we recommend that a >> tunnel be an interface of last resort, independent of IP version. >> Specifically, we suggest that when both native and tunneled access to >> a remote host is available, that the native-based access be used in >> preference to tunneled access. This should also promote greater >> efficiency and reliability. > > This recommendation appears to ignore cases where the tunnel offers data > protective services not available natively. We have changed " Specifically, we suggest that when both native and tunneled access to a remote host is available, that the native access be used in preference to tunneled access." to " Specifically, we suggest that when both native and tunneled access to a remote host is available, that the native access be used in preference to tunneled access except when the tunnel endpoint is known to not bypass security (e.g., an IPsec tunnel to a gateway provided by the security administrator of the network)." in order to allow tunnels offering protective service to still be preferred. > >> Given concerns about tunnel security or a network's lack of >> preparedness for tunnels, a network administrator may wish to simply >> block all use of tunnels. He or she may wish to do so using network >> controls; this could be either due to not having confidence in the >> ability to disable it on all hosts attached to the network or due to >> wanting an extra layer of prevention. > > It may be appropriate to note here that by "simply blocking all use of > tunnels", the network administrator hinders the ability of users from > taking steps to gain security benefit provided by use of tunnels. We have added the phrase "that subvert security" to the end of this sentence so that it reads " Given concerns about tunnel security or a network's lack of preparedness for tunnels, a network administrator may wish to simply block all use of tunnels that subvert security." > >> One simple method to do that is easy to employ for many tunnel >> protocols is to block outbound packets to the UDP or TCP port used >> (e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.). > > The description of this method is not precise. Is the method to block > dest ports, with these source ports, or either, or both? The method is to block destination ports. We have changed this sentence to read (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP, etc.) > >> It is not known if blocking all traffic to a given outbound port >> will interfere with >> non-tunneled traffic. > > Actually, I think it is generally known that blocking all traffic to a > given outbound port may very well interfere with non-tunnel traffic. > The document statement seems to discount operational experience of > simply blocking all traffic to a given outbound port may be harmful. We have changed this text to read " In some cases, however, blocking all traffic to a given outbound port (e.g., port 80) may interfere with non-tunneled traffic so this should be used with caution." > > In 3.1.3, >> Tunneling over UDP or TCP (including HTTP) to reach the Internet is >> not recommended as a solution for managed networks. > First, I'm going to read the sentence as if the word 'managed' was not > used as I think all networks on the Internet are 'managed' to some > degree. If the authors had a particular definition of the term 'managed > network' in mind, they should define it. > > So reading the sentence without the term 'managed', this is basically a > general applicability statement that use of tunneling over UDP or TCP is > not recommend for use to 'reach the Internet'. I don't see this > recommendation as being appropriate given the issue. We have changed this text to read " Tunneling over UDP or TCP (including HTTP) to reach the Internet is not recommended as a solution for networks that wish to enforce security polcies on the user traffic. (Windows, for example, disables Teredo by default if it detects that it is within an enterprise network that contains a Windows domain controller.)" > > In 3.2.3, >> As illustrated above, it should be clear that inspecting the contents >> of tunneled data packets is highly complex and often impractical. > > I would argue that inspecting the contents of non-tunneled data packets > is also highly complex and often impractical. We agree with you and we are not claiming otherwise. >> For this reason, if a network wishes to monitor IP traffic, tunneling >> is not recommended. > > I think it depends on what kind of IP traffic monitoring one wants to > do. Also, if the user doesn't want there data monitored, recommending > use of tunneling with data confidential protections seems quite > appropriate. > The term "NAT" appears to be used to refer to a device (e.g., "a NAT") > not a process (of address translation). This seems improper given that > NAT expands to Network Address Translation. We have changed the document to say "NAT device" when we talk about the device and NAT when we talk about the process, as you stated. > Many acronyms are not spelled out. > > Given this document provides only only a high-level discussion, why are > there so many normative references? Why does a reader need to read, for > instance, RFC 1918, to understand this document? Seems RFC 1918 only > provides information in support of an example. Seems there is > significant over use of normative references here. I think most of the > references listed as normative are more appropriately listed as > informative. Agreed. All the references have been moved to informative. > > In the paragraphs: >> Protocols that embed an IPv4 address in a tunneled IPv6 address >> directly between peers often do filtering based on checking the >> correpondence. >> >> Protocols that accept tunneled packets directly from a server or >> relay do filtering the same way as it would be done on a native >> link with traffic from a router. > > > the text implies the protocols do filtering. Is this correct? It seems > more likely that the devices implementing the protocol do the filtering. You are right. We have fixed the text to read " Implementations of protocols that embed an IPv4 address in a tunneled IPv6 address directly between peers often do filtering based on checking the correspondence. Implementations of protocols that accept tunneled packets directly from a server or relay do filtering the same way as it would be done on a native link with traffic from a router." > >> To do host-based filtering with protocols that allow both other >> hosts and a router over a common tunnel (e.g., 6to4 [RFC3056], >> Teredo, ISATAP [RFC4214], and 6over4 [RFC2529]), hosts would need >> to be able to know the outer IP address of all routers from which >> it could receive traffic. > I am having a hard time parsing this sentence. We have split this sentence into two parts and reworded it. The new text reads " Some protocols such as 6to4 [RFC3056], Teredo, ISATAP [RFC4214], and 6over4 [RFC2529] allow both other hosts and a router over a common tunnel To perform host-based filtering with such protocols a host would need to know the outer IP address of each router from which it could receive traffic, so that packets from hosts beyond the router will be accepted even though the source address would not embed the router's IP address. Router addresses might be learned via Secure Neighbor Discovery (SEND) [RFC3971] or some other mechanism (e.g., [RFC4214] section 8.3.2)." Thanks Suresh _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Oct 12 22:58:58 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6946B3A6B87; Sun, 12 Oct 2008 22:58:58 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872FD3A69D4 for ; Sun, 12 Oct 2008 20:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 v87aPosy6nK8 for ; Sun, 12 Oct 2008 20:46:41 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 691093A695E for ; Sun, 12 Oct 2008 20:46:41 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9D3lXit025310 for ; Sun, 12 Oct 2008 23:47:33 -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 m9D3lVhi025304 for ; Sun, 12 Oct 2008 23:47:31 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9D3lO4C026630 for ; Sun, 12 Oct 2008 23:47:24 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3211A10874D8; Sun, 12 Oct 2008 23:47:00 -0400 (EDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m9D3lnAp025839; Sun, 12 Oct 2008 22:47:49 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Oct 2008 22:46:55 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Oct 2008 22:46:54 -0500 Message-ID: <48F2C50D.1070107@ericsson.com> Date: Sun, 12 Oct 2008 23:48:29 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Tom Yu References: In-Reply-To: X-OriginalArrivalTime: 13 Oct 2008 03:46:54.0826 (UTC) FILETIME=[55ACD4A0:01C92CE6] X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Sun, 12 Oct 2008 22:58:57 -0700 Cc: secdir@mit.edu, v6ops-chairs@tools.ietf.org, jim_hoagland@symantec.com, dthaler@microsoft.com Subject: Re: [secdir] secdir review of draft-krishnan-v6ops-teredo-update-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Tom, Thank you very much for your detailed review and sorry for the long delay in our response. We have modified the draft to address some of your concerns. We also had a few questions for you. Please find our responses inline. Tom Yu wrote: > This document does not clearly identify its threat model. In its > Security Considerations, it mentions scanning for IPv6 addresses, > particularly if the external IPv4 address and port number are known. > I assume that the threat is an off-path attacker, because an on-path > attacker could directly view all of the relevant IPv4 and IPv6 > addresses. An off-path attacker is somewhat less likely to know the > external UDP port number of the Teredo client, though. Somewhat less > clear is whether the document assumes that the attacker lacks IPv4 > connectivity. We have added the following text to the Security Considerations section " The basic threat model for Teredo is described in detail in [RFC4380] section 7, but briefly the goal is that a Teredo client should be as secure as if a host were directly attached to an untrusted Internet link. This document specifies updates to [RFC4380] that improve the security of the base Teredo mechanism regarding specific threats." We have added the following text as a precise description of the threats "IPv6 address scanning [RFC5157] by off-path attackers:" for the paragraph starting with "The Teredo IPv6 Address format defined in [RFC4380] section 4..." and "Opening a hole in an enterprise firewall [I-D.ietf-v6ops-tunnel-security-concerns]:" for the paragraph starting with "Teredo is NOT RECOMMENDED as a solution for managed networks." > > I can infer from the Security Considerations text that one threat is > an attack targeting vulnerabilities in IPv6-listening application > software running on a Teredo client. I can infer an additional > possible threat is an attack targeting vulnerabilities in the IPv6 > stack implementation of a Teredo client. Malicious creation of new > mappings on the (non-full cone) NAT may also be a threat. > > An attack could target the Teredo client implementation directly, but > this might not require guessing the Teredo IPv6 address if the > attacker has IPv4 connectivity. Also, it appears that the Teredo > client implementation is primarily responsible for validating the > random number contained in the flags, so the flag randomization > procedure described in this document will not defend against this sort > of attack. The attack surface in these two cases (attacking through Teredo and attack through direct IPv4) is different. The document only addresses the issues introduced by Teredo and not the generic IPv4 issues. The Teredo RFC (RFC4380) covers more threats to Teredo and this draft only augments it with respect to specific threats. > > If the attacker lacks direct IPv4 connectivity, and the transited > Teredo servers or Teredo relays validate the randomized flag bits, the > malicious packets may be successfully blocked before they reach the > Teredo client's IPv4 stack. This requires additional state on the > Teredo server, but possibly not on a Teredo relay. A Teredo server cannot be used by an IPv6-only attacker to transit any packets, since a Teredo server has no such functionality. We are not aware of any way for a relay to 'validate' the randomized bits in any useful and backwardly compatible way. > > Increasing the IPv6 address range by a factor of 4096 seems like a > reasonable approach for reducing the exposure of a Teredo client to > IPv6 address scanning. It also moderately increases the difficulty of > using Teredo to maliciously create new NAT mappings. This flag > randomization does remove (except for one bit) all remaining > possibility for future extension of the Teredo addressing format, > which may be an acceptable tradeoff. You are right. The consensus was that this is an acceptable tradeoff. > > Deprecation of the cone bit seems like a good way of reducing the > exposure of information about the security policy of the NAT. An > attacker with direct IPv4 connectivity could probably directly probe > whether the NAT is a full-cone NAT, though. > > Should this document reference (either normatively or informatively) > draft-ietf-v6ops-tunnel-security-concerns-00, which appears to cover > some of the possible threats not mentioned explicitly in this > document? You are right. We have added a reference to draft-ietf-v6ops-tunnel-security-concerns-00 along with the specific cases for which it is required. Thanks Suresh _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 14 11:04:20 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8D83A68C2; Tue, 14 Oct 2008 11:04:20 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0073A6AB3 for ; Mon, 13 Oct 2008 00:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 UR85emUSeyVq for ; Mon, 13 Oct 2008 00:42:16 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A0A383A6A38 for ; Mon, 13 Oct 2008 00:42:16 -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 m9D7gK1u031542 for ; Mon, 13 Oct 2008 03:42:21 -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 m9D7g9lO031494 for ; Mon, 13 Oct 2008 03:42:10 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9D7g24G012718 for ; Mon, 13 Oct 2008 03:42:02 -0400 (EDT) Received: from unobtainium.braintrust.co.nz (unobtainium.braintrust.co.nz [60.234.76.2]) by mit.edu (Spam Firewall) with ESMTP id 6738B10E4DB6 for ; Mon, 13 Oct 2008 03:41:41 -0400 (EDT) Received: from [192.168.0.51] (ip-118-90-104-146.xdsl.xnet.co.nz [118.90.104.146]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id D04052793F; Mon, 13 Oct 2008 20:41:38 +1300 (NZDT) Message-Id: From: Nathan Ward To: Suresh Krishnan In-Reply-To: <48F2C29B.8090900@ericsson.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 13 Oct 2008 20:41:37 +1300 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Tue, 14 Oct 2008 11:04:19 -0700 Cc: Tim Polk , secdir@mit.edu, dthaler@microsoft.com, v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns-00 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On 13/10/2008, at 4:38 PM, Suresh Krishnan wrote: >>> One simple method to do that is easy to employ for many tunnel >>> protocols is to block outbound packets to the UDP or TCP port used >>> (e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.). >> The description of this method is not precise. Is the method to >> block dest ports, with these source ports, or either, or both? > > The method is to block destination ports. We have changed this > sentence > to read > (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for > L2TP, etc.) This makes me squirm a bit. It seems silly to promote blocking discrete ports, when a user could simply run their own Teredo server on a different port and tunnel out with that, or run any other proxy or tunnel server of some kind on any port they wanted. We've all run PPP over SSH before, it's not hard to do this stuff, there are tools to do it automatically. If an organisation is concerned about people tunnelling through their firewalls, they must use default-deny if they want to have any effect. >>> In 3.1.3, >>> Tunneling over UDP or TCP (including HTTP) to reach the Internet >>> is >>> not recommended as a solution for managed networks. >> First, I'm going to read the sentence as if the word 'managed' was >> not used as I think all networks on the Internet are 'managed' to >> some degree. If the authors had a particular definition of the >> term 'managed network' in mind, they should define it. >> So reading the sentence without the term 'managed', this is >> basically a general applicability statement that use of tunneling >> over UDP or TCP is not recommend for use to 'reach the Internet'. >> I don't see this recommendation as being appropriate given the issue. > > We have changed this text to read > > " Tunneling over UDP or TCP (including HTTP) to reach the Internet is > not recommended as a solution for networks that wish to enforce > security polcies on the user traffic. (Windows, for example, > disables Teredo by default if it detects that it is within an > enterprise network that contains a Windows domain controller.)" Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4? I don't imagine that UDP makes it any more difficult to inspect than an IP protocol. I think this statement should be changed to "Tunnelling through a security device (ie. firewall) is not recommended for.. " etc. -- Nathan Ward _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 14 11:04:20 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2390328C1D0; Tue, 14 Oct 2008 11:04:20 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DAD33A6A2B for ; Mon, 13 Oct 2008 06:39:50 -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 FqzLb98SxP4u for ; Mon, 13 Oct 2008 06:39:49 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id DE0343A6358 for ; Mon, 13 Oct 2008 06:39:48 -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 m9DDdoxd022800 for ; Mon, 13 Oct 2008 09:39:50 -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 m9DDdl71022766 for ; Mon, 13 Oct 2008 09:39:47 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9DDdcEt009115 for ; Mon, 13 Oct 2008 09:39:38 -0400 (EDT) Received: from cluster-b.mailcontrol.com (cluster-b.mailcontrol.com [217.68.146.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2B112107DB90 for ; Mon, 13 Oct 2008 09:39:15 -0400 (EDT) Received: from rly32b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly32b.srv.mailcontrol.com (MailControl) with ESMTP id m9DDd02P009096 for ; Mon, 13 Oct 2008 14:39:11 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly32b.srv.mailcontrol.com (MailControl) id m9DDcuUH008772 for secdir@mit.edu; Mon, 13 Oct 2008 14:38:56 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly32b-eth0.srv.mailcontrol.com (envelope-sender cboulton@avaya.com) (MIMEDefang) with ESMTP id m9DDct6I008356; Mon, 13 Oct 2008 14:38:56 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Oct 2008 14:38:55 +0100 Message-ID: In-Reply-To: <70CAEDA7-B4AB-4947-9522-4D148B5FE28B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-mediactrl-sip-control-framework-04 Thread-Index: AckrEuAdk9Y032QnTWGlZTihrX2RzgCIdhZQ References: <70CAEDA7-B4AB-4947-9522-4D148B5FE28B@cisco.com> From: "Chris Boulton" To: "Brian Weis" , , X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MailControl A-08-50-15 (www.mailcontrol.com) on 10.66.1.142 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9DDdl71022766 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Tue, 14 Oct 2008 11:04:19 -0700 Cc: "secdir@MIT.EDU" , Spencer Dawkins , Eric Burger Subject: Re: [secdir] Secdir review of draft-ietf-mediactrl-sip-control-framework-04 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org [Chris Boulton] Thanks for the great review. Comments in-line. Chris. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments. This document details mechanisms for establishing, using, and terminating a reliable transport connection channel using SIP and the Session Description Protocol offer/answer [RFC3264] exchange. The connection channel is setup via a separate SIP session, and the two sessions are bound together via an identifier (cfw-id). Peer authentication and transport security are the primary security considerations for this mechanism. To address these concerns, the document requires an implementation to support TLS and recommends its use. The cfw-id has some security ramifications in that it is used to identify particular sessions, bind sessions together, and is used to identify a particular application session. Specific security related comments on the document follow. Section 4.1. This section mandates an implementation support TLS, but it isn't clear whether this mandate is restricted to the Control Channel or includes the Control SIP Dialog. I would expect that it intends to cover both protocols. Please clarify hear and in Section 11.2. [Chris Boulton] Clarified intention in 4.1 and added appropriate text to section 11.1 which deals with session management. Section 6.1. The first paragraph says "The transaction identifier MUST be globally unique over space and time with at least 64 bits of randomness." This seems to be an important requirement, and it's rationale should be described here or in the security considerations. For example, perhaps the intention was for a purely random number to mitigate one client from spoofing another client within a server application. [Chris Boulton] Added some text to this section relating to uniqueness across clusters and avoiding clashes. Maintaining hard-to-guess identities may be especially important given that a "session" consists of two distinct protocols between the client and server, where the server application uses the cfw-id to join their state. Section 10. TLS is recommended by this document. If feasible, the example in this section should include it. [Chris Boulton] Well, the document recommends the use of TLS except when in a closed environment. In reality the majority of cases will involve application servers and media servers in a protected environment. I would like to keep the example in this document as simple as possible but certainly think that we should include TLS examples in the proposed 'Call Flows' document that is currently being worked. Section 11. This paragraph says "Channel Framework is designed to comply with the security-related requirements documented in the control protocol requirements document[RFC5167]." The requirements being referenced should be named (e.g., REQ-MCP-11? REQ-MCP-12?). [Chris Boulton] Done. Section 11.1. Regarding the sentence "the Media Channel Control Framework should make full use of mechanism provided by the SIP protocol", you should state which mechanisms and what protections they provide. [Chris Boulton] Done as by-product of earlier point. Section 11.2. Regarding the phrase "Clients and servers must be properly authenticated ....". This should say "authenticated and authorized". [Chris Boulton] Done. This section lists "both confidentiality and integrity". Replay protection is another important transport level protection that should be added to the list. [Chris Boulton] Done. Section 11.3. Is the text "It should be noted that this document does not specifically carry any specific mechanism to overcome such conflicts but will provide a summary of how it can be achieved." referring to the following paragraph? If so, it would be helpful to say so. [Chris Boulton] Added text. One additional policy consideration worth mentioning would be a need for an application to maintain which cfw-id is associated with which socket identifier, and verify that the cfw-id received by a client was correct for that socket. This would protect a server against one client spoofing another client. (Even if mutual TLS authentication is used on the control channel, it does not provide any assurance as to the correctness of the application data carried within the TLS session, including the cfw-id.) -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 14 11:55:04 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035B33A67F8; Tue, 14 Oct 2008 11:55:04 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BB43A6849 for ; Tue, 14 Oct 2008 11:55:02 -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 T3dV0aLRX2bh for ; Tue, 14 Oct 2008 11:55:02 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8B2FA3A63EC for ; Tue, 14 Oct 2008 11:55:01 -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 m9EIt3c9027114 for ; Tue, 14 Oct 2008 14:55:03 -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 m9EIt2rT027101 for ; Tue, 14 Oct 2008 14:55:02 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9EIss6G015419 for ; Tue, 14 Oct 2008 14:54:54 -0400 (EDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by mit.edu (Spam Firewall) with ESMTP id F22241087EF4 for ; Tue, 14 Oct 2008 14:54:32 -0400 (EDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out02.mta.xmission.com with esmtp (Exim 4.62) (envelope-from ) id 1Kpp2z-0005gW-Si; Tue, 14 Oct 2008 12:55:09 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=localhost.localdomain) by mx03.mta.xmission.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Kpp2L-00033U-EG; Tue, 14 Oct 2008 12:54:30 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id m9EIqlij007929; Tue, 14 Oct 2008 12:52:47 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id m9EIqlUh007925; Tue, 14 Oct 2008 12:52:47 -0600 Date: Tue, 14 Oct 2008 12:52:47 -0600 Message-Id: <200810141852.m9EIqlUh007925@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: ho set sender to hilarie using -f From: "Hilarie Orman" To: secdir@mit.edu X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=no signature X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;secdir@mit.edu X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Thu, 07 Dec 2006 04:40:56 +0000) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list MIME-Version: 1.0 Cc: rcallon@juniper.net, adrian@olddog.co.uk, rbradfor@cisco.com, jpv@cisco.com, dward@cisco.com Subject: [secdir] Review of draft-ietf-pce-path-03 X-BeenThere: secdir@ietf.org Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism, draft-ietf-pce-path-key-03.txt Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments. Based on the title, I thought this was about cryptographic keys, but it isn't. Even the commendably well-written abstract (all acronyms expanded!) did not disabuse me of this belief. If path keys were instead called, for example, opaque path identifiers, the draft would benefit. The confidentiality issue boils down to saying that in messages that necessarily pass from a trusted domain, across untrusted domains, and into a trusted domain, there is a protocol element that is, in some circumstances, confidential, so an exisiting mechanism can be used to carry an opaque identifier instead of the actual element. The mapping from the opaque identifier to the actual element is carried in protocol messages that "can be authenticated and made secure" as described in other documents. "Made secure" presumably encompasses confidentiality and integrity. Assuming that everyone knows how to configure their authentication and cryptographic keys with trusted parties correctly, the overall idea seems sound. An risk not mentioned in the security section is the possibility of infering the mapping if the opaque identifiers are not chosen randomly. Observers, over time, might be able to make such inferences based on being able to predict the identifiers and the network topology changes. Hilarie _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 14 16:37:07 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809563A6C12; Tue, 14 Oct 2008 16:37:07 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DD73A6C11 for ; Tue, 14 Oct 2008 16:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[AWL=2.048, 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 ldtYQNyEonmI for ; Tue, 14 Oct 2008 16:37:06 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E65AA3A683A for ; Tue, 14 Oct 2008 16:37:05 -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 m9ENc2KW000746 for ; Tue, 14 Oct 2008 19:38:02 -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 m9ENbuMB000700 for ; Tue, 14 Oct 2008 19:37:58 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9ENbnYF010838 for ; Tue, 14 Oct 2008 19:37:49 -0400 (EDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id E04EB10947B1 for ; Tue, 14 Oct 2008 19:37:27 -0400 (EDT) Received: from [192.168.2.2] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m9ENam7Q022231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Oct 2008 18:36:49 -0500 Message-ID: <48F52D0A.5080902@softarmor.com> Date: Tue, 14 Oct 2008 18:36:42 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Paul Kyzivat References: <48EFCE98.4000004@cisco.com> In-Reply-To: <48EFCE98.4000004@cisco.com> X-Enigmail-Version: 0.94.2.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: "suzuki.yasushi@lab.ntt.co.jp" , "secdir@mit.edu" , "drage@alcatel-lucent.com" , "tomoyuki.yoshikawa@east.ntt.co.jp" , "hasebe.miki@east.ntt.co.jp" , "j.koshiko@east.ntt.co.jp" , "iesg@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-sipping-race-examples-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org How about "Clarification of Time and State Interactions in the Session Initiation Protocol" -- Dean _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 14 16:47:21 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E853A6822; Tue, 14 Oct 2008 16:47:21 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600263A6822 for ; Tue, 14 Oct 2008 16:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 m76groB0LHvT for ; Tue, 14 Oct 2008 16:47:18 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 84BEF3A6774 for ; Tue, 14 Oct 2008 16:47:18 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9ENmGoX004247 for ; Tue, 14 Oct 2008 19:48:16 -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 m9ENmEET004231 for ; Tue, 14 Oct 2008 19:48:14 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9ENm6bj025493 for ; Tue, 14 Oct 2008 19:48:07 -0400 (EDT) X-ASG-Whitelist: Barracuda Reputation Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B33EBBB42A5 for ; Tue, 14 Oct 2008 19:48:06 -0400 (EDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 14 Oct 2008 16:48:05 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.1.291.1; Tue, 14 Oct 2008 16:48:05 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Tue, 14 Oct 2008 16:48:26 -0700 From: Larry Zhu To: Dean Willis , Paul Kyzivat Date: Tue, 14 Oct 2008 16:48:04 -0700 Thread-Topic: SECDIR review of draft-ietf-sipping-race-examples-06 Thread-Index: AckuVe1KCZZF/dAxRUyEFvJdIviqfgAAVfMQ Message-ID: References: <48EFCE98.4000004@cisco.com> <48F52D0A.5080902@softarmor.com> In-Reply-To: <48F52D0A.5080902@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9ENmEET004231 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: "suzuki.yasushi@lab.ntt.co.jp" , "secdir@mit.edu" , "drage@alcatel-lucent.com" , "tomoyuki.yoshikawa@east.ntt.co.jp" , "hasebe.miki@east.ntt.co.jp" , "j.koshiko@east.ntt.co.jp" , "iesg@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-sipping-race-examples-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org That sounds great! -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, October 14, 2008 4:37 PM To: Paul Kyzivat Cc: Larry Zhu; tomoyuki.yoshikawa@east.ntt.co.jp; suzuki.yasushi@lab.ntt.co.jp; j.koshiko@east.ntt.co.jp; hasebe.miki@east.ntt.co.jp; drage@alcatel-lucent.com; iesg@ietf.org; secdir@mit.edu Subject: Re: SECDIR review of draft-ietf-sipping-race-examples-06 How about "Clarification of Time and State Interactions in the Session Initiation Protocol" -- Dean _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 15 02:03:44 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3865328C20B; Wed, 15 Oct 2008 02:03:44 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1599A3A67D1 for ; Tue, 14 Oct 2008 17:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eCLhEAoq1hd for ; Tue, 14 Oct 2008 17:01:17 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 128D63A6B51 for ; Tue, 14 Oct 2008 17:00:42 -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 m9F01cax007764 for ; Tue, 14 Oct 2008 20:01:38 -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 m9F01arr007761 for ; Tue, 14 Oct 2008 20:01:36 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9F01SLX007647 for ; Tue, 14 Oct 2008 20:01:28 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id A6A361089805 for ; Tue, 14 Oct 2008 20:01:03 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAEC28C1DF; Tue, 14 Oct 2008 17:00:04 -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 846CE3A6900; Tue, 14 Oct 2008 17:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20081015000001.846CE3A6900@core3.amsl.com> Date: Tue, 14 Oct 2008 17:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Wed, 15 Oct 2008 02:03:43 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Simple Authentication and Security Layer (sasl) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org A modified charter has been submitted for the Simple Authentication and Security Layer (sasl) 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, October 21, 2008. Simple Authentication and Security Layer (sasl) =============================================== Last Revision 10/3/2008 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/sasl Chair(s): Kurt Zeilenga [kurt.zeilenga@isode.com] Tom Yu [tlyu@mit.edu] Security Area Director(s): Tim Polk [tim.polk@nist.gov] Pasi Eronen [pasi.eronen@nokia.com] Security Area Advisor: Pasi Eronen [pasi.eronen@nokia.com] Mailing Lists: General Discussion: ietf-sasl@imc.org To Subscribe: ietf-sasl-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-sasl/mail-archive/ Description of Working Group: The Simple Authentication and Security Layer [RFC4422] provides key security services to a number of application protocols including BEEP, IMAP, LDAP, POP, and SMTP. The purpose of this working group is to shepherd SASL, including select SASL mechanisms, through the Internet Standards process. This group will work to progress the SASL Technical Specification toward Draft Standard. The group has determined that DIGEST-MD5 [RFC2831] is not suitable for progression on the Standards Track due to interoperability, internationalization, and security concerns. The group will deliver a technical specification for a suitable password-based challenge/ response replacement mechanism for Standard Track consideration. The replacement mechanism is expected to be "better than" DIGEST-MD5 from a number of perspectives including interoperability, internationalization, and security. The replacement mechanism is not expected to (but may) provide a security layer itself, instead relying on security services provided at a lower layer (e.g., TLS) and channel bindings. The WG is expected to strike a consensus-supported balance between the many qualities desired in the replacement. Desired qualities include (but are not limited to) negotiated key hardening iteration count, downgrade attack protection, and mutual authentication. The group intends to consider a number of approaches, including draft-newman-auth-scam and draft-josefsson-password-auth, as input. Additionally, the WG will deliver a document summarizing its DIGEST-MD5 concerns and requesting RFC 2831 be moved to Historic status. This document will be based upon draft-ietf-sasl-digest-to- historic. This group will deliver a revised Technical Specification suitable for publication as Proposed Standard for the GSS-API family of SASL mechanisms. This work will be based upon draft-ietf-sasl-gs2. The group will produce a successor document for the CRAM-MD5 specification, RFC 2195. The outcome can be a Standards Track specification replacing RFC 2195, an Informational document moving RFC 2195 to Historic, or an Informational document that documents existing implementation practice. The following areas are not within the scope of work of this WG: - new features, - SASL Mechanisms not specifically mentioned above, and - SASL "profiles". However, the SASL WG is an acceptable forum for review of SASL-related submissions produced by others as long as such review does not impede progress on the WG objectives listed above. Milestones: Done initial I-D for RFC4422bis Nov 08 initial RFC4422bis implementation report Dec 08 WGLC RFC4422bis and implementation report I-D Done initial I-D for DIGEST-MD5 to Historic Done WGLC I-D for DIGEST-MD5 to Historic Done initial DIGEST-MD5 replacement I-D Jan 09 WGLC DIGEST-MD5 replacement I-D Done initial GS2 I-D Jan 09 WGLC GS2 I-D Nov 08 Reach consensus on CRAM-MD5 successor approach (and update milestones accordingly) _______________________________________________ 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 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 16 08:06:23 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02863A68C0; Thu, 16 Oct 2008 08:06:22 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38943A6A75 for ; Thu, 16 Oct 2008 05:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=3.426, 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 ewk0qHy8JZWm for ; Thu, 16 Oct 2008 05:02:21 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id F01613A6805 for ; Thu, 16 Oct 2008 05:02: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 m9GC3LGM009315 for ; Thu, 16 Oct 2008 08:03:21 -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 m9GC3Enu009140 for ; Thu, 16 Oct 2008 08:03:14 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9GC35V0019168 for ; Thu, 16 Oct 2008 08:03:06 -0400 (EDT) Received: from evx3.enoc.east.ntt.co.jp (eastmail3.ntt-east.co.jp [202.229.5.46]) by mit.edu (Spam Firewall) with ESMTP id A4083107F34F for ; Thu, 16 Oct 2008 08:02:43 -0400 (EDT) Received: from emix1.enoc.east.ntt.co.jp by evx3.enoc.east.ntt.co.jp with ESMTP id m9GC2cr06008; Thu, 16 Oct 2008 21:02:38 +0900 (JST) Received: from cmf1.noc.east.ntt.co.jp by emix1.enoc.east.ntt.co.jp with ESMTP id m9GC2b728614; Thu, 16 Oct 2008 21:02:37 +0900 (JST) Received: by cmf1.noc.east.ntt.co.jp id m9GC2bfC020247; Thu, 16 Oct 2008 21:02:37 +0900 Received: from cip7 [10.162.251.7] by cmf1.noc.east.ntt.co.jp with ESMTP id WAA16791; Thu, 16 Oct 2008 20:16:09 +0900 Received: from mail.east.ntt.co.jp by cip7.noc.east.ntt.co.jp with SMTP id AFS93758; Thu, 16 Oct 2008 20:16:02 +0900 (JST) Message-Id: <200810161116.AFS93758@cip7.noc.east.ntt.co.jp> Date: Thu, 16 Oct 2008 20:16:05 +0900 From: Miki HASEBE X-Mailer: EdMax Ver2.85.5F MIME-Version: 1.0 To: Larry Zhu In-Reply-To: References: X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Thu, 16 Oct 2008 08:06:21 -0700 Cc: "suzuki.yasushi@lab.ntt.co.jp" , Jon Peterson , Paul Kyzivat , "drage@alcatel-lucent.com" , "tomoyuki.yoshikawa@east.ntt.co.jp" , sipping-chairs@tools.ietf.org, "j.koshiko@east.ntt.co.jp" , "iesg@ietf.org" , Dean Willis , "secdir@mit.edu" , General Area Review Team Subject: Re: [secdir] SECDIR review of draft-ietf-sipping-race-examples-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi, I've summarized the comments which I think I have to reflect to the draft. 1.Change of title of the draft I'm not sure whether the title may be changed at the current step. Does sipping chairs agree to change to the following title? "Clarification of Time and State Interactions in the Session Initiation Protocol" 2.SIP-over-TCP I'll add the considertaion when using TCP as transport to each sequence. 3.BCP/Informational Who has the right to make a decision whether BCP or Informational? I assume BCP and update the draft to clarify recommendations as BCP and other descriptions. 4.Other Gen-ART and SECDIR comments will be reflected. Is my understanding correct that we will discuss it again after I send the revision reflecting the above comments? Thank you, Miki --------------------------------------------------------- Miki HASEBE Research and Development Center NTT-east Corporation Telephone +81 3 5359 5104 Facsimile +81 3 5359 1236 E-mail: hasebe.miki@east.ntt.co.jp 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan --------------------------------------------------------- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 16 08:48:57 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B123A6B53; Thu, 16 Oct 2008 08:48:57 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE49B3A6B4F; Thu, 16 Oct 2008 08:48:55 -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 nKgLOF87ChnV; Thu, 16 Oct 2008 08:48:54 -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 D3CA33A68AC; Thu, 16 Oct 2008 08:48:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,424,1220227200"; d="scan'208";a="176548284" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2008 15:49:55 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9GFntVg000697; Thu, 16 Oct 2008 08:49:55 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9GFntUP005624; Thu, 16 Oct 2008 15:49:55 GMT Date: Thu, 16 Oct 2008 08:49:55 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, gparsons@nortel.com, eburger@standardstrack.com, dave.cridland@isode.com Message-ID: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=669; t=1224172195; x=1225036195; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20SECDIR=20review=20of=20draft-cridland-urlfetch- binary-03 |Sender:=20; bh=2oK+RS8xmE1z/jjNspa+lFIyyrSP8KTAZfuTJ15Wdww=; b=E5Qk2k6PTqnfrmRIC4PgHAlBKV9Inan3jy3Czx5kQYBc0xSZ5WJbBXVdNi fjn+MXc3UUGrrQKgg652niIswN/MIvpl5YY4jJaYTAum0XIHLATOlF4TMVe5 WlG6Wyrhyw; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [secdir] SECDIR review of draft-cridland-urlfetch-binary-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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. Due to time constraints, I was not able to thoroughly review this document. However, it appears to be in good shape and the Security Considerations section along with the security considerations notes in the normatively referenced documents seem to cover all security threats that I could imagine. Regards, Chris _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 17 12:08:22 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4EEC3A67EA; Fri, 17 Oct 2008 12:08:22 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB513A67EA for ; Fri, 17 Oct 2008 12:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.99 X-Spam-Level: X-Spam-Status: No, score=-4.99 tagged_above=-999 required=5 tests=[AWL=1.609, 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 3bjcKkYHoHwJ for ; Fri, 17 Oct 2008 12:08:20 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id A8E413A6781 for ; Fri, 17 Oct 2008 12:08: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 m9HJ9OJK026764 for ; Fri, 17 Oct 2008 15:09:24 -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 m9HJ9N8C026741 for ; Fri, 17 Oct 2008 15:09:23 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9HJ9E9B007340 for ; Fri, 17 Oct 2008 15:09:14 -0400 (EDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2543EB7B743 for ; Fri, 17 Oct 2008 15:08:53 -0400 (EDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id m9HJ8qok085244 for ; Fri, 17 Oct 2008 15:08:52 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id m9HJ8qsm085241 for ; Fri, 17 Oct 2008 15:08:52 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 17 Oct 2008 15:08:52 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@mit.edu Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Fri, 17 Oct 2008 15:08:52 -0400 (EDT) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: [secdir] assignments delayed X-BeenThere: secdir@ietf.org Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org This week's secdir assignments will come out on Sunday or Monday. Those with documents on the telechat next week have gotten reminders in private mail. -- Sam _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 17 12:25:28 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C203A6969; Fri, 17 Oct 2008 12:25:28 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EA328C100 for ; Fri, 17 Oct 2008 12:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 FmhChFxCgXyU for ; Fri, 17 Oct 2008 12:25:17 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1CF353A683C for ; Fri, 17 Oct 2008 12:25:14 -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 m9HJQJCV030917 for ; Fri, 17 Oct 2008 15:26:19 -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 m9HJQGpp030901 for ; Fri, 17 Oct 2008 15:26:16 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9HJQ9NQ000745 for ; Fri, 17 Oct 2008 15:26:09 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9E761BD63A1 for ; Fri, 17 Oct 2008 15:26:07 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.33,434,1220227200"; d="scan'208";a="96413076" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2008 19:26:06 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9HJQ6GI011311; Fri, 17 Oct 2008 12:26:06 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9HJQ2Fl009120; Fri, 17 Oct 2008 19:26:03 GMT From: Cullen Jennings To: Charlie Kaufman In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: Message-Id: <2AEBF52A-07E8-4352-B236-DF9896A5192E@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 17 Oct 2008 13:25:57 -0600 X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7692; t=1224271566; x=1225135566; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Secdir=20review=20of=20draft-ietf-sip-f ork-loop-fix-07.txt |Sender:=20; bh=iMRvdeEXtH1VsvGKo3A9TQMTi13OkF4nu6qa3DryWQ4=; b=dNJPec3H0J76pfXOiB/RLgLgucJJyIuKTISBdcFPfDCwmCxX0rfP7kG89O 1ApcnUbiA8p9d5iTyFa8wOh8YP8YSuuW1gceVtNdOnxQca2uWUwDLiw/fBP9 mQ6lX1zIqGDxSvJJSIVq+odPVXI5Ap0jxt69SDmDN7n+LbZpBCVrc=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9HJQGpp030901 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Robert Sparks , slawrence@bluesocket.com, secdir@mit.edu, Keith Drage , Byron Campen , Dan Romascanu , IESG IESG , Dean Willis , alan.ietf@polyphase.ca Subject: Re: [secdir] Secdir review of draft-ietf-sip-fork-loop-fix-07.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi All, I have put this draft on the agenda for next weeks IESG call but I = have not seen much discussion of what if any changes should be made = given the review below. The unfortunate problem is we don't have any = particularly good solutions for the loop issue and mostly need to = decide what we can get published and implemented that is significantly = better than 3261. Cullen On Sep 29, 2008, at 12:11 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. > > Since my last review of this document where I complained of a = > dangerous exposure to looping attacks caused by malicious - or even = > accidental - misconfiguration, the document has been revised so as = > to make such loops somewhat less likely to occur by accident and = > somewhat less disastrous for network loading when they do occur. The = > attacks and their consequences are also much better explained in the = > document. Unfortunately, they don't solve the fundamental problem of = > having a single request generating an essentially infinite load. It = > still seems unacceptably risky to deploy. > > The problem can be compared to mailing list loops. If two Internet = > mailing lists each contain the other as a member, any message sent = > to either list ends up cycling between the two list processors = > sending continuous streams of messages to other members of both = > lists. In the Internet's younger days, that happened routinely. If = > three Internet mailing lists each contain the other two lists as = > members, and if the expanders are smart enough to send out copies of = > the message in parallel to the multiple recipients, then not only do = > other members get a continuous stream of messages but the list = > expanders will be overwhelmed by all of the parallel requests. I = > don't know exactly what solutions we have found to this problem, but = > it's possible it could be retrofit onto SIP. > > SIP is like the mailing list expander except that doesn't deposit = > messages in anyone's mailbox. Instead, it is searching for = > 'presence' of someone or something so as to be able to direct an = > instant message, phone call, or some such. Each place where it looks = > for someone may (like a mailing list) forward the query onto a = > number of other SIP servers. SIP does detect loops, but in remains = > the case that if there are N places to look for someone, and each of = > those N places points to the other N-1 places (a not unlikely na=EFve = > configuration), there will be N! queries processed before the search = > terminates. For N of even moderate size, that can effectively be an = > infinite loop. > > The main improvement in loop detection from the previous version of = > the spec is that it limits the parallelism of the processing of = > these N! queries so that a single bad query cannot deny service to = > other users of the SIP server. With the sample "Max-Breadth" of 60, = > it probably does not take a very large number of these infinite = > loops to overwhelm the system. > > The proposal I made in my last review which limited the total number = > of queries in the processing of a single request would break too = > many real-world scenarios. Other possibilities were discussed on the = > SIP mailing list and this was apparently the consensus approach. > > I don't believe there is any complete solution to this problem that = > doesn't break some known desirable scenarios. I can think of some = > partial solutions that improve the situation - perhaps be enough, = > but I can't be sure. These include: > > When checking for loops, test not only against earlier points in the = > history of this query thread, but also against any parallel queries = > that are currently waiting for responses from other SIP servers. = > This would more quickly catch the overload problem because in those = > circumstances the tables of delegated queries would quickly explode. > > Any time a loop is detected, the forwarding table entry that caused = > the loop should be disabled and flagged for an administrator to = > examine. This could be done by suspending the identity being = > searched for, or if enough information is present only suspending = > the forwarding address that generated the loop. The upside of this = > scheme is that loops will be broken quickly. The downside is that it = > creates a new security exposure where someone intentionally 'fakes' = > a loop in order to make some entity unfindable. > > There should be a real time bound on any forwarded SIP request, = > after which the request is deleted and its state removed. I don't = > know the appropriate real time bound, but I can't imagine any reason = > to let a request bounce around in the network for more than a week. = > One example query in the document (section 3) was estimated to take = > 3 trillion years to complete. > > Smaller issues: > > There should be some discussion in the document about what servers = > should do in the case of overload. If particular, crashing is = > probably not a good idea; overload should be expected. If the table = > of outstanding forwarded requests overflows (as it will in error and = > some non-error cases), there is a trade-off between discarding the = > oldest request, the newest request, the most forwarded request, the = > least forwarded request, etc. When the capacity for incoming = > connections is exceeded, it may be better to close some existing = > ones to allow new ones to arrive. > > Section 4.2.4: The document suggests a way to make loop detection = > cheaper by using a hash function over the repeating data and = > comparing the hashes. The original document suggested MD5. Even = > though for the purpose of this document MD5 would be perfectly = > reasonable, MD5 has become politically incorrect so the document now = > recommends CRC-32c as an alternative. There are two problems with = > that. One is that 32 bits are arguably not enough. Failing 1 in 4 = > billion requests is not very many, but it will happen. As the = > forwarding lists get longer (and particularly if a check is made = > against outstanding requests) the failure rate will get much larger. = > More subtly, CRC-32c is 'linear', so if there is a collision causing = > a failure, it may be a solid failure where retries also fail. A = > better solution would be to propose a politically correct hash (like = > 64 bits of a SHA-256) and put a hint/nudge that MD5 (or even MD4) = > would be just fine and explain why. This is only an implementation = > hint - there is no requirement that different implementations do = > this the same way. The best solution here is to compute a relatively = > small hash as a performance hack, but when there is a match check = > the unhashed values that must match. > > Typos: > > P12: ', parameters' -> ', or parameter' > P15: 'means' -> 'mean' > P17: 'Breadh' -> 'Breadth' > P19: 'beleif' -> 'belief' _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 17 14:21:06 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F873A6AC8; Fri, 17 Oct 2008 14:21:06 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E189B3A69B9 for ; Fri, 17 Oct 2008 14:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_36=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 KoWJmcQxwdxK for ; Fri, 17 Oct 2008 14:21:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4EB903A6AC8 for ; Fri, 17 Oct 2008 14:21:03 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 689EF4231; Fri, 17 Oct 2008 17:21:58 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org Date: Fri, 17 Oct 2008 17:21:58 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Cc: oauth@googlegroups.com, draft-hammer-oauth@tools.ietf.org, lisa@osafoundation.org Subject: [secdir] Secdir Review of draft-hammer-oauth-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org [For the oauth list: The IETF has a security directorate (see sec.ietf.org) which is a group of experts that review IETF drafts for security issues. I'm a member of that directorate and have been asked by the area director sponsoring the oauth BOF at the next IETF to perform such a review of the oauth draft. Typically reviews happen fairly late in the process, although as in this case they can happen early on request.] I have reviewed draft-hammer-oauth-00 as a special requests. These comments are primarily intended for the security and applications area directors as input into considering the oauth bof. These comments should also be taken as input into the consensus process surrounding the draft. Background: Oauth provides a way to delegate access to a resource in HTTP. The canonical example is a user who has photos stored say at photos.example.net and wants to buy prints from printer.example.com. The user does not want to give printer.example.com their name and password for photos.example.net; depending on what authentication is in place they may not even be able to do so. Oauth provides a way that after obtaining consent from the user, printer.example.com can gain a token that can be used to access the protected resource. The printer service may only be granted access to some photos--the ones that the user wants printed. The access may be time limited and have other restrictions. This mechanism is similar to proxy tickets in Kerberos and proxy certificates in grid contexts. It is related to constrained delegation in Microsoft Kerberos, although involves significantly less trust of the consumer (party seeking delegated access to a protected resource). The protocol roughly runs as follows: 1) Consumer makes a request to the service provider (where the protected resources live) and gets a blob called a request token 2) Consumer redirects the user to the service provider passing along the blob ; if the user authorizes the transaction then the consumer is notified. 3) Consumer asks service provider to turn the request token into another blob called an access token. 4) Consumer can use the access token to access protected resources. Associated with each token is a shared secret used to provide integrity protection and peer entity authentication of the party making the request. One thing we've been looking at with HTTP authentication schemes is whether they are browser specific or whether they will work well in atom/dav/etc environments. Most of oauth will work well in a non-browser context. However oauth redirects the user from the consumer to the service provider to seek authorization for the request token. This tends to mean that the service provider and consumer tend to need to have the same idea about what kind of agent the user is using. It seems clear that the service provider can enable whatever they like, but that oauth may have limitations when being used with classes of agent the service provider has never considered. I found the spec sufficiently clear. While I do have a lot of detailed comments, I'd expect that at this point in the process. Whenever you bring some idea into an large organization like the IETF, you're almost certainly guaranteed that there are a set of things that the organization cares about in its specs that need to be addressed. Interoperability The oauth document is not really a complete protocol; it is more like a set of components that can be used in building a higher level protocol. To some extent this is necessary: a consumer that wants to talk to a photo store will not know what to do if it is talking to a blog. Also, oauth treats issues like naming of resources to be accessed, naming of users etc as an API matter to be handled at a layer above oauth. However it really seems like there are a lot of things that are not specified in the spec that need to be done for interoperability. It seems like the description of how a service uses oauth would need to be a fairly significant document. In addition, the security analysis of oauth itself is going to be somewhat incomplete; oauth will need to be analyzed in the context of the using service. I realize that to some extent the same can be said for RFC 2822 or HTTP. However my qualitative feeling that this is more true for oauth. Oauth does not have mandatory-to-implement algorithms for security. We typically require that. There is no mandatory-to-implement method for conveying request parameters. There is no interoperable way to find the lifetime of a request or access token, to find out when an access token has been revoked, etc. Security Consumers are typically in different organizations than service providers. Their may be a potentially large number of consumers. However there is no automated key management for a shared secret used to authenticate the consumer to the service provider. I think RFC 4107 will require us to create such a mechanism. Section 12.8 implies that the consumer secret might not be secret--in particular, a single consumer secret would be used in all instances of a desktop application. That is, you'd download a binary, and inside that binary would be a secret used to authenticate to some provider. The text and concept will require revision to survive last call in the IETF. The oauth parts of messages from the client to a server are optionally integrity protected. However there is no response protection. At least for the hmac-sha1 signature type adding response protection would be trivial. It would be reasonably trivial for the RSA signature type, although the consumer would then need to know the public key of the service provider. Oauth service providers send shared secrets back to consumers for request and access tokens. There are two potential issues with this. First, the consumer does not contribute to the secret. Second, there is no mandatory confidentiality protection of the secret. This issue needs significant discussion with the security community if only to satisfy people that the oauth spec is reasonable in this regard. Oauth responses can be cut&pasted onto different requests. Fixing the response integrity problem does not inherently fix this issue. Oauth provides no mutual authentication. We have typically expected authentication systems that we're designing to provide mutual authentication especially when there is no good reason not to do so. It seems like fixing the response integrity problem could also fix fix the lack of mutual authentication. The replay prevention mechanism has a significant DOS concern for the service provider. A request contains a nonce and a timestamp. The timestamp must be non-decreasing but is not required to be particularly close to current time nor to ever change. The nonce is required to be unique for a given timestamp. So, if a particular consumer never changes the timestamp then the server must retain all nonce values presented to it. Mechanisms such a digest handle this by providing a server challenge in the www-authenticate header and providing a mechanism for dealing with the server and client getting out of sync. Oauth is less likely to actually use www-authenticate than digest. One possible solution would be to define an error meaning that the consumer must use a timestamp at least as large as some value in a future request. However without some sort of server challenge this requires synchronizing replay state across all instances of a service provider. For example, if you have a bunch of edge servers that implement your service, you need to make sure that all of them are aware of the nonce values that have been used. I suspect that in practice people would not implement replay protection in that environment. I'd like to see optional support for channel binding to TLS when TLS is used. In many cases oauth has a shared secret between the consumer and the service provider or a shared secret specific to the token in question. Using this secret to confirm that we're talking to the right server at the TLS level will provide extra defenses against phishing or other server substitution attacks. The support for channel binding should be good enough that the consumer can tell securely whether the server verified the channel binding. Adding this to the protocol is relatively easy. In some implementations, implementing it will also be easy; in others it might be fairly difficult. Thus I think the feature should be optional, but secured against downgrade attacks. The specification does not provide for automated key management of RSA public keys; I think this too will be required by RFC 4107. I can understand why you want to rule enrollment (initial key discovery) out of scope. However you need to provide a mechanism for a consumer to change its public key. Section 6.2 provides user interface requirements for what a service provider must do when seeking consent. I didn't see any problems with this, but I want to call it to the attention of the security community. Section 6.3 does not actually require that the service provider check that the request token is authorized. This requirement is critical; fortunately I think it is obvious enough that people are unlikely to omit the check in implementations. Extensibility The oauth extensibility model should be improved. There is a version field, but the behavior for an unknown version is unspecified. I know there are a lot of arguments about how to handle versioning. This behavior is inconsistent with all of them. You could drop the field; you could require an error if the version number does not match; you could use HTTP-style versioning where minor version mismatch is OK but major version mismatch generates an error. There is an error for parameter not understood. It seems like sending this error in response to an unknown parameter is permitted. Unfortunately, this combined with the way the version number is handled means there is no way for a new consumer to indicate support for a new feature while working with an old service provider. It may be desirable to have critical (the other guy must fail if he does not understand) parameters, but it seems like optional parameters as a way of extending the protocol are also required. Phishing I'm still thinking about the phishing implications of oauth. It's clear that oauth has the concerns associated with any redirect scheme. A malicious consumer can redirect the user to a phishing site rather than the actual service provider. This is only bad if the user discloses credentials or other confidential information to the malicious service provider. So, it could be seen as a mistrusted introduction problem. I analyze situations like that and ask myself how well will this approach work if the target of the redirect actually improves their authentication technology. Oauth seems like it scores reasonably under this analysis. However because there are three parties involved in the protocol the phishing issues are more complicated. If there is a problem it's relatively subtle; I'm not comfortable saying that I've analyzed things sufficiently, although assuming that mutual authentication and binding to TLS are added, I think I'm happy with everything I've considered so far. Of course, phishing defense only makes sense when TLS is being used. The point of phishing is to obtain confidential information. Without confidentiality protection being provided, there's no hope of preventing the attack. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Oct 19 11:01:43 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684553A6895; Sun, 19 Oct 2008 11:01:43 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646643A680A for ; Sun, 19 Oct 2008 11:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 TXrwe5VfachC for ; Sun, 19 Oct 2008 11:01:41 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 87B333A67B2 for ; Sun, 19 Oct 2008 11:01:41 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9JI2gte015112 for ; Sun, 19 Oct 2008 14:02:42 -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 m9JI2Xdq015097 for ; Sun, 19 Oct 2008 14:02:33 -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 m9JI2QsF013706 for ; Sun, 19 Oct 2008 14:02:26 -0400 (EDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A1C1811669B2 for ; Sun, 19 Oct 2008 14:02:05 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.33,446,1220227200"; d="scan'208";a="178350040" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2008 18:02:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9JI24Cw027272; Sun, 19 Oct 2008 11:02:04 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9JI22XN021926; Sun, 19 Oct 2008 18:02:03 GMT From: Cullen Jennings To: "DRAGE, Keith (Keith)" In-Reply-To: <5D1A7985295922448D5550C94DE29180023EA135@DEEXC1U01.de.lucent.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <2AEBF52A-07E8-4352-B236-DF9896A5192E@cisco.com> <5D1A7985295922448D5550C94DE29180023EA135@DEEXC1U01.de.lucent.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 19 Oct 2008 12:01:57 -0600 X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=593; t=1224439324; x=1225303324; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Secdir=20review=20of=20draft-ietf-sip-f ork-loop-fix-07.txt |Sender:=20; bh=gHsSlJnXQk1onr3w89adrb52q+/qp86oVgPrXFuKuEs=; b=Sewaua2ua36pVVSYcDD/WGdO7x19Vmh2xIeevyEIG3ZKjsNytp9ZljGIhw z2TvWlOIQY87AnI69T88WJOtato5ynQZ+FJp7obhRF7PToxPnXPzlbYermni /ZlG/Ott5G; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Robert Sparks , slawrence@bluesocket.com, alan.ietf@polyphase.ca, Dan Romascanu , IESG IESG , Dean Willis , Byron Campen , secdir@mit.edu Subject: Re: [secdir] Secdir review of draft-ietf-sip-fork-loop-fix-07.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Oct 17, 2008, at 5:41 PM, DRAGE, Keith (Keith) wrote: > There were proposals a while back to decrease the recommended > initial value of the Max-Forwards header from 70 to 20, but they do > not seem to have come to anything. Is this something that we believe > should now happen? My recollection was that when this got discussed in the WG, there were a lot of concerns about how much one could reduce it, and even if it was moved to 20, it does not really help much in any practical sense. I would not want to do this sort of change without checking with the WG. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Oct 19 18:55:40 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAC93A6906; Sun, 19 Oct 2008 18:55:40 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6A63A67B0 for ; Sun, 19 Oct 2008 18:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.513 X-Spam-Level: X-Spam-Status: No, score=-4.513 tagged_above=-999 required=5 tests=[AWL=2.086, 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 rM-vfd+Rx4N5 for ; Sun, 19 Oct 2008 18:55:38 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BBB5F3A68BE for ; Sun, 19 Oct 2008 18:55:38 -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 m9K1umR8028745 for ; Sun, 19 Oct 2008 21:56:48 -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 m9K1ulYd028742 for ; Sun, 19 Oct 2008 21:56:47 -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 m9K1ueKu026796 for ; Sun, 19 Oct 2008 21:56:40 -0400 (EDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by mit.edu (Spam Firewall) with ESMTP id 0090D1154179 for ; Sun, 19 Oct 2008 21:56:19 -0400 (EDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0K9000B7ILDQTZ00@mail-mta.sfvic.sunlabs.com> for secdir@mit.edu; Sun, 19 Oct 2008 18:56:14 -0700 (PDT) Received: from [129.150.32.20] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0K9000D2OLDNFCC0@mail.sunlabs.com> for secdir@mit.edu; Sun, 19 Oct 2008 18:56:12 -0700 (PDT) Date: Sun, 19 Oct 2008 18:56:11 -0700 From: Radia Perlman To: iesg@ietf.org, secdir@mit.edu, attila.takacs@ericsson.com, diego.caviglia@ericsson.com, dwfedyk@nortel.com, julien.meuric@orange-ftgroup.com Message-id: <48FBE53B.1060700@sun.com> MIME-version: 1.0 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: [secdir] Review of draft-ietf-ccamp-asymm-bw-bidir-lsps X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to set up bidirectional paths with different bandwidth requirements in each direction. It is a straightforward design, and as the authors note, there are no security considerations introduced by allowing asymmetric reservations. I see no problems with this document. Radia _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 20 00:32:59 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5BF3A6894; Mon, 20 Oct 2008 00:32:59 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9137D3A6A1E for ; Fri, 17 Oct 2008 12:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 G1etsy+hz61P for ; Fri, 17 Oct 2008 12:59:57 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 901113A67F8 for ; Fri, 17 Oct 2008 12:59:57 -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 m9HK10uh008215 for ; Fri, 17 Oct 2008 16:01:02 -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 m9HK0skx008186 for ; Fri, 17 Oct 2008 16:00:57 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9HK0lfq028869 for ; Fri, 17 Oct 2008 16:00:47 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id F3A8EBD035E for ; Fri, 17 Oct 2008 16:00:45 -0400 (EDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m9HK1mUp025058; Fri, 17 Oct 2008 15:01:48 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 14:59:37 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 14:59:37 -0500 Message-ID: <48F8EE0D.4060307@ericsson.com> Date: Fri, 17 Oct 2008 15:57:01 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Nathan Ward References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 17 Oct 2008 19:59:37.0608 (UTC) FILETIME=[E241A080:01C93092] X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Mon, 20 Oct 2008 00:32:57 -0700 Cc: Tim Polk , secdir@mit.edu, dthaler@microsoft.com, v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns-00 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Nathan, Thanks for your comments. Please see responses inline. Nathan Ward wrote: > On 13/10/2008, at 4:38 PM, Suresh Krishnan wrote: > >>>> One simple method to do that is easy to employ for many tunnel >>>> protocols is to block outbound packets to the UDP or TCP port used >>>> (e.g., UDP port 3544 for Teredo, UDP port 1701 for L2TP, etc.). >>> The description of this method is not precise. Is the method to >>> block dest ports, with these source ports, or either, or both? >> >> The method is to block destination ports. We have changed this sentence >> to read >> (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for >> L2TP, etc.) > > This makes me squirm a bit. > > It seems silly to promote blocking discrete ports, when a user could > simply run their own Teredo server on a different port and tunnel out > with that, or run any other proxy or tunnel server of some kind on any > port they wanted. We've all run PPP over SSH before, it's not hard to do > this stuff, there are tools to do it automatically. You are right. This will not stop people from tunneling over other ports. But what would you propose to be done instead? > > If an organisation is concerned about people tunnelling through their > firewalls, they must use default-deny if they want to have any effect. Given the savvy user you mentioned above, I don't understand how this will have any effect either. The users can still tunnel over anything that has been permitted ahead of the default deny. > >>>> In 3.1.3, >>>> Tunneling over UDP or TCP (including HTTP) to reach the Internet is >>>> not recommended as a solution for managed networks. >>> First, I'm going to read the sentence as if the word 'managed' was >>> not used as I think all networks on the Internet are 'managed' to >>> some degree. If the authors had a particular definition of the term >>> 'managed network' in mind, they should define it. >>> So reading the sentence without the term 'managed', this is basically >>> a general applicability statement that use of tunneling over UDP or >>> TCP is not recommend for use to 'reach the Internet'. I don't see >>> this recommendation as being appropriate given the issue. >> >> We have changed this text to read >> >> " Tunneling over UDP or TCP (including HTTP) to reach the Internet is >> not recommended as a solution for networks that wish to enforce >> security polcies on the user traffic. (Windows, for example, >> disables Teredo by default if it detects that it is within an >> enterprise network that contains a Windows domain controller.)" > > Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4? > I don't imagine that UDP makes it any more difficult to inspect than an > IP protocol. > > I think this statement should be changed to "Tunnelling through a > security device (ie. firewall) is not recommended for.. " etc. Sounds good. We will make this change. Cheers Suresh _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 20 00:32:59 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F1B3A6900; Mon, 20 Oct 2008 00:32:59 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E813A6AA9 for ; Fri, 17 Oct 2008 16:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.666 X-Spam-Level: X-Spam-Status: No, score=-4.666 tagged_above=-999 required=5 tests=[AWL=1.933, 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 ohsfQlGLoJxY for ; Fri, 17 Oct 2008 16:40:59 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5336C3A68A1 for ; Fri, 17 Oct 2008 16:40:58 -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 m9HNg3HH027526 for ; Fri, 17 Oct 2008 19:42:03 -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 m9HNfxg8027523 for ; Fri, 17 Oct 2008 19:41:59 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9HNfq62022876 for ; Fri, 17 Oct 2008 19:41:52 -0400 (EDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 46FAD11D52B5 for ; Fri, 17 Oct 2008 19:41:31 -0400 (EDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m9HNf9S0009112; Fri, 17 Oct 2008 18:41:09 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 18:41:08 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Oct 2008 01:41:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 18 Oct 2008 01:41:04 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180023EA135@DEEXC1U01.de.lucent.com> In-Reply-To: <2AEBF52A-07E8-4352-B236-DF9896A5192E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-sip-fork-loop-fix-07.txt Thread-Index: Ackwjj2PZLjr0iI0S4Skk4izxm3ETwAIpOmw References: <2AEBF52A-07E8-4352-B236-DF9896A5192E@cisco.com> From: "DRAGE, Keith (Keith)" To: "Cullen Jennings" , "Charlie Kaufman" X-OriginalArrivalTime: 17 Oct 2008 23:41:05.0812 (UTC) FILETIME=[D2A4A540:01C930B1] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9HNfxg8027523 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Mon, 20 Oct 2008 00:32:57 -0700 Cc: Robert Sparks , slawrence@bluesocket.com, secdir@mit.edu, Byron Campen , Dan Romascanu , IESG IESG , Dean Willis , alan.ietf@polyphase.ca Subject: Re: [secdir] Secdir review of draft-ietf-sip-fork-loop-fix-07.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I read: > I don't believe there is any complete solution to this problem that = > doesn't break some known desirable scenarios. I can think of some = > partial solutions that improve the situation - perhaps be enough, but = > I can't be sure. These include: So to a certain extent assumed that what followed were not necessarily expe= cted to be followed through. = For: > There should be a real time bound on any forwarded SIP request, after = > which the request is deleted and its state removed. I don't know the = > appropriate real time bound, but I can't imagine any reason to let a = > request bounce around in the network for more than a week. > One example query in the document (section 3) was estimated to take > 3 trillion years to complete. I assumed that because of the provided mechanisms we would avoid system ove= rload due to multiple parallel forking, and that therefore processing power= would let us get to the expiry of the Max-Forwards header within a reasona= ble time. = There were proposals a while back to decrease the recommended initial value= of the Max-Forwards header from 70 to 20, but they do not seem to have com= e to anything. Is this something that we believe should now happen? Regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] = > Sent: Friday, October 17, 2008 8:26 PM > To: Charlie Kaufman > Cc: secdir@mit.edu; IESG IESG; Robert Sparks; = > slawrence@bluesocket.com; alan.ietf@polyphase.ca; Byron = > Campen; Dean Willis; DRAGE, Keith (Keith); Dan Romascanu > Subject: Re: Secdir review of draft-ietf-sip-fork-loop-fix-07.txt > = > = > Hi All, > = > I have put this draft on the agenda for next weeks IESG call = > but I have not seen much discussion of what if any changes = > should be made given the review below. The unfortunate = > problem is we don't have any particularly good solutions for = > the loop issue and mostly need to decide what we can get = > published and implemented that is significantly better than 3261. > = > Cullen > = > On Sep 29, 2008, at 12:11 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. > > > > Since my last review of this document where I complained of a = > > dangerous exposure to looping attacks caused by malicious - or even = > > accidental - misconfiguration, the document has been = > revised so as to = > > make such loops somewhat less likely to occur by accident = > and somewhat = > > less disastrous for network loading when they do occur. The attacks = > > and their consequences are also much better explained in = > the document. = > > Unfortunately, they don't solve the fundamental problem of having a = > > single request generating an essentially infinite load. It = > still seems = > > unacceptably risky to deploy. > > > > The problem can be compared to mailing list loops. If two Internet = > > mailing lists each contain the other as a member, any = > message sent to = > > either list ends up cycling between the two list processors sending = > > continuous streams of messages to other members of both = > lists. In the = > > Internet's younger days, that happened routinely. If three Internet = > > mailing lists each contain the other two lists as members, = > and if the = > > expanders are smart enough to send out copies of the message in = > > parallel to the multiple recipients, then not only do other members = > > get a continuous stream of messages but the list expanders will be = > > overwhelmed by all of the parallel requests. I don't know = > exactly what = > > solutions we have found to this problem, but it's possible = > it could be = > > retrofit onto SIP. > > > > SIP is like the mailing list expander except that doesn't deposit = > > messages in anyone's mailbox. Instead, it is searching for = > 'presence' = > > of someone or something so as to be able to direct an = > instant message, = > > phone call, or some such. Each place where it looks for someone may = > > (like a mailing list) forward the query onto a number of other SIP = > > servers. SIP does detect loops, but in remains the case = > that if there = > > are N places to look for someone, and each of those N = > places points to = > > the other N-1 places (a not unlikely na=EFve configuration), = > there will = > > be N! queries processed before the search terminates. For N of even = > > moderate size, that can effectively be an infinite loop. > > > > The main improvement in loop detection from the previous version of = > > the spec is that it limits the parallelism of the = > processing of these = > > N! queries so that a single bad query cannot deny service to other = > > users of the SIP server. With the sample "Max-Breadth" of 60, it = > > probably does not take a very large number of these = > infinite loops to = > > overwhelm the system. > > > > The proposal I made in my last review which limited the = > total number = > > of queries in the processing of a single request would = > break too many = > > real-world scenarios. Other possibilities were discussed on the SIP = > > mailing list and this was apparently the consensus approach. > > > > I don't believe there is any complete solution to this problem that = > > doesn't break some known desirable scenarios. I can think of some = > > partial solutions that improve the situation - perhaps be = > enough, but = > > I can't be sure. These include: > > > > When checking for loops, test not only against earlier = > points in the = > > history of this query thread, but also against any parallel queries = > > that are currently waiting for responses from other SIP servers. > > This would more quickly catch the overload problem because in those = > > circumstances the tables of delegated queries would quickly explode. > > > > Any time a loop is detected, the forwarding table entry that caused = > > the loop should be disabled and flagged for an administrator to = > > examine. This could be done by suspending the identity = > being searched = > > for, or if enough information is present only suspending the = > > forwarding address that generated the loop. The upside of = > this scheme = > > is that loops will be broken quickly. The downside is that = > it creates = > > a new security exposure where someone intentionally 'fakes' > > a loop in order to make some entity unfindable. > > > > There should be a real time bound on any forwarded SIP = > request, after = > > which the request is deleted and its state removed. I don't = > know the = > > appropriate real time bound, but I can't imagine any reason = > to let a = > > request bounce around in the network for more than a week. > > One example query in the document (section 3) was estimated to take > > 3 trillion years to complete. > > > > Smaller issues: > > > > There should be some discussion in the document about what servers = > > should do in the case of overload. If particular, crashing = > is probably = > > not a good idea; overload should be expected. If the table of = > > outstanding forwarded requests overflows (as it will in = > error and some = > > non-error cases), there is a trade-off between discarding = > the oldest = > > request, the newest request, the most forwarded request, the least = > > forwarded request, etc. When the capacity for incoming = > connections is = > > exceeded, it may be better to close some existing ones to allow new = > > ones to arrive. > > > > Section 4.2.4: The document suggests a way to make loop detection = > > cheaper by using a hash function over the repeating data = > and comparing = > > the hashes. The original document suggested MD5. Even = > though for the = > > purpose of this document MD5 would be perfectly reasonable, MD5 has = > > become politically incorrect so the document now recommends = > CRC-32c as = > > an alternative. There are two problems with that. One is = > that 32 bits = > > are arguably not enough. Failing 1 in 4 billion requests is = > not very = > > many, but it will happen. As the forwarding lists get longer (and = > > particularly if a check is made against outstanding requests) the = > > failure rate will get much larger. > > More subtly, CRC-32c is 'linear', so if there is a = > collision causing a = > > failure, it may be a solid failure where retries also fail. = > A better = > > solution would be to propose a politically correct hash (like > > 64 bits of a SHA-256) and put a hint/nudge that MD5 (or even MD4) = > > would be just fine and explain why. This is only an implementation = > > hint - there is no requirement that different = > implementations do this = > > the same way. The best solution here is to compute a = > relatively small = > > hash as a performance hack, but when there is a match check the = > > unhashed values that must match. > > > > Typos: > > > > P12: ', parameters' -> ', or parameter' > > P15: 'means' -> 'mean' > > P17: 'Breadh' -> 'Breadth' > > P19: 'beleif' -> 'belief' > = > = _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 20 00:32:59 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4881028C0E4; Mon, 20 Oct 2008 00:32:59 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A3B3A6864 for ; Sun, 19 Oct 2008 13:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.53 X-Spam-Level: X-Spam-Status: No, score=-4.53 tagged_above=-999 required=5 tests=[AWL=2.069, 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 qFqDl+yTGugG for ; Sun, 19 Oct 2008 13:36:21 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 0FDE63A68E4 for ; Sun, 19 Oct 2008 13:36: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 m9JKbU5u016227 for ; Sun, 19 Oct 2008 16:37:30 -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 m9JKbQbg016224 for ; Sun, 19 Oct 2008 16:37:26 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9JKbJi7000398 for ; Sun, 19 Oct 2008 16:37:19 -0400 (EDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.248]) by mit.edu (Spam Firewall) with ESMTP id B5ACEBB877B for ; Sun, 19 Oct 2008 16:37:18 -0400 (EDT) Received: by rv-out-0708.google.com with SMTP id f25so1883666rvb.18 for ; Sun, 19 Oct 2008 13:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VgyhMwqMn5SLMRhbM4AXfVtBB79xV92gnWjrI9kR+S0=; b=dFsQGo/niegPXxffpz29RIVnWlt1lft8P1m4JrqZiLnpluaZpvyNHqn6esP1XACs/O M4PgWk5Iq7ppIwfipPaRqddHCqL1IZJ3swnwr8vcMO89BvKyDSptRZniYFIuAN5TzhpQ 9QZKEAijjCDrqjhOobXiqqDycSSEC+4OsHtao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=PaslFtxa8VJ34SqohiNx7UaV4jitUb/wGmKmpT+W5//VVN7BvnuUjiCbRdE9N6tf+a mMaSi2k32f1Zfk94Cj1yWXfLDwL4843GXk+pMSQOsT9uPPalq8YAEpgs1WFFsI0uOXTu uTbc73rfUtIs0Tsx4H0Kz+Ps/7tawtmBJWlOQ= Received: by 10.140.202.12 with SMTP id z12mr4274076rvf.186.1224448638401; Sun, 19 Oct 2008 13:37:18 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k2sm17004390rvb.1.2008.10.19.13.37.15 (version=SSLv3 cipher=RC4-MD5); Sun, 19 Oct 2008 13:37:17 -0700 (PDT) Message-ID: <48FB9A79.8040407@gmail.com> Date: Mon, 20 Oct 2008 09:37:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> In-Reply-To: <48F8EE0D.4060307@ericsson.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Mon, 20 Oct 2008 00:32:57 -0700 Cc: Nathan Ward , Tim Polk , secdir@mit.edu, dthaler@microsoft.com, v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org ... >> Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4? >> I don't imagine that UDP makes it any more difficult to inspect than >> an IP protocol. >> >> I think this statement should be changed to "Tunnelling through a >> security device (ie. firewall) is not recommended for.. " etc. > > Sounds good. We will make this change. Now you have me worried enough to say something I've been feeling ever since I really read this draft carefully. To exaggerate, why not just rename it "tunneling considered harmful" and chop it down to one paragraph? I think there's a real risk of this document being misunderstood by typical site IT managers, and being used simply as an excuse to block all kinds of tunnel-based v4/v6 coexistence. But tunnels are a legitimate coexistence strategy. I'd much rather see this document talking more about how to make the use of tunnels safe as part of v4/v6 coexistence. There is some of that material in the document, but the impression the draft leaves is now of a succession of warnings to block tunnels. Brian _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 20 00:32:59 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5816628C0EA; Mon, 20 Oct 2008 00:32:59 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FEE3A692D for ; Sun, 19 Oct 2008 21:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.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 E1KfvkAJTLDA for ; Sun, 19 Oct 2008 21:39:29 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 475593A6877 for ; Sun, 19 Oct 2008 21:39:28 -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 m9K4edvS020978 for ; Mon, 20 Oct 2008 00:40:39 -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 m9K4eZjl020964 for ; Mon, 20 Oct 2008 00:40:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9K4eQIL024745 for ; Mon, 20 Oct 2008 00:40:26 -0400 (EDT) X-ASG-Whitelist: Barracuda Reputation Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3F13C10A6DED for ; Mon, 20 Oct 2008 00:40:26 -0400 (EDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Sun, 19 Oct 2008 21:40:25 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.1.291.1; Sun, 19 Oct 2008 21:40:24 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Sun, 19 Oct 2008 21:40:50 -0700 From: Christian Huitema To: Brian E Carpenter , Suresh Krishnan Date: Sun, 19 Oct 2008 21:40:20 -0700 Thread-Topic: SECDIR review: draft-ietf-v6ops-tunnel-concerns Thread-Index: AckyK7876dxng3L8RzC/j07RVge7RAAQVcXg Message-ID: <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> In-Reply-To: <48FB9A79.8040407@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from base64 to 8bit by pch.mit.edu id m9K4eZjl020964 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Mon, 20 Oct 2008 00:32:57 -0700 Cc: Nathan Ward , Dave Thaler , Tim Polk , "secdir@mit.edu" , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org > I think there's a real risk of this document being misunderstood > by typical site IT managers, and being used simply as an excuse > to block all kinds of tunnel-based v4/v6 coexistence. But tunnels > are a legitimate coexistence strategy. I'd much rather see > this document talking more about how to make the use of tunnels > safe as part of v4/v6 coexistence. There is some of that material > in the document, but the impression the draft leaves is now of > a succession of warnings to block tunnels. Actually, it is a succession of warning to block standardized tunnels, those that are well documented and have a clear signature. By doing so, we are pushing application developers to just "roll their own technologies", and indeed to use evasive techniques such as encrypted packets, random port numbers or tunneling of HTTP. I am not sure that network managers are going to like the result... -- Christian Huitema _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 20 18:36:36 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7593A6ADE; Mon, 20 Oct 2008 18:36:36 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAC13A6AB4 for ; Mon, 20 Oct 2008 18:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 OA5Z7yVVC628 for ; Mon, 20 Oct 2008 18:36:33 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A0F2F3A6962 for ; Mon, 20 Oct 2008 18:36:33 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id m9L1bjQa093218 for ; Mon, 20 Oct 2008 21:37:45 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id m9L1bjET093215 for ; Mon, 20 Oct 2008 21:37:45 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 20 Oct 2008 21:37:45 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Mon, 20 Oct 2008 21:37:45 -0400 (EDT) Subject: [secdir] Assignments for October 27th 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org There were some late additions to the telechat this week, all of documents that had already been assigned for some time. Carl Wallace is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2008-10-21 David Harrington T draft-ietf-sip-xcapevent-04 Jeffrey Hutzelman T draft-ietf-sip-rph-new-namespaces-03 Charlie Kaufman TR draft-ietf-sip-fork-loop-fix-07 Sandy Murphy T draft-ietf-idr-as-representation-01 Last calls and special requests: Lakshminath Dondeti draft-ietf-enum-combined-08 Lakshminath Dondeti draft-ietf-avt-rfc4749-dtx-update-02 Phillip Hallam-Baker draft-ietf-psamp-info-11 Steve Hanna draft-rescorla-tls-suiteb-08 Sam Hartman draft-hammer-oauth-00 Paul Hoffman draft-bryan-metalink-03 Love Hornquist-Astrand draft-ietf-sip-sips-08 Tero Kivinen draft-ietf-sip-media-security-requirements-07 Julien Laganier draft-ietf-softwire-mesh-framework-05 Julien Laganier draft-ietf-softwire-encaps-ipsec-01 Julien Laganier draft-ietf-sipping-cc-transfer-11 Marcus Leech draft-ietf-dnsext-forgery-resilience-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-16 Catherine Meadows draft-ietf-behave-dccp-03 Alexey Melnikov draft-ietf-pce-pcep-xro-06 Alexey Melnikov draft-ietf-behave-stun-test-vectors-03 Sandy Murphy draft-ietf-mpls-mpls-and-gmpls-security-framework-03 Vidya Narayanan draft-ietf-lemonade-imap-notify-07 Magnus Nystrom draft-ietf-vrrp-unified-spec-02 Eric Rescorla draft-ietf-sip-dtls-srtp-framework-04 Joe Salowey draft-ietf-emu-eap-gpsk-15 Stefan Santesson draft-ietf-lemonade-architecture-03 Juergen Schoenwaelder draft-ietf-dhc-dhcpv6-bulk-leasequery-04 Susan Thomson draft-ietf-nfsv4-minorversion1-dot-x-09 Hannes Tschofenig draft-ietf-nfsv4-pnfs-block-09 Sean Turner draft-ietf-nfsv4-pnfs-obj-09 Carl Wallace R draft-hartman-webauth-phishing-09 Sam Weiler draft-chown-v6ops-rogue-ra-01 Nico Williams draft-ietf-v6ops-ra-guard-01 Nico Williams draft-ietf-nfsv4-minorversion1-26 Kurt Zeilenga R draft-daboo-imap-annotatemore-15 Larry Zhu draft-thaler-v6ops-teredo-extensions-01 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 20 18:59:50 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96393A6839; Mon, 20 Oct 2008 18:59:50 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302A13A6839 for ; Mon, 20 Oct 2008 18:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.076 X-Spam-Level: X-Spam-Status: No, score=-6.076 tagged_above=-999 required=5 tests=[AWL=0.523, 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 WuvHu2VfalJd for ; Mon, 20 Oct 2008 18:59:48 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 34E253A6ADF for ; Mon, 20 Oct 2008 18:59:47 -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 m9L20wdD005031 for ; Mon, 20 Oct 2008 22:00:58 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9L20sqa005018 for ; Mon, 20 Oct 2008 22:00:54 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9L20lD9021442 for ; Mon, 20 Oct 2008 22:00:47 -0400 (EDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mit.edu (Spam Firewall) with ESMTP id 4CA6CBDDD16; Mon, 20 Oct 2008 22:00:25 -0400 (EDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9L20O8R022137; Tue, 21 Oct 2008 02:00:24 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9L20Lw1049996; Mon, 20 Oct 2008 20:00:22 -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 m9L1iu1e018060; Mon, 20 Oct 2008 20:44:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9L1iu8t018059; Mon, 20 Oct 2008 20:44:56 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 20 Oct 2008 20:44:56 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20081021014455.GN8906@Sun.COM> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On thing that sticks out from the Introduction is this: | However, some applications (e.g. distributed file systems), | most often those not designed for use with Compartmented Mode | Workstations or other Multi-Level Secure (MLS) computers, | multiplex different transactions at different sensitivity levels | and/or with different privileges over a single IP communications | session (e.g. with the User Datagram Protocol). So far so good, and certainly true. But then: | In order to | maintain data Sensitivity Labeling for such applications, in | order to be able to implement routing and Mandatory Access | Control decisions in routers and guards on a per-IP-packet basis, | and for other reasons, there is a need to have a mechanism for | explicitly labeling the sensitivity information for each IPv6 | packet. So if I understand correctly then this document would have an implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the same TCP connection with different labels, *and* ensure that each packet contains parts of no more than one (exactly one) NFSv4 RPC. Surely that would have an enormous impact on transport protocol implementations! And all so that middle boxes can make labelled routing decisions at 100Gbps wire speed. And these are not simple labels either. And the middle boxes have to trust the end nodes to get the labelling right. Call me a skeptic. I don't see this flying. In any case, wouldn't it be easier to just use IPsec with labelled SAs (with no outer packet labelling) and let the middle boxes be label agnostic? The end nodes still have to be trusted to get the labelling right, but this way you free the middle boxes to do what they're good at (routing) and use crypto to provide integrity and confidentiality protection over any public networks. And if you really must have outer packet labelling for middle boxes to inspect, why not modify NFSv4 clients to use a TCP connection per-local {user, label}? That'd certainly be a lot less troublesome than to modify TCP to keep track of labels in a PCB's buffers/arrange to send each sub-buffer in a separate packet or train of packets! The changes proposed in this I-D are non-trivial, but there are clearly far simpler alternatives. Nico [0] "e.g. distributed file systems"? NFSv4 qualifies. [1] "multiplex different transactions... over a single IP communications session (e.g. with the User Datagram Protocol)"? NFSv4 qualifies, though the mandatory-to- implement transport for NFSv4 is TCP, not UDP. -- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 20 19:58:35 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35E63A6939; Mon, 20 Oct 2008 19:58:35 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F12C3A6939 for ; Mon, 20 Oct 2008 19:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=1.970, 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 KvFg1Dd6f9AD for ; Mon, 20 Oct 2008 19:58:34 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 97EFD3A68A1 for ; Mon, 20 Oct 2008 19:58:33 -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 m9L2xkDO013071 for ; Mon, 20 Oct 2008 22:59:47 -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 m9L2xkFj013068 for ; Mon, 20 Oct 2008 22:59:46 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9L2xdsK012759 for ; Mon, 20 Oct 2008 22:59:39 -0400 (EDT) Received: from balder-227.proper.com (balder-227.proper.com [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A586BBD24F7 for ; Mon, 20 Oct 2008 22:59:38 -0400 (EDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9L2xXUn080344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 19:59:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 20 Oct 2008 19:59:31 -0700 To: secdir@mit.edu From: Paul Hoffman X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: anthonybryan@gmail.com Subject: [secdir] SecDir review for draft-bryan-metalink X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 statement at the beginning of section 6 is correct and complete: Because Metalink is an XML-based format, existing XML security mechanisms can be used to secure its content. That is, this is a fine example of "take this content and bag it with a standard security wrapper". I don't see any other security issues specific to "these are files you want to download". Dangerous content in the files is really no different than dangerous content on a web page, for example. On a non-security note, I hate the content of the reference for [BITTORRENT], but I cannot suggest a better one. If the BitTorrent people don't want to make their reference stable, we just have to suck it up. --Paul Hoffman, Director --VPN Consortium _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 01:37:26 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF9A3A68E0; Tue, 21 Oct 2008 01:37:26 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167C53A6AF5 for ; Mon, 20 Oct 2008 11:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[AWL=2.234, 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 qsrcvSIfo7oF for ; Mon, 20 Oct 2008 11:13:38 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 937A43A6AEE for ; Mon, 20 Oct 2008 11:13:38 -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 m9KIEFN9006951 for ; Mon, 20 Oct 2008 14:14:15 -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 m9KIE934006926 for ; Mon, 20 Oct 2008 14:14:10 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9KIE287020209 for ; Mon, 20 Oct 2008 14:14:02 -0400 (EDT) Received: from nostrum.com (shaman.nostrum.com [72.232.15.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 026B610A062B for ; Mon, 20 Oct 2008 14:13:40 -0400 (EDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.1) with ESMTP id m9KIDElh047124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Oct 2008 13:13:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <83C01164-B1D0-4433-B611-DCB994AC34CE@nostrum.com> From: Robert Sparks To: Cullen Jennings In-Reply-To: <2AEBF52A-07E8-4352-B236-DF9896A5192E@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 20 Oct 2008 13:13:14 -0500 References: <2AEBF52A-07E8-4352-B236-DF9896A5192E@cisco.com> X-Mailer: Apple Mail (2.929.2) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9KIE934006926 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Tue, 21 Oct 2008 01:37:25 -0700 Cc: Robert Sparks , slawrence@bluesocket.com, Keith Drage , alan.ietf@polyphase.ca, Dan Romascanu , IESG IESG , Dean Willis , Byron Campen , secdir@mit.edu Subject: Re: [secdir] Secdir review of draft-ietf-sip-fork-loop-fix-07.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org To reinforce Cullen's point here: This draft makes a really bad situation significantly better - its not = perfect, and the WG has spend time discussing the kinds of issues = Charlie points to (I'll respond directly to Charlie's message in a = moment). I've seen several implementations of the loop-detection part of this = draft (and a couple of the max-breadth) already - we retested the = original doom-scenario at the SIPit last week, and, as anticipated, it = resulted in quick loop-detection instead of message explosion. It's important to get this published as a "make it better" step - we = need to encourage existing deployed implementations to make these = changes if they haven't already. We can continue work on making it = even better, but the discussions so far indicate that steps past = what's here will involve major architectural changes to the core = protocol. RjS On Oct 17, 2008, at 2:25 PM, Cullen Jennings wrote: > > Hi All, > > I have put this draft on the agenda for next weeks IESG call but I = > have not seen much discussion of what if any changes should be made = > given the review below. The unfortunate problem is we don't have any = > particularly good solutions for the loop issue and mostly need to = > decide what we can get published and implemented that is = > significantly better than 3261. > > Cullen > > On Sep 29, 2008, at 12:11 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. >> >> Since my last review of this document where I complained of a = >> dangerous exposure to looping attacks caused by malicious - or even = >> accidental - misconfiguration, the document has been revised so as = >> to make such loops somewhat less likely to occur by accident and = >> somewhat less disastrous for network loading when they do occur. = >> The attacks and their consequences are also much better explained = >> in the document. Unfortunately, they don't solve the fundamental = >> problem of having a single request generating an essentially = >> infinite load. It still seems unacceptably risky to deploy. >> >> The problem can be compared to mailing list loops. If two Internet = >> mailing lists each contain the other as a member, any message sent = >> to either list ends up cycling between the two list processors = >> sending continuous streams of messages to other members of both = >> lists. In the Internet's younger days, that happened routinely. If = >> three Internet mailing lists each contain the other two lists as = >> members, and if the expanders are smart enough to send out copies = >> of the message in parallel to the multiple recipients, then not = >> only do other members get a continuous stream of messages but the = >> list expanders will be overwhelmed by all of the parallel requests. = >> I don't know exactly what solutions we have found to this problem, = >> but it's possible it could be retrofit onto SIP. >> >> SIP is like the mailing list expander except that doesn't deposit = >> messages in anyone's mailbox. Instead, it is searching for = >> 'presence' of someone or something so as to be able to direct an = >> instant message, phone call, or some such. Each place where it = >> looks for someone may (like a mailing list) forward the query onto = >> a number of other SIP servers. SIP does detect loops, but in = >> remains the case that if there are N places to look for someone, = >> and each of those N places points to the other N-1 places (a not = >> unlikely na=EFve configuration), there will be N! queries processed = >> before the search terminates. For N of even moderate size, that can = >> effectively be an infinite loop. >> >> The main improvement in loop detection from the previous version of = >> the spec is that it limits the parallelism of the processing of = >> these N! queries so that a single bad query cannot deny service to = >> other users of the SIP server. With the sample "Max-Breadth" of 60, = >> it probably does not take a very large number of these infinite = >> loops to overwhelm the system. >> >> The proposal I made in my last review which limited the total = >> number of queries in the processing of a single request would break = >> too many real-world scenarios. Other possibilities were discussed = >> on the SIP mailing list and this was apparently the consensus = >> approach. >> >> I don't believe there is any complete solution to this problem that = >> doesn't break some known desirable scenarios. I can think of some = >> partial solutions that improve the situation - perhaps be enough, = >> but I can't be sure. These include: >> >> When checking for loops, test not only against earlier points in = >> the history of this query thread, but also against any parallel = >> queries that are currently waiting for responses from other SIP = >> servers. This would more quickly catch the overload problem because = >> in those circumstances the tables of delegated queries would = >> quickly explode. >> >> Any time a loop is detected, the forwarding table entry that caused = >> the loop should be disabled and flagged for an administrator to = >> examine. This could be done by suspending the identity being = >> searched for, or if enough information is present only suspending = >> the forwarding address that generated the loop. The upside of this = >> scheme is that loops will be broken quickly. The downside is that = >> it creates a new security exposure where someone intentionally = >> 'fakes' a loop in order to make some entity unfindable. >> >> There should be a real time bound on any forwarded SIP request, = >> after which the request is deleted and its state removed. I don't = >> know the appropriate real time bound, but I can't imagine any = >> reason to let a request bounce around in the network for more than = >> a week. One example query in the document (section 3) was estimated = >> to take 3 trillion years to complete. >> >> Smaller issues: >> >> There should be some discussion in the document about what servers = >> should do in the case of overload. If particular, crashing is = >> probably not a good idea; overload should be expected. If the table = >> of outstanding forwarded requests overflows (as it will in error = >> and some non-error cases), there is a trade-off between discarding = >> the oldest request, the newest request, the most forwarded request, = >> the least forwarded request, etc. When the capacity for incoming = >> connections is exceeded, it may be better to close some existing = >> ones to allow new ones to arrive. >> >> Section 4.2.4: The document suggests a way to make loop detection = >> cheaper by using a hash function over the repeating data and = >> comparing the hashes. The original document suggested MD5. Even = >> though for the purpose of this document MD5 would be perfectly = >> reasonable, MD5 has become politically incorrect so the document = >> now recommends CRC-32c as an alternative. There are two problems = >> with that. One is that 32 bits are arguably not enough. Failing 1 = >> in 4 billion requests is not very many, but it will happen. As the = >> forwarding lists get longer (and particularly if a check is made = >> against outstanding requests) the failure rate will get much = >> larger. More subtly, CRC-32c is 'linear', so if there is a = >> collision causing a failure, it may be a solid failure where = >> retries also fail. A better solution would be to propose a = >> politically correct hash (like 64 bits of a SHA-256) and put a hint/ = >> nudge that MD5 (or even MD4) would be just fine and explain why. = >> This is only an implementation hint - there is no requirement that = >> different implementations do this the same way. The best solution = >> here is to compute a relatively small hash as a performance hack, = >> but when there is a match check the unhashed values that must match. >> >> Typos: >> >> P12: ', parameters' -> ', or parameter' >> P15: 'means' -> 'mean' >> P17: 'Breadh' -> 'Breadth' >> P19: 'beleif' -> 'belief' > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 01:37:27 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101DA3A6A2B; Tue, 21 Oct 2008 01:37:27 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F60B3A68D0 for ; Mon, 20 Oct 2008 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.542 X-Spam-Level: X-Spam-Status: No, score=-4.542 tagged_above=-999 required=5 tests=[AWL=2.057, 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 XEPa+D4wZWDR for ; Mon, 20 Oct 2008 11:51:52 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 99FC73A6A11 for ; Mon, 20 Oct 2008 11:51:52 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9KIr3Ym021145 for ; Mon, 20 Oct 2008 14:53:03 -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 m9KIr1rV021100 for ; Mon, 20 Oct 2008 14:53:01 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9KIqrOK014289 for ; Mon, 20 Oct 2008 14:52:54 -0400 (EDT) Received: from nostrum.com (shaman.nostrum.com [72.232.15.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 6BA30134B84E for ; Mon, 20 Oct 2008 14:52:32 -0400 (EDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.1) with ESMTP id m9KIq7Kh049825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Oct 2008 13:52:08 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Charlie Kaufman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 20 Oct 2008 13:52:07 -0500 References: X-Mailer: Apple Mail (2.929.2) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9KIr1rV021100 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Tue, 21 Oct 2008 01:37:25 -0700 Cc: "fluffy@cisco.com" , "rjs@nostrum.com" , "slawrence@bluesocket.com" , "secdir@mit.edu" , "drage@alcatel-lucent.com" , "bcampen@estacado.net" , "dromasca@avaya.com" , "iesg@ietf.org" , "dean.willis@softarmor.com" , "alan.ietf@polyphase.ca" Subject: Re: [secdir] Secdir review of draft-ietf-sip-fork-loop-fix-07.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Charlie - Apologies for the delayed response - I saw this right before heading = to SIPit last week (and last week was really busy). Some comments inline: On Sep 29, 2008, at 1:11 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. > > Since my last review of this document where I complained of a = > dangerous exposure to looping attacks caused by malicious - or even = > accidental - misconfiguration, the document has been revised so as = > to make such loops somewhat less likely to occur by accident and = > somewhat less disastrous for network loading when they do occur. The = > attacks and their consequences are also much better explained in the = > document. Unfortunately, they don't solve the fundamental problem of = > having a single request generating an essentially infinite load. It = > still seems unacceptably risky to deploy. We beat on exactly this question in the WG when we were discussing = this revision. The group recognizes that there is still a path through = this can stimulate a very large number of message, even if they are = spread over a long period of time. The consensus was that this is a = significant enough improvement to move forward with it. To completely = solve the problem you're describing will likely require fundamental = protocol changes - things less likely to be quickly implemented and = deployed than what this draft is describing. > > > The problem can be compared to mailing list loops. If two Internet = > mailing lists each contain the other as a member, any message sent = > to either list ends up cycling between the two list processors = > sending continuous streams of messages to other members of both = > lists. In the Internet's younger days, that happened routinely. If = > three Internet mailing lists each contain the other two lists as = > members, and if the expanders are smart enough to send out copies of = > the message in parallel to the multiple recipients, then not only do = > other members get a continuous stream of messages but the list = > expanders will be overwhelmed by all of the parallel requests. I = > don't know exactly what solutions we have found to this problem, but = > it's possible it could be retrofit onto SIP. > > SIP is like the mailing list expander except that doesn't deposit = > messages in anyone's mailbox. Instead, it is searching for = > 'presence' of someone or something so as to be able to direct an = > instant message, phone call, or some such. Each place where it looks = > for someone may (like a mailing list) forward the query onto a = > number of other SIP servers. SIP does detect loops, but in remains = > the case that if there are N places to look for someone, and each of = > those N places points to the other N-1 places (a not unlikely na=EFve = > configuration), there will be N! queries processed before the search = > terminates. For N of even moderate size, that can effectively be an = > infinite loop. (At the risk of opening a different can of worms): And this is even worse in real deployments right now because there are = a lot of non-standard things in the network that are not SIP proxies = but act mostly like intermediaries (things often called B2BUAs or = SBCs). They _remove_ the historic information as they propagate the = message - rendering what's in _this_ draft ineffective. > > > The main improvement in loop detection from the previous version of = > the spec is that it limits the parallelism of the processing of = > these N! queries so that a single bad query cannot deny service to = > other users of the SIP server. With the sample "Max-Breadth" of 60, = > it probably does not take a very large number of these infinite = > loops to overwhelm the system. > > The proposal I made in my last review which limited the total number = > of queries in the processing of a single request would break too = > many real-world scenarios. Other possibilities were discussed on the = > SIP mailing list and this was apparently the consensus approach. > > I don't believe there is any complete solution to this problem that = > doesn't break some known desirable scenarios. I can think of some = > partial solutions that improve the situation - perhaps be enough, = > but I can't be sure. These include: I see these next two suggestions as reasonable operation/ = implementation recommendations rather than protocol changes - maybe we = could add them to the "advice-to" section? > > > When checking for loops, test not only against earlier points in the = > history of this query thread, but also against any parallel queries = > that are currently waiting for responses from other SIP servers. = > This would more quickly catch the overload problem because in those = > circumstances the tables of delegated queries would quickly explode. > > Any time a loop is detected, the forwarding table entry that caused = > the loop should be disabled and flagged for an administrator to = > examine. This could be done by suspending the identity being = > searched for, or if enough information is present only suspending = > the forwarding address that generated the loop. The upside of this = > scheme is that loops will be broken quickly. The downside is that it = > creates a new security exposure where someone intentionally 'fakes' = > a loop in order to make some entity unfindable. > > > There should be a real time bound on any forwarded SIP request, = > after which the request is deleted and its state removed. I don't = > know the appropriate real time bound, but I can't imagine any reason = > to let a request bounce around in the network for more than a week. = > One example query in the document (section 3) was estimated to take = > 3 trillion years to complete. Allowing a SIP request to pend forever was an intentional design = choice made very early in the protocol's lifetime - allowing the = rendezvous function to hunt for new targets forever is a direct, if = possible unintended, consequence. We have built in mechanisms to both = endpoints and proxies that allow them to make this hunt (or direct = pending request) stop. When we did that, particularly for proxies, we = argued for a _very_ long time about what a good recommended bound = would be and couldn't develop a good consensus - 3261's discussion of = Timer C says "must be at least 3 minutes". Essentially, this interacts = directly with how long you can let a request to start communicating = remain outstanding - (the early application was "letting a phone = ring"). And we have real-world scenarios, such as interacting with = IVRs from really big companies, where phone-calls stay in the ringing = state the whole time you're interacting with the robot - something = that can take 10s or 30s of minutes. > > > Smaller issues: > > There should be some discussion in the document about what servers = > should do in the case of overload. If particular, crashing is = > probably not a good idea; overload should be expected. If the table = > of outstanding forwarded requests overflows (as it will in error and = > some non-error cases), there is a trade-off between discarding the = > oldest request, the newest request, the most forwarded request, the = > least forwarded request, etc. When the capacity for incoming = > connections is exceeded, it may be better to close some existing = > ones to allow new ones to arrive. There is a separate effort in the WG right now addressing overload. > > > Section 4.2.4: The document suggests a way to make loop detection = > cheaper by using a hash function over the repeating data and = > comparing the hashes. The original document suggested MD5. Even = > though for the purpose of this document MD5 would be perfectly = > reasonable, MD5 has become politically incorrect so the document now = > recommends CRC-32c as an alternative. There are two problems with = > that. One is that 32 bits are arguably not enough. Failing 1 in 4 = > billion requests is not very many, but it will happen. As the = > forwarding lists get longer (and particularly if a check is made = > against outstanding requests) the failure rate will get much larger. = > More subtly, CRC-32c is 'linear', so if there is a collision causing = > a failure, it may be a solid failure where retries also fail. A = > better solution would be to propose a politically correct hash (like = > 64 bits of a SHA-256) and put a hint/nudge that MD5 (or even MD4) = > would be just fine and explain why. This is only an implementation = > hint - there is no requirement that different implementations do = > this the same way. The best solution here is to compute a relatively = > small hash as a performance hack, but when there is a match check = > the unhashed values that must match. Well, as you noted, this is only a suggestion in an "advice to = implementers" section. RFC2543/3261 recommended using MD5, and when = this went through the working group there was a lot of discussion = about not needing a cryptographic hash and that speed of computation = was important. Cullen can comment more perhaps. If I understand your = point correctly, we anticipated the repeated collision on retry in = that same section (4.2.4), leading to the recommendation to include = "at least one field in the input to the hash that varies between = different transactions". > > > Typos: > > P12: ', parameters' -> ', or parameter' > P15: 'means' -> 'mean' > P17: 'Breadh' -> 'Breadth' > P19: 'beleif' -> 'belief' Thanks for catching those! RjS _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 01:37:27 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB3A3A6AF2; Tue, 21 Oct 2008 01:37:27 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862413A683C for ; Mon, 20 Oct 2008 18:25:12 -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 XMTKR3V3Na27 for ; Mon, 20 Oct 2008 18:25:08 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 32EBF3A659A for ; Mon, 20 Oct 2008 18:25:07 -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 m9L1QJYD000313 for ; Mon, 20 Oct 2008 21:26:19 -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 m9L1QD91000310 for ; Mon, 20 Oct 2008 21:26:13 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9L1Q6bV020386 for ; Mon, 20 Oct 2008 21:26:06 -0400 (EDT) X-ASG-Whitelist: Barracuda Reputation Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id ECF4D11D6C9D for ; Mon, 20 Oct 2008 21:26:05 -0400 (EDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 1CC76425202C; Mon, 20 Oct 2008 18:26:05 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id EC25D28081; Mon, 20 Oct 2008 18:26:04 -0700 (PDT) X-AuditID: 11807130-ac9b1bb000000ea6-69-48fd2fa82392 Received: from [59.8.107.76] (unknown [17.83.206.70]) by relay11.apple.com (Apple SCV relay) with ESMTP id D46A82804F; Mon, 20 Oct 2008 18:26:00 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081007153748.8E7C03A6B3A@core3.amsl.com> References: <20081007153748.8E7C03A6B3A@core3.amsl.com> Date: Tue, 21 Oct 2008 10:16:29 +0900 To: Tim Polk , Shawn M Emery , secdir@mit.edu From: Dave Singer X-Brightmail-Tracker: AAAAAA== X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Tue, 21 Oct 2008 01:37:25 -0700 Cc: avt-chairs@tools.ietf.org, hd@qualcomm.com Subject: Re: [secdir] COMMENT: draft-ietf-avt-rtp-toffset X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org At 8:37 -0700 7/10/08, Tim Polk wrote: >Comment: >(1) I was amused when I read the security considerations. It *is* >hard to see how informative >offsets have any security implications, but I appreciate the effort! > >I would recommend adding a sentence pointing to RFC 3550 for the core security >considerations. added: The underlying security considerations of should be taken into account. > >(2) FYI, [hdrext] is now RFC 5285. Perhaps that should be added to >the RFC Editor Note. Yes, it is indeed published. At 2:03 -0600 8/10/08, Shawn M Emery wrote: >I believe more guidance would help here. For instance; security >considerations should be made based on how applications act upon >network jitter information and if the attribute is determined to be >sensitive to a DoS attack, for instance, then protecting this >information should be made. Referring to recommendations outlined >in the RTP RFC or better. added: It is possible that malicious senders (or systems tampering with packets in transit) could send offsets that are implausible, could confuse the receiver, or result in calculated jitter values that might mislead the sender. Both sender and receiver of the transmission offsets and jitter values should take care that such behavior does not result in denial-of-service or other problems. > >Other than that, I see no additional security concerns from that of RTP. -- David Singer Multimedia Standards, Apple Inc. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 01:37:27 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312073A6B3D; Tue, 21 Oct 2008 01:37:27 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C483A6AFF for ; Mon, 20 Oct 2008 18:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 mpCelDVhU7BH for ; Mon, 20 Oct 2008 18:47:38 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id B5D763A6B00 for ; Mon, 20 Oct 2008 18:47:38 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1882518rvf.49 for ; Mon, 20 Oct 2008 18:48:50 -0700 (PDT) Received: by 10.141.27.16 with SMTP id e16mr5311165rvj.136.1224553730788; Mon, 20 Oct 2008 18:48:50 -0700 (PDT) Received: from ?192.168.1.100? (adsl-70-231-246-196.dsl.snfc21.sbcglobal.net [70.231.246.196]) by mx.google.com with ESMTPS id g31sm2158055rvb.7.2008.10.20.18.48.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Oct 2008 18:48:50 -0700 (PDT) Message-ID: <48FD351C.3010300@acm.org> Date: Mon, 20 Oct 2008 18:49:16 -0700 From: John Panzer User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: oauth@googlegroups.com References: In-Reply-To: X-Mailman-Approved-At: Tue, 21 Oct 2008 01:37:25 -0700 Cc: draft-hammer-oauth@tools.ietf.org, lisa@osafoundation.org, secdir@ietf.org Subject: Re: [secdir] [oauth] Secdir Review of draft-hammer-oauth-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jpanzer@acm.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Sam Hartman wrote: > ... > One thing we've been looking at with HTTP authentication schemes is > whether they are browser specific or whether they will work well in > atom/dav/etc environments. Most of oauth will work well in a > non-browser context. However oauth redirects the user from the > consumer to the service provider to seek authorization for the request > token. This tends to mean that the service provider and consumer tend > to need to have the same idea about what kind of agent the user is > using. It seems clear that the service provider can enable whatever > they like, but that oauth may have limitations when being used with > classes of agent the service provider has never considered. > Side note: OAuth is also usable for persistent tokens, where the initial agent may be (or invoke) a web browser which can do redirects, but which uses some other agent for the actual access while sharing the same Consumer identity. And of course it's possible as you note to skip the web browser specific redirect with SP-specific extensions (we do this for OpenSocial gadgets), and OAuth is designed to allow these sorts of extensions. > ... > > The oauth parts of messages from the client to a server are optionally > integrity protected. However there is no response protection. At > least for the hmac-sha1 signature type adding response protection > would be trivial. It would be reasonably trivial for the RSA > signature type, although the consumer would then need to know the > public key of the service provider. > I'm not sure that it's true that this is trivial in all environments; I think that it would require at minimum access to the final, encoded output buffer, including headers, or some kind of window onto same, which I'm not sure that all environments trivially provide. I could be wrong about this but I'm continually surprised by the limitations imposed by web server libraries. John Panzer _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 07:13:36 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DA63A68C6; Tue, 21 Oct 2008 07:13:36 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6663A68C6 for ; Tue, 21 Oct 2008 07:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[AWL=1.910, 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 lIyYwQ7lvLSF for ; Tue, 21 Oct 2008 07:13:33 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 4BB493A683F for ; Tue, 21 Oct 2008 07:13:33 -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 m9LEElQJ015168 for ; Tue, 21 Oct 2008 10:14:47 -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 m9LEEkge015165 for ; Tue, 21 Oct 2008 10:14:46 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9LEEZJr021206 for ; Tue, 21 Oct 2008 10:14:35 -0400 (EDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 198EB11ED2CC for ; Tue, 21 Oct 2008 10:14:10 -0400 (EDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m9LEF0E1002890; Tue, 21 Oct 2008 09:15:04 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 09:14:05 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 16:14:02 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Oct 2008 16:14:00 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918002425722@DEEXC1U01.de.lucent.com> In-Reply-To: <641CB252AE2C36FA3BF7C4F0@Uranus.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-drage-sipping-service-identification-01 Thread-Index: AcfHEm2snU+cVS3vS1WPSMHkPx9sPlsc6toQ References: <641CB252AE2C36FA3BF7C4F0@Uranus.local> From: "DRAGE, Keith (Keith)" To: "Barry Leiba" , X-OriginalArrivalTime: 21 Oct 2008 14:14:02.0904 (UTC) FILETIME=[450FE180:01C93387] X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9LEEkge015165 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: jon.peterson@neustar.biz Subject: Re: [secdir] secdir review of draft-drage-sipping-service-identification-01 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have placed a response to the comments raised in this review (and other comments received in IETF LC) at: http://www.softarmor.com/sipping/process/wg-review/reviews/service-id-co mments.htm I have made some attempt to address the comments, which may well not provide the answers you were looking for. I would say that the starting point for this draft was RFC 3325, and therefore much of the handwaving obviously came from that document. I have marked one of your comments: "To resolve" as I am currently not sure how to address this. Note that draft-ietf-sipping-service-identification does address some of these issues and is referenced from the document. I will attempt to correct any further comments you care to raise. Regards Keith > -----Original Message----- > From: Barry Leiba [mailto:leiba@watson.ibm.com] > Sent: Sunday, July 15, 2007 8:00 PM > To: iesg@ietf.org; secdir@mit.edu; DRAGE, Keith (Keith) > Cc: jon.peterson@neustar.biz > Subject: secdir review of > draft-drage-sipping-service-identification-01 > > 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 was actually asked to review the -00 version, but that was > replaced by -01 in the meantime.) > > I have to say up front that I'm very unhappy with this > document. It doesn't say what its status is, but I see from > the tracker that it's informational, not standards-track. > Still, it seems to provide very little information, and waves > its hands about too many things. It also has enough problems > with grammar that I'm often not sure what it's trying to say. > The very first sentence of the introduction, for example: > > This document describes private extensions to the Session > Initiation > Protocol (SIP) that enable a network of trusted SIP > servers to assert > the service and for users entitled to that service. > > I can't parse that sentence, and I don't know what it means > to say. Similarly for the beginning of section 4.2: > > The P-Preferred-Service header field is used from a user agent to a > trusted proxy to carry the preferred service of the user > sending the > SIP message wishes to be used for the P-Asserted-Service > field value > that the trusted element will insert. > > It's hard to decide on the technical content of a document > when there are what seem to be key bits that aren't readable. > > What I *can* understand seems to be missing a lot. It seems > to me that this document is basically defining two new SIP > header fields, P-Asserted-Service and P-Preferred-Service. > The document is very vague -- necessarily so, it says -- > about the actual usage of these fields, and that's the second > thing that makes me unhappy with publishing this. The > vagueness results in my not understanding what it is that > these fields are used to assert or request, why and when a > SIP request would want/need to use these (and when it > wouldn't), and what, exactly, happens when they're used. I > can't imagine that an implementor who didn't already know > what was going on would get things right based on reading > this document. And my experience with even simple protocol > standards is that there are many implementors who get things > wrong even when the specs are clearly written -- and SIP is > not a simple standard. > > The third thing that bothers me is that the Security > Considerations section blows off all considerations, even > though there are many references in the document to > security-related issues. Trust domains are talked about > often, and there are MUST and MUST NOT requirements for > passing around information and credentials. None of that is > brought up as a security consideration. For example, here's > something, in section 5.1.3, that I think has to be discussed > in the security considerations section: > > If a UA is part of the Trust Domain from which it received > a request > containing a P-Asserted-Service header field, then it can use the > value freely but it MUST ensure that it does not forward the > information to any element that is not part of the Trust Domain. > > What happens if it does forward this information? How does > it know what elements are part of the trust domain? Can the > composition of the trust domain change over the life of a SIP > request/session? How can a trust domain rely on the actions > of a user agent? What if a malicious user tampers with the > user agent, which is, after all, under his control? How does > the trust domain defend itself against that? Why are > security-sensitive itens entrusted to a user agent in the first place? > > There may be reasonable answers to these sorts of questions, > but there's nothing at all about them in the security considerations. > > All in all, I think this document needs significant work > before it's ready to be published. > > > Barry > > -- > Barry Leiba, STSM, Internet Messaging Technology > (leiba@watson.ibm.com) > http://www.research.ibm.com/people/l/leiba > http://www.research.ibm.com/spam > > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 08:18:54 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E793A6B3C; Tue, 21 Oct 2008 08:18:54 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFCD3A6A39 for ; Tue, 21 Oct 2008 08:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 efpNYeS1t1pn for ; Tue, 21 Oct 2008 08:18:52 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8E2DA3A6B3C for ; Tue, 21 Oct 2008 08:18:52 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9LFK4lc030645 for ; Tue, 21 Oct 2008 11:20:06 -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 m9LFK0Ai030621 for ; Tue, 21 Oct 2008 11:20:00 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9LFJqZw010784 for ; Tue, 21 Oct 2008 11:19:52 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 54EC1134FFAA for ; Tue, 21 Oct 2008 11:19:30 -0400 (EDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m9LFJEIN006257; Tue, 21 Oct 2008 10:19:16 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:19:15 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:19:15 -0500 Message-ID: <48FDF264.1030006@ericsson.com> Date: Tue, 21 Oct 2008 11:16:52 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Brian E Carpenter References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> In-Reply-To: <48FB9A79.8040407@gmail.com> X-OriginalArrivalTime: 21 Oct 2008 15:19:15.0549 (UTC) FILETIME=[612E20D0:01C93390] X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Nathan Ward , Tim Polk , secdir@mit.edu, dthaler@microsoft.com, v6ops@ops.ietf.org, jim_hoagland@symantec.com Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Brian, Thanks for your comments. Please see responses inline. Brian E Carpenter wrote: > ... >>> Why tunnelling over UDP or TCP? Why not tunnelling in IP as in 6to4? >>> I don't imagine that UDP makes it any more difficult to inspect than >>> an IP protocol. >>> >>> I think this statement should be changed to "Tunnelling through a >>> security device (ie. firewall) is not recommended for.. " etc. >> Sounds good. We will make this change. > > Now you have me worried enough to say something I've been feeling > ever since I really read this draft carefully. > > To exaggerate, why not just rename it "tunneling considered > harmful" and chop it down to one paragraph? The draft is about security concerns with tunnels. It discusses concerns and associated recommendations if the concern is considered valid by an admin. It was not our goal to say "tunneling considered harmful" but rather to say "If you want to do foo, tunneling might prevent you from doing foo. So disable tunnels" or "If you don't want your users to do foo, tunneling might allow them to do foo. So disable tunnels". > > I think there's a real risk of this document being misunderstood > by typical site IT managers, and being used simply as an excuse > to block all kinds of tunnel-based v4/v6 coexistence. But tunnels > are a legitimate coexistence strategy. I'd much rather see > this document talking more about how to make the use of tunnels > safe as part of v4/v6 coexistence. There is some of that material > in the document, but the impression the draft leaves is now of > a succession of warnings to block tunnels. Although the draft started out as security concerns related to Teredo tunnels, it has been generalized to all kinds of tunnels and not limited to v4/v6 transition tunnels. The draft lists problems and possible solutions to those problems. If you think there is a problem with the tone of the document, I am sure we can work on fixing it, but I sincerely believe that all the stated concerns are real and not FUD. Thanks Suresh _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 08:45:51 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8053A6A39; Tue, 21 Oct 2008 08:45:51 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BA33A67C0; Tue, 21 Oct 2008 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmENTzD2JhgF; Tue, 21 Oct 2008 08:45: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 711793A6A7C; Tue, 21 Oct 2008 08:45:49 -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 m9LFl0PS014562; Tue, 21 Oct 2008 11:47:00 -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 m9LFkuBR028627; Tue, 21 Oct 2008 11:46:58 -0400 (EDT) Received: from enkidu.fw5540.net ([10.0.3.64]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2008102111465707796 ; Tue, 21 Oct 2008 11:46:57 -0400 Message-Id: From: Catherine Meadows To: secdir@ietf.org, iesg@ietf.org, rem@videolan.org, dthaler@microsoft.com, dwing@cisco.com Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 11:45:51 -0400 X-Mailer: Apple Mail (2.929.2) Subject: [secdir] SecDir Review of draft-ietf-behave-dccp-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 gives a set of behavioral requirements for network address translation for DCCP. In the secure considerations section, the authors discuss the requirements that have security considerations, and give recommendations. This mostly looks in good shape, but I have trouble understanding the discussion of Requirement 5 in this section. It reads, in its entirety: REQ-5 recommends that a NAT that passively monitors DCCP state keep idle sessions alive for at least 124 minutes or 4 minutes depending on the state of the connection. it may attempt to actively determine the liveliness of a DCCP connection or let the NAT administrator configure more conservative timeouts. It's unclear what the relationship is to security is here. The discussion needs to make that explicit. Some minor nits: "problems. and" in the discussion of REQ-4 should be "problems and" Second sentence in the discussion of REQ-5 should begin with a capital letter. 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 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 08:58:46 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F2F3A6A92; Tue, 21 Oct 2008 08:58:46 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6B23A67C0 for ; Tue, 21 Oct 2008 08:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 sOqD1VljiwuH for ; Tue, 21 Oct 2008 08:58:45 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1E1E23A6B41 for ; Tue, 21 Oct 2008 08:58:44 -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 m9LFxwuh008922 for ; Tue, 21 Oct 2008 11:59:59 -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 m9LFxtW6008908 for ; Tue, 21 Oct 2008 11:59:56 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9LFxnef027878 for ; Tue, 21 Oct 2008 11:59:49 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4BF11BD919A for ; Tue, 21 Oct 2008 11:59:28 -0400 (EDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m9LFxMAt025627; Tue, 21 Oct 2008 10:59:22 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:59:22 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:59:22 -0500 Message-ID: <48FDFBCB.1090508@ericsson.com> Date: Tue, 21 Oct 2008 11:56:59 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Christian Huitema References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-OriginalArrivalTime: 21 Oct 2008 15:59:22.0081 (UTC) FILETIME=[FB95C510:01C93395] X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Nathan Ward , Dave Thaler , Tim Polk , "secdir@mit.edu" , Brian E Carpenter , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Christian, Thanks for your comments. Please see my response inline Christian Huitema wrote: >> I think there's a real risk of this document being misunderstood >> by typical site IT managers, and being used simply as an excuse >> to block all kinds of tunnel-based v4/v6 coexistence. But tunnels >> are a legitimate coexistence strategy. I'd much rather see >> this document talking more about how to make the use of tunnels >> safe as part of v4/v6 coexistence. There is some of that material >> in the document, but the impression the draft leaves is now of >> a succession of warnings to block tunnels. > > Actually, it is a succession of warning to block standardized tunnels, > those that are well documented and have a clear signature. > By doing so, we are pushing application developers to just "roll > their own technologies", and indeed to use evasive techniques such as > encrypted packets, random port numbers or tunneling of HTTP. I am not > sure that network managers are going to like the result... While I agree with you about the possibility of an "arms race" I really do not see anything we can do about this. What would you recommend instead? I am really open to suggestions. Thanks Suresh _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 10:51:26 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C81D3A6ACE; Tue, 21 Oct 2008 10:51:26 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01DBA3A6ACE for ; Tue, 21 Oct 2008 10:51:25 -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 ifnI4cMhgbAI for ; Tue, 21 Oct 2008 10:51:24 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1D1DA3A6A95 for ; Tue, 21 Oct 2008 10:51:24 -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 m9LHqN1o005538 for ; Tue, 21 Oct 2008 13:52:23 -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 m9LHqJOU005513 for ; Tue, 21 Oct 2008 13:52:19 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9LHqC2u018923 for ; Tue, 21 Oct 2008 13:52:12 -0400 (EDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9308D135CF56 for ; Tue, 21 Oct 2008 13:51:51 -0400 (EDT) Received: from [72.60.67.226] ([72.60.67.226]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m9LHpWu1014552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 13:51:34 -0400 (EDT) Date: Tue, 21 Oct 2008 13:51:31 -0400 From: Jeffrey Hutzelman To: iesg@ietf.org, secdir@mit.edu, sip-chairs@tools.ietf.org, jmpolk@cisco.com Message-ID: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: [secdir] secdir review of draft-ietf-sip-rph-new-namespaces-03.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 and registers a number of new SIP resource-priority namespaces. It does not define any particular semantics or operational procedures for the new namespaces, beyond what is required by RFC4412, and so introduces no new security considerations. I'm a little confused about the need for this document. As I understand it, RFC4412 envisions there being only a very small, almost fixed set of namespaces, which is why defining new namespaces requires standards action. In my opinion, the present document does not satisfactorily explain why it is necessary to have a large number of namespaces intended for itinerant use. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 13:18:25 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C77B3A6907; Tue, 21 Oct 2008 13:18:25 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384553A6907 for ; Tue, 21 Oct 2008 13:18:24 -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 qJSqAyxMI8UR for ; Tue, 21 Oct 2008 13:18:23 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 024EB3A6903 for ; Tue, 21 Oct 2008 13:18:22 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m9LKJbT3014684 for ; Tue, 21 Oct 2008 16:19:37 -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 m9LKJZq1014663 for ; Tue, 21 Oct 2008 16:19:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9LKJSM7024899 for ; Tue, 21 Oct 2008 16:19:28 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by mit.edu (Spam Firewall) with SMTP id 2CD6EBD5620 for ; Tue, 21 Oct 2008 16:19:08 -0400 (EDT) Received: (qmail 19239 invoked by uid 0); 21 Oct 2008 20:19:01 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (209.183.196.229) by woodstock.binhost.com with SMTP; 21 Oct 2008 20:19:01 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Oct 2008 16:16:14 -0400 To: Nicolas Williams From: Russ Housley In-Reply-To: <20081021014455.GN8906@Sun.COM> References: <20081021014455.GN8906@Sun.COM> Mime-Version: 1.0 Message-Id: <20081021201908.2CD6EBD5620@mit.edu> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Nico: >So if I understand correctly then this document would have an >implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the >same TCP connection with different labels, *and* ensure that each packet >contains parts of no more than one (exactly one) NFSv4 RPC. I am aware of several multi-level secure implementations; none of them of make any attempt to do anything like this. Russ _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 13:36:59 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151C428C1A3; Tue, 21 Oct 2008 13:36:59 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09ED028C1A3 for ; Tue, 21 Oct 2008 13:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.437, 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 14uEki7Kf3XY for ; Tue, 21 Oct 2008 13:36:57 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1724728C194 for ; Tue, 21 Oct 2008 13:36:57 -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 m9LKcCr6018649 for ; Tue, 21 Oct 2008 16:38:12 -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 m9LKc8kn018641 for ; Tue, 21 Oct 2008 16:38:09 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9LKc1tG017255 for ; Tue, 21 Oct 2008 16:38:01 -0400 (EDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mit.edu (Spam Firewall) with ESMTP id 482E6BDE2C9 for ; Tue, 21 Oct 2008 16:37:40 -0400 (EDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9LKbdmQ027987 for ; Tue, 21 Oct 2008 20:37:39 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m9LKbbcn058106 for ; Tue, 21 Oct 2008 14:37:37 -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 m9LKLw2l020007; Tue, 21 Oct 2008 15:22:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9LKLfvI020006; Tue, 21 Oct 2008 15:21:41 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 21 Oct 2008 15:21:41 -0500 From: Nicolas Williams To: Russ Housley Message-ID: <20081021202140.GE8906@Sun.COM> References: <20081021014455.GN8906@Sun.COM> <20081021201908.2CD6EBD5620@mit.edu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081021201908.2CD6EBD5620@mit.edu> User-Agent: Mutt/1.5.7i X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Tue, Oct 21, 2008 at 04:16:14PM -0400, Russ Housley wrote: > Nico: > > >So if I understand correctly then this document would have an > >implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the > >same TCP connection with different labels, *and* ensure that each packet > >contains parts of no more than one (exactly one) NFSv4 RPC. > > I am aware of several multi-level secure implementations; none of > them of make any attempt to do anything like this. Bill Sommerfeld points out that I have read much too much into the paragraph that I quoted. I should only have read that a solution is desired, and that the solution could well be not to multiplex traffic for multiple users on a single session. Nico -- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 13:39:15 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A903A6804; Tue, 21 Oct 2008 13:39:15 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0653A67E2 for ; Tue, 21 Oct 2008 13:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-1.150, 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 HEibfgGF4BCE for ; Tue, 21 Oct 2008 13:39:13 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 8BF1D3A6804 for ; Tue, 21 Oct 2008 13:39:13 -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 m9LKe7Gr019136; Tue, 21 Oct 2008 16:40:07 -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 m9LKe1ME001652; Tue, 21 Oct 2008 16:40:07 -0400 (EDT) Received: from enkidu.fw5540.net ([10.0.3.64]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2008102116400708376 ; Tue, 21 Oct 2008 16:40:07 -0400 Message-Id: <2925A3D3-BAAD-4C6C-A950-BD89031AF9C4@nrl.navy.mil> From: Catherine Meadows To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200810211942.24209.rem@videolan.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 16:39:00 -0400 References: <200810211942.24209.rem@videolan.org> X-Mailer: Apple Mail (2.929.2) Cc: Magnus Westerlund , dwing@cisco.com, dthaler@microsoft.com, secdir@ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-behave-dccp-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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Yes, that is much clearer. Just one small thing: from the wording it = looks like it is the NAT that is letting the NAT administrator reconfigure it. I would instead have To protect against denial-of-service attack filling its state storage capacity, a NAT may attempt to actively determine the liveliness of a DCCP connection, or the NAT administrator could configure more = conservative timeouts. Cathy 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 On Oct 21, 2008, at 12:42 PM, R=E9mi Denis-Courmont wrote: > Hello, > > Le mardi 21 octobre 2008 18:45:51 Catherine Meadows, vous avez =E9crit : >> 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 gives a set of behavioral requirements for network address >> translation for DCCP. >> In the secure considerations section, the authors discuss the >> requirements that have security considerations, >> and give recommendations. This mostly looks in good shape, but I >> have trouble understanding the discussion of >> Requirement 5 in this section. It reads, in its entirety: >> >> REQ-5 recommends that a NAT that passively monitors DCCP state keep >> idle sessions alive for at least 124 minutes or 4 minutes = >> depending >> on the state of the connection. it may attempt to actively = >> determine >> the liveliness of a DCCP connection or let the NAT administrator >> configure more conservative timeouts. > > The text was supposed to be as follow, but the first proposition got = > cut out > during edition: > > If a NAT is undergoing a denial-of-service attack, > it may attempt to actively determine the liveliness of a DCCP > connection or let the NAT administrator configure more conservative > timeouts. > >> It's unclear what the relationship is to security is here. The >> discussion needs to make that explicit. > > The wording comes from BEHAVE-TCP. I can hardly imagine the NAT = > administrator > rush to his NAT to reconfigure it, so this might be better... ? > > To protect against denial-of-service attack filling its state storage > capacity, a NAT > may attempt to actively determine the liveliness of a DCCP > connection or let the NAT administrator configure more conservative > timeouts. > > Thanks for the review > > -- = > R=E9mi Denis-Courmont > http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummary > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 13:57:40 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A7C3A6B96; Tue, 21 Oct 2008 13:57:40 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45AE13A6B96 for ; Tue, 21 Oct 2008 13:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.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 o1vjGgNIDo+s for ; Tue, 21 Oct 2008 13:57:38 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 4AC5E3A6774 for ; Tue, 21 Oct 2008 13:57:38 -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 m9LKwlKP023689 for ; Tue, 21 Oct 2008 16:58:47 -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 m9LKvSpY023276 for ; Tue, 21 Oct 2008 16:57:28 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9LKvLfY021357 for ; Tue, 21 Oct 2008 16:57:22 -0400 (EDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mit.edu (Spam Firewall) with ESMTP id 82806BC62C5 for ; Tue, 21 Oct 2008 16:57:15 -0400 (EDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id VYqj1a00R0FhH24AAYxF0D; Tue, 21 Oct 2008 20:57:15 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id VYxC1a00E4F1VyU8UYxDpA; Tue, 21 Oct 2008 20:57:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=TYlj2CSRNSMA:10 a=UJkQ7-MJF88A:10 a=kuDhkFWb9PttVD0XenoA:9 a=3WPrn_a2DFmxOIeh9dc0WfMvIPcA:4 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Oct 2008 16:57:12 -0400 To: Nicolas Williams , Sam Hartman From: Michael StJohns In-Reply-To: <20081021014455.GN8906@Sun.COM> References: <20081021014455.GN8906@Sun.COM> Mime-Version: 1.0 Message-Id: <20081021205715.82806BC62C5@mit.edu> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org At 09:44 PM 10/20/2008, Nicolas Williams wrote: >So if I understand correctly then this document would have an >implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the >same TCP connection with different labels, *and* ensure that each packet >contains parts of no more than one (exactly one) NFSv4 RPC. Classified documents have this thing called paragraph marking. Each paragraph within a document is marked with the highest level of data within the paragraph. A page is marked with the highest level of data in any paragraph on that page. The overall document is marked with and protected at the highest level of data within the document. For your example, what would probably happen is that the NFS processes on both sides would create a connection at the highest level of data they expect to exchange. The NFS processes would be responsible for the labeling and segregation of data exchanged over that connection. E.g. the IP packets would ALL be labeled at the high level, even if some of them carried data at a level below. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 14:15:04 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A4D3A6B52; Tue, 21 Oct 2008 14:15:04 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F673A6B52 for ; Tue, 21 Oct 2008 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[AWL=2.048, 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 gFFECmfuGOmT for ; Tue, 21 Oct 2008 14:15:02 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 34DEF3A68FC for ; Tue, 21 Oct 2008 14:15:02 -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 m9LLG7xS027900 for ; Tue, 21 Oct 2008 17:16:07 -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 m9LLG1MZ027873 for ; Tue, 21 Oct 2008 17:16:01 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9LLFsCs018687 for ; Tue, 21 Oct 2008 17:15:54 -0400 (EDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mit.edu (Spam Firewall) with ESMTP id 8ADE7BE3C6D for ; Tue, 21 Oct 2008 17:15:53 -0400 (EDT) Received: by wf-out-1314.google.com with SMTP id 27so3008138wfd.21 for ; Tue, 21 Oct 2008 14:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UkyAC1fAePv/hkr8NcvHqxFSVyqYn8fjglelRQmIk8o=; b=NUthboK+jyWdISF7TTjgfVZNw5AE90oWbIYR4srdPlastzfzxeKy+8azgyQJK2pnZ0 JClY5M2GaPyFBLoVosrE/KF+nRxaBF/3RWx02JHvdtxr+d6O8ms5D3aIN71L8MQK4yUn XtowYSaQePGgyYRw74kcd+MuOR58tR8XOjYZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=WuhDTAxzu1a0xFPrFZz28xdd4ucHzighsjuz/lvTi4q0p/LL+zh9rKk5oyalVAEjV9 G9KnarOC7IiYmasZA2tjJSsz2CM+JM47qVTtBCtqAf4BzKqWjccYh+ESFxqscd/aGACp 2B7/79nxjqKMszrk25Ddg0c5V/jYz+BBTbeiA= Received: by 10.142.188.4 with SMTP id l4mr3978910wff.151.1224623753307; Tue, 21 Oct 2008 14:15:53 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 9sm19251550wfc.19.2008.10.21.14.15.49 (version=SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 14:15:52 -0700 (PDT) Message-ID: <48FE4681.4070006@gmail.com> Date: Wed, 22 Oct 2008 10:15:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> In-Reply-To: <48FDFBCB.1090508@ericsson.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Christian Huitema , Nathan Ward , Dave Thaler , Tim Polk , "secdir@mit.edu" , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Suresh, You wrote to Christian: > While I agree with you about the possibility of an "arms race" I really > do not see anything we can do about this. What would you recommend > instead? I am really open to suggestions. My feeling is that we need to tell IT managers something like "If your users have a need for IPv6 tunnels, here is how to make them as safe as possible: and after that, explain the threats, and state that tunnels should be disabled if you are not protected against the threats. There are also other positive suggestions, like operating an on-site 6to4 relay and/or Teredo server, so that those mechanisms don't cross the border router. I agree with you that there are real threats (or will be, once there is enough deployment to make IPv6 tunnels an interesting target). It's quite appropriate to document them. Brian _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 14:20:56 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2323A6B54; Tue, 21 Oct 2008 14:20:56 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D533A6B54 for ; Tue, 21 Oct 2008 14:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.582 X-Spam-Level: X-Spam-Status: No, score=-107.582 tagged_above=-999 required=5 tests=[AWL=-0.983, 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 QSQ3B7PKojDg for ; Tue, 21 Oct 2008 14:20:54 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8DF663A68CC for ; Tue, 21 Oct 2008 14:20:54 -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 m9LLLviY029568 for ; Tue, 21 Oct 2008 17:21:57 -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 m9LLLuYA029562 for ; Tue, 21 Oct 2008 17:21:56 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9LLLnZG026414 for ; Tue, 21 Oct 2008 17:21:49 -0400 (EDT) X-ASG-Whitelist: Barracuda Reputation Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A992EBE1B8F for ; Tue, 21 Oct 2008 17:21:48 -0400 (EDT) Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 21 Oct 2008 14:21:47 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk1-exhub-c104.redmond.corp.microsoft.com (157.54.46.188) with Microsoft SMTP Server id 8.1.291.1; Tue, 21 Oct 2008 14:21:47 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Tue, 21 Oct 2008 14:22:15 -0700 From: Christian Huitema To: Brian E Carpenter , Suresh Krishnan Date: Tue, 21 Oct 2008 14:20:53 -0700 Thread-Topic: SECDIR review: draft-ietf-v6ops-tunnel-concerns Thread-Index: AckzwjjrdHuNFu8ORRuRlXgsrzgyngAAGMeQ Message-ID: <8EFB68EAE061884A8517F2A755E8B60A134A7F7EE5@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> In-Reply-To: <48FE4681.4070006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from base64 to 8bit by pch.mit.edu id m9LLLuYA029562 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Nathan Ward , Dave Thaler , Tim Polk , "secdir@mit.edu" , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org > My feeling is that we need to tell IT managers something like > "If your users have a need for IPv6 tunnels, here is how to > make them as safe as possible: > > I agree. Change the message to a positive tone. Start with the assumption that tunnels are going to happen one way or another, then work from there to specify the safe deployment guidelines, as appropriate for the various deployment cases. -- Christian Huitema _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 14:27:39 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455683A68CC; Tue, 21 Oct 2008 14:27:39 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1223A685D for ; Tue, 21 Oct 2008 14:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 p-6SK0md--LJ for ; Tue, 21 Oct 2008 14:27:38 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id DDD803A67EF for ; Tue, 21 Oct 2008 14:27:37 -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 m9LLSTZX030940 for ; Tue, 21 Oct 2008 17:28:29 -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 m9LLSL4p030916 for ; Tue, 21 Oct 2008 17:28:21 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9LLSCW0004752 for ; Tue, 21 Oct 2008 17:28:12 -0400 (EDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mit.edu (Spam Firewall) with ESMTP id E01CF1356F5A; Tue, 21 Oct 2008 17:27:50 -0400 (EDT) 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 m9LLRo3b002194; Tue, 21 Oct 2008 21:27:50 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 m9LLRjbx031141; Tue, 21 Oct 2008 15:27:45 -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 m9LL4k8p020040; Tue, 21 Oct 2008 16:04:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9LL4j0k020039; Tue, 21 Oct 2008 16:04:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 21 Oct 2008 16:04:45 -0500 From: Nicolas Williams To: Michael StJohns Message-ID: <20081021210445.GH8906@Sun.COM> References: <20081021014455.GN8906@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Tue, Oct 21, 2008 at 04:57:12PM -0400, Michael StJohns wrote: > Classified documents have this thing called paragraph marking. Each > paragraph within a document is marked with the highest level of data > within the paragraph. A page is marked with the highest level of data > in any paragraph on that page. The overall document is marked with > and protected at the highest level of data within the document. > > For your example, what would probably happen is that the NFS processes > on both sides would create a connection at the highest level of data > they expect to exchange. The NFS processes would be responsible for > the labeling and segregation of data exchanged over that connection. > E.g. the IP packets would ALL be labeled at the high level, even if > some of them carried data at a level below. Thanks for the clarification. Nico -- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Oct 21 14:46:52 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A923A6B8A; Tue, 21 Oct 2008 14:46:52 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C54F3A6B8A for ; Tue, 21 Oct 2008 14:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 hAy4ml+vFyF9 for ; Tue, 21 Oct 2008 14:46:50 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 397643A6A1F for ; Tue, 21 Oct 2008 14:46:50 -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 m9LLlSrq002348 for ; Tue, 21 Oct 2008 17:47:28 -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 m9LLlJ8Z002310 for ; Tue, 21 Oct 2008 17:47:19 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9LLl9xg003493 for ; Tue, 21 Oct 2008 17:47:10 -0400 (EDT) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 3434BBE1FD2; Tue, 21 Oct 2008 17:47:03 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D41FEAF670; Tue, 21 Oct 2008 21:47:02 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 761F1AF644; Tue, 21 Oct 2008 21:47:02 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id D8C1883860E; Tue, 21 Oct 2008 17:47:00 -0400 (EDT) Date: Tue, 21 Oct 2008 17:47:00 -0400 From: "Steven M. Bellovin" To: Michael StJohns Message-ID: <20081021174700.10888ab2@cs.columbia.edu> In-Reply-To: <20081021205715.82806BC62C5@mit.edu> References: <20081021014455.GN8906@Sun.COM> <20081021205715.82806BC62C5@mit.edu> Organization: Columbia University X-Mailer: Claws Mail 3.6.1 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Tue, 21 Oct 2008 16:57:12 -0400 Michael StJohns wrote: ... > Classified documents have this thing called paragraph marking. Each > paragraph within a document is marked with the highest level of data > within the paragraph. A page is marked with the highest level of > data in any paragraph on that page. The overall document is marked > with and protected at the highest level of data within the document. Those who want the gory details should see http://www.fas.org/sgp/isoo/marking.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 22 00:12:57 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FAA63A6835; Wed, 22 Oct 2008 00:12:57 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DA9628C0FC for ; Tue, 21 Oct 2008 09:41:16 -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 fH4YLG9k63Fb for ; Tue, 21 Oct 2008 09:41:15 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id B0A4C3A6A70 for ; Tue, 21 Oct 2008 09:41:14 -0700 (PDT) Received: from basile.remlab.net (unknown [IPv6:2002:591b:3aef:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id D3D347DC; Tue, 21 Oct 2008 18:42:26 +0200 (CEST) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: VideoLAN project - www.videolan.org To: Catherine Meadows Date: Tue, 21 Oct 2008 19:42:23 +0300 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810211942.24209.rem@videolan.org> X-Mailman-Approved-At: Wed, 22 Oct 2008 00:12:56 -0700 Cc: Magnus Westerlund , dwing@cisco.com, dthaler@microsoft.com, secdir@ietf.org Subject: Re: [secdir] SecDir Review of draft-ietf-behave-dccp-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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hello, Le mardi 21 octobre 2008 18:45:51 Catherine Meadows, vous avez =E9crit=A0: > 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 gives a set of behavioral requirements for network address > translation for DCCP. > In the secure considerations section, the authors discuss the > requirements that have security considerations, > and give recommendations. This mostly looks in good shape, but I > have trouble understanding the discussion of > Requirement 5 in this section. It reads, in its entirety: > > REQ-5 recommends that a NAT that passively monitors DCCP state keep > idle sessions alive for at least 124 minutes or 4 minutes depending > on the state of the connection. it may attempt to actively determine > the liveliness of a DCCP connection or let the NAT administrator > configure more conservative timeouts. The text was supposed to be as follow, but the first proposition got cut ou= t = during edition: If a NAT is undergoing a denial-of-service attack, it may attempt to actively determine the liveliness of a DCCP connection or let the NAT administrator configure more conservative timeouts. > It's unclear what the relationship is to security is here. The > discussion needs to make that explicit. The wording comes from BEHAVE-TCP. I can hardly imagine the NAT administrat= or = rush to his NAT to reconfigure it, so this might be better... ? To protect against denial-of-service attack filling its state storage capacity, a NAT may attempt to actively determine the liveliness of a DCCP connection or let the NAT administrator configure more conservative timeouts. Thanks for the review -- = R=E9mi Denis-Courmont http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummary _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 22 00:12:57 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B006E3A69BA; Wed, 22 Oct 2008 00:12:57 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD3E3A6B3C for ; Tue, 21 Oct 2008 09:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 8EPiUXIMjO9R for ; Tue, 21 Oct 2008 09:37:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 718B63A6A70 for ; Tue, 21 Oct 2008 09:37:19 -0700 (PDT) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id m9LGcXKE006028 for ; Tue, 21 Oct 2008 09:38:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1224607114; bh=voK4lXEcJdKt1x9NH2b2IUQ8/CU=; h=DomainKey-Signature:Message-ID:Date:From:To:Subject:Cc: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:References; b=by1hJGnkIzdFy7Jl87QPsZmBsjlAzkvP jpZlVuKPwKDG4ivUm8OfGwOHQCQFB+qo1HlINrfZqoOuJQw+6yVxeA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=LrkN+FLr2yPK1mrjPEdgt+uJt8lhSzejv3IKwWyzcKnsh/65b6pdhU+adej7G56NL qyehxJwYOJWODpxZTDPOQ== Received: from yx-out-2324.google.com (yxb8.prod.google.com [10.190.1.72]) by spaceape7.eur.corp.google.com with ESMTP id m9LGcGhV026639 for ; Tue, 21 Oct 2008 09:38:31 -0700 Received: by yx-out-2324.google.com with SMTP id 8so425746yxb.69 for ; Tue, 21 Oct 2008 09:38:31 -0700 (PDT) Received: by 10.90.96.1 with SMTP id t1mr7840551agb.116.1224607111167; Tue, 21 Oct 2008 09:38:31 -0700 (PDT) Received: by 10.90.78.3 with HTTP; Tue, 21 Oct 2008 09:38:31 -0700 (PDT) Message-ID: Date: Tue, 21 Oct 2008 09:38:31 -0700 From: "Brian Eaton" To: oauth@googlegroups.com In-Reply-To: <48FD351C.3010300@acm.org> MIME-Version: 1.0 Content-Disposition: inline References: <48FD351C.3010300@acm.org> X-Mailman-Approved-At: Wed, 22 Oct 2008 00:12:56 -0700 Cc: draft-hammer-oauth@tools.ietf.org, lisa@osafoundation.org, secdir@ietf.org Subject: Re: [secdir] [oauth] Re: Secdir Review of draft-hammer-oauth-00.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org > Sam Hartman wrote: >> The oauth parts of messages from the client to a server are optionally >> integrity protected. However there is no response protection. At >> least for the hmac-sha1 signature type adding response protection >> would be trivial. It would be reasonably trivial for the RSA >> signature type, although the consumer would then need to know the >> public key of the service provider. HTTPS provides protection for responses. Adding a second level of message integrity creates new key distribution problems and doesn't significantly improve security. (That's doubly true when you consider that secrecy of the response from the OAuth server is more important than integrity.) _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 22 00:12:57 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C0C3A69EE; Wed, 22 Oct 2008 00:12:57 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3868B3A67F2 for ; Tue, 21 Oct 2008 22:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.548, 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 oqbONRxMVKxJ for ; Tue, 21 Oct 2008 22:58:58 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 37D863A6768 for ; Tue, 21 Oct 2008 22:58:58 -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 m9M60DsV028884 for ; Wed, 22 Oct 2008 02:00:13 -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 m9M609Re028865 for ; Wed, 22 Oct 2008 02:00:09 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9M601l9007308 for ; Wed, 22 Oct 2008 02:00:02 -0400 (EDT) Received: from unobtainium.braintrust.co.nz (unobtainium.braintrust.co.nz [60.234.76.2]) by mit.edu (Spam Firewall) with ESMTP id 327FA135D60A for ; Wed, 22 Oct 2008 01:59:40 -0400 (EDT) Received: from [192.168.0.51] (ip-118-90-107-173.xdsl.xnet.co.nz [118.90.107.173]) by unobtainium.braintrust.co.nz (Postfix) with ESMTP id A3E5527940; Wed, 22 Oct 2008 18:59:37 +1300 (NZDT) Message-Id: <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> From: Nathan Ward To: Brian E Carpenter In-Reply-To: <48FE4681.4070006@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 18:59:36 +1300 References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Wed, 22 Oct 2008 00:12:56 -0700 Cc: Christian Huitema , Dave Thaler , Tim Polk , "secdir@mit.edu" , Suresh Krishnan , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On 22/10/2008, at 10:15 AM, Brian E Carpenter wrote: > Suresh, > > You wrote to Christian: > >> While I agree with you about the possibility of an "arms race" I >> really >> do not see anything we can do about this. What would you recommend >> instead? I am really open to suggestions. > > My feeling is that we need to tell IT managers something like > "If your users have a need for IPv6 tunnels, here is how to > make them as safe as possible: > > > > and after that, explain the threats, and state that tunnels > should be disabled if you are not protected against the threats. > > There are also other positive suggestions, like operating > an on-site 6to4 relay and/or Teredo server, so that those > mechanisms don't cross the border router. Operating a Teredo server on site does not help unfortunately. It helps an administrator filter outbound packets when sent to an IPv6 address outside 2001::/32. It does not help an administrator filter inbound packets, or packets to/from other Teredo hosts. > I agree with you that there are real threats (or will be, once > there is enough deployment to make IPv6 tunnels an interesting > target). It's quite appropriate to document them. I need to preface these remarks by say that I haven't read the document apart from a quick skim read, so sorry if I'm saying something that's already in there, or is not relevant. I think it's important to distinguish between tunnels that end users' systems create automatically (ala 6to4, Teredo in Vista), and tunnels that end users create to work around firewalls. The former is easy to document solutions for, in fact, it seems to me that any tunnelling protocol RFC should include details as to how a network administrator can prevent these protocols passing through their network. For Teredo this means blocking port 3544/3545. For 6to4 this means blocking protocol 41 (preferably returning ICMPv6 messages encapsulated in 6to4 so the the application is told about it..). This is more about blocking things that do not work or perform poorly in a certain environment, rather than trying to secure a network. The latter is not so easy, and I think this document should simply point out that the only way to really do this is to completely control the end users' machines, and not allow any third party software or configuration changes. Anything else is instilling a false sense of security in the minds of network administrators who perhaps are not as fluent in these things as we are. -- Nathan Ward _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 22 07:49:13 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA17528C137; Wed, 22 Oct 2008 07:49:13 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01193A6B97 for ; Wed, 22 Oct 2008 07:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.276, 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 BqjRGYqIoss8 for ; Wed, 22 Oct 2008 07:20:48 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 539E83A6A08 for ; Wed, 22 Oct 2008 07:20:48 -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 m9MEM4vD027454 for ; Wed, 22 Oct 2008 10:22:04 -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 m9MELve5027431 for ; Wed, 22 Oct 2008 10:21:57 -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 m9MELoP1024779 for ; Wed, 22 Oct 2008 10:21:51 -0400 (EDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id F206C1166291; Wed, 22 Oct 2008 10:21:29 -0400 (EDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9MELMcX027306; Wed, 22 Oct 2008 14:21:23 GMT Received: from localhost.East.Sun.COM (dhcp-ubur02-174-108.East.Sun.COM [129.148.174.108]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m9MELMbN043195; Wed, 22 Oct 2008 10:21:22 -0400 (EDT) Received: from localhost.East.Sun.COM (localhost [127.0.0.1]) by localhost.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m9MELLl3010111; Wed, 22 Oct 2008 10:21:21 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9MELGqW010110; Wed, 22 Oct 2008 10:21:16 -0400 (EDT) X-Authentication-Warning: localhost.East.Sun.COM: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Nicolas Williams In-Reply-To: <20081021014455.GN8906@Sun.COM> References: <20081021014455.GN8906@Sun.COM> Date: Wed, 22 Oct 2008 10:21:14 -0400 Message-Id: <1224685274.2323.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.23.92 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list X-Mailman-Approved-At: Wed, 22 Oct 2008 07:49:13 -0700 Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Mon, 2008-10-20 at 20:44 -0500, Nicolas Williams wrote: > But then: > > | In order to > | maintain data Sensitivity Labeling for such applications, in > | order to be able to implement routing and Mandatory Access > | Control decisions in routers and guards on a per-IP-packet basis, > | and for other reasons, there is a need to have a mechanism for > | explicitly labeling the sensitivity information for each IPv6 > | packet. > > > So if I understand correctly then this document would have an > implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the > same TCP connection with different labels, *and* ensure that each packet > contains parts of no more than one (exactly one) NFSv4 RPC. You do not understand correctly. See section 6.2.1 of that document, which reads in part: NOTE WELL: A connection-oriented transport-layer protocol session (e.g. TCP session, SCTP session) MUST have the same DOI and same Sensitivity Label for the life of that connection. The DOI is selected at connection initiation and MUST NOT change during the session. - Bill _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 22 08:11:14 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9F628C0FC; Wed, 22 Oct 2008 08:11:14 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E1A3A68AD; Wed, 22 Oct 2008 08:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 J4gcpFoc5D6z; Wed, 22 Oct 2008 08:11:11 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 5265F3A6778; Wed, 22 Oct 2008 08:11: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 m9MFCO8Y001382; Wed, 22 Oct 2008 10:12:25 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m9MFCOS5005851; Wed, 22 Oct 2008 10:12:24 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 11:12:23 -0400 Date: Wed, 22 Oct 2008 11:12:25 -0400 (Eastern Daylight Time) From: Sandra Murphy To: gih@apnic.net, ggm@apnic.net, iesg@ietf.org, secdir@ietf.org, idr-chairs@tools.ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 22 Oct 2008 15:12:23.0841 (UTC) FILETIME=[96323910:01C93458] Subject: [secdir] secdir review of draft-ietf-idr-as-representation-01.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 suggests a standard representation of AS numbers that will accomodate the old 2-byte AS numbers and the new 4-byte AS numbers. It mentions three different representations and proposes one of those as the standard. A standard representation needs to be chosen to eliminate ambiguity among representations in configurations, documentation, etc. The Security Considerations section says This document does not refer to matters associated with security of routing systems. I concur. --Sandy _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 22 13:19:12 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E2D28C142; Wed, 22 Oct 2008 13:19:12 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B2D28C142 for ; Wed, 22 Oct 2008 13:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[AWL=2.031, 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 x0Hh2TC-ZQLA for ; Wed, 22 Oct 2008 13:19:10 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 86FF128C12D for ; Wed, 22 Oct 2008 13:19:10 -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 m9MKKRYt031472 for ; Wed, 22 Oct 2008 16:20:27 -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 m9MKKJ0V031421 for ; Wed, 22 Oct 2008 16:20:19 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9MKK8de017567 for ; Wed, 22 Oct 2008 16:20:09 -0400 (EDT) Received: from mail-gx0-f20.google.com (mail-gx0-f20.google.com [209.85.217.20]) by mit.edu (Spam Firewall) with ESMTP id BD30D10BB6CF for ; Wed, 22 Oct 2008 16:20:07 -0400 (EDT) Received: by mail-gx0-f20.google.com with SMTP id 13so9776528gxk.6 for ; Wed, 22 Oct 2008 13:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/uoRPRq8x4yh9euQOshuI6QEd3Qa7Y75PwiiOFRtV64=; b=e5NbrS194sOV2viBQEdkvLJO1UZns9YUmJPVukrvd7QGLXKBQ//debitZ38c27GaeG uLrIBiVZVdQsDPexkw/1gauwheAoTr+PUco8S8nci0rlsLE1MJcrv6h6lHDi9IsVFFfu 7an5VTPh2UF9Vf486C3ouqgDDtLhfFqocGGEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BMuXRtHuy81rVFrfaFFylXWrRVWa/qp7mNZKrUCAnxazUFSygH/wOn0qWzk1AIqCOF 4/lwSYCUdIOFM2oMyYoJmqBsym9OCenJgXEehzdmsbSnRkv1VlXweM7CsBQJLgaDizCO 6sDc/LHP82CWjRIvHgZZ9AJpqa+GGIrVAxbHY= Received: by 10.143.35.4 with SMTP id n4mr4561992wfj.64.1224706807011; Wed, 22 Oct 2008 13:20:07 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 28sm22227652wfg.15.2008.10.22.13.20.03 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 13:20:06 -0700 (PDT) Message-ID: <48FF8AEC.9060708@gmail.com> Date: Thu, 23 Oct 2008 09:19:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nathan Ward References: <8B128AB2-BBD9-49B9-A837-F00DD80BF5D3@Isode.com> <48F2C29B.8090900@ericsson.com> <48F8EE0D.4060307@ericsson.com> <48FB9A79.8040407@gmail.com> <8EFB68EAE061884A8517F2A755E8B60A134A70E895@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48FDFBCB.1090508@ericsson.com> <48FE4681.4070006@gmail.com> <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> In-Reply-To: <5333EA69-337F-4373-A247-1852B61D96C0@daork.net> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: Christian Huitema , Dave Thaler , Tim Polk , "secdir@mit.edu" , Suresh Krishnan , "v6ops@ops.ietf.org" , "Jim_Hoagland@symantec.com" Subject: Re: [secdir] SECDIR review: draft-ietf-v6ops-tunnel-concerns X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Nathan, On 2008-10-22 18:59, Nathan Ward wrote: > On 22/10/2008, at 10:15 AM, Brian E Carpenter wrote: > >> Suresh, >> >> You wrote to Christian: >> >>> While I agree with you about the possibility of an "arms race" I really >>> do not see anything we can do about this. What would you recommend >>> instead? I am really open to suggestions. >> >> My feeling is that we need to tell IT managers something like >> "If your users have a need for IPv6 tunnels, here is how to >> make them as safe as possible: >> >> >> >> and after that, explain the threats, and state that tunnels >> should be disabled if you are not protected against the threats. >> >> There are also other positive suggestions, like operating >> an on-site 6to4 relay and/or Teredo server, so that those >> mechanisms don't cross the border router. > > Operating a Teredo server on site does not help unfortunately. > > It helps an administrator filter outbound packets when sent to an IPv6 > address outside 2001::/32. It does not help an administrator filter > inbound packets, or packets to/from other Teredo hosts. As far as I can see, there's a general problem in attempting to detect and block Teredo packets (I mean UDP/IPv4 packets in Teredo format). But it seems to me that by running an internal Teredo server, a site is much better placed to track and trace Teredo users. This is important as Teredo users really need to be running an IPv6-savvy host firewall. > >> I agree with you that there are real threats (or will be, once >> there is enough deployment to make IPv6 tunnels an interesting >> target). It's quite appropriate to document them. > > > I need to preface these remarks by say that I haven't read the document > apart from a quick skim read, so sorry if I'm saying something that's > already in there, or is not relevant. > > I think it's important to distinguish between tunnels that end users' > systems create automatically (ala 6to4, Teredo in Vista), and tunnels > that end users create to work around firewalls. > > The former is easy to document solutions for, in fact, it seems to me > that any tunnelling protocol RFC should include details as to how a > network administrator can prevent these protocols passing through their > network. For Teredo this means blocking port 3544/3545. For 6to4 this > means blocking protocol 41 (preferably returning ICMPv6 messages > encapsulated in 6to4 so the the application is told about it..). This is > more about blocking things that do not work or perform poorly in a > certain environment, rather than trying to secure a network. > > The latter is not so easy, and I think this document should simply point > out that the only way to really do this is to completely control the end > users' machines, and not allow any third party software or configuration > changes. Anything else is instilling a false sense of security in the > minds of network administrators who perhaps are not as fluent in these > things as we are. Yes, but there are plenty of environments where that's impossible, and default deny is unacceptable because it blocks legitimate usage. I think the document needs to steer between the extremes, and suggest scenarios that are reasonably safe. Brian _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 23 13:52:06 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CD53A6AD1; Thu, 23 Oct 2008 13:52:06 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D593A6AD1 for ; Thu, 23 Oct 2008 13:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.477, 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 5Z75KRY-iHss for ; Thu, 23 Oct 2008 13:52:04 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A0ED33A69F4 for ; Thu, 23 Oct 2008 13:52:04 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id m9NKrMud030261 for ; Thu, 23 Oct 2008 16:53:22 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id m9NKrM89030258 for ; Thu, 23 Oct 2008 16:53:22 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 23 Oct 2008 16:53:22 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Thu, 23 Oct 2008 16:53:22 -0400 (EDT) Subject: [secdir] Assignments for October 30th 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I'll be on holiday for the next two weeks; if there are any secdir secretary issues that need timely attention, please take them up with the ADs. Kurt Zeilenga is next in the rotation. -- Sam All of the below are last call or special request reviews -- there aren't any docs on the November 6th telechat agenda yet. Lakshminath Dondeti draft-ietf-enum-combined-08 Lakshminath Dondeti draft-ietf-avt-rfc4749-dtx-update-02 Phillip Hallam-Baker draft-ietf-psamp-info-11 Steve Hanna draft-rescorla-tls-suiteb-09 Sam Hartman draft-hammer-oauth-00 Love Hornquist-Astrand draft-ietf-sip-sips-08 Tero Kivinen draft-ietf-sip-media-security-requirements-07 Julien Laganier draft-ietf-softwire-mesh-framework-05 Julien Laganier draft-ietf-softwire-encaps-ipsec-01 Julien Laganier draft-ietf-sipping-cc-transfer-11 Marcus Leech draft-ietf-dnsext-forgery-resilience-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-16 Alexey Melnikov draft-ietf-pce-pcep-xro-06 Alexey Melnikov draft-ietf-behave-stun-test-vectors-03 Sandy Murphy draft-ietf-mpls-mpls-and-gmpls-security-framework-03 Vidya Narayanan draft-ietf-lemonade-imap-notify-07 Magnus Nystrom draft-ietf-vrrp-unified-spec-02 Eric Rescorla draft-ietf-sip-dtls-srtp-framework-04 Joe Salowey draft-ietf-emu-eap-gpsk-15 Stefan Santesson draft-ietf-lemonade-architecture-03 Juergen Schoenwaelder draft-ietf-dhc-dhcpv6-bulk-leasequery-04 Yaron Sheffer draft-ietf-mip4-dsmipv4-07 Susan Thomson draft-ietf-nfsv4-minorversion1-dot-x-09 Hannes Tschofenig draft-ietf-nfsv4-pnfs-block-09 Sean Turner draft-ietf-nfsv4-pnfs-obj-09 Carl Wallace R draft-hartman-webauth-phishing-09 Carl Wallace draft-ietf-isis-hmac-sha-05 Sam Weiler draft-chown-v6ops-rogue-ra-01 Sam Weiler draft-housley-iesg-rfc3932bis-04 Brian Weis draft-ietf-isis-wg-extlsp-03 Nico Williams draft-ietf-v6ops-ra-guard-01 Nico Williams draft-ietf-nfsv4-minorversion1-26 Tom Yu draft-ietf-idr-as-documentation-reservation-00 Kurt Zeilenga R draft-daboo-imap-annotatemore-15 Larry Zhu draft-thaler-v6ops-teredo-extensions-01 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 24 08:23:12 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8753A6BB2; Fri, 24 Oct 2008 08:23:12 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC523A6BAE for ; Fri, 24 Oct 2008 08:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.878 X-Spam-Level: X-Spam-Status: No, score=-3.878 tagged_above=-999 required=5 tests=[AWL=2.721, 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 4bxTih2cboFk for ; Fri, 24 Oct 2008 08:23:10 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 81F7B3A6BAC for ; Fri, 24 Oct 2008 08:23:10 -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 m9OFOVHC004395 for ; Fri, 24 Oct 2008 11:24:31 -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 m9OFOMJu004350 for ; Fri, 24 Oct 2008 11:24:22 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9OFOFQB015660 for ; Fri, 24 Oct 2008 11:24:16 -0400 (EDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id E7DB410BA643 for ; Fri, 24 Oct 2008 11:23:54 -0400 (EDT) Received: (qmail 7091 invoked from network); 24 Oct 2008 15:10:19 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 24 Oct 2008 15:10:19 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 24 Oct 2008 15:10:19 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 24 Oct 2008 11:23:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-hartman-webauth-phishing-09.txt Thread-Index: Ack17IYf+e9KSQgJRbS96wW0EVTM6g== From: "Carl Wallace" To: , , , X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m9OFOMJu004350 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: [secdir] secdir review of draft-hartman-webauth-phishing-09.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 abstract of this draft indicates it "proposes requirements for protocols between web browsers and relying parties at websites". Generally, the audience for the requirements seems to be broader than the abstract states and at times it was difficult to figure out who the intended audience is. It may be worthwhile to separate the requirements into UI requirements and protocol requirements. In paragraph 5 of section 1, the reference to "social engineering attacks against TLS server authentication" is unprepared and is not elaborated on. This is also stated in the Security Considerations section. An example or two would help. Are there any additional requirements that would help reduce the effectiveness of these attacks? In the first paragraph of section 3, there's a missing assumption that user's trust anchor stores are sufficiently poorly maintained (or CA issuance practices sufficiently broken) to enable the TLS certificate presented by the attacker to be validated. Section 4 should assert a requirement somewhere to properly maintain a trust store and validate certificates where used. In the third paragraph of section 4.4, the statement "a shared secret will provide a better confidence" isn't necessarily true. "will" should be "may" or "will often". Section 4.7 should address how a user can gain confidence in the server when setting up a new account. It's also not clear what the aim is in this section. Is the enrollment referenced here with a web site where an identity provider is used (and has a password for the user) or something different? In section 5, the statement "validation of the certificates used in TLS...can be useful" is an understatement. This should be required. Not sure if this draft is the right place to comment, but, if requirements are for UI designers, it may be worth including a note about credential selection dialogs displayed to clients engaged in mutual authentication with public key credentials. It's fairly common for the selection dialog to be pruned such that no credentials are displayed due to certification path complexities between the trust list of the server and the user's cert. It's also common for too many credentials to be displayed (including those that will be invalid in the given context). In section 1 and in Security Considerations, users gain assurance that a web page was "generated by a party that either knows their password or who is authenticated by an identity provider who knows their password". Why is this important? Shouldn't the assurance be that the page was generated by the entity authenticated as described in section 4.4? How does this reconcile with the requirement to not share a password during enrollment? The draft identifies password reuse as a problem but does not mention usage of tools to facilitate management of different passwords (aside from avoidance of plaintext password protocols). This seems worth discussing since the Security Considerations highlights a need to maintain passwords for legacy systems plus passwords for systems that meet these requirements or maybe it's just out of scope. Nits - In section 1.2, change "smoothe" to "amooth". - In the last sentence of the second paragraph in Security Considerations, change "there exposure" to "their exposure". - Change "OTher" to "Other" in title of Section 4.1 - In section 4.1, change "do not have smart cards" to "do not have smart card readers". - The abstract asserts a MUST that is not repeated in the body of the draft. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sun Oct 26 08:27:28 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9DB3A6942; Sun, 26 Oct 2008 08:27:28 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D713A6942 for ; Sun, 26 Oct 2008 08:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.522 X-Spam-Level: X-Spam-Status: No, score=-4.522 tagged_above=-999 required=5 tests=[AWL=2.077, 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 pZZVe--j4-Lx for ; Sun, 26 Oct 2008 08:27:26 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5734A3A6841 for ; Sun, 26 Oct 2008 08:27: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 m9QFSoLU006166 for ; Sun, 26 Oct 2008 11:28:53 -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 m9QFSiQJ006148 for ; Sun, 26 Oct 2008 11:28:46 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9QFSbTx009977 for ; Sun, 26 Oct 2008 11:28:38 -0400 (EDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by mit.edu (Spam Firewall) with ESMTP id EB766BDCCCF for ; Sun, 26 Oct 2008 11:28:14 -0400 (EDT) Received: from [92.40.138.220] (92.40.138.220.sub.mbb.three.co.uk [92.40.138.220]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 26 Oct 2008 15:28:09 +0000 Message-ID: <49048C6F.5010801@isode.com> Date: Sun, 26 Oct 2008 15:27:43 +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: draft-ietf-behave-stun-test-vectors-03@tools.ietf.org MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: secdir@mit.edu Subject: [secdir] secdir review of draft-ietf-behave-stun-test-vectors-03.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 provides test vectors for FINGERPRINT and MESSAGE-INTEGRITY Session Traversal Utilities for NAT (STUN) protocol attributes. I agree with the author that there are no Security considerations worth noting in the document. IMHO, the importing thing for this type of document is to have 2 independent implementations that confirm that values provided in the document are indeed correct. /**/ I liked that one example included non-ASCII characters in the username. Nits: I think the convention for representing Unicode characters need to be specifically mentioned somewhere around Introduction. Also, SASLPrep and HMAC-SHA1 probably need informative references. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Oct 27 15:08:30 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4053A6A2C; Mon, 27 Oct 2008 15:08:30 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B903A6A2C for ; Mon, 27 Oct 2008 15:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=2.175, 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 WDXFlpQDsBaz for ; Mon, 27 Oct 2008 15:08:28 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E3C2A3A6A66 for ; Mon, 27 Oct 2008 15:08:27 -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 m9RM8O6T003904 for ; Mon, 27 Oct 2008 18:08:24 -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 m9RM8KaP003900 for ; Mon, 27 Oct 2008 18:08:21 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9RM89M2016054 for ; Mon, 27 Oct 2008 18:08:09 -0400 (EDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by mit.edu (Spam Firewall) with ESMTP id 424961207A56 for ; Mon, 27 Oct 2008 18:07:44 -0400 (EDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 756CDC0042; Mon, 27 Oct 2008 23:07:44 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Xo9NjO4-nMNi; Mon, 27 Oct 2008 23:07:39 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59269C0032; Mon, 27 Oct 2008 23:07:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8DC8C82B9C5; Mon, 27 Oct 2008 23:07:39 +0100 (CET) Date: Mon, 27 Oct 2008 23:07:39 +0100 From: Juergen Schoenwaelder To: Mark Stapp Message-ID: <20081027220739.GB3989@elstar.local> Mail-Followup-To: Mark Stapp , iesg@ietf.org, secdir@mit.edu, dhc-chairs@tools.ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Cc: dhc-chairs@tools.ietf.org, secdir@mit.edu, iesg@ietf.org Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt X-BeenThere: secdir@ietf.org Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 find the document clear and easy to read. I think the text in the security considerations section is adequate for this DHCPv6 extension. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 29 00:53:58 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175C33A6CD3; Wed, 29 Oct 2008 00:53:58 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82A83A689E for ; Tue, 28 Oct 2008 14:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.924 X-Spam-Level: X-Spam-Status: No, score=-104.924 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 8LFSJnUBI4js for ; Tue, 28 Oct 2008 14:14:34 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 63E4A3A6CAA for ; Tue, 28 Oct 2008 14:14:34 -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 m9SLEVcQ011373 for ; Tue, 28 Oct 2008 17:14:31 -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 m9SLETLq011358 for ; Tue, 28 Oct 2008 17:14:30 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9SLEKYr013252 for ; Tue, 28 Oct 2008 17:14:20 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 5C5F3BD6CE4 for ; Tue, 28 Oct 2008 17:13:55 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3C928C2C9; Tue, 28 Oct 2008 14:13:52 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 988E73A689E; Tue, 28 Oct 2008 14:13:51 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20081028211351.988E73A689E@core3.amsl.com> Date: Tue, 28 Oct 2008 14:13:51 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Wed, 29 Oct 2008 00:53:57 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance working group in the Transport 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 November 4, 2008. Behavior Engineering for Hindrance Avoidance (behave) ===================================================== Last Modified: 2008-10-23 Current Status: Active Working Group Chair(s): Dan Wing [dwing@cisco.com] Dave Thaler [dthaler@microsoft.com] Transport Area Director(s): Magnus Westerlund [magnus.westerlund@ericsson.com] Lars Eggert [lars.eggert@nokia.com] Transport Area Advisor: Magnus Westerlund [magnus.westerlund@ericsson.com] Mailing Lists: General Discussion: behave@ietf.org To Subscribe: behave-request@ietf.org In Body: In Body: subscribe Archive: http://www1.ietf.org/mail-archive/web/behave/current/index.html Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end- to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security that is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. The goal of this work is to encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following four translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function services is intended to service a specific IPv4 network using either private or public IPv4 addresses. Because this scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. The WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The fundamental parts of ICMP are also required to work. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Milestones: Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requirements for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Dec 08 Submit standards-track relay protocol to IESG Dec 08 Submit BCP document for SCTP NAT behavior Jan 09 Determine relative prioritization of the four translation cases. Mar 09 Submit standards-track document for relaying of a TCP bytestream Mar 09 Submit standard-track document of an IPv6 relay protocol to IESG Mar 09 Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Sep 09 Target for first solution to be submitted to IESG for publication as standards track RFC. _______________________________________________ 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 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 29 00:53:58 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB403A6CE0; Wed, 29 Oct 2008 00:53:58 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DD73A6C5F for ; Tue, 28 Oct 2008 15:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.439 X-Spam-Level: X-Spam-Status: No, score=-105.439 tagged_above=-999 required=5 tests=[AWL=1.160, 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 nztFV5glsUAS for ; Tue, 28 Oct 2008 15:05:11 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8BE963A6CB6 for ; Tue, 28 Oct 2008 15:05:11 -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 m9SM5Ask022799 for ; Tue, 28 Oct 2008 18:05:10 -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 m9SM596P022790 for ; Tue, 28 Oct 2008 18:05:09 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9SM50f0018799 for ; Tue, 28 Oct 2008 18:05:00 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 972E41378B38 for ; Tue, 28 Oct 2008 18:04:29 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4631228C2CF; Tue, 28 Oct 2008 15:04:29 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7E7333A690E; Tue, 28 Oct 2008 15:04:28 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20081028220428.7E7333A690E@core3.amsl.com> Date: Tue, 28 Oct 2008 15:04:28 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Wed, 29 Oct 2008 00:53:57 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org A modified charter has been submitted for the Mobility for IP: Performance, Signaling and Handoff Optimization working group in the Internet 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 November 4, 2008. Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------- Last Modified: 2008-10-16 Current Status: Active Working Group Chair(s): Stefano Faccin [smfaccin@marvell.com] Vijay Devarapalli [vijay.devarapalli@azairenet.com] Internet Area Director(s): Jari Arkko [jari.arkko@piuha.net] Mark Townsley [townsley@cisco.com] Internet Area Advisor: Jari Arkko [jari.arkko@piuha.net] Mailing Lists: General Discussion: mipshop@ietf.org To Subscribe: mipshop-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mipshop/index.html Description of Working Group: Mobile IPv6 enables IPv6 mobile nodes to continue a session using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause delay, packet loss, and also represent signaling overhead traffic on the network. The MIPSHOP WG has so far worked on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Mobile IPv6 Fast Handovers (FMIPv6) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link. The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and the necessary extensions to improve these protocols. The MIPSHOP WG will also identify missing components that are required for deploying these protocols and standardize the necessary extensions. The WG will also address using these protocols to provide fast handovers for network-based mobility management protocols like Proxy Mobile IPv6. The IEEE 802.21 Media Independent Handover (MIH) working group aims at providing services to assist with handoffs between heterogeneous link-layer technologies, and across IP subnet boundaries. MIH services can be delivered through link-layer specific solutions and/or through a "layer 3 or above" protocol. MIPSHOP will define the delivery of information for MIH services for this latter case. A L3 based mechanism to identify a valid information server is also required. The MIPSHOP will work on developing a protocol for transport of MIH services information and mechanisms for discovering the MIH server. Security for the transport of MIH information will also be addressed. The MOBOPTS Research Group in the IRTF is chartered to work on optimizations related to Mobile IPv6 and IP handoffs among other things. The MIPSHOP WG will take mature proposals from the MOBOPTS group and standardize them in the IETF on a case-by-case basis. The MIPSHOP WG will also consider and standardize optimizations for the Mobile IPv6 protocol and IP mobility in general. Scope of MIPSHOP: The working group will work on: 1. FMIPv6 Mobile Node - Access Router security using the AAA infrastructure Currently MIPSHOP has produced a standards track protocol for setting up security between the mobile node and access router for security FMIPv6 signaling messages. However, the protocol depends on SeND (Secure Neighbor Discovery) to be available on the mobile node and the access router. An alternate mechanism that leverages the AAA infrastructure would be useful. Many target systems where FMIPv6 is likely to be used use a AAA infrastructure to authenticate and authorize network access. The working group will work on a Informational document describing how the AAA infrastructure could be used for setting up security associations between the mobile node and the access router. 2. Prefix Management for point-to-point links with FMIPv6 Using FMIPv6 over point-to-points like requires some additional considerations with respect to managing and allocating prefixes for the mobile node on these point-to-point links. Therefore the WG will work on an Informational document to address the issues. 3. Handover optimizations when Proxy Mobile IPv6 is used for handovers Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol where a node in the access network, called the Mobile Access Gateway (MAG) handles mobility on behalf of the mobile node. It has been proposed to use FMIPv6 to optimize the handover in terms of reducing the packet loss and transferring relevant context from the old MAG to the new MAG. The workgin group will also work on other optimizations like the use of a transient binding cache entry for improving a PMIPv6-based handover. 4. Work on protocols and extensions for transporting information related to IEEE 802.21: The work includes the layer 3 protocol for transporting MIH related information and DHCP and DNS extensions for discovering the information servers. Goals and Milestones: Done Submit draft-ietf-mipshop-mih-support to the IESG for publication as Proposed Standard Done Working Group Last Call on draft-ietf-mipshop-mos-dns-discovery Done Working Group Last Call on draft-ietf-mipshop-mos-dhcp-options Oct 2008 Submit draft-ietf-mipshop-mos-dns-discovery to the IESG for publication as Proposed Standard Nov 2008 Submit draft-ietf-mipshop-mos-dhcp-options to the IESG for publication as Proposed Standard Feb 2008 Working Group Last Call on draft-ietf-mipshop-pfmipv6 Feb 2008 Working Group Last Call on draft-ietf-mipshop-transient-bce-pmipv6 Mar 2008 Submit draft-ietf-mipshop-pfmipv6 to the IESG for publication as Proposed Standard Mar 2008 Submit draft-ietf-mipshop-transient-bce-pmipv6 to the IESG for publication as Experimental Apr 2008 Working group last call on draft-ietf-mipshop-fmipv6-ptp May 2008 Submit draft-ietf-mipshop-fmipv6-ptp to the IESG for publication as Informational May 2008 Working Group Last Call on draft-ietf-mipshop-fmipv6-aaa-key Jun 2009 Submit draft-ietf-mipshop-fmipv6-aaa-key to the IESG for publication as Informational _______________________________________________ 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 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Wed Oct 29 05:41:33 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8750D28C368; Wed, 29 Oct 2008 05:41:33 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C5C3A6D09; Wed, 29 Oct 2008 05:35:55 -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 W-P0t+CPn2fU; Wed, 29 Oct 2008 05:35:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 966503A6D16; Wed, 29 Oct 2008 05:35:40 -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 m9TCZYLX026675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 14:35:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9TCZX0O022369; Wed, 29 Oct 2008 14:35:33 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18696.22677.949221.261766@fireball.kivinen.iki.fi> Date: Wed, 29 Oct 2008 14:35:33 +0200 From: Tero Kivinen To: draft-ietf-sip-media-security-requirements-07@tools.ietf.org, sip-chairs@tools.ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 25 min X-Total-Time: 33 min X-Mailman-Approved-At: Wed, 29 Oct 2008 05:41:32 -0700 Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] Review of draft-ietf-sip-media-security-requirements-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 talks about security requirements of the SIP media. As such the whole document talks about security. I do not have any security comments for it, but I have some other comments and notes about it. The biggest problem I had when I was reading the document, was that section 3, suddenly starts listing different requirements like R-PASS-MEDIA, R-PASS-SIG etc, and there is no indication where those are described. I tried to look for them in the table of contents, but couldn't find them listed there. Reading forward I finally found those in the section 5, but as they are not as separate sections there, they were not listed in the table of contents. It would be better to move each of those requirement to separate subsection, i.e. make "5.1.1 R-FORK-RETARGET" and so on, so those references earlier could point to section 5.1.1 and those would also be listed in the table of contents. There is also unexpanded acronym of UAC in section 4.2, and I do not what it means and it is not expanded or described in any way. There seemed to be also quite a lot of other acronyms, so it would be useful to check out if those are really described (or expanded) somewhere in the document. Also it would be useful to expand HERFP also in the section 5.1 when describing R-HERFP, not only section 4.2. Now the description of R-HERFP does not tell that much: "The media security key management protocol MUST function securely even in the presence of HERFP behavior." especially if reader doesn't remember what HERFP stands for... The description of R-RTP-VALID seems bit odd. It says that "...key negotiation packets MUST NOT pass the RTP validity check...". That seems bit odd considering that the name is R-RTP-VALID and it says MUST NOT pass validity check. Is that description really correct? Some nits: Section 8. Acknowledgements has Richard Barnes twice. Section A.4.3. SSRC and ROC has typo in word binding: "Another, used by Security Descriptions, is to use "late bindng" -- ... -- kivinen@safenet-inc.com _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 30 03:34:17 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA75E3A6AEE; Thu, 30 Oct 2008 03:34:17 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC59C3A698D; Thu, 30 Oct 2008 03:34:16 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWRxhbx0c0pp; Thu, 30 Oct 2008 03:34:12 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 35C603A6C97; Thu, 30 Oct 2008 03:34:11 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 56B0E29C003; Thu, 30 Oct 2008 12:33:46 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E7D7929C005; Thu, 30 Oct 2008 12:33:43 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9UAXgQC008041; Thu, 30 Oct 2008 12:33:43 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 30 Oct 2008 12:33:42 +0200 From: Yaron Sheffer To: "iesg@ietf.org" , "secdir@ietf.org" , "tsirtsis@googlemail.com" , "vpark@qualcomm.com" , "hesham@elevatemobile.com" , Henrik Levkowetz , "pete.mccann@motorola.com" Date: Thu, 30 Oct 2008 12:33:41 +0200 Thread-Topic: Secdir review of draft-ietf-mip4-dsmipv4-07 Thread-Index: Ack6evmfFHZryFahRtG9ZSAbM4ZGfw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CD002@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-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: , Content-Type: multipart/mixed; boundary="===============0934474920==" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org --===============0934474920== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_015F_01C93A8B.BD71D970" ------=_NextPart_000_015F_01C93A8B.BD71D970 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0160_01C93A8B.BD71D970" ------=_NextPart_001_0160_01C93A8B.BD71D970 Content-Type: text/plain; charset="us-ascii" 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. I found this document very well written. I did not find additional security issues beyond those documented in the Security Considerations, other than the establishment of yet another tunneling method. Such methods are often abused in order to bypass security middleboxes. However it does make sense to discuss interactions with the existing documents on MIP4 and MIP6 security, see below. Security comments: - There are two recent RFCs on the interaction between Mobile IP and IPsec, RFC 5265 and 5266. I would expect the current document to refer to the interaction between IPsec and DSMIP. IPsec for this traffic will be affected by two factors: (1) protecting MIP4 traffic does not protect *all* traffic, in the case of tunneling to the CoA, and (2) as always with nested tunnels, access control policy will not be enforced correctly, because only the IP-in-IP header will be used to authorize the traffic. - This document establishes TWO new ways to tunnel IPv6 traffic, one inside of MIP4 tunneling and another "in parallel" to MIP4 traffic. Security devices will have to learn how to detect and secure this traffic. I would expect an informative reference to draft-ietf-v6ops-tunnel-security-concerns. Other comments: - IMHO, the document would be easier to read through if Sec. 3 (formats) were moved *after* Sec. 4 (processing rules). - In the IANA considerations, it is unclear if the last paragraph (expert review) refers to the preceding paragraph, or to both of the new number spaces. - 4.3: spelling: mechanisma -> mechanisms ------=_NextPart_001_0160_01C93A8B.BD71D970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

I found this document very well written. I did not = find additional security issues beyond those documented in the Security Considerations, other than the establishment of yet another tunneling = method. Such methods are often abused in order to bypass security middleboxes. = However it does make sense to discuss interactions with the existing documents on = MIP4 and MIP6 security, see below.

 

Security comments:

 

- There are two recent RFCs on the interaction = between Mobile IP and IPsec, RFC 5265 and 5266. I would expect the current = document to refer to the interaction between IPsec and DSMIP. IPsec for this traffic = will be affected by two factors: (1) protecting MIP4 traffic does not protect = *all* traffic, in the case of tunneling to the CoA, and (2) as always with nested = tunnels, access control policy will not be enforced correctly, because only the IP-in-IP = header will be used to authorize the traffic.

- This document establishes TWO new ways to tunnel = IPv6 traffic, one inside of MIP4 tunneling and another “in = parallel” to MIP4 traffic. Security devices will have to learn how to detect and secure = this traffic. I would expect an informative reference to = draft-ietf-v6ops-tunnel-security-concerns.

 

Other comments:

 

- IMHO, the document would be easier to read through = if Sec. 3 (formats) were moved *after* Sec. 4 (processing = rules).

- In the IANA considerations, it is unclear if the = last paragraph (expert review) refers to the preceding paragraph, or to both = of the new number spaces.

- 4.3: spelling: mechanisma -> = mechanisms

------=_NextPart_001_0160_01C93A8B.BD71D970-- ------=_NextPart_000_015F_01C93A8B.BD71D970 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAzMDEwMzM0MFowIwYJKoZIhvcNAQkEMRYEFKMFq/kNqrrp tt8Tz4J/lrU2LWKdMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA EohWCZpJyqLjQvlIpnGNBM//AKx9TjZNb2hSQIcIEf1UhCffqhGx4lZno2Nmcz37jEjhnR9MVkTP w1Y0Mm/vI8PqFMDIXakyBgAOcQjjQHZQD83ntuVL1pNwAfE2NgRTJa98XbbVCR8R+c+9/rPFOcYk fm6KIjrUxOmhdvhKDaWtR+VJ+zClWwqxB10oO0u1XW/1CygiRDyoLKnNnpGixaTpKfQv4svOqOQl p1idvfU68FMylV2jsnyGuhmJa1Swa/1bmcmTJkb/UxEEZbFZXtn9v6V4ANy2IaxaejqGcHYRqvRt dboPZ0cRMb1/3A9nV8cCxG/ziXPGUsAmPcz+LAAAAAAAAA== ------=_NextPart_000_015F_01C93A8B.BD71D970-- --===============0934474920== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --===============0934474920==-- From secdir-bounces@ietf.org Thu Oct 30 04:35:59 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B853A6AB1; Thu, 30 Oct 2008 04:35:59 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A173A6838; Thu, 30 Oct 2008 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 EhV8xFxtyaGZ; Thu, 30 Oct 2008 04:35:57 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 02AD23A694D; Thu, 30 Oct 2008 04:35:47 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9UBZK0M016454; Thu, 30 Oct 2008 13:35:44 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 13:35:24 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 13:35:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 13:35:22 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB72020F3B23@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pasi's AD Notes for October 2008 Thread-Index: Ack6g5g9ssk8Wz2hSgmBUmb9QF6RZA== From: To: , X-OriginalArrivalTime: 30 Oct 2008 11:35:24.0644 (UTC) FILETIME=[99746A40:01C93A83] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for October 2008 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi all, 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 - There'll be one security-related BoF in IETF73: OAuth in the applications area. - SecDir mailing list was moved to ietf.org -- remember to use the new address when sending reviews. - Tim and I have been planning the SAAG agenda for Minneapolis. It's the last slot before dinner on Thursday, so we're hoping to keep it quite short, though. - Lars Eggert and I talked with the Outpost24 guys about the TCP DoS vulnerabilities they've found; we're meeting CERT-FI folks next week, and hope to get more details (probably under NDA for now). - I've continued tools development, and tried to sort out the process (from both Nokia and IETF/AMS points of view) of how to actually contribute code and get it running. Not completely successful yet, but making progress. - Big thanks to Paul Hoffman for fixing the spam problem in PKIX mailing list archives (not a single spam after the fix; used to be about 40%). - Working with IANA on fixing the IANA registries for RFC 4909 (needed for draft-jerichow-msec-mikey-genext-oma). - Some discussions about allocating more IPv4/IPv6 addresses for documentation/example use, but nothing conclusive so far. WORKING GROUPS DKIM - draft-ietf-dkim-ssp: in AD Evaluation -- I sent my AD review comments, and I'm waiting for revised ID or reply. - draft-ietf-dkim-overview: in Publication Requested, waiting for me to read it. - Waiting for WG to send list of RFC errata IDs the WG agrees on. - The work items are almost done; some discussions on the list about rechartering or winding down. EMU - draft-ietf-emu-gpsk: in IETF Last Call (ends 2008-11-03), on agenda of 2008-11-06 IESG telechat. - EMU WG received a liaison statement reply from ITU-T SG 17 regarding X.1034, "Guidelines on EAP-based authentication and key management in a data communication network". - (not WG item) draft-arkko-eap-aka-kdf went through IETF Last call; now doing final checks to make sure everything is aligned here and in relevant 3GPP specs. IPSECME - (not wearing AD hat) I need to check that my comments got entered into the issue tracker, and reply to Paul about some of them. - (not wearing AD hat) Waiting for Russ to verify errata #1502 for RFC 4718 [since 2008-09-12] ISMS - I haven't managed to read the mailing list at all this month; I really need to do so. KEYPROV - I need to put more time into KEYPROV in November and December; the WG is over a year behind its milestones, and it doesn't look like the documents are anywhere near ready. SASL - SASL WG was rechartered. SYSLOG - draft-ietf-syslog-transport-tls: was approved and is now in RFC Editor Queue - draft-ietf-syslog-sign: there has been a bunch of replies to my AD evaluation comments that I need to read and process, but I haven't done so yet. However, I'm hoping to see a revised ID that would address those concerns where everyone agrees what should be done. - draft-ietf-ipcdn-pktc-eventmess: this is in RFC Editor Queue, but had references to documents syslog WG decided to drop -- big thanks to David Harrington and Richard Woundy for getting this fixed. TLS - draft-ietf-tls-des-idea: in Publication Requested state, waiting for Tim to review this (since I'm the editor) [since 2008-10-20] - draft-ietf-tls-ecdhe-psk: hoping the WG will soon request publication and send the shepherd write-up etc. - draft-ietf-tls-psk-new-mac-aes-gcm: same as ecdhe-psk. - Certicom has posted an updated statement about ECC IPR (http://www.certicom.com/index.php/ip-contributions), which probably will also appear in the IETF IPR tool soon. Joe Salowey has asked them about including draft-ietf-tls-ecdhe-psk in the list of documents. - (not WG item) draft-rescorla-tls-suiteb: on agenda of 2008-11-06 IESG telechat. OTHER DOCUMENTS - draft-ietf-avt-rtcpssm: Joerg replied on 2008-10-27 about the "feedback debug" messages; I need to read his email and reply. - draft-ietf-pkix-cmp-transport-protocols: It seems some folks are interested in reviving this long-expired draft, so that current implementation behavior is documented somewhere. I've promised to read and comment if/when something is submitted. - draft-randall-3447bis: James Randall posted the -00 draft; I should read this and comment. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I've promised to read this once there's a new version. - "Security roadmap for routing protocols": I've promised to read and comment this once Gregory sends something. - draft-mattsson-srtp-store-and-forward: I've promised to read this and send comments, but haven't done so yet. DISCUSSES (active -- something happened within last month) - draft-ietf-enum-experiences: the authors have replied to my updated discuss; I need to read their message and reply [since 2008-10-27] - draft-ietf-dime-mip6-integrated: waiting for authors to submit a revised ID [since 2008-10-29] - draft-ietf-mip6-whyauthdataoption: waiting for authors to submit a revised ID, and reply to some of my comments [since 2008-10-29] - draft-ietf-mipshop-mstp-solution: I need to check version -08 and talk with Jari and the authors about what's the best way to handle this document [since 2008-10-20] - draft-ietf-pce-pcep: version -16 addressed all my major concerns; I hope to see a revised ID fixing the remaining things before the submission cut-off date [since 2008-10-30] - draft-ietf-simple-imdn: version -09 addressed most of my comments; waiting for the authors to reply to the remaining ones [since 2008-10-27] - draft-ietf-sip-fork-loop-fix: version -08 was submitted recently; I need to check that my concerns were addressed [since 2008-10-29] - draft-ietf-sip-xcapevent: waiting for revised ID or RFC Editor Note to fix the ABNF/XML bugs [since 2008-10-24] - draft-ietf-sipping-policy-package: waiting for more information from from Mary or Jon [since 2008-10-28] - draft-ietf-tsvwg-emergency-rsvp: I moved to "abstain" position. 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 reply to my comments or submit a revised ID [since 2008-08-28] - draft-cam-winget-eap-fast-provisioning: waiting for authors to reply to my comments or submit a revised ID [since 2008-08-28] - draft-ietf-lemonade-msgevent: waiting for authors to submit a revised ID [since 2008-09-08] - draft-ietf-sieve-refuse-reject: waiting for authors to reply to my comments [since 2008-09-11] - draft-zhou-emu-fast-gtc: changes probably agreed, waiting for authors to submit a revised ID to see exact text [since 2008-08-28] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-ietf-bfd-base: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-multihop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to my comments or submit a revised ID [since 2008-06-05] - draft-ietf-shim6-proto: waiting for Erik to propose something to solve IPsec interaction issue [since 2008-06-18] --end-- _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Thu Oct 30 07:31:21 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3224A3A6855; Thu, 30 Oct 2008 07:31:21 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072D03A680C; Thu, 30 Oct 2008 07:31:20 -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 le5FHQh8fIAi; Thu, 30 Oct 2008 07:31:11 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 2CC4C3A6922; Thu, 30 Oct 2008 07:31:11 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m9UEUqH5013733; Thu, 30 Oct 2008 10:30:53 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m9UEUiMf019241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2008 10:30:50 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m9UEUiTT024403; Thu, 30 Oct 2008 10:30:44 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, idr-chairs@tools.ietf.org, gih@apnic.net From: Tom Yu Date: Thu, 30 Oct 2008 10:30:44 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 Subject: [secdir] secdir review of draft-ietf-idr-as-documentation-reservation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org 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 a reserved block of AS numbers that would prevent conflicts between documentation examples and deployed systems. The Security Considerations section states AS number reservations do not have any direct impact on Internet infrastructure security. I concur with this assessment. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Oct 31 01:14:13 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58FA3A6803; Fri, 31 Oct 2008 01:14:13 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C718828C1C0 for ; Thu, 30 Oct 2008 15:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.874 X-Spam-Level: X-Spam-Status: No, score=-105.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 iWNsSuZ8Zwad for ; Thu, 30 Oct 2008 15:04:32 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1B2A828C1E6 for ; Thu, 30 Oct 2008 15:04:24 -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 m9UM4MJi021595 for ; Thu, 30 Oct 2008 18:04:22 -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 m9UM4L4W021592 for ; Thu, 30 Oct 2008 18:04:21 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m9UM4Daf019157 for ; Thu, 30 Oct 2008 18:04:13 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id DC217C0A40D for ; Thu, 30 Oct 2008 18:03:40 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9472D3A6981; Thu, 30 Oct 2008 15:03:40 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 085DD28C196; Thu, 30 Oct 2008 15:03:39 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20081030220340.085DD28C196@core3.amsl.com> Date: Thu, 30 Oct 2008 15:03:40 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Approved-At: Fri, 31 Oct 2008 01:14:13 -0700 Subject: [secdir] [New-work] WG Review: Low Extra Delay Background Transport (ledbat) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org A new IETF working group has been proposed in the Transport 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 November 6, 2008. [Note: The LEDBAT WG stems from the TANA BoF held in Dublin.] Low Extra Delay Background Transport (ledbat) -------------------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2008-10-30 Chair(s): TBD Transport Area Director(s): * Magnus Westerlund [magnus.westerlund@ericsson.com] * Lars Eggert [lars.eggert@nokia.com] Transport Area Advisor: * Lars Eggert [lars.eggert@nokia.com] Mailing Lists: General Discussion: tana@ietf.org To Subscribe: tana-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/tana/ [Note: If chartered, mailing list will change to ledbat@ietf.org.] Description of Working Group: The LEDBAT WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. LEDBAT is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best-effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck * eliminate long standing queues and thus keep delay low when no other traffic is present * quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control * add little to the queueing delays induced by TCP traffic * operate well in networks with FIFO queueing with drop-tail discipline * be deployable for popular applications that currently comprise noticeable fractions of Internet traffic * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. Once experience is gained with this congestion control algorithm on the Internet, the WG will consider if it is appropriate to ask the IESG to advance the document as a Proposed Standard. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. Goals and Milestones: Oct 2009 Submit "Multiple Transport Connections in Applications Design" to the IESG for consideration as an Informational RFC Oct 2009 Submit "Low Extra Delay Background Transport (LEDBAT)" to the IESG for consideration as an Experimental RFC _______________________________________________ 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 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Sat Nov 1 01:08:35 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D303A68A4; Sat, 1 Nov 2008 01:08:35 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605A13A6B01 for ; Sat, 1 Nov 2008 01:08:34 -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 XXKWNeskRC3n for ; Sat, 1 Nov 2008 01:08:33 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 8BAC13A68A4 for ; Sat, 1 Nov 2008 01:08:32 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id mA188UBt018896 for ; Sat, 1 Nov 2008 04:08:30 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id mA188Tfw018892 for ; Sat, 1 Nov 2008 04:08:30 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 1 Nov 2008 04:08:29 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Sat, 01 Nov 2008 04:08:30 -0400 (EDT) Subject: [secdir] Telechat Assignments for November 4th X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Rather than send a full set of assignments this week, I'm just sending a list of documents on telechat next Thursday. Some of these may have been reviewed recently; if so, there's no need to respond -- the reviews have undoubtedly been received, just not recorded. The "R" flag (for "recheck") marks documents that have been reviewed at least once before. As noted on October 23rd, I'm on holiday through next week -- please contact the ADs with any issues or questions. And for the full list of outstanding assignments, see that message from the 23rd. -- Sam Reviewer Draft Derek Atkins TR draft-kato-ipsec-camellia-modes-09 Lakshminath Dondeti T draft-ietf-enum-combined-08 Lakshminath Dondeti T draft-ietf-avt-rfc4749-dtx-update-02 Donald Eastlake TR draft-ietf-enum-infrastructure-07 Phillip Hallam-Baker T draft-ietf-psamp-info-11 Steve Hanna T draft-rescorla-tls-suiteb-10 Paul Hoffman TR draft-ietf-avt-dtls-srtp-06 Love Hornquist-Astrand T draft-ietf-sip-sips-08 Tero Kivinen T draft-ietf-sip-media-security-requirements-08 Julien Laganier T draft-ietf-sipping-cc-transfer-11 Catherine Meadows TR draft-ietf-behave-dccp-04 Alexey Melnikov T draft-ietf-behave-stun-test-vectors-03 Magnus Nystrom T draft-ietf-vrrp-unified-spec-02 Eric Rescorla T draft-ietf-sip-dtls-srtp-framework-05 Joe Salowey T draft-ietf-emu-eap-gpsk-16 Tom Yu T draft-ietf-idr-as-documentation-reservation-00 Again, recent reviews have NOT been noted in my database -- if you've reviewed the doc recently, you don't need to do anything. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir