From weiler+secdir@watson.org Mon Nov 2 08:14:27 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0612828C0ED for ; Mon, 2 Nov 2009 08:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x7T7C3b+8mi for ; Mon, 2 Nov 2009 08:14:26 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id EE6CD3A67A5 for ; Mon, 2 Nov 2009 08:14:25 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nA2GEjb6071697 for ; Mon, 2 Nov 2009 11:14:45 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nA2GEjtL071694 for ; Mon, 2 Nov 2009 11:14:45 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 2 Nov 2009 11:14:45 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 02 Nov 2009 11:14:45 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:14:27 -0000 Rob Austein is next in the rotation. (For those who may wonder what that means: I typically make new assignments round-robin using a list sorted by last name. Rob, Richard Barnes, Pat Cain, etc. will be getting new assignments next time around.) As a reminder, the next telechat is November 19th, following the Hiroshima meeting. Please try to complete last call reviews by the end of the last call. For documents on telechat, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Documents flagged with an "R" below are "rechecks" -- the doc has been reviewed before, but something has changed. I'm looking forward to seeing many of you in Hiroshima. The usual secdir lunch will be on Tuesday in Castleview 1. -- Sam For telechat 2009-11-19 Reviewer Deadline Draft Chris Newman T 2009-11-17 draft-ietf-forces-sctptml-06 Stefan Santesson TR2009-11-17 draft-ietf-tsvwg-rsvp-l3vpn-03 Stefan Santesson T 2009-11-17 draft-ietf-bmwg-ipsec-term-12 Yaron Sheffer T 2009-11-17 draft-ietf-dna-simple-11 Hannes Tschofenig T 2009-11-17 draft-carpenter-renum-needs-work-04 Carl Wallace T 2009-11-17 draft-ietf-6man-overlap-fragment-03 For telechat 2009-12-03 Reviewer Deadline Draft Nico Williams T 2009-12-01 draft-dusseault-http-patch-15 Larry Zhu T 2009-12-01 draft-combes-ipdvb-mib-rcs-08 Last calls and special requests: Reviewer Deadline Draft Derek Atkins 2009-11-23 draft-klensin-ftp-registry-02 Rob Austein 2009-10-07 draft-reschke-rfc2731bis-03 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Sam Hartman R2009-10-23 draft-hammer-oauth-03 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-08 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-17 Charlie Kaufman None draft-baker-ietf-core-04 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Russ Mundy 2009-10-21 draft-ietf-hokey-preauth-ps-09 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Sandy Murphy 2009-10-23 draft-nottingham-site-meta-03 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Radia Perlman None draft-bryan-http-digest-algorithm-values-update-03 Eric Rescorla 2009-11-10 draft-gennai-smime-cnipa-pec-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-10-23 draft-ietf-l3vpn-ospfv3-pece-03 Sean Turner 2009-10-28 draft-ietf-ipsecme-traffic-visibility-09 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2009-11-16 draft-melnikov-imap-keywords-06 Brian Weis R2009-11-20 draft-ietf-pim-sm-linklocal-09 Brian Weis 2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Tom Yu 2009-11-23 draft-ietf-ccamp-lsp-dppm-10 Kurt Zeilenga 2009-11-09 draft-ietf-morg-status-in-list-01 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-04 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 Glen Zorn 2009-11-18 draft-ietf-sasl-gs2-17 From gonzalo.camarillo@ericsson.com Tue Nov 3 01:15:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3AF28C145 for ; Tue, 3 Nov 2009 01:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dldSaZGTo4lv for ; Tue, 3 Nov 2009 01:15:19 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9ABDD3A6825 for ; Tue, 3 Nov 2009 01:15:18 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-9b-4aeff4b90cfc Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A0.27.04191.9B4FFEA4; Tue, 3 Nov 2009 10:15:37 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 10:15:33 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 10:15:32 +0100 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5D45A2507; Tue, 3 Nov 2009 11:15:32 +0200 (EET) Message-ID: <4AEFF4B4.6050505@ericsson.com> Date: Tue, 03 Nov 2009 11:15:32 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dan Wing References: <4AD85644.5020904@ericsson.com> <003b01ca50d6$d6d2e7d0$c4f0200a@cisco.com> In-Reply-To: <003b01ca50d6$d6d2e7d0$c4f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2009 09:15:32.0684 (UTC) FILETIME=[31E2B0C0:01CA5C66] X-Brightmail-Tracker: AAAAAA== Cc: fluffy@cisco.com, secdir@ietf.org, oran@cisco.com, fandreas@cisco.com, 'Sam Hartman' , rjsparks@nostrum.com Subject: Re: [secdir] review of draft-ietf-mmusic-connectivity-precon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:15:20 -0000 Hi Cullen, based on Sam's and Dan's comments below, could you please make the following change to the RFC Editor's note you already included in the IESG evaluation record: https://datatracker.ietf.org/idtracker/ballot/3178/ OLD: S/MIME [RFC3853] provides such end- to-end integrity protection, as described in [RFC3261]. NEW: The SIP identity mechanism specified in RFC 4474 [RFC4474] provides such end-to-end integrity protection. Thanks, Gonzalo Dan Wing wrote: > > >> -----Original Message----- >> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >> Sent: Monday, October 19, 2009 9:06 AM >> To: Gonzalo Camarillo >> Cc: Stephen Kent; fluffy@cisco.com; secdir@ietf.org; >> oran@cisco.com; fandreas@cisco.com; dwing@cisco.com; >> rjsparks@nostrum.com >> Subject: Re: [secdir] review of >> draft-ietf-mmusic-connectivity-precon-06 >> >>>>>>> "Gonzalo" == Gonzalo Camarillo >> writes: >> >> Gonzalo> [RFC4032], it is strongly RECOMMENDED that integrity >> Gonzalo> protection be applied to the SDP session descriptions. >> Gonzalo> S/MIME [RFC3853] provides such end- to-end integrity >> Gonzalo> protection, as described in [RFC3261]. Additionally, the >> >> >> I'm surprised you're referencing S/MIME here rather than something >> like identity. >> I understand none of the above have huge deployment, but I >> thought we had a fairly strong understanding that S/MIME was >> not the direction we were moving towards. > > You're right. S/MIME doesn't work and and isn't used. The > suggestion for integrity protection should be RFC4474 ("SIP > Identity"). > > -d > > > From Kurt.Zeilenga@Isode.com Thu Nov 5 12:28:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB663A6909; Thu, 5 Nov 2009 12:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxz9qj3knKbU; Thu, 5 Nov 2009 12:28:11 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 261943A68D6; Thu, 5 Nov 2009 12:28:11 -0800 (PST) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 5 Nov 2009 20:28:32 +0000 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga Date: Thu, 5 Nov 2009 12:27:57 -0800 Message-Id: <84142585-588C-4AB9-899F-0C0708AD9577@Isode.com> To: Security Area Directorate X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: draft-ietf-morg-status-in-list@tools.ietf.org, The IESG Subject: [secdir] draft-ietf-morg-status-in-list X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:28:12 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft proposes an IMAP extension which saves the client and hence the server a bit of work in obtaining status information about mailboxes. In my opinion, the extension does not add any significant security consideration to IMAP. While I personally would have just said "This extension does not add any significant security consideration to IMAP. See RFC XXXX for a generally applicable security considerations.", it nice that the author took the time to detail a (I think) quite minor security consideration. -- Kurt From jhutz@cmu.edu Thu Nov 5 15:39:47 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F82928C10F for ; Thu, 5 Nov 2009 15:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-1.992, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOKFFKMZwKv8 for ; Thu, 5 Nov 2009 15:39:47 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id D7DAE28C0CF for ; Thu, 5 Nov 2009 15:39:46 -0800 (PST) Received: from [10.0.0.3] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nA5Ne8ta006863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 18:40:08 -0500 (EST) Date: Thu, 05 Nov 2009 18:40:08 -0500 From: Jeffrey Hutzelman To: secdir@ietf.org Message-ID: <9915111DF00B91F96E02FAB9@atlantis.pc.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Subject: [secdir] PGP key-signing - session leader needed X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:39:47 -0000 We'd like to hold a PGP key-signing session at next week's IETF meeting, in one of the usual timeslots. Given the current agenda, I'm guessing that will probably be Tuesday evening immediately following the last session, but I haven't yet worked out that detail with the secretariat. The tricky part is, I won't be in Hiroshima, so I need someone to volunteer to run the session. This is fairly straightforward -- explain how the process works, then get to it. You'll also need to bring printouts of the list of fingerprints to hand out. I will arrange for the announcement (which usually goes out around now in any case), and will also collect keys and make them available for download in the usual places. If anyone has a bit of time to spare for this, please let me know ASAP. Thanks... -- Jeff From weiler+secdir@watson.org Fri Nov 6 19:44:35 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E68128C0CE for ; Fri, 6 Nov 2009 19:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 DsePkpOHhcUF for ; Fri, 6 Nov 2009 19:44:34 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 414053A6A0C for ; Fri, 6 Nov 2009 19:44:34 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nA73ivoc088519 for ; Fri, 6 Nov 2009 22:44:57 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nA73ivCU088516 for ; Fri, 6 Nov 2009 22:44:57 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 6 Nov 2009 22:44:57 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 06 Nov 2009 22:44:57 -0500 (EST) Subject: [secdir] Assignments (fwd) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 03:44:35 -0000 There are no "new" secdir assignments today. Below is a copy of the last assignment message, from this Monday. Safe travels to those coming to Hiroshima. (Through some miracle of merciful fate, there have been no new last calls issued nor new things added to the November 19th telechat agenda since I sent secdir assignments on Monday. This makes your jet-lagged secdir secretary very happy.) -- Sam ---------- Forwarded message ---------- Date: Mon, 2 Nov 2009 11:14:45 -0500 (EST) From: Samuel Weiler Reply-To: secdir-secretary@mit.edu To: secdir@ietf.org Subject: Assignments Rob Austein is next in the rotation. (For those who may wonder what that means: I typically make new assignments round-robin using a list sorted by last name. Rob, Richard Barnes, Pat Cain, etc. will be getting new assignments next time around.) As a reminder, the next telechat is November 19th, following the Hiroshima meeting. Please try to complete last call reviews by the end of the last call. For documents on telechat, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Documents flagged with an "R" below are "rechecks" -- the doc has been reviewed before, but something has changed. I'm looking forward to seeing many of you in Hiroshima. The usual secdir lunch will be on Tuesday in Castleview 1. -- Sam For telechat 2009-11-19 Reviewer Deadline Draft Chris Newman T 2009-11-17 draft-ietf-forces-sctptml-06 Stefan Santesson TR2009-11-17 draft-ietf-tsvwg-rsvp-l3vpn-03 Stefan Santesson T 2009-11-17 draft-ietf-bmwg-ipsec-term-12 Yaron Sheffer T 2009-11-17 draft-ietf-dna-simple-11 Hannes Tschofenig T 2009-11-17 draft-carpenter-renum-needs-work-04 Carl Wallace T 2009-11-17 draft-ietf-6man-overlap-fragment-03 For telechat 2009-12-03 Reviewer Deadline Draft Nico Williams T 2009-12-01 draft-dusseault-http-patch-15 Larry Zhu T 2009-12-01 draft-combes-ipdvb-mib-rcs-08 Last calls and special requests: Reviewer Deadline Draft Derek Atkins 2009-11-23 draft-klensin-ftp-registry-02 Rob Austein 2009-10-07 draft-reschke-rfc2731bis-03 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Sam Hartman R2009-10-23 draft-hammer-oauth-03 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-08 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-17 Charlie Kaufman None draft-baker-ietf-core-04 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Russ Mundy 2009-10-21 draft-ietf-hokey-preauth-ps-09 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Sandy Murphy 2009-10-23 draft-nottingham-site-meta-03 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Radia Perlman None draft-bryan-http-digest-algorithm-values-update-03 Eric Rescorla 2009-11-10 draft-gennai-smime-cnipa-pec-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-10-23 draft-ietf-l3vpn-ospfv3-pece-03 Sean Turner 2009-10-28 draft-ietf-ipsecme-traffic-visibility-09 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Sam Weiler 2009-11-16 draft-melnikov-imap-keywords-06 Brian Weis R2009-11-20 draft-ietf-pim-sm-linklocal-09 Brian Weis 2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Tom Yu 2009-11-23 draft-ietf-ccamp-lsp-dppm-10 Kurt Zeilenga 2009-11-09 draft-ietf-morg-status-in-list-01 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-04 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 Glen Zorn 2009-11-18 draft-ietf-sasl-gs2-17 From william.polk@nist.gov Sun Nov 8 15:10:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775213A68A0 for ; Sun, 8 Nov 2009 15:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 MGPGbOL1UL9G for ; Sun, 8 Nov 2009 15:10:17 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 9493F3A682E for ; Sun, 8 Nov 2009 15:10:17 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nA8NAYsJ023381 for ; Sun, 8 Nov 2009 18:10:34 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Sun, 8 Nov 2009 18:10:27 -0500 From: "Polk, William T." To: "secdir@ietf.org" Date: Sun, 8 Nov 2009 18:07:19 -0500 Thread-Topic: Secdir lunch options (Was FW: [76all] ANA Hotel Quick Lunch Options) Thread-Index: AQHKYMin6AvRgK6ukUiALVL7ZyEodQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] Secdir lunch options (Was FW: [76all] ANA Hotel Quick Lunch Options) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 23:10:19 -0000 Folks, For those who opted out of the meeting attendee list, here is some informat= ion about lunch options in the hotel. I understand there are a variety of = other options within a few blocks of the hotel... Thanks, Tim ________________________________________ From: 76all-bounces@ietf.org [76all-bounces@ietf.org] On Behalf Of Alexa Mo= rris [amorris@amsl.com] Sent: Sunday, November 08, 2009 3:35 AM To: 76all@ietf.org Subject: [76all] ANA Hotel Quick Lunch Options The ANA Hotel has put together some quick and portable lunch options especially for us. The exact selection will vary daily, but a example of a typical day will include options such as: 1) Rye Bread Sandwich (with Pastrami) Teriyaki Chicken, Fried Shrimp, Lasagna, Salad and Fruits 2) Teriyaki Chicken and Vegetables, Rice and Salad 3) Vegetable Sandwich, Salad, Potato Galette, Chickpea, Broccoli, Mushroom Saute, Penne in Tomato sauce How much: 1,000 yen (approximately $11 USD) Where: 3rd floor foyer When: 11:30am-1pm, Monday through Friday. Supplies are limited. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ 76all mailing list 76all@ietf.org https://www.ietf.org/mailman/listinfo/76all From william.polk@nist.gov Sun Nov 8 15:23:33 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14323A6819 for ; Sun, 8 Nov 2009 15:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 TbzIWL8VQBGC for ; Sun, 8 Nov 2009 15:23:33 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id C84DE3A682E for ; Sun, 8 Nov 2009 15:23:32 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nA8NNoZf028121 for ; Sun, 8 Nov 2009 18:23:50 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Sun, 8 Nov 2009 18:23:43 -0500 From: "Polk, William T." To: "secdir@ietf.org" Date: Sun, 8 Nov 2009 18:23:42 -0500 Thread-Topic: room for secdir lunch at IETF 76 Thread-Index: AQHKYMqC6OeW9rX0F0GE2ZiAK/fD9A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] room for secdir lunch at IETF 76 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 23:23:33 -0000 Folks, The Secdir lunch will be held in Castleview 1 on the 22nd floor during the = usual Tuesday lunch slot. See you there! Thanks, Tim Polk= From weiler@watson.org Mon Nov 9 12:44:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B040D28C243; Mon, 9 Nov 2009 12:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 1cHQWtxZAmwL; Mon, 9 Nov 2009 12:44:15 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id D516928C23F; Mon, 9 Nov 2009 12:44:14 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nA9KieX3084890; Mon, 9 Nov 2009 15:44:40 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nA9KidXx084887; Mon, 9 Nov 2009 15:44:39 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 9 Nov 2009 15:44:39 -0500 (EST) From: Samuel Weiler To: ietf@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 09 Nov 2009 15:44:40 -0500 (EST) Cc: Alexey.Melnikov@isode.com, secdir@ietf.org Subject: [secdir] secdir review of draft-melnikov-imap-keywords-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:44:15 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. >From a security perspective, I have no issues with this document. It creates a new registry and defines two sets of assignment metrics, one for "common use" keywords, and one for vendor-specific keywords. It also registers four keywords. (I'm wondering if it shouldn't be registering more.) I'm finding the IANA assignment metrics to be a little more ambiguous that I'd like. Starting with the vendor-specific text: Registration of vendor specific IMAP keywords is done on First Come First Serve [RFC5226] basis and doesn't require the Expert Review. However such review is still encouraged. Should the review be requested, ... Who requests the review? The registrant or IANA? Does IANA need to encourage the review? Perhaps it would be better to have all requests (including vendor-specific) be sent to the mailing list, with IANA assignment of the vendor-specific ones being automatic following a (short) delay for comment and optional revision. And for the common-use: Registration of an IMAP keyword intended for common use (whether or not they use the "$" prefix) requires Expert Review [RFC5226]. IESG appoints one or more Expert Reviewer, one of which is designated as the primary Expert Reviewer. IMAP keywords intended for common use SHOULD be standardized in IETF Consensus [RFC5226] documents. ... In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. Would it be better to say: "requires either IETF Consensus or Expert Review"? (For example: do the registrations made in this doc have to go through Expert Review? Isn't it enough to have them in a consensus doc?") And how do you expect the expert to encourage/enforce the SHOULD, given the "favour registering it over requiring perfect documentation" guideline? Again, the current text isn't as clear as I'd like. -- Sam From secdir-bounces@mit.edu Mon Nov 9 02:29:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68AA83A67B1 for ; Mon, 9 Nov 2009 02:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=5.975, BAYES_00=-2.599, GB_I_INVITATION=-2, MSGID_FROM_MTA_HEADER=0.803, 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 mHDfzmkf0a6p for ; Mon, 9 Nov 2009 02:29:58 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 6EF3328C197 for ; Mon, 9 Nov 2009 02:29:58 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id nA9AUM9P007859 for ; Mon, 9 Nov 2009 05:30:22 -0500 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 nA9AULj5007856 for ; Mon, 9 Nov 2009 05:30:21 -0500 Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id nA9ASPlB029736 for ; Mon, 9 Nov 2009 05:30:12 -0500 (EST) Message-Id: <200911091030.nA9ASPlB029736@fort-point-station.mit.edu> X-AuditID: 12074422-b7c99ae0000069af-d3-4af7ef222285 Received: from mail-pz0-f151.google.com (mail-pz0-f151.google.com [209.85.222.151]) by (Symantec Brightmail Gateway) with SMTP id E3.9C.27055.32FE7FA4; Mon, 9 Nov 2009 05:29:55 -0500 (EST) Received: by pzk15 with SMTP id 15so574467pzk.2 for ; Mon, 09 Nov 2009 02:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:from:to:subject:x-google-loop:date :mime-version:content-type; bh=ial3mMtqdC+1lk7ICw/BQuzukEHWwNbsU/OQmbBCNJc=; b=hHtNrC4ety+MlT1sb5ECSrb61yidXyOdJlx5VwRB7WvZgzksWcyzG+N/WMJra5tHt/ RyE/epWyIPZS860mMr+sqMnYGBpAx16LA3K7CJmeugfIdvlAtAXknXOhNSWKK5VXvk71 m168ckYg76p5ZS6vnwAxryCTy/fYRz3wv9BJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=from:to:subject:x-google-loop:date:mime-version:content-type; b=Ocxvc3lbSRKXyeyaenLKVQh+36SE0gyHDJJTsz2gtGul218ft1MszmIY9FBEVhCdfq KkjN6EdW7JyK80tqclX+bP5NuIFQK8HzbnYI/O8FxC51H+ivVEdx6ZZm81da6rpzcqR1 Cf+2CXxP3sZv304sc1Ki1qG5IRSi4SdSk4pTE= Received: by 10.114.5.14 with SMTP id 14mr231584wae.3.1257762594553; Mon, 09 Nov 2009 02:29:54 -0800 (PST) From: noreply@googlegroups.com To: secdir@mit.edu X-Google-Loop: sub_invite Date: Mon, 09 Nov 2009 10:29:54 +0000 Mime-Version: 1.0 X-Brightmail-Tracker: AAAABBGXKsERl9nHEZfp0RGYDoo= X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 09 Nov 2009 14:43:08 -0800 Subject: [secdir] Google Groups: You've been invited to IETF Smart Grid X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:29:59 -0000 Fred B fredbakersba@gmail.com has invited you to join the IETF Smart Grid group with this message: I set up a google group for smart grid discussions, notably that of Wednesday evening. Care to join? Here is the group's description: This is a temporary mailing list for organizing discussion of the IETF's possible Smart Grid efforts. One expects it to be replaced with a list@ietf. org at some point in the future. ---------------------- Google Groups Information ---------------------- You can accept this invitation by clicking the following URL: http://groups.google.com/group/ietf-smart-grid/sub?s=RugwzAwAAACumIhgvgGn_ORZb1Gybfvg&hl=en --------------------- If This Message Is Unwanted --------------------- If you feel that this message is abuse, please inform the Google Groups staff by using the URL below. http://groups.google.com/groups/abuse?invite=YgAAABuuaE3MAAAAClwLVv4AAAAAABC9R87zBgP8fg9Brqm4oudLT2k&hl=en _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From petithug@acm.org Mon Nov 9 10:29:29 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520AB3A6852; Mon, 9 Nov 2009 10:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ASldFbDAWMZ; Mon, 9 Nov 2009 10:29:27 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id D9E643A6774; Mon, 9 Nov 2009 10:29:27 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 57F9ADBCC0D0; Mon, 9 Nov 2009 18:29:53 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 86553DBCC0CE; Mon, 9 Nov 2009 18:29:52 +0000 (UTC) Message-ID: <4AF85F9F.4060407@acm.org> Date: Mon, 09 Nov 2009 10:29:51 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 Nov 2009 14:43:08 -0800 Cc: ops-dir@ietf.org, uri-review@ietf.org, "secdir@ietf.org" Subject: [secdir] End of Last Call for draft-ietf-behave-turn-uri X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:29:29 -0000 I just released a new version of this I-D incorporating all the modifications requested during Last Call: http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-turn-uri-04 There was only one major modification in this new version, which is the filtering of the list of preferred TURN transport when the scheme is "turns", to prevent the use an UDP or TCP transport in this case. The reference implementation was updated to reflect this and is available here: http://ietf.implementers.org/turn-uri-0.2.zip I made some proposals during the discussion that were never acknowledged, so here the list of them, this the modification made in the new version of the I-D: - Ted Hardie found confusing to reuse elements from the hierarchical URI syntax when the URI is opaque. No more guidance was provided[1], so I just added a sentence explaining this. - In the same thread, Ted Hardie pointed out that the text didn't explained clearly that the list of preferred transports was not an input for the TURN parser but for the resolution algorithm. The I-D was modified as proposed[1]. - Following the secdir review, Pasi Eronen requested some additional text to deal with TLS. The I-D was modified as proposed[2]. - Following the security bug discovered by Margaret Wasserman, I started a discussion[3] on the BEHAVE mailing-list asking if it was OK to be able to use a TLS transport even if a "turn:" scheme was used. There was no subsequent discussion on this, so the I-D now prevents to use a UDP or TCP transport if a "turns:" scheme is used, but does not prevent using a TLS transport if a "turn:" scheme is used. - Following the ops-dir review by Margaret Wasserman, I started a discussion[4] on the BEHAVE mailing-list for opinions on the implicit processing in the I-D. There was no subsequent discussion on this, so the implicit processing was not modified in the I-D. - The last iteration of the modifications[5] for the algorithms steps were integrated in the I-D. Here's the full changelog: o Improved the algorithm steps. o It is possible to use a TLS transport event if the scheme is turn:. o Clarified when to stop the resolution with an error in step 2. o Added transport list filtering process. o Improved security section following sec-dir review. o Fixed nits reported by gen-art review. o Added example for remote hosting. o Removed URIs section. o Editorial modification. Many thanks to all the reviewers. [1] http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=49076&tid=1257785026 [2] http://www.ietf.org/mail-archive/web/secdir/current/msg01205.html [3] http://www.ietf.org/mail-archive/web/behave/current/msg07289.html [4] http://www.ietf.org/mail-archive/web/behave/current/msg07292.html [5] http://www.ietf.org/mail-archive/web/behave/current/msg07314.html -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From Nicolas.Williams@sun.com Mon Nov 9 16:26:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7AA3A63EB; Mon, 9 Nov 2009 16:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.012 X-Spam-Level: X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+1wgRZTKz72; Mon, 9 Nov 2009 16:26:20 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 826AF3A677E; Mon, 9 Nov 2009 16:26:20 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAA0QlAb025965; Tue, 10 Nov 2009 00:26:47 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 nAA0Qk2N009000; Mon, 9 Nov 2009 17:26:46 -0700 (MST) 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 nAA07hOm012038; Mon, 9 Nov 2009 18:07:43 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAA07hsF012037; Mon, 9 Nov 2009 18:07:43 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 9 Nov 2009 18:07:43 -0600 From: Nicolas Williams To: ietf@ietf.org Message-ID: <20091110000743.GN1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Cc: jasnell@gmail.com, lisa.dusseault@gmail.com, secdir@ietf.org Subject: [secdir] secdir review of draft-dusseault-http-patch-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:26:21 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds a new verb to HTTP, "PATCH", for updating resources via diffs of some kind expressed as a MIME type. The security considerations of this document are reasonably complete. They deal primarily with the need to do virus detection after a patch is applied. I believe this document is ready, from a security point of view. Nico -- From Hannes.Tschofenig@gmx.net Mon Nov 9 17:22:54 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2BF3A68E0 for ; Mon, 9 Nov 2009 17:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V8+EJFrZAfk for ; Mon, 9 Nov 2009 17:22:53 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 50C8C3A6809 for ; Mon, 9 Nov 2009 17:22:53 -0800 (PST) Received: (qmail invoked by alias); 10 Nov 2009 01:23:17 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp011) with SMTP; 10 Nov 2009 02:23:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX182dwcn6PE210l4Xg6Gk54hskZxLc3sK5igKHazIK 5QCgsYamIr2LYV From: "Hannes Tschofenig" To: Date: Tue, 10 Nov 2009 10:26:32 +0900 Message-ID: <07d401ca61a4$d8491740$4a3e000a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcphpNW0dhH1mwcgT+aS4Ekfennm3A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [secdir] OAuth X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:22:54 -0000 Hi all, I spoke to Tim and Pasi about creating awareness for the work done by the identity management/OAuth community. For this purpose I have created a high-level slide set (see http://www.tschofenig.priv.at/oauth/OAuth-IETF76.ppt). I would like to give a short summary of the Oauth work at the SECDIR lunch and I hope to find some additional reviewers for the OAuth documents. Ciao Hannes From secdir-bounces@mit.edu Mon Nov 9 15:03:07 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785453A69D6 for ; Mon, 9 Nov 2009 15:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHUXFPQm2xlr for ; Mon, 9 Nov 2009 15:03:06 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 539263A69D9 for ; Mon, 9 Nov 2009 15:03:06 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id nA9N3W8T031917 for ; Mon, 9 Nov 2009 18:03:32 -0500 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 nA9N3Ut9031905 for ; Mon, 9 Nov 2009 18:03:30 -0500 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id nA9MwK2L029803 for ; Mon, 9 Nov 2009 18:03:24 -0500 (EST) X-AuditID: 1209190d-b7be3ae0000069a5-53-4af89fa5400c Received: from mail-yw0-f162.google.com (mail-yw0-f162.google.com [209.85.211.162]) by (Symantec Brightmail Gateway) with SMTP id 35.4D.27045.5AF98FA4; Mon, 9 Nov 2009 18:03:01 -0500 (EST) Received: by ywh34 with SMTP id 34so8399124ywh.2 for ; Mon, 09 Nov 2009 15:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:received:x-sender:x-apparently-to :received:received:received:received-spf:received:x-server-uuid :received:from:to:date:subject:thread-topic:thread-index:message-id :accept-language:content-language:x-ms-has-attach :x-ms-tnef-correlator:acceptlanguage:mime-version:x-wss-id :content-type:reply-to:sender:precedence:x-google-loop:mailing-list :list-id:list-post:list-help:list-unsubscribe:x-beenthere-env :x-beenthere; bh=xCjak+/5AqOspfYFN88NfkF7H0YVnyJ6hpwttaDkGtQ=; b=DuXfyUXlv2SpUyedgU9kYgnpvlvMNRZ28JoqEUu9eIdC0vRvxhEeVs/JNgEYrRJFzP BBo9MbdIAlxgyJg0QtDhslfbJbwXClOCBEkdkRELO+EEegeV+B6L8ghswuw+AGYrRKsW df8G8fe6f4JnGOR+oYOVtpALVwQmAk9kNP4rI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-sender:x-apparently-to:received-spf:authentication-results :x-server-uuid:from:to:date:subject:thread-topic:thread-index :message-id:accept-language:content-language:x-ms-has-attach :x-ms-tnef-correlator:acceptlanguage:mime-version:x-wss-id :content-type:reply-to:sender:precedence:x-google-loop:mailing-list :list-id:list-post:list-help:list-unsubscribe:x-beenthere-env :x-beenthere; b=ALEgS4gJ1Ob6QxfFTdmm5LwSfSUMsGcBH/bawmGxMMdsv1gtE7Ii9lDXWyfGD1PUZn 4FS/9Dgu0w98CG1y3JlsFYYnaPXB8zA4NpjKKDV8fk8MtON94kWvl/kIMzP49nu0sRPt X1AOcxZx7Eq1r8fV4bUdg65kXWMHq5BgTUsPM= Received: by 10.91.91.19 with SMTP id t19mr65623agl.33.1257807763778; Mon, 09 Nov 2009 15:02:43 -0800 (PST) Received: by 10.176.11.6 with SMTP id 6gr34yqk.0; Mon, 09 Nov 2009 15:02:29 -0800 (PST) X-Sender: davari@broadcom.com X-Apparently-To: ietf-smart-grid@googlegroups.com Received: by 10.224.116.5 with SMTP id k5mr554281qaq.19.1257807748604; Mon, 09 Nov 2009 15:02:28 -0800 (PST) Received: by 10.224.116.5 with SMTP id k5mr554277qaq.19.1257807747954; Mon, 09 Nov 2009 15:02:27 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by gmr-mx.google.com with ESMTP id 19si12130ywh.10.2009.11.09.15.02.27; Mon, 09 Nov 2009 15:02:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of davari@broadcom.com designates 216.31.210.19 as permitted sender) client-ip=216.31.210.19; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of davari@broadcom.com designates 216.31.210.19 as permitted sender) smtp.mail=davari@broadcom.com Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 09 Nov 2009 15:02:11 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 9 Nov 2009 15:02:11 -0800 From: "Shahram Davari" To: "ietf-smart-grid@googlegroups.com" Date: Mon, 9 Nov 2009 15:02:09 -0800 Thread-Topic: What aspects of smart-grid is in scope? Thread-Index: AcphkKqedSSwDHqdQdSRXVL+ghqbOA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815771A00F@SJEXCHCCR02.corp.ad.broadcom.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-WSS-ID: 66E640F93J83778433-01-01 Precedence: bulk X-Google-Loop: groups Mailing-List: list ietf-smart-grid@googlegroups.com; contact ietf-smart-grid+owner@googlegroups.com X-BeenThere-Env: ietf-smart-grid@googlegroups.com X-BeenThere: ietf-smart-grid@googlegroups.com X-Brightmail-Tracker: AAAABBGXKsERlzcDEZfZwBGX6dE= X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Content-Type: multipart/mixed; boundary="===============1591228686==" Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 09 Nov 2009 19:16:55 -0800 Subject: [secdir] What aspects of smart-grid is in scope? X-BeenThere: secdir@ietf.org Reply-To: ietf-smart-grid@googlegroups.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 23:03:07 -0000 --===============1591228686== Content-Language: en-US Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6815771A00FSJEXCHCCR02co_ --_000_2C2F1EBA8050E74EA81502D5740B4BD6815771A00FSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I am new to this list, so please accept my apology if this has been already= discussed. As far as I know smart grid has many components. One is as you = have discussed the smart meters and actuators for users. However, an equall= y important part of smart-grid is the substation monitoring and automatic c= ontrol. There are specific requirements in that area such as fast fail-over= , zero-packet loss, security, outdoor fanless operation, Electromagnetic in= terference, remote access, remote monitoring and fast remote action trigger= , etc. I just want to understand are these in scope of this group and whether it h= as been discussed? Thanks, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD6815771A00FSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi,
 
I am new = to this=20 list, so please accept my apology if this has been already discussed. As fa= r as=20 I know smart grid has many components. One is as you have discussed the sma= rt=20 meters and actuators for users. However, an equally important part of smart= -grid=20 is the substation monitoring and automatic control. There are specific=20 requirements in that area such as fast fail-over, zero-packet loss, securit= y,=20 outdoor fanless operation, Electromagnetic interference, remote access,=20 remote monitoring and fast remote action trigger, etc.
 
I just wa= nt to=20 understand are these in scope of this group and whether it has been=20 discussed?
 
Thanks,
Shahram
--_000_2C2F1EBA8050E74EA81502D5740B4BD6815771A00FSJEXCHCCR02co_-- --===============1591228686== 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 --===============1591228686==-- From secdir-bounces@mit.edu Mon Nov 9 19:11:45 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558BA28C0EA for ; Mon, 9 Nov 2009 19:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, X_IP=3.177] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niDuglI7NVW5 for ; Mon, 9 Nov 2009 19:11:43 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 0F3D328C0D7 for ; Mon, 9 Nov 2009 19:11:42 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id nAA3C9PO010151 for ; Mon, 9 Nov 2009 22:12:09 -0500 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 nAA3C87Y010148 for ; Mon, 9 Nov 2009 22:12:08 -0500 Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id nAA3BiB0000122 for ; Mon, 9 Nov 2009 22:12:13 -0500 (EST) X-AuditID: 1209190e-b7b50ae000006a07-43-4af8d9f0d516 Received: from mail-yx0-f163.google.com (mail-yx0-f163.google.com [209.85.210.163]) by (Symantec Brightmail Gateway) with SMTP id 66.20.27143.0F9D8FA4; Mon, 9 Nov 2009 22:11:44 -0500 (EST) Received: by yxe35 with SMTP id 35so8846201yxe.2 for ; Mon, 09 Nov 2009 19:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:received:x-sender:x-apparently-to :mime-version:received:date:in-reply-to:x-ip:references:user-agent :x-http-useragent:message-id:subject:from:to:content-type:reply-to :sender:precedence:x-google-loop:mailing-list:list-id:list-post :list-help:list-unsubscribe:x-beenthere-env:x-beenthere; bh=RGV2N4emWNrzM+HEP9KLi8LuINT1dXNjlSMZZzspU/I=; b=ZxnSxq+8u4au0ODTOMQ4wVZFSAR+t3ySTS/CVOKzfGmrNwUFVlFj7bDqxBN49heglk 4J46ep3ziOrW+Ufk3qFLoo3oM+/ntqYdvk+ZS0TXXtQfyf4CDDCn9vXwg5LJ/oac/9WW xfRRPjCWmGEO1ch47D49J8rFIg/aRqs4XVt3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-sender:x-apparently-to:mime-version:date:in-reply-to:x-ip :references:user-agent:x-http-useragent:message-id:subject:from:to :content-type:reply-to:sender:precedence:x-google-loop:mailing-list :list-id:list-post:list-help:list-unsubscribe:x-beenthere-env :x-beenthere; b=cPsvIjksFNuIv+z7mu3TTle/42g/zqUOGbqMOV3q4gSkdJk0WxkGTWNU0ig1762YF9 vBHwA2Be1VMjND0yamokVaX3TqK3trNZSdcf69uiQpW29xcXQMSIiKI+j8qwh/Uk3j6y y+82M88pcK6b3y6Of99bJuuOhEloG5YxqCx20= Received: by 10.90.10.19 with SMTP id 19mr108581agj.9.1257822704317; Mon, 09 Nov 2009 19:11:44 -0800 (PST) Received: by 10.176.235.29 with SMTP id i29gr41yqh.0; Mon, 09 Nov 2009 19:11:35 -0800 (PST) X-Sender: sant9442@gmail.com X-Apparently-To: ietf-smart-grid@googlegroups.com MIME-Version: 1.0 Received: by 10.150.39.39 with SMTP id m39mr31908ybm.9.1257822694922; Mon, 09 Nov 2009 19:11:34 -0800 (PST) Date: Mon, 9 Nov 2009 19:11:34 -0800 (PST) In-Reply-To: <4AF84BC2.7040606@tana.it> X-IP: 99.3.147.93 References: <4AF8447D.4010905@santronics.com> <4AF84BC2.7040606@tana.it> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 (.NET CLR 3.5.30729),gzip(gfe),gzip(gfe) Message-ID: From: Hector Santos To: IETF Smart Grid Precedence: bulk X-Google-Loop: groups Mailing-List: list ietf-smart-grid@googlegroups.com; contact ietf-smart-grid+owner@googlegroups.com X-BeenThere-Env: ietf-smart-grid@googlegroups.com X-BeenThere: ietf-smart-grid@googlegroups.com X-Brightmail-Tracker: AAAABBGXKsERly2FEZfZvxGX6dE= X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 09 Nov 2009 19:16:55 -0800 Subject: Re: [secdir] Some observations that may be of interest X-BeenThere: secdir@ietf.org Reply-To: ietf-smart-grid@googlegroups.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:11:45 -0000 On Nov 9, 12:05 pm, Alessandro Vesely wrote: > Hector Santos wrote: > There is a difference between sharing information and being battery > farmed. However big that difference may seem, it is also subtle. I'm > not sure how much the people are willing to discern between industry > goals and their own, world's citizens goals. We need that distinction, > for the sake of democracy. I think the Privacy Impact Assessment > should be thoroughly carried out and result in policy recommendations > aimed at enabling users to share what they deem correct, with no > penalizations nor forcing. +1, the concern I have is the level of vendor PIA compliance and will there be a consumer choice? I mean, its not like the customer really has a choose in agreeing with a home energy TOS :) Unless of course, with the Smart Grid comes energy provider competition (Enron anyone?) and collusion isn't an issue. Catching up with some of IETF draft documents, what came to mind is maybe a possible need to provide a set of Smart Grid Device (SGD) design principles. Half joking, I came up with: First law of Smart Grid Dynamics: Smart Grid Devices (SGD) must not create nor consume more energy than it is designed to save or optimize. So if a vendor device is doing much more than it is required for "Smart Grid", this distinction can possible serve as a basis of separation for PII (Persionally Identifable Information) user optional feedback. We might also wish to develop a way to measure the impact of application level SGDs which might lead to: Second law of Smart Grid Dynamics: Smart Grid Devices (SGD) must not create entropy in the network. That might suggest to not be overzealous with message notification ideas. -- HLS _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From stefan@aaa-sec.com Mon Nov 9 19:39:58 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9732A3A685B for ; Mon, 9 Nov 2009 19:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_20=-0.74, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK13wC38ao6p for ; Mon, 9 Nov 2009 19:39:57 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.94.111]) by core3.amsl.com (Postfix) with ESMTP id 7BB3E3A6824 for ; Mon, 9 Nov 2009 19:39:56 -0800 (PST) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5F4B729C612 for ; Tue, 10 Nov 2009 04:40:04 +0100 (CET) Received: (qmail 89078 invoked from network); 10 Nov 2009 03:40:03 -0000 Received: from host-19-9.meeting.ietf.org (HELO [133.93.19.9]) (stefan@fiddler.nu@[133.93.19.9]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Nov 2009 03:40:03 -0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 10 Nov 2009 12:39:57 +0900 From: Stefan Santesson To: Message-ID: Thread-Topic: Null Prefix attack Thread-Index: Acpht3j5dYMFmcJzXEaLaISDJJBFDw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [secdir] Null Prefix attack X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:39:58 -0000 Referring to the discussion at the Secdir lunch today. Here is a link to the document describing the attack: http://thoughtcrime.org/papers/null-prefix-attacks.pdf Article on the subject: http://www.theregister.co.uk/2009/10/05/fraudulent_paypay_certificate_publis hed/ /Stefan From ted.ietf@gmail.com Mon Nov 9 19:55:42 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134593A6A24; Mon, 9 Nov 2009 19:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+BTpyiPcukW; Mon, 9 Nov 2009 19:55:40 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id CD1B63A6921; Mon, 9 Nov 2009 19:55:40 -0800 (PST) Received: by pwi6 with SMTP id 6so836211pwi.29 for ; Mon, 09 Nov 2009 19:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pL/JMaaLqHVvBSLnlPp3rrDykABUoN1hAdFwC6MrP6M=; b=OM2Q9YoLtRJjlYuPOrZXo1+hVLnZLVM24Q+oqbr4zx5HWtdICX7SkLvsYGi3IoQyzE EcPZUyNNGwVFXecPwqry5LWR00er/93PE6WX3EYUxRfV8ZRv797jMXBRcTsnBcL9vwW7 JR0B3IS/r4zCa+P4lW7L3Q1F4l8EfGWqH7VM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xJ70Hub4j+pCpjgtyY3fstoGIxU7X5EfYnXHH/wg63ZhtZuhcTr7aIiQ/C/VdQqM68 qJhKDLnmBBz2zIvcVzfo4hDbqGP5oU1c3r8A+hsTguwF90o1RngKl2cwhJFUqhFt68Sy n6ivVw5jNP3L8rpZPrWD16MWp/A8fXp1+1WMc= MIME-Version: 1.0 Received: by 10.143.137.2 with SMTP id p2mr860756wfn.136.1257825363463; Mon, 09 Nov 2009 19:56:03 -0800 (PST) In-Reply-To: <4AF85F9F.4060407@acm.org> References: <4AF85F9F.4060407@acm.org> Date: Mon, 9 Nov 2009 19:56:03 -0800 Message-ID: <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> From: Ted Hardie To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 09 Nov 2009 20:10:45 -0800 Cc: ops-dir@ietf.org, "behave@ietf.org" , uri-review@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Uri-review] End of Last Call for draft-ietf-behave-turn-uri X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:55:42 -0000 Hi Marc, Thanks for the changes; I thought you had suggested using new productions, rather than re-using the existing ones from the hierarchical URI mechanism. Sorry if I did not reply on that--I think that would be a good idea, but if there is rough consensus for the current approach, I am happy to go along. regards, Ted Hardie On Mon, Nov 9, 2009 at 10:29 AM, Marc Petit-Huguenin wro= te: > I just released a new version of this I-D incorporating all the modificat= ions > requested during Last Call: > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-turn-uri-04 > > > There was only one major modification in this new version, which is the > filtering of the list of preferred TURN transport when the scheme is "tur= ns", to > prevent the use an UDP or TCP transport in this case. =A0The reference > implementation was updated to reflect this and is available here: > > http://ietf.implementers.org/turn-uri-0.2.zip > > > I made some proposals during the discussion that were never acknowledged,= so > here the list of them, this the modification made in the new version of t= he I-D: > > - Ted Hardie found confusing to reuse elements from the hierarchical URI = syntax > when the URI is opaque. =A0No more guidance was provided[1], so I just ad= ded a > sentence explaining this. > > - In the same thread, Ted Hardie pointed out that the text didn't explain= ed > clearly that the list of preferred transports was not an input for the TU= RN > parser but for the resolution algorithm. =A0The I-D was modified as propo= sed[1]. > > - Following the secdir review, Pasi Eronen requested some additional text= to > deal with TLS. =A0The I-D was modified as proposed[2]. > > - Following the security bug discovered by Margaret Wasserman, I started = a > discussion[3] on the BEHAVE mailing-list asking if it was OK to be able t= o use a > TLS transport even if a "turn:" scheme was used. =A0There was no subseque= nt > discussion on this, so the I-D now prevents to use a UDP or TCP transport= if a > "turns:" scheme is used, but does not prevent using a TLS transport if a = "turn:" > scheme is used. > > - Following the ops-dir review by Margaret Wasserman, I started a discuss= ion[4] > on the BEHAVE mailing-list for opinions on the implicit processing in the= I-D. > There was no subsequent discussion on this, so the implicit processing wa= s not > modified in the I-D. > > - The last iteration of the modifications[5] for the algorithms steps wer= e > integrated in the I-D. > > > Here's the full changelog: > > =A0 o =A0Improved the algorithm steps. > =A0 o =A0It is possible to use a TLS transport event if the scheme is > =A0 =A0 =A0turn:. > =A0 o =A0Clarified when to stop the resolution with an error in step 2. > =A0 o =A0Added transport list filtering process. > =A0 o =A0Improved security section following sec-dir review. > =A0 o =A0Fixed nits reported by gen-art review. > =A0 o =A0Added example for remote hosting. > =A0 o =A0Removed URIs section. > =A0 o =A0Editorial modification. > > > Many thanks to all the reviewers. > > > [1] http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D933&k2=3D4= 9076&tid=3D1257785026 > [2] http://www.ietf.org/mail-archive/web/secdir/current/msg01205.html > [3] http://www.ietf.org/mail-archive/web/behave/current/msg07289.html > [4] http://www.ietf.org/mail-archive/web/behave/current/msg07292.html > [5] http://www.ietf.org/mail-archive/web/behave/current/msg07314.html > > -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > _______________________________________________ > Uri-review mailing list > Uri-review@ietf.org > https://www.ietf.org/mailman/listinfo/uri-review > From secdir-bounces@mit.edu Tue Nov 10 00:16:55 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD35A3A697F for ; Tue, 10 Nov 2009 00:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.572 X-Spam-Level: X-Spam-Status: No, score=-4.572 tagged_above=-999 required=5 tests=[AWL=2.027, 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 PNr-VszdemIk for ; Tue, 10 Nov 2009 00:16:55 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id F30473A695C for ; Tue, 10 Nov 2009 00:16:54 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id nAA8HLVc025509 for ; Tue, 10 Nov 2009 03:17:21 -0500 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 nAA8HIxJ025500 for ; Tue, 10 Nov 2009 03:17:18 -0500 Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id nAA8ERWc003079 for ; Tue, 10 Nov 2009 03:17:10 -0500 (EST) X-AuditID: 12074423-b7c05ae000006913-b6-4af921749f38 Received: from mail-pz0-f194.google.com (mail-pz0-f194.google.com [209.85.222.194]) by (Symantec Brightmail Gateway) with SMTP id 75.80.26899.47129FA4; Tue, 10 Nov 2009 03:16:52 -0500 (EST) Received: by pzk32 with SMTP id 32so3058567pzk.21 for ; Tue, 10 Nov 2009 00:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=xHM2NQ/J1QekJ4pvZeZdoHBqFcLBvczvSCIzg/VHXe0=; b=AGUDT+c9D7yhxiJMB/MXQR56Tubc1oXPQgX2faw4MI3ClAp4UXrSoIi5RDRbEX7sOu XPCDfTXq3jt/Fco4xNHOKIjf5BXI0a2YgI36bFWkgh/uJa1/bZOafOqhGgF5DNXkVW+d aAMKWVUpQvCHQEq4NdKM13TCB0vUXEeK/pIag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=BFsMar0KTisxjBtzMzmzdmuk9rE/R6k9MBBZrEMMIMqDiI0tc/WIVc4jVUH524evbR 9cm5We+qVExxVCFN6NlJ/M0eA/zEfY6W1PkgrwRlze6U/VFjDe614kmzyipg+tbYEBKJ /ek0nVqrXIYkAhQTRwZYQxjiLEzqyDEPXcGV4= MIME-Version: 1.0 Received: by 10.140.136.15 with SMTP id j15mr481679rvd.229.1257841012011; Tue, 10 Nov 2009 00:16:52 -0800 (PST) In-Reply-To: <200911091030.nA9ASPlB029736@fort-point-station.mit.edu> References: <200911091030.nA9ASPlB029736@fort-point-station.mit.edu> Date: Tue, 10 Nov 2009 03:16:51 -0500 Message-ID: <6c9fcc2a0911100016u139f20b8ke1efa89c3409a55d@mail.gmail.com> From: Barry Leiba To: secdir@mit.edu X-Brightmail-Tracker: AAAAAxGXKsERl9nHEZfp0Q== X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: Re: [secdir] Google Groups: You've been invited to IETF Smart Grid X-BeenThere: secdir@ietf.org Reply-To: barryleiba@computer.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:16:55 -0000 > I set up a google group for smart grid discussions, notably that of Wednesday > evening. Care to join? Oh, geez, can we unsubscribe the secdir list from this? Individuals should subscribe as they like, but we should NOT have the secdir mailing list subscribed to it! Barry _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Nov 10 01:05:34 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02B028C127 for ; Tue, 10 Nov 2009 01:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 VO1bG2QYCtIZ for ; Tue, 10 Nov 2009 01:05:33 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id B683F28C13D for ; Tue, 10 Nov 2009 01:05:33 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id nAA960TC002535 for ; Tue, 10 Nov 2009 04:06:00 -0500 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 nAA95o4G002457 for ; Tue, 10 Nov 2009 04:05:50 -0500 Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id nAA959g7005650 for ; Tue, 10 Nov 2009 04:05:51 -0500 (EST) X-AuditID: 12074423-b7c05ae000006913-de-4af92cd36df6 Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by (Symantec Brightmail Gateway) with SMTP id 62.51.26899.3DC29FA4; Tue, 10 Nov 2009 04:05:23 -0500 (EST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nAA951XU005711; Tue, 10 Nov 2009 04:05:08 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 10 Nov 2009 04:04:54 -0500 From: "Polk, William T." To: "barryleiba@computer.org" , "secdir@mit.edu" Date: Tue, 10 Nov 2009 04:03:51 -0500 Thread-Topic: [secdir] Google Groups: You've been invited to IETF Smart Grid Thread-Index: Acph3lDvdREM3lWOT6e4gFFr4zfm8QABmdfv Message-ID: References: <200911091030.nA9ASPlB029736@fort-point-station.mit.edu>, <6c9fcc2a0911100016u139f20b8ke1efa89c3409a55d@mail.gmail.com> In-Reply-To: <6c9fcc2a0911100016u139f20b8ke1efa89c3409a55d@mail.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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Brightmail-Tracker: AAAAAA== X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id nAA95o4G002457 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: Re: [secdir] Google Groups: You've been invited to IETF Smart Grid X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:05:34 -0000 That was a mistake all the way around... but it was rectified quickly. Sorry about that. Tim ________________________________________ From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] On Behalf Of Barry Leiba [barryleiba.mailing.lists@gmail.com] Sent: Tuesday, November 10, 2009 3:16 AM To: secdir@mit.edu Subject: Re: [secdir] Google Groups: You've been invited to IETF Smart Grid > I set up a google group for smart grid discussions, notably that of Wednesday > evening. Care to join? Oh, geez, can we unsubscribe the secdir list from this? Individuals should subscribe as they like, but we should NOT have the secdir mailing list subscribed to it! 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 _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Nov 10 06:19:50 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C0C3A6973 for ; Tue, 10 Nov 2009 06:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCLreDjm1YH2 for ; Tue, 10 Nov 2009 06:19:49 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 93A733A67A1 for ; Tue, 10 Nov 2009 06:19:49 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id nAAEKDVp009734 for ; Tue, 10 Nov 2009 09:20:13 -0500 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 nAAEK1Dq009663 for ; Tue, 10 Nov 2009 09:20:01 -0500 Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id nAAEJen9010433 for ; Tue, 10 Nov 2009 09:19:50 -0500 (EST) X-AuditID: 12074423-b7c05ae000006913-8a-4af9767321aa Received: from ey-out-1920.google.com (ey-out-1920.google.com [74.125.78.147]) by (Symantec Brightmail Gateway) with SMTP id C2.B9.26899.37679FA4; Tue, 10 Nov 2009 09:19:31 -0500 (EST) Received: by ey-out-1920.google.com with SMTP id 26so19762eyw.6 for ; Tue, 10 Nov 2009 06:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fEfzPiwA1AlEGwkhcJ+n4Geo141EU+hTRTb3NWA4RlQ=; b=Yid6JiZLVWGYBB3H+Nt5qeP3d+p6KIR6TpKY6WF272xtFqtXFv/hecqSgh9YMHOp+x NgDTzyk9vZkoRilcov99TvZKzpyk52ijjHWFbZLgS3KupVi5EgI3qF47R0bHnq2tAxDG z4l2pkaexxj870q3WXRWTF1vvJTTTTimTohYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cNnPlEojXGVuePDaR90IPKQUmouKfSmHfO/qgoOEwuER1zFVjhVWhtokBdw4uvVszP Lx0tBZWGurvPkMc873e6+82pedcCeVPwhqC5FlEpuw/SK1fCyx/DHF7MUgE/v23diI5+ Oebi81ALuo0wC4xhQurMOYU9x6Cw37TmtoDYM= MIME-Version: 1.0 Received: by 10.216.86.85 with SMTP id v63mr42580wee.32.1257862770625; Tue, 10 Nov 2009 06:19:30 -0800 (PST) In-Reply-To: <6c9fcc2a0911100016u139f20b8ke1efa89c3409a55d@mail.gmail.com> References: <200911091030.nA9ASPlB029736@fort-point-station.mit.edu> <6c9fcc2a0911100016u139f20b8ke1efa89c3409a55d@mail.gmail.com> Date: Tue, 10 Nov 2009 09:19:30 -0500 Message-ID: <1028365c0911100619w583833b8v2b846ca06848e6a1@mail.gmail.com> From: Donald Eastlake To: barryleiba@computer.org X-Brightmail-Tracker: AAAAARGX6dA= X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: multipart/mixed; boundary="===============2025151753==" Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: secdir@mit.edu Subject: Re: [secdir] Google Groups: You've been invited to IETF Smart Grid X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 14:19:50 -0000 --===============2025151753== Content-Type: multipart/alternative; boundary=0016e6d9a0579e8c87047804ff83 --0016e6d9a0579e8c87047804ff83 Content-Type: text/plain; charset=ISO-8859-1 Yes. I signed up for the group and was getting too many message, which I thought were being sent to a separate list and clicked on the gmail unsubscribe button, which was presumably available due to mailing list headers, and found that it was trying to unsubscribe me from secdir, which I certainly didn't want. Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Nov 10, 2009 at 3:16 AM, Barry Leiba < barryleiba.mailing.lists@gmail.com> wrote: > > I set up a google group for smart grid discussions, notably that of > Wednesday > > evening. Care to join? > > Oh, geez, can we unsubscribe the secdir list from this? Individuals > should subscribe as they like, but we should NOT have the secdir > mailing list subscribed to it! > > 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 > --0016e6d9a0579e8c87047804ff83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes. I signed up for the group and was getting too many message, which I th= ought were being sent to a separate list and clicked on the gmail unsubscri= be button, which was presumably available due to mailing list headers, and = found that it was trying to unsubscribe me from secdir, which I certainly d= idn't want.

Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Donald E. Eastlake = 3rd =A0 +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 = USA
d3e3e3@gmail.com


On Tue, Nov 10, 2009 at 3:16 AM, Barry L= eiba <barryleiba.mailing.lists@gmail.com> wrote:
> I set up a google group for smart grid discussions, = notably that of Wednesday
> evening. Care to join?

Oh, geez, can we unsubscribe the secdir list from this? =A0Individual= s
should subscribe as they like, but we should NOT have the secdir
mailing list subscribed to it!

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

--0016e6d9a0579e8c87047804ff83-- --===============2025151753== 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 --===============2025151753==-- From Shouichi.Sakane@jp.yokogawa.com Tue Nov 10 15:41:55 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6936D3A6904; Tue, 10 Nov 2009 15:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ADZkGSq0kqE; Tue, 10 Nov 2009 15:41:54 -0800 (PST) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by core3.amsl.com (Postfix) with ESMTP id 2780B3A6782; Tue, 10 Nov 2009 15:41:54 -0800 (PST) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id nAANgKDF016206; Wed, 11 Nov 2009 08:42:20 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id nAANgJJo016203; Wed, 11 Nov 2009 08:42:20 +0900 (JST) Received: from EXMAIL03.jp.ykgw.net ([10.0.11.29]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Wed, 11 Nov 2009 08:42:19 +0900 From: To: , , , Date: Wed, 11 Nov 2009 08:40:21 +0900 Thread-Topic: secdir review of draft-ietf-krb-wg-cross-problem-statement-04 Thread-Index: AcpI+qkS8jP8gG3tQPe3IferT5xYbQZZIIJP Message-ID: <50AE88406D015A4F827FB4F7E361C6E4C0C92969C0@EXMAIL03.jp.ykgw.net> References: In-Reply-To: Accept-Language: en-US, ja-JP Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 10 Nov 2009 17:35:23 -0800 Subject: Re: [secdir] secdir review of draft-ietf-krb-wg-cross-problem-statement-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:41:55 -0000 Stephan, First of all, I apologize that my response is too late. I was noticed that Tim requested me to make any response to your message during the IETF meeting. But, I haven't seen your mail. I found your mail at my spam mail box, which my company's stupid mail system automatically dispatched. I apologize again. Most of your suggestion and correction is fixed in revision 05. I attached it to this mail in case. My response is in-line. > I reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by > the IESG. These comments were written primarily for the benefit > of the security area directors. Document editors and WG chairs > should treat these comments just like any other last call comments. > I apologize for submitting these comments late. > > This document describes issues that arise during Kerberos > cross-realm operation, especially those related to two > desired uses of cross-realm Kerberos at Shell. > > I am not a Kerberos expert although I am fairly familiar > with the operation of the protocol. I know a good deal > about multi-domain security since I did research in that > area for several years at Sun (although mainly with PKI). > > Since this is a working group draft from the Kerberos WG, > I assume that the document has passed WGLC and therefore > represents WG consensus. However, I have some concerns. > > My main concern is that the document seems to be based > mainly on the experiences of one customer. Surely there > must be many more customers that have used cross-realm > Kerberos over the years. If they have run into issues, > those should be reflected in the document. If they have > not had problems, then I would suggest that the issues > are very limited in scope and probably no remedies are > needed. We need to consider what's best for the Internet > as a whole, not just one customer. I agree with that we must consider to adopt technology to a whole. The reason why I describe two *examples* is to help for readers who live in typical networks, not in the industry control networks or building automation networks, which consist of sensors, actuators or non-large bandwidth link. The document just describes two types of networks. I believe that the krb WG got a consensus that the requirements in this document are enough to describe the requirements of a whole of the Internet. That is why the document was passed to the WGLC. > Here are my more detailed comments: >=20 > There is an extra period in the third paragraph of > section 1 between "to" and "and". > In section 2.1, "limited limit" should be "limited time" > and "consists on" should be "consists of" (twice). Also > "user access" should be "user accesses". And "anytime" > should be "at all times". > > In section 3, after "sub systems", you need a period > not a comma. The phrase "control center" should be "control > centers". And "each is named" should be "each one called a". > Also, "connected each other" should be "connected to each > other". "In the both" should be "in both". Most of your corrections are fixed in revision 05. In the last correction from you, I changed to "In the both examples" rather than "In both of the systems". Do you agree with that ? Whole text is below: In the both examples, the end devices are basically connected to a local network by a twisted pair cable, with a low band-width of 32 kbps. > In section 3, I suggest replacing this text: >=20 > Because there is a requirement of the explosion-proof. The > requirement restricts the amount of total energy in the device. >=20 > with this text: >=20 > These adjustments restrict the amount of total energy in > the device, thereby reducing the risk of explosions. Thank you. I will merge it into new version. > Also, I suggest clarification of this text: >=20 > If it took > time for data to reach, they could not be associated. The travel > time of data from the device to the other device is demanded within 1 > second at least. >=20 > I think the authors may mean this: >=20 > In order for one device to control another, the time required > for data to travel between the devices cannot be more than > one second. I changed to the following in revision 05. If it takes time for data to travel through the network, normal operations can not be ensured. The travel time of data from a device to another device in the both examples must be within 1 second at most. > The requirements are not really demonstrated from the text above. > For example, R-1 says: >=20 > R-1 It is necessary to partition a management domain into some > domains. Or it is necessary to delegate a management authority > to another independent management domain. >=20 > Maybe this is required due to time constraints (the less than one > second rule), which lead to latency or performance issues if a > single KDC is used. Maybe it is required due to a lack of trust > between the entities responsible for managing the domains. The > reason for this requirement is not explained so it is not > compelling. Agreed. I changed R-1 in revision 05 like the following: R-1 For organizational reasons and scalability needs, a management domain typically must be partitioned into two or more sub- domains of management. Therefore, any architecture and implementation solution to the Kerberos cross-realm problem must (i) support the case of cross-realm operations across multiple management domains and (ii) support delegation of management authority from one domain to another management domain. This must be performed without any decrease in the security level or quality of those cross-realm operations and must not expose Kerberos entities to new types of attacks. > Similarly, the rationale for R-2 is not described clearly. > Couldn't two organizations manage a single Kerberos domain? What I am saying here was that two different organizations managing different Kerberos domains need to co-exist on the same network. In revision 05, R-2 is changed into the following: R-2 Any architecture and implementation solution to the Kerberos cross-realm problem must support the co-existence of multiple independent management domains on the same network. Furthermore, it must allow organizations (corresponding to different management domains) to delegate the management of a part of or the totality of their system at any one time. > The issue described in section 5.1 seems to be fundamental > to the way that cross-realm operations are performed in > Kerberos. If intermediary realms are involved then they need > to be trusted. The edge of the realm doesn't always know the relationship of other realms on the path of the chain. Some relationships in the path may be weaker than the both ends are supposing. > One could address this problem by not having > intermediate realms (fully connecting all realms) but this > would require many shared keys and therefore not scale well. > > The issue described in section 5.3 is valid but it has not > been demonstrated that a direct trust model is needed. The 5.3 specifies that there is an issue to reduce maintenance cost of the direct trust model. Regards, =3D=3D=3D Shoichi Sakane From Shouichi.Sakane@jp.yokogawa.com Tue Nov 10 15:48:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F183A68DE; Tue, 10 Nov 2009 15:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P5GllP+DB3u; Tue, 10 Nov 2009 15:48:21 -0800 (PST) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by core3.amsl.com (Postfix) with ESMTP id 23FB43A6904; Tue, 10 Nov 2009 15:48:21 -0800 (PST) Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id nAANmmW5006326; Wed, 11 Nov 2009 08:48:48 +0900 (JST) Received: from zex001-0m9025.jp.ykgw.net (zex001-0m9025.jp.ykgw.net [10.0.11.44]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id nAANmmeB006323; Wed, 11 Nov 2009 08:48:48 +0900 (JST) Received: from EXMAIL03.jp.ykgw.net ([10.0.11.29]) by zex001-0m9025.jp.ykgw.net ([10.0.11.44]) with mapi; Wed, 11 Nov 2009 08:48:47 +0900 From: To: , , , Date: Wed, 11 Nov 2009 08:46:30 +0900 Thread-Topic: secdir review of draft-ietf-krb-wg-cross-problem-statement-04 Thread-Index: AcpI+qkS8jP8gG3tQPe3IferT5xYbQZZIIJPAAA29i8= Message-ID: <50AE88406D015A4F827FB4F7E361C6E4C0C92969C1@EXMAIL03.jp.ykgw.net> References: , <50AE88406D015A4F827FB4F7E361C6E4C0C92969C0@EXMAIL03.jp.ykgw.net> In-Reply-To: <50AE88406D015A4F827FB4F7E361C6E4C0C92969C0@EXMAIL03.jp.ykgw.net> Accept-Language: en-US, ja-JP Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 10 Nov 2009 17:35:23 -0800 Subject: Re: [secdir] secdir review of draft-ietf-krb-wg-cross-problem-statement-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:48:22 -0000 > Most of your suggestion and correction is fixed in revision 05. > I attached it to this mail in case. I am sorry. I forgot to attach revision 05 to my previous mail. I will send it to Stephan directly in another mail.= From petithug@acm.org Thu Nov 12 09:56:50 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCAF3A697F; Thu, 12 Nov 2009 09:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.694 X-Spam-Level: X-Spam-Status: No, score=-101.694 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYzTLimf5dE2; Thu, 12 Nov 2009 09:56:50 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id ED81D3A693E; Thu, 12 Nov 2009 09:56:49 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id D3293DC0409C; Thu, 12 Nov 2009 17:57:18 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id E124DDC0409A; Thu, 12 Nov 2009 17:57:17 +0000 (UTC) Message-ID: <4AFC4C7D.4040801@acm.org> Date: Thu, 12 Nov 2009 09:57:17 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Ted Hardie References: <4AF85F9F.4060407@acm.org> <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> In-Reply-To: <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 12 Nov 2009 14:30:29 -0800 Cc: ops-dir@ietf.org, "behave@ietf.org" , uri-review@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Uri-review] End of Last Call for draft-ietf-behave-turn-uri X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 17:56:50 -0000 Hi Ted, Ted Hardie wrote: > Hi Marc, > > Thanks for the changes; I thought you had suggested using new > productions, rather than re-using the existing ones from the > hierarchical > URI mechanism. Sorry if I did not reply on that--I think that would > be a good idea, but if there is rough consensus for the current approach, > I am happy to go along. > OK I'll replace the following text: " turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] scheme = "turn" / "turns" transport = "udp" / "tcp" / transport-ext transport-ext = 1*unreserved , and are specified in [RFC3986]. Note that the usage of components defined in the [RFC3986] as part of a generic hierarchical URI does not mean that a TURN/TURNS URI is hierarchical." by this text: " turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] scheme = "turn" / "turns" transport = "udp" / "tcp" / transport-ext transport-ext = 1*unreserved host = IP-literal / IPv4address / reg-name port = *DIGIT IP-literal = "[" ( IPv6address / IPvFuture ) "]" IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) IPv6address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" h16 = 1*4HEXDIG ls32 = ( h16 ":" h16 ) / IPv4address IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 reg-name = *( unreserved / pct-encoded / sub-delims ) and are specified in [RFC3986]." I will also add this in the Acknowledgments section: "The and ABNF productions have been copied from [RFC3986]." If I do not receive any subsequent comment on this, this text will be in the next revision of the document, to be released Tuesday 17th. Thanks. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From weiler+secdir@watson.org Sun Nov 15 13:26:53 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2963A6A02 for ; Sun, 15 Nov 2009 13:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJRfmqW7BKSe for ; Sun, 15 Nov 2009 13:26:52 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 2E8803A6765 for ; Sun, 15 Nov 2009 13:26:51 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nAFLQodS011380 for ; Sun, 15 Nov 2009 16:26:50 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nAFLQoZJ011377 for ; Sun, 15 Nov 2009 16:26:50 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 15 Nov 2009 16:26:50 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Sun, 15 Nov 2009 16:26:50 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 21:26:53 -0000 Several new items, but the telechat list for this coming week is still unchanged. Alan DeKok is next in the rotation. Please try to complete last call reviews by the end of the last call. For documents on telechat, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-11-19 Reviewer Deadline Draft Chris Newman T 2009-11-17 draft-ietf-forces-sctptml-06 Stefan Santesson TR2009-11-17 draft-ietf-tsvwg-rsvp-l3vpn-03 Stefan Santesson T 2009-11-17 draft-ietf-bmwg-ipsec-term-12 Yaron Sheffer T 2009-11-17 draft-ietf-dna-simple-11 Hannes Tschofenig T 2009-11-17 draft-carpenter-renum-needs-work-04 Carl Wallace T 2009-11-17 draft-ietf-6man-overlap-fragment-03 For telechat 2009-12-03 Reviewer Deadline Draft Larry Zhu T 2009-12-01 draft-combes-ipdvb-mib-rcs-08 Last calls and special requests: Reviewer Deadline Draft Derek Atkins 2009-11-23 draft-klensin-ftp-registry-02 Rob Austein 2009-10-07 draft-reschke-rfc2731bis-03 Rob Austein 2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02 Richard Barnes 2009-11-28 draft-ietf-pkix-new-asn1-07 Pat Cain 2009-11-28 draft-ietf-pkix-rfc3161-update-09 Ran Canetti 2009-11-25 draft-ietf-nsis-qos-nslp-17 Dave Cridland 2009-11-25 draft-ietf-nsis-qspec-22 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Sam Hartman R2009-10-23 draft-hammer-oauth-04 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-08 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-17 Charlie Kaufman None draft-baker-ietf-core-04 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Russ Mundy 2009-10-21 draft-ietf-hokey-preauth-ps-09 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Sandy Murphy 2009-10-23 draft-nottingham-site-meta-03 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Hilarie Orman 2009-12-08 draft-lha-gssapi-delegate-policy-04 Radia Perlman None draft-bryan-http-digest-algorithm-values-update-03 Eric Rescorla 2009-11-10 draft-gennai-smime-cnipa-pec-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-12 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-10-23 draft-ietf-l3vpn-ospfv3-pece-03 Sean Turner 2009-10-28 draft-ietf-ipsecme-traffic-visibility-10 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis R2009-11-20 draft-ietf-pim-sm-linklocal-09 Brian Weis 2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Tom Yu 2009-11-23 draft-ietf-ccamp-lsp-dppm-10 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-05 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 Glen Zorn 2009-11-18 draft-ietf-sasl-gs2-17 From fielding@gbiv.com Thu Nov 12 19:31:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E723A69E6; Thu, 12 Nov 2009 19:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=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 7bPff8BZ5r+e; Thu, 12 Nov 2009 19:31:11 -0800 (PST) Received: from spaceymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 75B5F3A6984; Thu, 12 Nov 2009 19:31:11 -0800 (PST) Received: from rtf.corp.day.com (wsip-98-189-13-228.oc.oc.cox.net [98.189.13.228]) by spaceymail-a4.g.dreamhost.com (Postfix) with ESMTP id C62DF161526; Thu, 12 Nov 2009 19:31:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4AFC4C7D.4040801@acm.org> Date: Thu, 12 Nov 2009 19:31:40 -0800 Content-Transfer-Encoding: 7bit Message-Id: <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com> References: <4AF85F9F.4060407@acm.org> <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> <4AFC4C7D.4040801@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Sun, 15 Nov 2009 20:24:48 -0800 Cc: uri-review@ietf.org, Ted Hardie , "behave@ietf.org" , ops-dir@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Uri-review] End of Last Call for draft-ietf-behave-turn-uri X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 03:31:12 -0000 On Nov 12, 2009, at 9:57 AM, Marc Petit-Huguenin wrote: > Hi Ted, > > Ted Hardie wrote: >> Hi Marc, >> >> Thanks for the changes; I thought you had suggested using new >> productions, rather than re-using the existing ones from the >> hierarchical >> URI mechanism. Sorry if I did not reply on that--I think that would >> be a good idea, but if there is rough consensus for the current approach, >> I am happy to go along. >> > > OK I'll replace the following text: > > " turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] > scheme = "turn" / "turns" > transport = "udp" / "tcp" / transport-ext > transport-ext = 1*unreserved > > , and are specified in [RFC3986]. > > Note that the usage of components defined in the [RFC3986] as part of > a generic hierarchical URI does not mean that a TURN/TURNS URI is > hierarchical." > > by this text: > > " turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] > scheme = "turn" / "turns" > transport = "udp" / "tcp" / transport-ext > transport-ext = 1*unreserved > host = IP-literal / IPv4address / reg-name > port = *DIGIT > IP-literal = "[" ( IPv6address / IPvFuture ) "]" > IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) > IPv6address = 6( h16 ":" ) ls32 > / "::" 5( h16 ":" ) ls32 > / [ h16 ] "::" 4( h16 ":" ) ls32 > / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 > / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 > / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 > / [ *4( h16 ":" ) h16 ] "::" ls32 > / [ *5( h16 ":" ) h16 ] "::" h16 > / [ *6( h16 ":" ) h16 ] "::" > h16 = 1*4HEXDIG > ls32 = ( h16 ":" h16 ) / IPv4address > IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet > dec-octet = DIGIT ; 0-9 > / %x31-39 DIGIT ; 10-99 > / "1" 2DIGIT ; 100-199 > / "2" %x30-34 DIGIT ; 200-249 > / "25" %x30-35 ; 250-255 > reg-name = *( unreserved / pct-encoded / sub-delims ) > > > and are specified in > [RFC3986]." > > I will also add this in the Acknowledgments section: > > "The and ABNF productions have been copied from > [RFC3986]." Umm, why don't you just use the RFC3986 ABNF directly, make it a normative dependency, and not recreate that which is already a standard? While you are at it, please redesign the URI to be hierarchical. The proposed syntax goes out of its way to create arbitrary differences from STD66. Transport does not belong as a query parameter. Transports are a fundamental part of authority management. The traditional way of handling multiple transports is to provide a unique scheme for each one, since that is how clients will determine which identifier to use on the basis of whether they support the different transports. TLS is a transport. In other words: turnURI = "turn" [ "." transport ] "://" authority transport = "tls" / "udp" / "sctp" ; TCP is the default authority = I would also suggest appending path-abempty [ "?" query ] as well, if there is any chance (no matter how remote) that you might find a use for path or query information in the future. Cheers, Roy T. Fielding Chief Scientist, Day Software From petithug@acm.org Thu Nov 12 23:11:23 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4F03A6901; Thu, 12 Nov 2009 23:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.693 X-Spam-Level: X-Spam-Status: No, score=-101.693 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpzDGfzqU1-K; Thu, 12 Nov 2009 23:11:22 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 71C663A688E; Thu, 12 Nov 2009 23:11:22 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id DD650DC0409E; Fri, 13 Nov 2009 07:11:51 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D5783DC0409C; Fri, 13 Nov 2009 07:11:50 +0000 (UTC) Message-ID: <4AFD06B6.9090000@acm.org> Date: Thu, 12 Nov 2009 23:11:50 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: "Roy T. Fielding" References: <4AF85F9F.4060407@acm.org> <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> <4AFC4C7D.4040801@acm.org> <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com> In-Reply-To: <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Nov 2009 20:24:48 -0800 Cc: uri-review@ietf.org, Ted Hardie , "behave@ietf.org" , ops-dir@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Uri-review] End of Last Call for draft-ietf-behave-turn-uri X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 07:11:23 -0000 Hi Roy, Roy T. Fielding wrote: > On Nov 12, 2009, at 9:57 AM, Marc Petit-Huguenin wrote: > >> Hi Ted, >> >> Ted Hardie wrote: >>> Hi Marc, >>> >>> Thanks for the changes; I thought you had suggested using new >>> productions, rather than re-using the existing ones from the >>> hierarchical >>> URI mechanism. Sorry if I did not reply on that--I think that would >>> be a good idea, but if there is rough consensus for the current approach, >>> I am happy to go along. >>> >> OK I'll replace the following text: >> >> " turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] >> scheme = "turn" / "turns" >> transport = "udp" / "tcp" / transport-ext >> transport-ext = 1*unreserved >> >> , and are specified in [RFC3986]. >> >> Note that the usage of components defined in the [RFC3986] as part of >> a generic hierarchical URI does not mean that a TURN/TURNS URI is >> hierarchical." >> >> by this text: >> >> " turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ] >> scheme = "turn" / "turns" >> transport = "udp" / "tcp" / transport-ext >> transport-ext = 1*unreserved >> host = IP-literal / IPv4address / reg-name >> port = *DIGIT >> IP-literal = "[" ( IPv6address / IPvFuture ) "]" >> IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) >> IPv6address = 6( h16 ":" ) ls32 >> / "::" 5( h16 ":" ) ls32 >> / [ h16 ] "::" 4( h16 ":" ) ls32 >> / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 >> / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 >> / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 >> / [ *4( h16 ":" ) h16 ] "::" ls32 >> / [ *5( h16 ":" ) h16 ] "::" h16 >> / [ *6( h16 ":" ) h16 ] "::" >> h16 = 1*4HEXDIG >> ls32 = ( h16 ":" h16 ) / IPv4address >> IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet >> dec-octet = DIGIT ; 0-9 >> / %x31-39 DIGIT ; 10-99 >> / "1" 2DIGIT ; 100-199 >> / "2" %x30-34 DIGIT ; 200-249 >> / "25" %x30-35 ; 250-255 >> reg-name = *( unreserved / pct-encoded / sub-delims ) >> >> >> and are specified in >> [RFC3986]." >> >> I will also add this in the Acknowledgments section: >> >> "The and ABNF productions have been copied from >> [RFC3986]." > > Umm, why don't you just use the RFC3986 ABNF directly, make it > a normative dependency, and not recreate that which is already > a standard? Ted Hardie suggested the exact opposite. > > While you are at it, please redesign the URI to be hierarchical. > The proposed syntax goes out of its way to create arbitrary > differences from STD66. Your advice contradicts RFC 4395 section 2.2: "Avoid improper use of "//". The use of double slashes in the first part of a URI is not an artistic indicator that what follows is a URI: Double slashes are used ONLY when the syntax of the URI's contains a hierarchical structure as described in RFC 3986. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See Section 3.2 of RFC 3986 for more details.) URI schemes that do not contain a conformant hierarchical structure in their SHOULD NOT use double slashes following the ":" string." > > Transport does not belong as a query parameter. Transports are > a fundamental part of authority management. The traditional way > of handling multiple transports is to provide a unique scheme for > each one, since that is how clients will determine which identifier > to use on the basis of whether they support the different transports. > TLS is a transport. Can you please provide the RFC # and section that says this? I was not able to find it. Thanks. > > In other words: > > turnURI = "turn" [ "." transport ] "://" authority > transport = "tls" / "udp" / "sctp" ; TCP is the default > authority = > > I would also suggest appending path-abempty [ "?" query ] > as well, if there is any chance (no matter how remote) that > you might find a use for path or query information in the future. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From cwallace@cygnacom.com Mon Nov 16 06:03:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819503A683D; Mon, 16 Nov 2009 06:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.996, 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 wnl-1BPXfgKx; Mon, 16 Nov 2009 06:03:20 -0800 (PST) Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by core3.amsl.com (Postfix) with ESMTP id 1A8DB3A67FA; Mon, 16 Nov 2009 06:03:20 -0800 (PST) Received: from unknown [65.242.48.13] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 8ab510b4.2117852080.559614.00-076.p03c11o141.symantecmail.net (envelope-from ); Mon, 16 Nov 2009 07:03:20 -0700 (MST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA66C5.8CBDACB9" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 16 Nov 2009 09:03:18 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-6man-overlap-fragment-03 thread-index: AcpmxYxonn3RSpCsRvabsh+qj1HhlA== From: "Carl Wallace" To: , X-Spam: [F=0.2000000000; S=0.200(2009110601)] X-MAIL-FROM: X-SOURCE-IP: [65.242.48.13] Cc: suresh.krishnan@ericsson.com Subject: [secdir] secdir review of draft-ietf-6man-overlap-fragment-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:03:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA66C5.8CBDACB9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. =20 This document updates RFC 2460 to forbid overlapping fragments. I have no issues with this draft. =20 ------_=_NextPart_001_01CA66C5.8CBDACB9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This document updates RFC 2460 to forbid = overlapping fragments.  I have no issues with this draft.

 

------_=_NextPart_001_01CA66C5.8CBDACB9-- From ted.ietf@gmail.com Mon Nov 16 09:40:26 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919D728C1BD; Mon, 16 Nov 2009 09:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=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 YCkGdoV6Yzxs; Mon, 16 Nov 2009 09:40:21 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 4BE6C28C1DC; Mon, 16 Nov 2009 09:40:18 -0800 (PST) Received: by pzk6 with SMTP id 6so4412630pzk.29 for ; Mon, 16 Nov 2009 09:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HrpnbLri9WwpWk6aHps5zGyt7rSPCGRpkECE9pWmjKA=; b=K3BDmZAFx6DMqwK5o1RE90cF9Km+9a1fBMvGATNkR5RBXNWZoR1VyYajcye1+N4ev2 l6JagJpEbg7EpaVLl2E5zGgZaAU9ngbkmugDB+ZCrQrA/fnoVDXYH+UAvd3BPI0JOrF+ qrGny5j8UYaJV7VteiNv+w1jDafW1DeEkBOic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vGG9+dDibRtBNTMT2bl0kCqwOGpNr7MS8qx79iCxDhi/nr3U2QaM8Rlqr0FWZ0B2Ov U0C1jFuX9fWerd+am2IbkuxOWAUIfZBgsEZzDUqoIvUPWPyBvBfbSZTv6o+2Ml/46QII kwOlkL4l0JMbqgMi2WBMo9ccCzG3LzIFrjkqc= MIME-Version: 1.0 Received: by 10.143.129.7 with SMTP id g7mr879514wfn.241.1258393214693; Mon, 16 Nov 2009 09:40:14 -0800 (PST) In-Reply-To: <4AFD06B6.9090000@acm.org> References: <4AF85F9F.4060407@acm.org> <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> <4AFC4C7D.4040801@acm.org> <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com> <4AFD06B6.9090000@acm.org> Date: Mon, 16 Nov 2009 09:40:14 -0800 Message-ID: <6e04e83a0911160940x53675f34t503463b60070da51@mail.gmail.com> From: Ted Hardie To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 16 Nov 2009 22:55:03 -0800 Cc: uri-review@ietf.org, "Roy T. Fielding" , "behave@ietf.org" , ops-dir@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Uri-review] End of Last Call for draft-ietf-behave-turn-uri X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 17:40:26 -0000 On Thu, Nov 12, 2009 at 11:11 PM, Marc Petit-Huguenin wr= ote: > Hi Roy, > > Roy T. Fielding wrote: >> On Nov 12, 2009, at 9:57 AM, Marc Petit-Huguenin wrote: >> >>> Hi Ted, >>> >>> Ted Hardie wrote: >>>> Hi Marc, >>>> >>>> Thanks for the changes; I thought you had suggested using new >>>> productions, rather than re-using the existing ones from the >>>> hierarchical >>>> URI mechanism. =A0Sorry if I did not reply on that--I think that would >>>> be a good idea, but if there is rough consensus for the current approa= ch, >>>> I am happy to go along. >>>> >>> OK I'll replace the following text: >>> >>> " =A0turnURI =A0 =3D scheme ":" host [ ":" port ] [ "?transport=3D" tra= nsport ] >>> =A0 scheme =A0 =A0=3D "turn" / "turns" >>> =A0 transport =3D "udp" / "tcp" / transport-ext >>> =A0 transport-ext =3D 1*unreserved >>> >>> , and are specified in [RFC3986]. >>> >>> Note that the usage of components defined in the [RFC3986] as part of >>> a generic hierarchical URI does not mean that a TURN/TURNS URI is >>> hierarchical." >>> >>> by this text: >>> >>> " =A0turnURI =A0 =3D scheme ":" host [ ":" port ] [ "?transport=3D" tra= nsport ] >>> =A0 scheme =A0 =A0 =A0 =A0=3D "turn" / "turns" >>> =A0 transport =A0 =A0 =3D "udp" / "tcp" / transport-ext >>> =A0 transport-ext =3D 1*unreserved >>> =A0 host =A0 =A0 =A0 =A0 =A0=3D IP-literal / IPv4address / reg-name >>> =A0 port =A0 =A0 =A0 =A0 =A0=3D *DIGIT >>> =A0 IP-literal =A0 =A0=3D "[" ( IPv6address / IPvFuture =A0) "]" >>> =A0 IPvFuture =A0 =A0 =3D "v" 1*HEXDIG "." 1*( unreserved / sub-delims = / ":" ) >>> =A0 IPv6address =A0 =3D =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A06( h16 ":" ) ls32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 "::" 5( h16 ":" ) ls32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / [ =A0 =A0 =A0 =A0 =A0 =A0 =A0 h16 ] "= ::" 4( h16 ":" ) ls32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":"= ) ls32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":"= ) ls32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / [ *3( h16 ":" ) h16 ] "::" =A0 =A0h16= ":" =A0 ls32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / [ *4( h16 ":" ) h16 ] "::" =A0 =A0 = =A0 =A0 =A0 =A0 =A0ls32 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / [ *5( h16 ":" ) h16 ] "::" =A0 =A0 = =A0 =A0 =A0 =A0 =A0h16 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / [ *6( h16 ":" ) h16 ] "::" >>> =A0 h16 =A0 =A0 =A0 =A0 =A0 =3D 1*4HEXDIG >>> =A0 ls32 =A0 =A0 =A0 =A0 =A0=3D ( h16 ":" h16 ) / IPv4address >>> =A0 IPv4address =A0 =3D dec-octet "." dec-octet "." dec-octet "." dec-o= ctet >>> =A0 dec-octet =A0 =A0 =3D DIGIT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; 0-9 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / %x31-39 DIGIT =A0 =A0 =A0 =A0 ; 10-99 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "1" 2DIGIT =A0 =A0 =A0 =A0 =A0 =A0; 1= 00-199 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "2" %x30-34 DIGIT =A0 =A0 ; 200-249 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / "25" %x30-35 =A0 =A0 =A0 =A0 =A0; 250= -255 >>> =A0 reg-name =A0 =A0 =A0=3D *( unreserved / pct-encoded / sub-delims ) >>> >>> >>> =A0 and are specified in >>> =A0 [RFC3986]." >>> >>> I will also add this in the Acknowledgments section: >>> >>> "The and ABNF productions have been copied from >>> [RFC3986]." >> >> Umm, why don't you just use the RFC3986 ABNF directly, make it >> a normative dependency, and not recreate that which is already >> a standard? > > Ted Hardie suggested the exact opposite. Howdy, Sorry for the episodic nature of these comments; jet-lag combined with day-job issues have really taken their toll on my response time. My apolog= ies especially that I wasn't able to discuss this in person in Hiroshima with any of the relevant folks--I had to leave early. The thrust of my list comment was intended to find some way of distinguishi= ng the way this URI scheme uses its components. Using new ABNF productions was one fairly low-impact way of signaling these were different, but I beli= eve that re-using the same names and copying the ABNF doesn't really qualify as new productions. At the very least, I think you'd need new names that highlighted the roles these play; even that is not much of a signal once these are in the wild. As you recall, I'd originally suggested that the URI mailing list be cc'ed for ideas on other approaches, and Roy is certainly one of the folks that I'd hoped w= ould review it there. If I can help by setting up a conference call or otherwise getting some more real-time communication going, please let me know. I remain hope= ful that we can find some way of approaching the problem that doesn't involve a complete pushback. I apologize again for any delay my own response time = has induced. regards, Ted Hardie From petithug@acm.org Mon Nov 16 12:38:17 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77F028C0E0; Mon, 16 Nov 2009 12:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udOOC3aGuqla; Mon, 16 Nov 2009 12:38:16 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id B0C1E3A680D; Mon, 16 Nov 2009 12:38:16 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 8ABE2DC0409E; Mon, 16 Nov 2009 20:38:15 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 92888DC0409C; Mon, 16 Nov 2009 20:38:14 +0000 (UTC) Message-ID: <4B01B835.3010408@acm.org> Date: Mon, 16 Nov 2009 12:38:13 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Ted Hardie , Dan Wing References: <4AF85F9F.4060407@acm.org> <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> <4AFC4C7D.4040801@acm.org> <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com> <4AFD06B6.9090000@acm.org> <6e04e83a0911160940x53675f34t503463b60070da51@mail.gmail.com> In-Reply-To: <6e04e83a0911160940x53675f34t503463b60070da51@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 16 Nov 2009 22:55:03 -0800 Cc: uri-review@ietf.org, "Roy T. Fielding" , "behave@ietf.org" , ops-dir@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Uri-review] End of Last Call for draft-ietf-behave-turn-uri X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:38:17 -0000 Ted Hardie wrote: > On Thu, Nov 12, 2009 at 11:11 PM, Marc Petit-Huguenin wrote: >> Hi Roy, >> >> Roy T. Fielding wrote: >>> On Nov 12, 2009, at 9:57 AM, Marc Petit-Huguenin wrote: >>> [...] >>> Umm, why don't you just use the RFC3986 ABNF directly, make it >>> a normative dependency, and not recreate that which is already >>> a standard? >> Ted Hardie suggested the exact opposite. > > Howdy, > > Sorry for the episodic nature of these comments; jet-lag combined with > day-job issues have really taken their toll on my response time. My apologies > especially that I wasn't able to discuss this in person in Hiroshima with > any of the relevant folks--I had to leave early. > > The thrust of my list comment was intended to find some way of distinguishing > the way this URI scheme uses its components. Using new ABNF productions > was one fairly low-impact way of signaling these were different, but I believe > that re-using the same names and copying the ABNF doesn't really qualify > as new productions. At the very least, I think you'd need new names that > highlighted the roles these play; even that is not much of a signal > once these are > in the wild. > > As you recall, I'd originally suggested that the URI mailing list be > cc'ed for ideas > on other approaches, and Roy is certainly one of the folks that I'd hoped would > review it there. If I can help by setting up a conference call or > otherwise getting > some more real-time communication going, please let me know. I remain hopeful > that we can find some way of approaching the problem that doesn't involve > a complete pushback. I apologize again for any delay my own response time has > induced. Well, I had other private discussions about this, and I am now seriously considering dropping the TURN/TURNS URI and just keeping the resolution mechanism. The only purpose of the URI is to carry the 3 pieces of information needed for the resolution algorithm (host/IP address, port and TURN transport), but this 3 pieces of information can be stored in the client configuration individually. That is not as neat as having one, single character string, but seeing all the difficulties in having the syntax approved, this is probably the best solution. I used RFC 4501 as a guideline for this design, but now people are telling me that a DNS URI was a bad idea... So unless someone objects to this, the next version (probably released Monday 23rd) will be without the URI stuff. The only problem is that the name of the I-D (draft-ietf-turn-uri) will no longer reflect the content. Dan, any suggestion here? Thanks. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From gorry@erg.abdn.ac.uk Tue Nov 17 00:02:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538BC3A6B9C for ; Tue, 17 Nov 2009 00:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkih07I8ciI5 for ; Tue, 17 Nov 2009 00:02:58 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 4EBEF3A6B9D for ; Tue, 17 Nov 2009 00:02:57 -0800 (PST) Received: from Gorry-Fairhursts-Laptop-7.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id nAH82UeW021585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Nov 2009 08:02:33 GMT Message-ID: <4B025896.6060505@erg.abdn.ac.uk> Date: Tue, 17 Nov 2009 08:02:30 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Tue, 17 Nov 2009 00:23:00 -0800 Cc: Gorry , "James M. Polk" Subject: [secdir] SECDIR early review request for draft-ietf-tsvwg-rsvp-security-groupkeying X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 08:02:59 -0000 Dear SECDIR, I am pleased to inform you that TSVWG has started the WG last call on "Applicability of Keying Methods for RSVP Security" with an intended status of Informational. This draft is about RSVP security and the chairs would like to receive an early SECDIR review to confirm this is ready for publication. The WGLC runs until the 4th December. Abstract The Resource reSerVation Protocol (RSVP) allows hop-by-hop authentication of RSVP neighbors. This requires messages to be cryptographically signed using a shared secret between participating nodes. This document compares group keying for RSVP with per neighbor or per interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. The present document also discusses applicability of group keying to RSVP encryption. The draft is available at this URL on the tools page: http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-security-groupkeying/ Best wishes, James & Gorry TSVWG Co-Chairs From alexey.melnikov@isode.com Wed Nov 18 00:17:26 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501E63A68A0; Wed, 18 Nov 2009 00:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMogWQK8XUwJ; Wed, 18 Nov 2009 00:17:25 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DC33D3A6893; Wed, 18 Nov 2009 00:17:24 -0800 (PST) Received: from [92.40.113.136] (92.40.113.136.sub.mbb.three.co.uk [92.40.113.136]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 18 Nov 2009 08:17:19 +0000 Message-ID: <4B03AD81.9090103@isode.com> Date: Wed, 18 Nov 2009 08:17:05 +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: Samuel Weiler References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, ietf@ietf.org Subject: Re: [secdir] secdir review of draft-melnikov-imap-keywords-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 08:17:26 -0000 Hi Samuel, Thank you for the review. Samuel Weiler 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. > > From a security perspective, I have no issues with this document. It > creates a new registry and defines two sets of assignment metrics, one > for "common use" keywords, and one for vendor-specific keywords. > > It also registers four keywords. (I'm wondering if it shouldn't be > registering more.) Further registrations will be done by the designated expert. I am concerned that if I put all of them in the document, then the document will never finish. > I'm finding the IANA assignment metrics to be a little more ambiguous > that I'd like. > > Starting with the vendor-specific text: > > Registration of vendor specific IMAP keywords is done on First Come > First Serve [RFC5226] basis and doesn't require the Expert Review. > However such review is still encouraged. Should the review be > requested, ... > > Who requests the review? > The registrant or IANA? Good question. I was thinking about the registrant. But IANA requesting review would be a good idea as well. > Does IANA need to encourage the review? Perhaps it would be better to > have all requests (including vendor-specific) be sent to the mailing > list, with IANA assignment of the vendor-specific ones being automatic > following a (short) delay for comment and optional revision. Ok, I've implemented this procedure in my copy. > And for the common-use: > > Registration of an IMAP keyword intended for common use (whether or > not they use the "$" prefix) requires Expert Review [RFC5226]. IESG > appoints one or more Expert Reviewer, one of which is designated as > the primary Expert Reviewer. IMAP keywords intended for common use > SHOULD be standardized in IETF Consensus [RFC5226] documents. ... > In cases when an IMAP > Keyword being registered is already deployed, Expert Reviewers > should favour registering it over requiring perfect documentation. > > Would it be better to say: "requires either IETF Consensus or Expert > Review"? Not everybody is subscribed to ietf or ietf-announce mailing lists, so I would like for all common use registrations to go through the expert. > (For example: do the registrations made in this doc have to go through > Expert Review? No, because they are a part of the document that creates the registry ;-). > Isn't it enough to have them in a consensus doc?") And how do you > expect the expert to encourage/enforce the SHOULD, given the "favour > registering it over requiring perfect documentation" guideline? > Again, the current text isn't as clear as I'd like. This is intentional. This is a judgment call by the expert. From Martin.Vigoureux@alcatel-lucent.com Wed Nov 18 04:11:14 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB8D3A6B72 for ; Wed, 18 Nov 2009 04:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJang9eDPwu3 for ; Wed, 18 Nov 2009 04:11:13 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 736443A6948 for ; Wed, 18 Nov 2009 04:11:12 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAICB2TF002365; Wed, 18 Nov 2009 13:11:02 +0100 Received: from [172.27.205.212] ([172.27.205.212]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 13:11:02 +0100 Message-ID: <4B03E456.7040900@alcatel-lucent.com> Date: Wed, 18 Nov 2009 13:11:02 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Nov 2009 12:11:02.0113 (UTC) FILETIME=[321C4D10:01CA6848] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 X-Mailman-Approved-At: Wed, 18 Nov 2009 08:10:24 -0800 Cc: dward@cisco.com, malcolm.betts@huawei.com, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-tp-oam-requirements-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 12:11:14 -0000 Dear Phillip, thanks for your review. Would the following rephrasing (of the Security Considerations) satisfy your expectations? For your information, Tim Polk had a similar type of comment as part of IESG Review and is ok with the text proposed below. Thanks martin OLD In general, mechanisms SHOULD be provided to ensure that OAM functions cannot be accessed unauthorized. Further, OAM messages MAY be authenticated to prove their origin and to make sure that they are destined for the receiving node. An OAM packet received over a PW, LSP or Section MUST NOT be forwarded beyond the End Point of that PW, LSP or Section, so as to avoid that the OAM packet leaves the current administrative domain. NEW OAM systems (network management stations) SHOULD be designed such that OAM functions cannot be accessed without authorization. OAM protocol solutions MUST include the facility for OAM messages to authenticated to prove their origin and to make sure that they are destined for the receiving node. The use of such facilities MUST be configurable. An OAM packet received over a PW, LSP or Section MUST NOT be forwarded beyond the End Point of that PW, LSP or Section, so as to avoid that the OAM packet leaves the current administrative domain. Phillip Hallam-Baker a écrit : > I am reviewing this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. Feel free to > forward to any appropriate forum. > > > This documents sets out requirements for Operations, Administration > and Maintenance of MPLS Transport Profile. > > It is a high level architectural requirements document, intentionally > separated from the details of specific implementations. As such it is > appropriate for the security considerations section to be at a high > level. > > It is however a mystery to this reader why encryption is specified as > a should but integrity protections only merit a MAY. I would be much > more reassured by a document that ignores confidentiality issues > completely (as has been the general policy for low level routing &ct.) > and points out the fact that this is yet another opportunity for a > malicious party to play merry heck by introducing bogus data that > other parts of the network will then operate on. > > For example, introduction of bogus messages would allow an attacker to > reserve excessive bandwidth in the name of another party, possibly > performing a DoS attack or possibly to perform a financial fraud, > causing some party to incur costs for bandwidth not required. > > In comparison the confidentiality issues are rather minor, and in any > event almost certainly subsumed by the fact that anyone who can > observe the content of the OAM packets can almost certainly observe > the volumes of the data flows and infer that information. While > confidentiality is a nice to have, it is not worth much without > integrity. > > I suggest that the security considerations section makes the ability > to support integrity protections a MUST or SHOULD requirement. If only > a SHOULD is applied, confidentiality would be better demoted to MAY. > From yaronf@checkpoint.com Wed Nov 18 09:56:18 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825B93A6AB0; Wed, 18 Nov 2009 09:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBafr0mD2T2f; Wed, 18 Nov 2009 09:56:15 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A02393A6920; Wed, 18 Nov 2009 09:56:14 -0800 (PST) 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 nAIHuAGo001970; Wed, 18 Nov 2009 19:56:10 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 18 Nov 2009 19:56:17 +0200 From: Yaron Sheffer To: secdir , "iesg@ietf.org" , "draft-ietf-dna-simple.all@tools.ietf.org" Date: Wed, 18 Nov 2009 19:56:15 +0200 Thread-Topic: SecDir review of draft-ietf-dna-simple-11 Thread-Index: AcpoeGxYXUdrY+VLRKuuzZmGkUkAXA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7B@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7Bilex01adche_" MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-dna-simple-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 17:56:18 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7Bilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document provides a simple procedure (for some value of "simple") to d= etect whether an IPv6 node is reconnecting into a network it's previously s= een. I should prefix these comments by a big disclaimer re: my very basic IPv6 e= xpertise. Security The Security Considerations are focused on one specific aspect, namely the = use of SEND. I think we should make clear here that none of the DNA operati= ons by themselves add any measure of security, unless SEND is actually used= . Specifically, I suggest to add the text: "The DNA procedure does not in i= tself provide positive, secure authentication of the router(s) on the netwo= rk, or authentication of the network itself, as e.g. would be provided by m= utual authentication at the link layer. Therefore when such assurance is no= t available, the host MUST NOT make any security-sensitive decisions based = on the DNA procedure. In particular, it MUST NOT decide it has rejoined a n= etwork known to be physically secure, and proceed to abandon cryptographic = protection." Other Comments 4.1: DUID - is this the host's DUID or the router's? Per RFC 3315, both hav= e such a value. 4.3: "all currently configured IP addresses" - but only for this physical i= nterface, right? 4.8: why is no DAD performed? Someone else might have joined the network wh= ile I was disconnected, and has a duplicate of my address. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7Bilex01adche_ 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 b= y the IESG.  These comments were written primarily for the benefit of th= e security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

This document provides a simple procedure (for some valu= e of “simple”) to detect whether an IPv6 node is reconnecting into a network it’s previously seen.

 

I should prefix these comments by a big disclaimer re: m= y very basic IPv6 expertise.

 

Security

 

The Security Considerations are focused on one specific aspect, namely the use of SEND. I think we should make clear here that none= of the DNA operations by themselves add any measure of security, unless SEND i= s actually used. Specifically, I suggest to add the text: “The DNA procedure does not in itself provide positive, secure authentication of the router(s) on the network, or authentication of the network itself, as e.g. = would be provided by mutual authentication at the link layer. Therefore when such= assurance is not available, the host MUST NOT make any security-sensitive decisions b= ased on the DNA procedure. In particular, it MUST NOT decide it has rejoined a n= etwork known to be physically secure, and proceed to abandon cryptographic protect= ion.”

 

Other Comments

 

4.1: DUID - is this the host’s DUID or the router'= s? Per RFC 3315, both have such a value.

4.3: "all currently configured IP addresses" -= but only for this physical interface, right?

4.8: why is no DAD performed? Someone else might have jo= ined the network while I was disconnected, and has a duplicate of my address.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888AD7Bilex01adche_-- From rbarnes@bbn.com Wed Nov 18 10:21:13 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F143A6993; Wed, 18 Nov 2009 10:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 8xX-EJXr0oAl; Wed, 18 Nov 2009 10:21:12 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 8F2583A68E4; Wed, 18 Nov 2009 10:21:12 -0800 (PST) Received: from [192.1.255.180] (helo=col-dhcp-192-1-255-180.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NAp9R-0005Si-Bx; Wed, 18 Nov 2009 13:21:09 -0500 Message-Id: From: Richard Barnes To: secdir@ietf.org, iesg@ietf.org, IETF discussion list Content-Type: multipart/alternative; boundary=Apple-Mail-6--1059088642 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 13:21:09 -0500 X-Mailer: Apple Mail (2.936) Cc: draft-ietf-pkix-new-asn1@tools.ietf.org Subject: [secdir] SECDIR review of draft-ietf-pkix-new-asn1-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:21:13 -0000 --Apple-Mail-6--1059088642 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document updates the ASN.1 descriptions of several security- relevant data objects (e.g., CMS messages and S/MIME objects) from the 1988 version of ASN.1 to the 2002 version, without changing the structure expressed by these definitions -- there are no changes to bits on the wire. The document correctly states that this document itself creates no security issues, because it makes no changes to any protocols (it simply expresses the structure of those protocols in a different, updated syntax). The only minor concern I have is to be sure that the above claims about the lack of changes are true, i.e., that the ASN.1 syntax is correct. To ensure this correctness, I would recommend an expert review focused on the ASN.1, if one has not already been done. --Richard --Apple-Mail-6--1059088642 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have reviewed this = document as part of the security directorate's ongoing effort to review = all IETF documents being processed by the IESG.  These comments = were written primarily for the benefit of the security area = directors.  Document editors and WG chairs should treat these = comments just like any other last call comments.

This document updates the ASN.1 descriptions = of several security-relevant data objects (e.g., CMS messages and S/MIME = objects) from the 1988 version of ASN.1 to the 2002 version, without = changing the structure expressed by these definitions -- there are no = changes to bits on the wire.  The document correctly states that = this document itself creates no security issues, because it makes no = changes to any protocols (it simply expresses the structure of those = protocols in a different, updated syntax).  The only minor concern = I have is to be sure that the above claims about the lack of changes are = true, i.e., that the ASN.1 syntax is correct.  To ensure this = correctness, I would recommend an expert review focused on the ASN.1, if = one has not already been done.

--Richard
= --Apple-Mail-6--1059088642-- From weiler+secdir@watson.org Fri Nov 20 09:07:35 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BF03A6946 for ; Fri, 20 Nov 2009 09:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 WslQbEAQhIF4 for ; Fri, 20 Nov 2009 09:07:34 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 040F73A689E for ; Fri, 20 Nov 2009 09:07:33 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nAKH7UWQ014686 for ; Fri, 20 Nov 2009 12:07:30 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nAKH7UCp014682 for ; Fri, 20 Nov 2009 12:07:30 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 20 Nov 2009 12:07:30 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 20 Nov 2009 12:07:30 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 17:07:35 -0000 Dan Harkins in next in the rotation. Please try to complete last call reviews by the end of the last call. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-12-03 Reviewer Deadline Draft Derek Atkins T 2009-12-01 draft-klensin-ftp-registry-02 Rob Austein T 2009-12-01 draft-reschke-rfc2731bis-04 Shawn Emery T 2009-12-01 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06 Stephen Farrell T 2009-12-01 draft-ietf-csi-sndp-prob-03 Phillip Hallam-Baker T 2009-12-01 draft-ietf-hip-native-api-09 Stefan Santesson TR2009-12-01 draft-ietf-tsvwg-rsvp-l3vpn-04 Larry Zhu T 2009-12-01 draft-combes-ipdvb-mib-rcs-08 For telechat 2009-12-17 Reviewer Deadline Draft Donald Eastlake T 2009-12-15 draft-cheshire-dnsext-multicastdns-08 Last calls and special requests: Reviewer Deadline Draft Rob Austein 2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02 Pat Cain 2009-11-28 draft-ietf-pkix-rfc3161-update-09 Ran Canetti 2009-11-25 draft-ietf-nsis-qos-nslp-17 Dave Cridland 2009-11-25 draft-ietf-nsis-qspec-22 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Alan DeKok 2009-12-16 draft-eastlake-nlpid-iana-considerations-03 Steve Hanna 2009-12-04 draft-ietf-rohc-rfc4995bis-01 Sam Hartman R2009-10-23 draft-hammer-oauth-05 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-08 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-17 Charlie Kaufman None draft-baker-ietf-core-04 Stephen Kent None draft-ietf-tsvwg-rsvp-security-groupkeying-05 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Russ Mundy 2009-10-21 draft-ietf-hokey-preauth-ps-09 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Sandy Murphy 2009-10-23 draft-nottingham-site-meta-04 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Hilarie Orman 2009-12-08 draft-lha-gssapi-delegate-policy-04 Radia Perlman None draft-bryan-http-digest-algorithm-values-update-03 Eric Rescorla 2009-11-10 draft-gennai-smime-cnipa-pec-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-12 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-10-23 draft-ietf-l3vpn-ospfv3-pece-03 Sean Turner 2009-10-28 draft-ietf-ipsecme-traffic-visibility-10 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis R2009-11-20 draft-ietf-pim-sm-linklocal-09 Brian Weis 2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Tom Yu 2009-11-23 draft-ietf-ccamp-lsp-dppm-10 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-05 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 Glen Zorn 2009-11-18 draft-ietf-sasl-gs2-18 From gwz@net-zen.net Fri Nov 20 11:41:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26A33A6873 for ; Fri, 20 Nov 2009 11:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIgusJr-3YvW for ; Fri, 20 Nov 2009 11:41:22 -0800 (PST) Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by core3.amsl.com (Postfix) with SMTP id 989FB3A672E for ; Fri, 20 Nov 2009 11:41:22 -0800 (PST) Received: (qmail 18483 invoked from network); 20 Nov 2009 19:41:18 -0000 Received: from unknown (66.187.181.250) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 20 Nov 2009 19:41:12 -0000 From: "Glen Zorn" To: , , , , "'Kurt Zeilenga'" , , "'Alexey Melnikov'" Date: Fri, 20 Nov 2009 14:39:59 -0500 Organization: Network Zen Message-ID: <000001ca6a19$665b3320$33119960$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpqGOx74WhdqIuES2On4tKsAj6aVA== Content-Language: en-us Subject: [secdir] secdir review of draft-ietf-sasl-gs2-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 19:41:22 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. GENERAL COMMENTS The reference to a document is not the document; for example, in the following excerpt from section 2, there are no names defined in the reference to RFC 2743: The document uses many terms and function names defined in [RFC2743] as updated by [RFC5554]. Please change to something like The document uses many terms and function names defined in RFC 2743 [RFC2743] as updated by RFC 5554 [RFC5554]. Note that this comment applies globally to all such usages in the document. ABSTRACT The last sentence of the Abstract says: "See for more information." Unless the referenced URL is intended to be permanently available (and probably even then), this line should be removed before publication as an RFC. SECTION 3 Third paragraph, first sentence. Old: If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 implementation need some other mechanism to map mechanism OIDs to SASL name internally. In this case, the implementation can only New: If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 implementation needs some other mechanism to map mechanism OIDs to SASL names internally. In this case, the implementation can only SECTION 3.1 s/characters outside of the base32 alphabet/characters outside of the Base32 alphabet/ SECTION 3.2 s/This obliterate the need/This obliterates the need/ The final sentence seems slightly clumsy; suggest the following change: Old: The computed mechanism name can be used directly in the implementation, and the implementation need not concern itself with that the mechanism is part of a mechanism family. New: The computed mechanism name can be used directly in the implementation, and the implementation need not be concerned if the mechanism is part of a mechanism family. SECTION 4 In the fourth paragraph, s/As this indicate an error condition/As this indicates an error condition/ In paragraph 5, "The [RFC2743] section 3.1 initial context token header" has the sound of GSSAPI "code words" ;-). Suggest changing to "The GSSAPIv2 initial context token header (see section 3.1 of RFC 2743 [RFC2743])" or some such. A similar comment pertains to the first paragraph on page 9; suggest: Old: When the "gs2-nonstd-flag" flag is present, the client did not find/ remove a [RFC2743] section 3.1 token header from the initial token returned by GSS_Init_sec_context. This signals to the server that it MUST NOT re-add the data that is normally removed by the client. New: When the "gs2-nonstd-flag" flag is present, the client did not find/ remove a GSSAPIv2 token header (RFC 2743, section 3.1) from the initial token returned by GSS_Init_sec_context. This signals to the server that it MUST NOT re-add the data that is normally removed by the client. s/The NUL characters is forbidden/The NUL character is forbidden/ s/Upon the receipt/Upon receipt/ s/results in failed authentication exchange/results in a failed authentication exchange/ SECTION 5 I find this section rather difficult to understand: not all of the possible combinations of gs2-cb-flag and server support for channel bindings seem to be covered. A table might help, if not for that the gs2-cb-flag is tri-valued & used to signal two different things. SECTION 5.1 First sentence s/The calls to GSS_Init_sec_context and GSS_Accept_sec_context takes a/The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a/ SECTION 6 This section needs a lot of work if it is expected to be understood by non-members of the Illuminati ;->. Just one example (of many possible): Example #3: a two round-trip GSS-API context token exchange, no channel binding, no standard token header. C: Request authentication exchange S: Empty Challenge C: F,n,, S: Send reply context token as is C: Send reply context token as is S: Send reply context token as is C: Empty message S: Outcome of authentication exchange What does this mean? What do 'F' & 'n' stand for? How is it useful? It might be claimed that these questions could be answered by dissecting the ABNF for the gs2 header, but I don't think that's a good answer: examples should be self-contained. SECTION 8 The first paragraph says: GS2 does not use any GSS-API per-message tokens. Therefore the setting of req_flags related to per-message tokens is irrelevant. OK, but what should the client and server behavior should be WRT the flags? SECTION 14.1 Old: If a client implement GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implement GSS-API mechanism X negotiated through a GSS-API mechanism Z, the authentication negotiation will fail. New: If a client implements GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implements GSS-API mechanism X negotiated through a GSS-API mechanism Z, the authentication negotiation will fail. SECTION 14.2 s/use of GSS-API mechanisms that negotiate other mechanisms are/use of GSS-API mechanisms that negotiate other mechanisms is/ From charliek@microsoft.com Fri Nov 20 20:42:04 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1243A676A; Fri, 20 Nov 2009 20:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TobS58oLaJMe; Fri, 20 Nov 2009 20:41:53 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 7F75B3A65A5; Fri, 20 Nov 2009 20:41:53 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Nov 2009 20:42:12 -0800 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.222]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Fri, 20 Nov 2009 20:41:50 -0800 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "fred@cisco.com" Thread-Topic: Secdir review of draft-baker-ietf-core-03.txt Thread-Index: AcpqZOucgF7ASXSvTZqJfaG1Udrgvg== Date: Sat, 21 Nov 2009 04:41:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: C7hl C8ZS GnTz J9cr MVjp Qatk TPKk T49Z UevW Ui5u Vidt X2UW Yeld abWV eSPD fyYq; 3; ZgByAGUAZABAAGMAaQBzAGMAbwAuAGMAbwBtADsAaQBlAHMAZwBAAGkAZQB0AGYALgBvAHIAZwA7AHMAZQBjAGQAaQByAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {5BCD9C1E-933D-4FE5-979E-7AAF08380D58}; YwBoAGEAcgBsAGkAZQBrAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=; Sat, 21 Nov 2009 04:41:41 GMT; UwBlAGMAZABpAHIAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGIAYQBrAGUAcgAtAGkAZQB0AGYALQBjAG8AcgBlAC0AMAAzAC4AdAB4AHQA x-cr-puzzleid: {5BCD9C1E-933D-4FE5-979E-7AAF08380D58} Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B0912082E2E08TK5EX14MBXC115r_" MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-baker-ietf-core-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 04:42:04 -0000 --_000_D80EDFF2AD83E648BD1164257B9B0912082E2E08TK5EX14MBXC115r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Others should treat these comments just like any other last call comment= s. Feel free to forward to any appropriate forum. This document (proposed as an Informational RFC) summarizes the core protoc= ols on which the Internet operates. It is specifically targeted at NIST in = the context of the Smart Grid discussion. They are looking to "profile" a s= ubset of the Internet Protocol Suite. Since the audience for this review is= security focused, I'll talk about security first. But since I read it all,= I'll include comments on the rest too. I would encourage others to read th= e document. It's both informative and could generate a lively discussion ab= out what constitutes "the core". As a truly informational document, this document has no security implicatio= ns, though it does talk about security. It considers IPsec, TLS, and S/MIME= to be the core security protocols. I would consider adding DNSSEC to that = list, and possibly removing S/MIME, but these three are certainly a reasona= ble place to start. Section 3.1 attempts to explain why it's natural for IPsec and TLS to both = exist, and reminded me how much each has encroached onto the territory of t= he other making that task more difficult. I believe that the original disti= nction was that IPsec was designed to be implemented in operating systems o= r networking infrastructure in a way that was transparent to applications, = while SSL was designed to be implemented in applications in a way that was = transparent to operating systems and networking infrastructure. That's not = a bits on the wire distinction, but I believe all the other differences der= ive from that. But TLS has now been extended to protect datagrams and IPsec= to authenticate users with SecurID cards. I don't know which is the more n= atural fit for Smart Grid, but I doubt it's both. Comments on the whole document: Section 1 para 3: re: picking a subset of protocols rather than protocol su= bsets. This makes sense for "old" protocols, like TCP, that have few option= s. It doesn't for "new" protocols, like PKIX, which allow variation without= end. Section 2.1.3.1: The Internet Layer here is what you called the Network Lay= er on the previous page (I think). Fragmentation and reassembly is only par= t of this layer any more if you hold your head just right. I'm not sure "id= entifying" a datagram's source and destination is properly the roll of this= layer. "Finding" the destination is more like it. This section describes t= he part of the IP layer implemented by endnodes. Most of IP is implemented = (today) in intermediate nodes. Would OSPF be a core protocol, or do you ass= ume these systems run atop an existing infrastructure? Section 2.2.1: Physical security: It's worth mentioning that many systems a= ssume physical security within some subnet (like a machine room or a corpor= ate intranet) and reflect that in believing that source and destination IP = addresses are authentic if they are both in a controlled range. One might q= uestion whether this is wise, but it is certainly common. Protocols often r= eflect assumptions about physical failures and attacks in the timeout/retry= parameters they choose. Section 2.2.2: The last paragraph seems to have fallen into this document f= rom somewhere else. Does it belong elsewhere? Section 2.3: DNS seems like a critical piece of making the Internet work. T= here might be applications that could live without it, but not many. Section 2.3.1: DNS also supports limited slow mobility. A service can move = and change IP address if everyone references it by DNS name. Section 3.1.2: It's misleading to say that IPsec implemented between the ro= uting and transport layer. That's true in transport mode, but in tunnel mod= e there is an IP header before and after the IPsec header (putting it in th= e middle of routing). Section 3.1.2: In the RFC list RFC4304 is the right RFC to reference but it= is not ISAKMP. RFC4309 specifies AES CCM mode, which I believe is not the = most commonly used cryptographic algorithm. Section 3.1.4: I'd be surprised if S/MIME was originally an extension to SM= TP. Even when S/MIME was PEM, it was largely transport independent (and des= igned to pass over X.400, which was a contender in those days). S/MIME - an= d more generally CMS - is not really a networking protocol at all. It is de= signed to protect data at rest. I can take a CMS protected file and send th= e pile of bits to you by floppy disk or paper tape. Years later, if you can= still read the media, you can still process it. It's a tough call whether = it is an Internet Core Protocol. It's certainly an important IETF protocol. Section 3.2: "the IPv6 space" -> "the size of the IPv6 address space" Section 3.2: "in the near term." -> "in the near term if interoperability w= ith existing IPv4-only systems is important." Section 3.2.1.1: It's worth noting that IPv4 addresses are typically admini= stratively assigned in blocks, which then get subdivided, and that they are= commonly handed out individually to client nodes using DHCP but that serve= rs typically need permanent IPv4 addresses so that other nodes can find the= m in DNS. Section 3.2.1.3: Avoid a common confusion by explaining that reliable in th= is case means that retries are automatic and that failures are reliably det= ected. Reliable Multicast can't get the data there if the network is broken= . Section 3.2.2.1: IPv6 also hands out addresses administratively in blocks w= hich are then subdivided. Autoconfiguration is only different from DHCP in = that you're "guaranteed" not to run out. Section 3.2.2.2: Mention that addresses are hierarchical when handed out ad= ministratively in order to keep routing tables from exploding in size. Between section 3.2.3 and 3.3: This would be a good place to remind people = of the "hourglass": many protocols above, many below, but a single IP in th= e middle. (Well IPv4 and IPv6, but that's "temporary"). Section 3.3.1, para 1: I would claim that UDP is a perfectly valid transpor= t protocol. It only appears not to be because it is the native mode of IP a= nd therefore seems natural. Running over X.25, TCP would seem like the null= protocol and UDP would be interesting and novel. Section 3.3.1, para 2: UDP has problems because it does not play well with = others in terms of congestion backoff. Does it have problems other than tha= t? Section 3.4.1, para 1, line 6: "all" -> "allow" Middle of page 22: "address/aport" -> "address/port" --_000_D80EDFF2AD83E648BD1164257B9B0912082E2E08TK5EX14MBXC115r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am reviewing this document as par= t of the security directorate's ongoing effort to review all IETF documents= being processed by the IESG.  These comments were written primarily f= or the benefit of the security area directors.  Others should treat th= ese comments just like any other last call comments. Feel free to forward t= o any appropriate forum.

&nb= sp;

This document (proposed as an Information= al RFC) summarizes the core protocols on which the Internet operates. It is= specifically targeted at NIST in the context of the Smart Grid discussion.= They are looking to “profile” a subset of the Internet Protoco= l Suite. Since the audience for this review is security focused, I’ll= talk about security first. But since I read it all, I’ll include com= ments on the rest too. I would encourage others to read the document. It= 217;s both informative and could generate a lively discussion about what co= nstitutes “the core”.

&= nbsp;

As a truly informational document, this= document has no security implications, though it does talk about security.= It considers IPsec, TLS, and S/MIME to be the core security protocols. I w= ould consider adding DNSSEC to that list, and possibly removing S/MIME, but= these three are certainly a reasonable place to start.

 

Section 3.1 attem= pts to explain why it’s natural for IPsec and TLS to both exist, and = reminded me how much each has encroached onto the territory of the other ma= king that task more difficult. I believe that the original distinction was = that IPsec was designed to be implemented in operating systems or networkin= g infrastructure in a way that was transparent to applications, while SSL w= as designed to be implemented in applications in a way that was transparent= to operating systems and networking infrastructure. That’s not a bit= s on the wire distinction, but I believe all the other differences derive f= rom that. But TLS has now been extended to protect datagrams and IPsec to a= uthenticate users with SecurID cards. I don’t know which is the more = natural fit for Smart Grid, but I doubt it’s both.

 

Comments on the = whole document:

 

Section 1 para 3: re: picking a subset of protocols rathe= r than protocol subsets. This makes sense for “old” protocols, = like TCP, that have few options. It doesn’t for “new” pro= tocols, like PKIX, which allow variation without end.

 

Section 2.1.3.1: Th= e Internet Layer here is what you called the Network Layer on the previous = page (I think). Fragmentation and reassembly is only part of this layer any= more if you hold your head just right. I’m not sure “identifyi= ng” a datagram’s source and destination is properly the roll of= this layer. “Finding” the destination is more like it. This se= ction describes the part of the IP layer implemented by endnodes. Most of I= P is implemented (today) in intermediate nodes. Would OSPF be a core protoc= ol, or do you assume these systems run atop an existing infrastructure?

 

S= ection 2.2.1: Physical security: It’s worth mentioning that many syst= ems assume physical security within some subnet (like a machine room or a c= orporate intranet) and reflect that in believing that source and destinatio= n IP addresses are authentic if they are both in a controlled range. One mi= ght question whether this is wise, but it is certainly common. Protocols of= ten reflect assumptions about physical failures and attacks in the timeout/= retry parameters they choose.

 = ;

Section 2.2.2: The last paragraph seems to = have fallen into this document from somewhere else. Does it belong elsewher= e?

 

Section 2.3: DNS seems like a critical piece of making the Internet wo= rk. There might be applications that could live without it, but not many.

 

Section 2.3.1: DNS also supports limited slow mobility. A service can move= and change IP address if everyone references it by DNS name.

 

Section 3.1= .2: It’s misleading to say that IPsec implemented between the routing= and transport layer. That’s true in transport mode, but in tunnel mo= de there is an IP header before and after the IPsec header (putting it in t= he middle of routing).

 =

Section 3.1.2: In the RFC list RFC4304 is the righ= t RFC to reference but it is not ISAKMP. RFC4309 specifies AES CCM mode, wh= ich I believe is not the most commonly used cryptographic algorithm. <= /o:p>

 

Sec= tion 3.1.4: I’d be surprised if S/MIME was originally an extension to= SMTP. Even when S/MIME was PEM, it was largely transport independent (and = designed to pass over X.400, which was a contender in those days). S/MIME &= #8211; and more generally CMS – is not really a networking protocol a= t all. It is designed to protect data at rest. I can take a CMS protected f= ile and send the pile of bits to you by floppy disk or paper tape. Years la= ter, if you can still read the media, you can still process it. It’s = a tough call whether it is an Internet Core Protocol. It’s certainly = an important IETF protocol.

 <= /o:p>

Section 3.2: “the IPv6 space” -&g= t; “the size of the IPv6 address space”

 

Section 3.2: “= in the near term.” -> “in the near term if interoperability = with existing IPv4-only systems is important.”

 

Section 3.2.1.1: It&= #8217;s worth noting that IPv4 addresses are typically administratively ass= igned in blocks, which then get subdivided, and that they are commonly hand= ed out individually to client nodes using DHCP but that servers typically n= eed permanent IPv4 addresses so that other nodes can find them in DNS.=

 

Se= ction 3.2.1.3: Avoid a common confusion by explaining that reliable in this= case means that retries are automatic and that failures are reliably detec= ted. Reliable Multicast can’t get the data there if the network is br= oken.

 

Section 3.2.2.1: IPv6 also hands out addresses administratively in = blocks which are then subdivided. Autoconfiguration is only different from = DHCP in that you’re “guaranteed” not to run out.

 

Sectio= n 3.2.2.2: Mention that addresses are hierarchical when handed out administ= ratively in order to keep routing tables from exploding in size.=

 

Between = section 3.2.3 and 3.3: This would be a good place to remind people of the &= #8220;hourglass”: many protocols above, many below, but a single IP i= n the middle. (Well IPv4 and IPv6, but that’s “temporary”= ).

 

Section 3.3.1, para 1: I would claim that UDP is a perfectly valid tra= nsport protocol. It only appears not to be because it is the native mode of= IP and therefore seems natural. Running over X.25, TCP would seem like the= null protocol and UDP would be interesting and novel.

 

Section 3.3.1, par= a 2: UDP has problems because it does not play well with others in terms of= congestion backoff. Does it have problems other than that?

<= p class=3DMsoNormal> 

Section 3.4.1= , para 1, line 6: “all” -> “allow”

 

Middle of p= age 22: “address/aport” -> “address/port”

= --_000_D80EDFF2AD83E648BD1164257B9B0912082E2E08TK5EX14MBXC115r_-- From fred@cisco.com Sat Nov 21 05:08:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0D83A686C; Sat, 21 Nov 2009 05:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw0AWSNw-iax; Sat, 21 Nov 2009 05:08:57 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CDCE03A682E; Sat, 21 Nov 2009 05:08:57 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAMN0B0tAaHte/2dsb2JhbACCIi65cZddhDwEgXCBEQ X-IronPort-AV: E=Sophos;i="4.47,264,1257120000"; d="scan'208,217";a="107575571" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2009 13:08:53 +0000 Received: from [192.168.24.77] (tky-vpn-client-230-1.cisco.com [10.70.230.1]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nALD8p5p024076; Sat, 21 Nov 2009 13:08:52 GMT Message-Id: <0A395F99-B665-43DC-BE24-CD4F69169913@cisco.com> From: Fred Baker To: Charlie Kaufman In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-86--818626926 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 21 Nov 2009 22:08:50 +0900 References: X-Mailer: Apple Mail (2.936) Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 13:08:59 -0000 --Apple-Mail-86--818626926 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Thanks. I'll review your comments next week when I'm at home :-) On Nov 21, 2009, at 1:41 PM, Charlie Kaufman wrote: > I am reviewing this document as part of the security directorate's =20 > ongoing effort to review all IETF documents being processed by the =20 > IESG. These comments were written primarily for the benefit of the =20= > security area directors. Others should treat these comments just =20 > like any other last call comments. Feel free to forward to any =20 > appropriate forum. > > This document (proposed as an Informational RFC) summarizes the core =20= > protocols on which the Internet operates. It is specifically =20 > targeted at NIST in the context of the Smart Grid discussion. They =20 > are looking to =93profile=94 a subset of the Internet Protocol Suite. =20= > Since the audience for this review is security focused, I=92ll talk =20= > about security first. But since I read it all, I=92ll include comments = =20 > on the rest too. I would encourage others to read the document. It=92s = =20 > both informative and could generate a lively discussion about what =20 > constitutes =93the core=94. > > As a truly informational document, this document has no security =20 > implications, though it does talk about security. It considers =20 > IPsec, TLS, and S/MIME to be the core security protocols. I would =20 > consider adding DNSSEC to that list, and possibly removing S/MIME, =20 > but these three are certainly a reasonable place to start. > > Section 3.1 attempts to explain why it=92s natural for IPsec and TLS =20= > to both exist, and reminded me how much each has encroached onto the =20= > territory of the other making that task more difficult. I believe =20 > that the original distinction was that IPsec was designed to be =20 > implemented in operating systems or networking infrastructure in a =20 > way that was transparent to applications, while SSL was designed to =20= > be implemented in applications in a way that was transparent to =20 > operating systems and networking infrastructure. That=92s not a bits =20= > on the wire distinction, but I believe all the other differences =20 > derive from that. But TLS has now been extended to protect datagrams =20= > and IPsec to authenticate users with SecurID cards. I don=92t know =20 > which is the more natural fit for Smart Grid, but I doubt it=92s both. > > Comments on the whole document: > > Section 1 para 3: re: picking a subset of protocols rather than =20 > protocol subsets. This makes sense for =93old=94 protocols, like TCP, =20= > that have few options. It doesn=92t for =93new=94 protocols, like = PKIX, =20 > which allow variation without end. > > Section 2.1.3.1: The Internet Layer here is what you called the =20 > Network Layer on the previous page (I think). Fragmentation and =20 > reassembly is only part of this layer any more if you hold your head =20= > just right. I=92m not sure =93identifying=94 a datagram=92s source and = =20 > destination is properly the roll of this layer. =93Finding=94 the =20 > destination is more like it. This section describes the part of the =20= > IP layer implemented by endnodes. Most of IP is implemented (today) =20= > in intermediate nodes. Would OSPF be a core protocol, or do you =20 > assume these systems run atop an existing infrastructure? > > Section 2.2.1: Physical security: It=92s worth mentioning that many =20= > systems assume physical security within some subnet (like a machine =20= > room or a corporate intranet) and reflect that in believing that =20 > source and destination IP addresses are authentic if they are both =20 > in a controlled range. One might question whether this is wise, but =20= > it is certainly common. Protocols often reflect assumptions about =20 > physical failures and attacks in the timeout/retry parameters they =20 > choose. > > Section 2.2.2: The last paragraph seems to have fallen into this =20 > document from somewhere else. Does it belong elsewhere? > > Section 2.3: DNS seems like a critical piece of making the Internet =20= > work. There might be applications that could live without it, but =20 > not many. > > Section 2.3.1: DNS also supports limited slow mobility. A service =20 > can move and change IP address if everyone references it by DNS name. > > Section 3.1.2: It=92s misleading to say that IPsec implemented between = =20 > the routing and transport layer. That=92s true in transport mode, but =20= > in tunnel mode there is an IP header before and after the IPsec =20 > header (putting it in the middle of routing). > > Section 3.1.2: In the RFC list RFC4304 is the right RFC to reference =20= > but it is not ISAKMP. RFC4309 specifies AES CCM mode, which I =20 > believe is not the most commonly used cryptographic algorithm. > > Section 3.1.4: I=92d be surprised if S/MIME was originally an =20 > extension to SMTP. Even when S/MIME was PEM, it was largely =20 > transport independent (and designed to pass over X.400, which was a =20= > contender in those days). S/MIME =96 and more generally CMS =96 is not = =20 > really a networking protocol at all. It is designed to protect data =20= > at rest. I can take a CMS protected file and send the pile of bits =20 > to you by floppy disk or paper tape. Years later, if you can still =20 > read the media, you can still process it. It=92s a tough call whether =20= > it is an Internet Core Protocol. It=92s certainly an important IETF =20= > protocol. > > Section 3.2: =93the IPv6 space=94 -> =93the size of the IPv6 address = space=94 > > Section 3.2: =93in the near term.=94 -> =93in the near term if =20 > interoperability with existing IPv4-only systems is important.=94 > > Section 3.2.1.1: It=92s worth noting that IPv4 addresses are typically = =20 > administratively assigned in blocks, which then get subdivided, and =20= > that they are commonly handed out individually to client nodes using =20= > DHCP but that servers typically need permanent IPv4 addresses so =20 > that other nodes can find them in DNS. > > Section 3.2.1.3: Avoid a common confusion by explaining that =20 > reliable in this case means that retries are automatic and that =20 > failures are reliably detected. Reliable Multicast can=92t get the =20 > data there if the network is broken. > > Section 3.2.2.1: IPv6 also hands out addresses administratively in =20 > blocks which are then subdivided. Autoconfiguration is only =20 > different from DHCP in that you=92re =93guaranteed=94 not to run out. > > Section 3.2.2.2: Mention that addresses are hierarchical when handed =20= > out administratively in order to keep routing tables from exploding =20= > in size. > > Between section 3.2.3 and 3.3: This would be a good place to remind =20= > people of the =93hourglass=94: many protocols above, many below, but a = =20 > single IP in the middle. (Well IPv4 and IPv6, but that=92s = =93temporary=94). > > Section 3.3.1, para 1: I would claim that UDP is a perfectly valid =20 > transport protocol. It only appears not to be because it is the =20 > native mode of IP and therefore seems natural. Running over X.25, =20 > TCP would seem like the null protocol and UDP would be interesting =20 > and novel. > > Section 3.3.1, para 2: UDP has problems because it does not play =20 > well with others in terms of congestion backoff. Does it have =20 > problems other than that? > > Section 3.4.1, para 1, line 6: =93all=94 -> =93allow=94 > > Middle of page 22: =93address/aport=94 -> =93address/port=94 --Apple-Mail-86--818626926 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Thanks. I'll review your = comments next week when I'm at home :-)

On Nov 21, = 2009, at 1:41 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.  Others should treat = these comments just like any other last call comments. Feel free to = forward to any appropriate forum.
This document (proposed as an = Informational RFC) summarizes the core protocols on which the Internet = operates. It is specifically targeted at NIST in the context of the = Smart Grid discussion. They are looking to =93profile=94 a subset of the = Internet Protocol Suite. Since the audience for this review is security = focused, I=92ll talk about security first. But since I read it all, I=92ll= include comments on the rest too. I would encourage others to read the = document. It=92s both informative and could generate a lively discussion = about what constitutes =93the core=94.
As a truly informational document, = this document has no security implications, though it does talk about = security. It considers IPsec, TLS, and S/MIME to be the core security = protocols. I would consider adding DNSSEC to that list, and possibly = removing S/MIME, but these three are certainly a reasonable place to = start.
 
Section 3.1 = attempts to explain why it=92s natural for IPsec and TLS to both exist, = and reminded me how much each has encroached onto the territory of the = other making that task more difficult. I believe that the original = distinction was that IPsec was designed to be implemented in operating = systems or networking infrastructure in a way that was transparent to = applications, while SSL was designed to be implemented in applications = in a way that was transparent to operating systems and networking = infrastructure. That=92s not a bits on the wire distinction, but I = believe all the other differences derive from that. But TLS has now been = extended to protect datagrams and IPsec to authenticate users with = SecurID cards. I don=92t know which is the more natural fit for Smart = Grid, but I doubt it=92s both.
Comments on the whole = document:
 
Section 2.1.3.1: The Internet Layer = here is what you called the Network Layer on the previous page (I = think). Fragmentation and reassembly is only part of this layer any more = if you hold your head just right. I=92m not sure =93identifying=94 a = datagram=92s source and destination is properly the roll of this layer. = =93Finding=94 the destination is more like it. This section describes = the part of the IP layer implemented by endnodes. Most of IP is = implemented (today) in intermediate nodes. Would OSPF be a core = protocol, or do you assume these systems run atop an existing = infrastructure?
 
 
 
 
Section 2.3.1: DNS = also supports limited slow mobility. A service can move and change IP = address if everyone references it by DNS name.
Section 3.1.2: It=92s misleading to = say that IPsec implemented between the routing and transport layer. = That=92s true in transport mode, but in tunnel mode there is an IP = header before and after the IPsec header (putting it in the middle of = routing).
 
Section 3.1.4: I=92d be surprised if = S/MIME was originally an extension to SMTP. Even when S/MIME was PEM, it = was largely transport independent (and designed to pass over X.400, = which was a contender in those days). S/MIME =96 and more generally CMS = =96 is not really a networking protocol at all. It is designed to = protect data at rest. I can take a CMS protected file and send the pile = of bits to you by floppy disk or paper tape. Years later, if you can = still read the media, you can still process it. It=92s a tough call = whether it is an Internet Core Protocol. It=92s certainly an important = IETF protocol.
 
 
 
 
 
 
Section 3.2.2.2: = Mention that addresses are hierarchical when handed out administratively = in order to keep routing tables from exploding in = size.
 
Between section = 3.2.3 and 3.3: This would be a good place to remind people of the = =93hourglass=94: many protocols above, many below, but a single IP in = the middle. (Well IPv4 and IPv6, but that=92s = =93temporary=94).
 
 
Section 3.3.1, para = 2: UDP has problems because it does not play well with others in terms = of congestion backoff. Does it have problems other than = that?
 
Section 3.4.1, para = 1, line 6: =93all=94 -> =93allow=94
Middle of page 22: =93address/aport=94= -> = =93address/port=94
<= br>
= --Apple-Mail-86--818626926-- From hallam@gmail.com Sat Nov 21 08:24:38 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592D83A69E6 for ; Sat, 21 Nov 2009 08:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIZK2dbswKEn for ; Sat, 21 Nov 2009 08:24:37 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 2E5BA3A69E4 for ; Sat, 21 Nov 2009 08:24:37 -0800 (PST) Received: by yxe30 with SMTP id 30so4578861yxe.29 for ; Sat, 21 Nov 2009 08:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RZdapHHnpdM72p0xl86AIh/lv6oU/hImMj3k2iQmfCU=; b=AE+sckYc9xEohlG4LCy/3qJ9iaPZECNxSnpceT20AJOlOc91lizRvCBWwQbAdhovRJ e2j/iMWKU1It2/T0qnNiSvlGyMeUTOk5gRoK+sl7UhixLDljK7dJQBeBDgz6vtbP6itv SaAhSuMWe+UurFi9T+ldOEU+kilRgcJ/XNwig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B3CSVSsXdZDu1okwIWoJW8oiObbA5dOjQrIeXsfV3ZrTIGONHTOmwgS2axPJzOrAuY eXSp85T5emZoXLHxvZ9Hqo+Wr8SW49qJ6e9m7fwVIrT9Jdlg/5B75HA4TyrFxWQXhTIQ lkLHqCCx6DNvySbtV9okvDy1du3LRkkzKnfZk= MIME-Version: 1.0 Received: by 10.90.16.38 with SMTP id 38mr4085910agp.112.1258820670590; Sat, 21 Nov 2009 08:24:30 -0800 (PST) In-Reply-To: <4B03E456.7040900@alcatel-lucent.com> References: <4B03E456.7040900@alcatel-lucent.com> Date: Sat, 21 Nov 2009 11:24:30 -0500 Message-ID: From: Phillip Hallam-Baker To: Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dward@cisco.com, malcolm.betts@huawei.com, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-tp-oam-requirements-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 16:24:38 -0000 Yes, that works for me. On Wed, Nov 18, 2009 at 7:11 AM, Martin Vigoureux wrote: > Dear Phillip, > > thanks for your review. > Would the following rephrasing (of the Security Considerations) > satisfy your expectations? > For your information, Tim Polk had a similar type of comment > as part of IESG Review and is ok with the text proposed below. > Thanks > > martin > > > OLD > =A0In general, mechanisms SHOULD be provided to ensure that OAM > =A0functions cannot be accessed unauthorized. > > =A0Further, OAM messages MAY be authenticated to prove their origin and > =A0to make sure that they are destined for the receiving node. > > =A0An OAM packet received over a PW, LSP or Section MUST NOT be > =A0forwarded beyond the End Point of that PW, LSP or Section, so as to > =A0avoid that the OAM packet leaves the current administrative domain. > NEW > =A0OAM systems (network management stations) SHOULD be designed such > =A0that OAM functions cannot be accessed without authorization. > > =A0OAM protocol solutions MUST include the facility for OAM messages to > =A0authenticated to prove their origin and to make sure that they are > =A0destined for the receiving node. The use of such facilities MUST be > =A0configurable. > > =A0An OAM packet received over a PW, LSP or Section MUST NOT be > =A0forwarded beyond the End Point of that PW, LSP or Section, so as to > =A0avoid that the OAM packet leaves the current administrative domain. > > > Phillip Hallam-Baker a =E9crit : >> >> I am reviewing this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. =A0These comments were written primarily for the benefit of the >> security area directors. =A0Document editors and WG chairs should treat >> these comments just like any other last call comments. Feel free to >> forward to any appropriate forum. >> >> >> This documents sets out requirements for Operations, Administration >> and Maintenance of MPLS Transport Profile. >> >> It is a high level architectural requirements document, intentionally >> separated from the details of specific implementations. As such it is >> appropriate for the security considerations section to be at a high >> level. >> >> It is however a mystery to this reader why encryption is specified as >> a should but integrity protections only merit a MAY. I would be much >> more reassured by a document that ignores confidentiality issues >> completely (as has been the general policy for low level routing &ct.) >> and points out the fact that this is yet another opportunity for a >> malicious party to play merry heck by introducing bogus data that >> other parts of the network will then operate on. >> >> For example, introduction of bogus messages would allow an attacker to >> reserve excessive bandwidth in the name of another party, possibly >> performing a DoS attack or possibly to perform a financial fraud, >> causing some party to incur costs for bandwidth not required. >> >> In comparison the confidentiality issues are rather minor, and in any >> event almost certainly subsumed by the fact that anyone who can >> observe the content of the OAM packets can almost certainly observe >> the volumes of the data flows and infer that information. While >> confidentiality is a nice to have, it is not worth much without >> integrity. >> >> I suggest that the security considerations section makes the ability >> to support integrity protections a MUST or SHOULD requirement. If only >> a SHOULD is applied, confidentiality would be better demoted to MAY. >> > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From smb@cs.columbia.edu Sat Nov 21 09:03:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29F33A69A0; Sat, 21 Nov 2009 09:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umW5rpMSa6mY; Sat, 21 Nov 2009 09:03:11 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 94E6B3A6906; Sat, 21 Nov 2009 09:03:11 -0800 (PST) Received: from [192.168.2.182] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nALH34p3007857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 21 Nov 2009 12:03:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Steven Bellovin In-Reply-To: Date: Sat, 21 Nov 2009 12:03:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <988E4A1D-518B-467F-97A1-3087CE6D071A@cs.columbia.edu> References: To: Charlie Kaufman X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.7 Cc: "fred@cisco.com" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 17:03:12 -0000 On Nov 20, 2009, at 11:41 PM, Charlie Kaufman wrote: > =20 > Section 3.1.4: I=92d be surprised if S/MIME was originally an = extension to SMTP. Even when S/MIME was PEM, it was largely transport = independent (and designed to pass over X.400, which was a contender in = those days). S/MIME =96 and more generally CMS =96 is not really a = networking protocol at all. It is designed to protect data at rest. I = can take a CMS protected file and send the pile of bits to you by floppy = disk or paper tape. Years later, if you can still read the media, you = can still process it. It=92s a tough call whether it is an Internet Core = Protocol. It=92s certainly an important IETF protocol. That section is incorrect in several respects, in my opinion. First, = S/MIME doesn't protect "SMTP Mail", in my opinion, since to me "SMTP" is = referring to the 821/2821/5321 parts of the protocol. S/MIME is more = for the 822/2822/5322 parts. More precisely, S/MIME is a way to put in = security at the MIME layer (references omitted), which in turn extend = 822/2822/5322. The distinction is important because HTTP uses MIME but = not SMTP. (It could have used S/MIME, but that's a separate wistful = thread.) Second, it's an interesting question if CMS should be = mentioned separately -- you can't do S/MIME without CMS. --Steve Bellovin, http://www.cs.columbia.edu/~smb From hallam@gmail.com Sat Nov 21 12:42:42 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495A63A67AC; Sat, 21 Nov 2009 12:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1lIZWdBj+z7; Sat, 21 Nov 2009 12:42:40 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 87C823A682F; Sat, 21 Nov 2009 12:42:40 -0800 (PST) Received: by ywh15 with SMTP id 15so4218858ywh.5 for ; Sat, 21 Nov 2009 12:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zVqqxNyO6m1vrifW3LwZrbExMWyM/W1PqcyP8m/JV5w=; b=NQxMUh1uAnIucKOUPlCvvdKvzTJ2p65U6ospQuIZMIfYHz4KiTJ8oK37rEc1X+tpv0 hLnEKzoc2Z8xnjihjHXElTpEwfYm3/7PVha3+le18LbkJyRBBxjss7/pD1cnz0uRcaOW 9ILYJKLc8pB13+LLrfK7aYBSlT3kn0JnXMQh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZW0tdRdoTNLouMsnTRFSOKN8287f2KzttJuj5yNXftpbWXFloBjJTfvr0g4K6LSRt6 Mf45U1nlpjvp99Jw2POkpfNsL2ddJC4DMtvzp7ZwLzvY+EuopUqmt4x9W5+qcUDTGDJf F20RyuzmaA+d5IeRXrB8A/8JAMlXk2liGVB/0= MIME-Version: 1.0 Received: by 10.91.18.24 with SMTP id v24mr4463679agi.61.1258836153936; Sat, 21 Nov 2009 12:42:33 -0800 (PST) In-Reply-To: <988E4A1D-518B-467F-97A1-3087CE6D071A@cs.columbia.edu> References: <988E4A1D-518B-467F-97A1-3087CE6D071A@cs.columbia.edu> Date: Sat, 21 Nov 2009 15:42:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Steven Bellovin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "secdir@ietf.org" , "fred@cisco.com" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 20:42:42 -0000 You can however do CMS without S/MIME. I agree that we should regard S/MIME as an extension to MIME. But the origin was really to take the RSA developed PKCS#7 technology and apply it to MIME. There really isn't much of a link there to the PEM work. The IETF attempt to resurrect PEM in MIME was MOSS. The problem here is trying to cram everything into a layered model in the OSI style. These attempts always fail because the IETF protocols are not a layered architecture. It is much more like a web of modules that expose interfaces to other co-operating modules. While there is a rough conceptual organization according to the degree of abstraction, this is not the only organization present and it is nowhere near as rigid as in the OSI model. The point about S/MIME being protection of data at rest is a critical one. We do in fact have a security layer for SMTP - TLS. More mail is secured using TLS than any other mail encryption protocol. The point being that smart grid is not an opportunity for the IETF to roll out the architecture that they would have liked to have developed rather than the one that did develop. Some of the differences can be explained by path dependence, but quite a few can be explained by the market having made the better choice. On Sat, Nov 21, 2009 at 12:03 PM, Steven Bellovin wro= te: > > On Nov 20, 2009, at 11:41 PM, Charlie Kaufman wrote: > >> >> Section 3.1.4: I=92d be surprised if S/MIME was originally an extension = to SMTP. Even when S/MIME was PEM, it was largely transport independent (an= d designed to pass over X.400, which was a contender in those days). S/MIME= =96 and more generally CMS =96 is not really a networking protocol at all.= It is designed to protect data at rest. I can take a CMS protected file an= d send the pile of bits to you by floppy disk or paper tape. Years later, i= f you can still read the media, you can still process it. It=92s a tough ca= ll whether it is an Internet Core Protocol. It=92s certainly an important I= ETF protocol. > > That section is incorrect in several respects, in my opinion. =A0First, S= /MIME doesn't protect "SMTP Mail", in my opinion, since to me "SMTP" is ref= erring to the 821/2821/5321 parts of the protocol. =A0S/MIME is more for th= e 822/2822/5322 parts. =A0More precisely, S/MIME is a way to put in securit= y at the MIME layer (references omitted), which in turn extend 822/2822/532= 2. =A0The distinction is important because HTTP uses MIME but not SMTP. =A0= (It could have used S/MIME, but that's a separate wistful thread.) =A0Secon= d, it's an interesting question if CMS should be mentioned separately -- yo= u can't do S/MIME without CMS. > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--Steve Bellovin, http://www.cs.columbia.e= du/~smb > > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From fred@cisco.com Sat Nov 21 13:06:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04423A6849; Sat, 21 Nov 2009 13:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.435 X-Spam-Level: X-Spam-Status: No, score=-106.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 NO4v5bLcd-k1; Sat, 21 Nov 2009 13:06:05 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 881CC3A6405; Sat, 21 Nov 2009 13:06:05 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI/kB0tAaHte/2dsb2JhbAC8A5cahDwEgwGKCw X-IronPort-AV: E=Sophos;i="4.47,264,1257120000"; d="scan'208";a="52372946" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 21 Nov 2009 21:06:00 +0000 Received: from [192.168.24.77] (tky-vpn-client-231-90.cisco.com [10.70.231.90]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nALL5xsb012538; Sat, 21 Nov 2009 21:05:59 GMT Message-Id: <493132B2-1F3F-4B6B-938A-A9E927523CF9@cisco.com> From: Fred Baker To: Phillip Hallam-Baker , "Steven M. Bellovin" , Charlie Kaufman In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 22 Nov 2009 06:05:57 +0900 References: <988E4A1D-518B-467F-97A1-3087CE6D071A@cs.columbia.edu> X-Mailer: Apple Mail (2.936) Cc: "iesg@ietf.org IESG" , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 21:06:06 -0000 Hmm. I wonder of one of the directorate members would like to suggest =20= better text for the section? I don't claim any expertise on that topic. On Nov 22, 2009, at 5:42 AM, Phillip Hallam-Baker wrote: > You can however do CMS without S/MIME. > > I agree that we should regard S/MIME as an extension to MIME. But the > origin was really to take the RSA developed PKCS#7 technology and > apply it to MIME. There really isn't much of a link there to the PEM > work. The IETF attempt to resurrect PEM in MIME was MOSS. > > > The problem here is trying to cram everything into a layered model in > the OSI style. These attempts always fail because the IETF protocols > are not a layered architecture. It is much more like a web of modules > that expose interfaces to other co-operating modules. While there is a > rough conceptual organization according to the degree of abstraction, > this is not the only organization present and it is nowhere near as > rigid as in the OSI model. > > The point about S/MIME being protection of data at rest is a critical > one. We do in fact have a security layer for SMTP - TLS. More mail is > secured using TLS than any other mail encryption protocol. > > The point being that smart grid is not an opportunity for the IETF to > roll out the architecture that they would have liked to have developed > rather than the one that did develop. Some of the differences can be > explained by path dependence, but quite a few can be explained by the > market having made the better choice. > > > On Sat, Nov 21, 2009 at 12:03 PM, Steven Bellovin =20 > wrote: >> >> On Nov 20, 2009, at 11:41 PM, Charlie Kaufman wrote: >> >>> >>> Section 3.1.4: I=92d be surprised if S/MIME was originally an =20 >>> extension to SMTP. Even when S/MIME was PEM, it was largely =20 >>> transport independent (and designed to pass over X.400, which was =20= >>> a contender in those days). S/MIME =96 and more generally CMS =96 is = =20 >>> not really a networking protocol at all. It is designed to protect =20= >>> data at rest. I can take a CMS protected file and send the pile of =20= >>> bits to you by floppy disk or paper tape. Years later, if you can =20= >>> still read the media, you can still process it. It=92s a tough call =20= >>> whether it is an Internet Core Protocol. It=92s certainly an =20 >>> important IETF protocol. >> >> That section is incorrect in several respects, in my opinion. =20 >> First, S/MIME doesn't protect "SMTP Mail", in my opinion, since to =20= >> me "SMTP" is referring to the 821/2821/5321 parts of the protocol. =20= >> S/MIME is more for the 822/2822/5322 parts. More precisely, S/MIME =20= >> is a way to put in security at the MIME layer (references omitted), =20= >> which in turn extend 822/2822/5322. The distinction is important =20 >> because HTTP uses MIME but not SMTP. (It could have used S/MIME, =20 >> but that's a separate wistful thread.) Second, it's an interesting =20= >> question if CMS should be mentioned separately -- you can't do S/=20 >> MIME without CMS. >> >> >> --Steve Bellovin, http://www.cs.columbia.edu/~smb >> >> >> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> > > > > --=20 > --=20 > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ From smb@cs.columbia.edu Sat Nov 21 14:13:38 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADA93A69F7; Sat, 21 Nov 2009 14:13:38 -0800 (PST) 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 XVFcSp4wGzh8; Sat, 21 Nov 2009 14:13:37 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 4941D3A6952; Sat, 21 Nov 2009 14:13:36 -0800 (PST) Received: from [192.168.2.182] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nALMDTV4017924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 21 Nov 2009 17:13:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Sat, 21 Nov 2009 17:13:28 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <988E4A1D-518B-467F-97A1-3087CE6D071A@cs.columbia.edu> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "secdir@ietf.org" , "fred@cisco.com" , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 22:13:38 -0000 On Nov 21, 2009, at 3:42 PM, Phillip Hallam-Baker wrote: > You can however do CMS without S/MIME. Precisely my point. > > I agree that we should regard S/MIME as an extension to MIME. But the > origin was really to take the RSA developed PKCS#7 technology and > apply it to MIME. There really isn't much of a link there to the PEM > work. The IETF attempt to resurrect PEM in MIME was MOSS. > .... > > The point about S/MIME being protection of data at rest is a critical > one. Right -- what should we recommend? > We do in fact have a security layer for SMTP - TLS. More mail is > secured using TLS than any other mail encryption protocol. Yes, but not really relevant for this section. --Steve Bellovin, http://www.cs.columbia.edu/~smb From phoffman@imc.org Sun Nov 22 10:11:46 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8374B3A68AF; Sun, 22 Nov 2009 10:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkSKi4dvy86M; Sun, 22 Nov 2009 10:11:44 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 987EE3A6984; Sun, 22 Nov 2009 10:11:43 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAMIBQqR048805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Nov 2009 11:11:34 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <493132B2-1F3F-4B6B-938A-A9E927523CF9@cisco.com> References: <988E4A1D-518B-467F-97A1-3087CE6D071A@cs.columbia.edu> <493132B2-1F3F-4B6B-938A-A9E927523CF9@cisco.com> Date: Sun, 22 Nov 2009 10:11:22 -0800 To: Fred Baker From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "iesg@ietf.org IESG" , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 18:11:46 -0000 At 6:05 AM +0900 11/22/09, Fred Baker wrote: >Hmm. I wonder of one of the directorate members would like to suggest better text for the section? I don't claim any expertise on that topic. 3.1.4 Cryptographic Message Syntax (CMS) The CMS [RFC3852] specification defines how to digitally sign, digest, authenticate, and encrypt message content. It is commonly used for email with S/MIME [RFC3851] and other message-based (as compared to session-based) protocols. From Nicolas.Williams@sun.com Mon Nov 23 09:04:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23183A68DE; Mon, 23 Nov 2009 09:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+C+M6Q+Vsk5; Mon, 23 Nov 2009 09:04:23 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id AAACE28C0DC; Mon, 23 Nov 2009 09:04:22 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nANH4I5j012734; Mon, 23 Nov 2009 17:04:18 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 nANH4GUh062446; Mon, 23 Nov 2009 10:04:16 -0700 (MST) 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 nANGqZPi004019; Mon, 23 Nov 2009 10:52:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nANGqYsE004018; Mon, 23 Nov 2009 10:52:34 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 23 Nov 2009 10:52:34 -0600 From: Nicolas Williams To: Glen Zorn Message-ID: <20091123165233.GJ773@Sun.COM> References: <000001ca6a19$665b3320$33119960$@net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001ca6a19$665b3320$33119960$@net> User-Agent: Mutt/1.5.7i Cc: simon@josefsson.org, secdir@ietf.org, 'Kurt Zeilenga' , iesg@ietf.org, 'Alexey Melnikov' Subject: Re: [secdir] secdir review of draft-ietf-sasl-gs2-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:04:24 -0000 On Fri, Nov 20, 2009 at 02:39:59PM -0500, Glen Zorn wrote: > GENERAL COMMENTS > The reference to a document is not the document; for example, in the > following excerpt from section 2, there are no names defined in the > reference to RFC 2743: > The document uses many terms and function names defined in [RFC2743] > as updated by [RFC5554]. > Please change to something like > The document uses many terms and function names defined in RFC 2743 > [RFC2743] > as updated by RFC 5554 [RFC5554]. > Note that this comment applies globally to all such usages in the document. I'm with Alexey on this. The RFC Editor might even re-write this by replacing the reference with the full title and reference. (Personally I very much dislike unnecessary redundancy, as in "defined in RFC 2743 [RFC2743]", but whatever style the RFC Editor thinks is appropriate and consistent with current RFC Editor practice is what we should go with. > ABSTRACT > The last sentence of the Abstract says: "See > for more information." Unless the > referenced URL is intended to be permanently available (and probably even > then), this line should be removed before publication as an RFC. I think that's clearly not intended to remain in the final RFC, but to help reviewers understand the progression. I agree that this is best placed in a changelog-type section, but at this point it does not matter. > In paragraph 5, "The [RFC2743] section 3.1 initial context token header" has > the sound of GSSAPI "code words" ;-). Suggest changing to "The GSSAPIv2 > initial context token header (see section 3.1 of RFC 2743 [RFC2743])" or > some such. My attitude is that different technologies tend to have different terminology, and we can't forever be explaining it when we have documents that deal with more than one technology. In this case the reader is expected to, and indeed must have some familiarity with both, SASL and the GSS-API. I'm not sure how we could avoid that. The text in qquestion is very specific as to where you'll find the definition of "initial context token header": RFC2743, section 3.1. That should suffice; it's certainly better than writing a lengthy exposition on what a context token is, what an initial context token is, what an "initial context token header" is, and why it's there. (Also, FYI it's GSS-API, or GSS-API v2, update 1 -- not "GSSAPIv2". One of the many _annoying_ terminology bridging problems of the past is that the original SASL/GSS-API bridge wasn't named properly. As a result "GSS-API" means one thing, and "GSSAPI" (without the hyphen) can mean another, and you have to know the context in order to tell which it is. Better to always be careful to include the hyphen. This is really, really annoying. I hope this document will put that problem to bed for good once GS2 is widely adopted..) > SECTION 5 > I find this section rather difficult to understand: not all of the possible > combinations of gs2-cb-flag and server support for channel bindings seem to > be covered. A table might help, if not for that the gs2-cb-flag is > tri-valued & used to signal two different things. I believe we handled all cases. There are three flag values and two server support alternatives. I suppose we can add a table, something like: FLAG SERVER CB SUPPORT DISPOSITION ---- ----------------- ----------- n Irrelevant If server disallows non-channel- bound authentication, then fail y CB not supported Authentication may succeed y CB supported Authentication must fail p CB supported Authentication may succeed, with CB used p CB not supported Authentication will fail CB not supported Client does not even try because it insists on CB Note the use of 'may', 'must' and 'will' in the above. "Authentication must fail" means that the server must fail authentication. "Authentication will fail" means that the GS2 message exchange will proceed but authentication will necessarily fail as a result of CB inputs differing on the client and server side. > SECTION 6 > This section needs a lot of work if it is expected to be understood by > non-members of the Illuminati ;->. Just one example (of many possible): > > Example #3: a two round-trip GSS-API context token exchange, no > channel binding, no standard token header. > > C: Request authentication exchange > S: Empty Challenge > C: F,n,, standard header> > S: Send reply context token as is > C: Send reply context token as is > S: Send reply context token as is > C: Empty message > S: Outcome of authentication exchange > > What does this mean? What do 'F' & 'n' stand for? How is it useful? It > might be claimed that these questions could be answered by dissecting the > ABNF for the gs2 header, but I don't think that's a good answer: examples > should be self-contained. I don't agree. Example protocol exchanges need to be simplified -- we're trying show what the flows look like, not to be exacting in detail. The more explanation the example needs, the less clear it obviously is. In the example above the "" makes it clear, if you've read the preceding sections, that the "F,n,," part is the GS2 header. We could add quotes to the F,n,, part, if you think that will help. > The first paragraph says: > > GS2 does not use any GSS-API per-message tokens. Therefore the > setting of req_flags related to per-message tokens is irrelevant. > > OK, but what should the client and server behavior should be WRT the flags? There's no actual behavior w.r.t. req_flags and ret_flags. The GSS-API mechanism is free to enable per-msg token features not requested by the caller, but they are truly irrelevant: the application won't be using per-msg tokens. It may make things simpler if we explicitly require that req_flags not be set: GS2 does not use any GSS-API per-message tokens. Therefore the per-message token ret_flags from GSS_Init_sec_context() and GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT set the per-message req_flags. Thanks! Nico -- From alexey.melnikov@isode.com Mon Nov 23 13:46:27 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4C928C1CB; Mon, 23 Nov 2009 13:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 hM6VsnK90Cr1; Mon, 23 Nov 2009 13:46:27 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CA64928C1C9; Mon, 23 Nov 2009 13:46:26 -0800 (PST) Received: from [172.16.2.197] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 23 Nov 2009 21:46:21 +0000 Message-ID: <4B0B0298.70309@isode.com> Date: Mon, 23 Nov 2009 21:46:00 +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: Nicolas Williams References: <000001ca6a19$665b3320$33119960$@net> <20091123165233.GJ773@Sun.COM> In-Reply-To: <20091123165233.GJ773@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, simon@josefsson.org, 'Kurt Zeilenga' , Glen Zorn , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sasl-gs2-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:46:27 -0000 Nicolas Williams wrote: >On Fri, Nov 20, 2009 at 02:39:59PM -0500, Glen Zorn wrote: > > >>The first paragraph says: >> >> GS2 does not use any GSS-API per-message tokens. Therefore the >> setting of req_flags related to per-message tokens is irrelevant. >> >>OK, but what should the client and server behavior should be WRT the flags? >> >> >There's no actual behavior w.r.t. req_flags and ret_flags. The GSS-API >mechanism is free to enable per-msg token features not requested by the >caller, but they are truly irrelevant: the application won't be using >per-msg tokens. It may make things simpler if we explicitly require >that req_flags not be set: > > GS2 does not use any GSS-API per-message tokens. Therefore the > per-message token ret_flags from GSS_Init_sec_context() and > GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT > set the per-message req_flags. > I agree this would be an improvement. > > > From tlyu@MIT.EDU Mon Nov 23 21:33:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA83F3A6862; Mon, 23 Nov 2009 21:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 1k4Zwj8uk68C; Mon, 23 Nov 2009 21:33:15 -0800 (PST) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 02B313A67B4; Mon, 23 Nov 2009 21:33:14 -0800 (PST) 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 nAO5WfrO005440; Tue, 24 Nov 2009 00:32:44 -0500 (EST) 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 nAO5TLHo021954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 00:29:21 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id nAO5T9MX023407; Tue, 24 Nov 2009 00:29:09 -0500 (EST) To: secdir@ietf.org, iesg@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-lsp-dmpp@tools.ietf.org From: Tom Yu Date: Tue, 24 Nov 2009 00:29:09 -0500 Message-ID: Lines: 48 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 Subject: [secdir] secdir review of draft-ietf-ccamp-lsp-dppm-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:33:15 -0000 This document appears to define a set of performance metrics for characterizing dynamic LSP provisioning performance in GMPLS networks. Editorial: The document claims (in the Introduction) that these metrics characterize the performance of the signaling protocol. I find that the metrics more accurately measure the performance of the LSP setup and teardown operations, and are only tangentially related to the performance of the signaling protocol (unless somehow the performance of the signaling protocol implicitly includes the actions that the routers take in response, in which case I think the document should state it more plainly.) Security: [Most of these are probably minor points merely requiring clarifying text.] The Security Considerations section mentions the consequences of active traffic injection into the control plane, including skewing the results of measurements and causing congestion and denial of service. If the injected control traffic is expected to have the potential effect of enabling dramatically more data traffic, I think this effect should also be included in the Security Considerations, perhaps with advice to select probing control messages that do not materially alter the flow of data channel traffic. This document does not address security considerations related to the protocols communicating of the results of the measurements, or of any protocol used to request initiation of a measurement, perhaps because this document does not specify such protocols. I assume that these any document that specifies such other protocols will cover those security considerations, even if this document does not obviously refer to such specifications. On the other hand, if this document is intended as guidance for protocol specifications that describe implementation of the measurement of and communication of these metrics, perhaps it should also outline the security considerations that those additional protocol specifications should address. For example, what sort of authentication is required in a protocol that initiates a measurement of these metrics? It's not completely clear to me what sort of threat the passive measurement scenario involves; perhaps a router could repeatedly and with high frequency initiate LSP changes that overwhelm the monitoring channel? From pfaltstr@cisco.com Tue Nov 24 08:46:11 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB8B28C123; Tue, 24 Nov 2009 08:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1LivTSxqf0e; Tue, 24 Nov 2009 08:46:10 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 95F5F3A6B4B; Tue, 24 Nov 2009 08:46:03 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJicC0tAZnwM/2dsb2JhbAC+FJgEhDkE X-IronPort-AV: E=Sophos;i="4.47,280,1257120000"; d="scan'208";a="203715307" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2009 16:45:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAOGjcZ0002166; Tue, 24 Nov 2009 16:45:58 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 17:45:49 +0100 Received: from [192.165.72.14] ([10.55.91.228]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 17:45:49 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4C70B55D-9260-429A-9B2D-CE355C282BF4@google.com> Date: Tue, 24 Nov 2009 17:45:48 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4AD9BF2E.8010606@hyperthought.com> <4C70B55D-9260-429A-9B2D-CE355C282BF4@google.com> To: Vint Cerf X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 24 Nov 2009 16:45:49.0574 (UTC) FILETIME=[93E1B260:01CA6D25] X-Mailman-Approved-At: Tue, 24 Nov 2009 11:08:12 -0800 Cc: secdir@ietf.org, idnabis-chairs@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-idnabis-tables-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:46:11 -0000 This is taken care of in the new (-08) version of the document. Patrik On 17 okt 2009, at 18.01, Vint Cerf wrote: > scott, good point - we will attend to this editorial suggestion. > > v > > On Oct 17, 2009, at 8:57 AM, Scott G. Kelly wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> The document specifies rules for deciding whether a code point should be >> included in an Internationalized Domain Name. It's a member of a >> 4-document group, and as Paul pointed out in a related review, should be >> considered as such. >> >> The security considerations section consists of one sentence: >> >> "The security issues associated with this work are discussed in >> [IDNA2008-protocol]." >> >> Following that link to the protocol document's security considerations >> section: >> >> "Security Considerations for this version of IDNA, except for the >> special issues associated with right to left and characters, are >> described in [IDNA2008-Defs]. Specific issues for labels containing >> characters associated with scripts written right to left appear in >> [IDNA2008-BIDI]." >> >> The security considerations in those two documents (especially the >> protocol document) do seem to cover the issues, although like Sam, I >> don't feel qualified to definitively state this, and so I think the >> security ADs should pay some attention to this collection of documents. >> >> Editorially, one might consider removing the reference indirection and >> pointing the reader directly at [IDNA2008-Defs] and [IDNA2008-BIDI]. >> >> --Scott > From secdir-bounces@mit.edu Tue Nov 24 10:00:26 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00A63A696B for ; Tue, 24 Nov 2009 10:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.892 X-Spam-Level: X-Spam-Status: No, score=-103.892 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_40=-0.185, 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 tW8Alo8yXPUx for ; Tue, 24 Nov 2009 10:00:25 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 05E4628C146 for ; Tue, 24 Nov 2009 10:00:23 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id nAOI0HJQ013459 for ; Tue, 24 Nov 2009 13:00:17 -0500 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 nAOI0GYo013450 for ; Tue, 24 Nov 2009 13:00:16 -0500 Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id nAOHvP6x012812 for ; Tue, 24 Nov 2009 13:00:25 -0500 (EST) X-AuditID: 1209190c-b7ca4ae0000075eb-c9-4b0c1f21c99a Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by (Symantec Brightmail Gateway) with SMTP id AA.47.30187.12F1C0B4; Tue, 24 Nov 2009 13:00:01 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B456628C14A; Tue, 24 Nov 2009 10:00:04 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2BDA23A69CE; Tue, 24 Nov 2009 10:00:01 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20091124180002.2BDA23A69CE@core3.amsl.com> Date: Tue, 24 Nov 2009 10:00:02 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Brightmail-Tracker: AAAABBHIIFARyCm6EcgsOhHLcZY= X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 24 Nov 2009 11:08:12 -0800 Subject: [secdir] [New-work] WG Review: HTTP State Management Mechanism (httpstate) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:00:27 -0000 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 Tuesday, December 1, 2009. HTTP State Management Mechanism (httpstate) --------------------------------------------------- Current Status: Proposed Working Group Last modified: 2009-11-11 Chair(s): TBD Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: http-state@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/http-state Archive: http://www.ietf.org/mail-archive/web/http- state/current/maillist.html Alternative Archive: http://groups.google.com/group/http-state Description of Working Group: The HTTP State Management Mechanism (aka Cookies) was originally created by Netscape Communications in their informal Netscape cookie specification ("cookie_spec.html"), from which formal specifications RFC 2109 and RFC 2965 evolved. The formal specifications, however, were never fully implemented in practice; RFC 2109, in addition to cookie_spec.html, more closely resemble real-world implementations than RFC 2965, even though RFC 2965 officially obsoletes the former. Compounding the problem are undocumented features (such as HTTPOnly), and varying behaviors among real-world implementations. The working group will create a new RFC that obsoletes RFC 2109 and specifies Cookies as they are actually used in existing implementations and deployments. Where differences exist among the most commonly used implementations, the working group will document the variations. Where consensus exists among the most commonly used implementations, the working group will specify the consensus behavior. The working group must not introduce any new syntax or new semantics not already in common use. The working group's specific deliverables are: * A standards-track document that is suitable to supersede RFC 2109 (likely based on draft-abarth-cookie) * An informational document cataloguing the differences between major implementations In doing so, the working group should consider: * cookie_spec.html - Netscape Cookie Specification http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsre f/std/cookie_spec.html * RFC 2109 - HTTP State Management Mechanism (Obsoleted by RFC 2965) http://tools.ietf.org/html/rfc2109 * RFC 2964 - Use of HTTP State Management http://tools.ietf.org/html/rfc2964 * RFC 2965 - HTTP State Management Mechanism (Obsoletes RFC 2109) http://tools.ietf.org/html/rfc2965 * I-D - HTTP State Management Mechanism v2 http://tools.ietf.org/html/draft-pettersen-cookie-v2 * I-D - Cookie-based HTTP Authentication http://tools.ietf.org/html/draft-broyer-http-cookie-auth * Widely Implemented - HTTPOnly http://www.owasp.org/index.php/HTTPOnly * Browser Security Handbook - Cookies http://code.google.com/p/browsersec/wiki/Part2#Same- origin_policy_for_cookies * HTTP Cookies: Standards, Privacy, and Politics by David M. Kristol http://arxiv.org/PS_cache/cs/pdf/0105/0105018v1.pdf Goals and Milestones: Jan 2010 - Feature-complete Internet-Draft of Cookie specification Mar 2010 - Feature-complete test suite of Cookie specification May 2010 - First fully conforming implementation in a major browser Jul 2010 - Last Call for Cookie specification Sep 2010 - Second fully conforming implementation in a major browser Nov 2010 - Submit Cookie specification to IESG for consideration as a Draft Standard Nov 2010 - Submit deviation description to IESG for consideration 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 From petithug@acm.org Wed Nov 25 09:53:18 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CEE3A6AFE; Wed, 25 Nov 2009 09:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNKpBvZVEPbU; Wed, 25 Nov 2009 09:53:17 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 436A33A6AFD; Wed, 25 Nov 2009 09:53:17 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id EFEDEDFC40E0; Wed, 25 Nov 2009 17:53:11 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 0B681DFC40DE; Wed, 25 Nov 2009 17:53:10 +0000 (UTC) Message-ID: <4B0D6F06.6040408@acm.org> Date: Wed, 25 Nov 2009 09:53:10 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: behave@ietf.org References: <20091125174501.DB6DA3A6AF2@core3.amsl.com> In-Reply-To: <20091125174501.DB6DA3A6AF2@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 Nov 2009 11:09:53 -0800 Cc: ops-dir@ietf.org, uri-review@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [BEHAVE] I-D Action:draft-ietf-behave-turn-uri-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:53:18 -0000 This new version removes completely the text about the turn and turns URIs. The removed text was moved to draft-petithuguenin-behave-turn-uri-bis. The reference implementation was updated to reflect this split: http://ietf.implementers.org/turn-uri-0.3.zip Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > > Title : Traversal Using Relays around NAT (TURN) Resolution Mechanism > Author(s) : M. Petit-Huguenin > Filename : draft-ietf-behave-turn-uri-05.txt > Pages : 13 > Date : 2009-11-25 > > This document defines a resolution mechanism to generate a list of > server transport addresses that can be tried to create a Traversal > Using Relays around NAT (TURN) allocation. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From canetti@tau.ac.il Fri Nov 27 08:15:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25CE3A69C0; Fri, 27 Nov 2009 08:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOueMAObYIrH; Fri, 27 Nov 2009 08:15:58 -0800 (PST) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by core3.amsl.com (Postfix) with ESMTP id 6BB0B3A6970; Fri, 27 Nov 2009 08:15:57 -0800 (PST) Received: from [10.0.0.2] (bzq-80-27-10.red.bezeqint.net [82.80.27.10]) by doar.tau.ac.il (Postfix) with ESMTP id F2021BEF8; Fri, 27 Nov 2009 18:15:49 +0200 (IST) Message-ID: <4B0FFB32.5090303@tau.ac.il> Date: Fri, 27 Nov 2009 18:15:46 +0200 From: Ran Canetti User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: secdir , nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Nov 2009 09:12:14 -0800 Subject: [secdir] Security review of http://www.ietf.org/id/draft-ietf-nsis-qos-nslp-17.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:28:13 -0000 *** I have reviewed this document as part of the security directorate's *** ongoing effort to review all IETF documents being processed by the *** IESG. These comments were written primarily for the benefit of the *** security area directors. Document editors and WG chairs should treat *** these comments just like any other last call comments. The document describes the NSIS signaling layer protocol, for signaling QOS reservations. The document builds on extensive ground work in the NSIS WG - in particular a requirements document (RFC 3726), a security threats document (RFC 4081), and a framework document (RFC 4080). Indeed, overall the document seems well thought out. I didn't find any issues with the proposed protocol in of itself. Here are some general remarks/thoughts that came to mind, and some nits: - regarding the NJT analogy (section 7.2) - on the NJT all payments are made to a single entity, thus this "pricing by distance" is easy. On the internet there are multiple independent business entities (eg, ISPs)... Does the protocol provide a way for the client to avoid having to setup business relationship separately with each server on the way? (Note that this is different from letting the traffic go through without QOS negotiation with each router on the way - Ideally the client should not even have to be aware of all the entities on the way. This does not seem compatible with the model where there is a single entity that's associated with a session, and this entity has to establish a relationship with each netwrok on the way.) -A very basic security issue with QOS is how the client (either at the data origin or destination) gets an assurance that the reservation was made (ie, that he got what he paid for). I havnt found mentioning of this issue in 4081. - Another issue is the need for authentication of the data packets. Deploying QOS without proper authentication of each and every QOS packet is dangerous... beyond the issue of correct charging, there is the danger that lack of authetication for QOS protected packets may adversely affect all traffic on the Internet, even non-QOS related traffic: without authentication, it may be possible to flood the network with rogoue high priority packets. Nits: - section 2: Why do SIDs need to be "cryptographically random"? (whatever this term means...) uniqueness (with high probability) seems enough. - might be good to explain the differences from RSVP (or point to where these are explained.) Best, Ran From weiler@watson.org Sat Nov 28 13:14:00 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A743A6851; Sat, 28 Nov 2009 13:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEPs+6K0XVRo; Sat, 28 Nov 2009 13:13:59 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 3D52B3A68AF; Sat, 28 Nov 2009 13:13:59 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nASLDpX2008902; Sat, 28 Nov 2009 16:13:51 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nASLDp3H008899; Sat, 28 Nov 2009 16:13:51 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 28 Nov 2009 16:13:51 -0500 (EST) From: Samuel Weiler To: Alexey Melnikov In-Reply-To: <4B03AD81.9090103@isode.com> Message-ID: References: <4B03AD81.9090103@isode.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 28 Nov 2009 16:13:51 -0500 (EST) Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-melnikov-imap-keywords-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 21:14:00 -0000 On Wed, 18 Nov 2009, Alexey Melnikov wrote: > Further registrations will be done by the designated expert. I am > concerned that if I put all of them in the document, then the > document will never finish. Sympathies. >> And for the common-use: >> >> Registration of an IMAP keyword intended for common use (whether or >> not they use the "$" prefix) requires Expert Review [RFC5226]. IESG >> appoints one or more Expert Reviewer, one of which is designated as >> the primary Expert Reviewer. IMAP keywords intended for common use >> SHOULD be standardized in IETF Consensus [RFC5226] documents. ... >> In cases when an IMAP >> Keyword being registered is already deployed, Expert Reviewers >> should favour registering it over requiring perfect documentation. >> >> Would it be better to say: "requires either IETF Consensus or Expert >> Review"? > > Not everybody is subscribed to ietf or ietf-announce mailing lists, so I > would like for all common use registrations to go through the expert. I don't like the logic (while not everybody is subscribed to the lists, your expert surely could be, and it's easy from an AD to punt the doc to the expert). That said, since you want everything to go through the expert, to avoid confusion, I suggest removing the citation to the inapplicable 5226 metric: "IETF Consensus [RFC5226]". >> (For example: do the registrations made in this doc have to go through >> Expert Review? > > No, because they are a part of the document that creates the registry ;-). > >> Isn't it enough to have them in a consensus doc?") And how do you expect >> the expert to encourage/enforce the SHOULD, given the "favour registering >> it over requiring perfect documentation" guideline? Again, the current >> text isn't as clear as I'd like. > > This is intentional. This is a judgment call by the expert. This sounds inconsistent. I'm hearing "it's within the scope of the expert's judgement to require an IETF Consensus doc" and "In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation." If I were an implementer who got told "you need a consensus doc", I'd be more than a little tempted to go ahead and deploy, then reapply for the registration. -- Sam From weiler+secdir@watson.org Sat Nov 28 13:22:27 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7693A6859 for ; Sat, 28 Nov 2009 13:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 DNmIvIt6WDru for ; Sat, 28 Nov 2009 13:22:26 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 529FC3A6816 for ; Sat, 28 Nov 2009 13:22:26 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nASLMJWf009731 for ; Sat, 28 Nov 2009 16:22:19 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nASLMJvV009728 for ; Sat, 28 Nov 2009 16:22:19 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 28 Nov 2009 16:22:19 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 28 Nov 2009 16:22:19 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 21:22:27 -0000 Please check the list of documents on the telechat agenda for this coming Thursday. Charlie Kaufman is next in the rotation. Please try to complete last call reviews by the end of the last call. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam Reviewer Deadline Draft Derek Atkins T 2009-12-01 draft-klensin-ftp-registry-02 Rob Austein T 2009-12-01 draft-reschke-rfc2731bis-04 Shawn Emery T 2009-12-01 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06 Stephen Farrell T 2009-12-01 draft-ietf-csi-sndp-prob-03 Phillip Hallam-Baker T 2009-12-01 draft-ietf-hip-native-api-09 Sam Hartman TR2009-12-01 draft-hammer-oauth-07 Love Hornquist-Astrand T 2009-12-01 draft-ietf-ipfix-mib-08 Sandy Murphy T 2009-12-01 draft-nottingham-site-meta-04 Stefan Santesson TR2009-12-01 draft-ietf-tsvwg-rsvp-l3vpn-05 Brian Weis TR2009-12-01 draft-ietf-pim-sm-linklocal-09 Larry Zhu T 2009-12-01 draft-combes-ipdvb-mib-rcs-08 For telechat 2009-12-17 Reviewer Deadline Draft Donald Eastlake T 2009-12-15 draft-cheshire-dnsext-multicastdns-08 Paul Hoffman T 2009-12-15 draft-ietf-tcpm-early-rexmt-03 Hannes Tschofenig T 2009-12-15 draft-ietf-l3vpn-ospfv3-pece-04 Last calls and special requests: Reviewer Deadline Draft Rob Austein 2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02 Pat Cain 2009-11-28 draft-ietf-pkix-rfc3161-update-09 Dave Cridland 2009-11-25 draft-ietf-nsis-qspec-22 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Alan DeKok 2009-12-16 draft-eastlake-nlpid-iana-considerations-03 Steve Hanna 2009-12-04 draft-ietf-rohc-rfc4995bis-01 Dan Harkins 2009-12-12 draft-duerst-mailto-bis-07 David Harrington 2009-12-07 draft-ietf-capwap-802dot11-mib-05 Sam Hartman 2009-12-11 draft-ietf-tls-renegotiation-01 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Love Hornquist-Astrand 2009-12-16 draft-ietf-ccamp-confirm-data-channel-status-08 Jeffrey Hutzelman 2009-10-15 draft-ietf-idnabis-protocol-17 Jeffrey Hutzelman 2009-12-07 draft-ietf-capwap-base-mib-06 Stephen Kent None draft-ietf-tsvwg-rsvp-security-groupkeying-05 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Russ Mundy 2009-10-21 draft-ietf-hokey-preauth-ps-09 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Hilarie Orman 2009-12-08 draft-lha-gssapi-delegate-policy-04 Radia Perlman None draft-bryan-http-digest-algorithm-values-update-03 Eric Rescorla 2009-11-10 draft-gennai-smime-cnipa-pec-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-12 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Sean Turner 2009-10-28 draft-ietf-ipsecme-traffic-visibility-10 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis 2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-05 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-09-17 draft-ietf-rohc-hcoipsec-11 From alexey.melnikov@isode.com Sat Nov 28 13:30:46 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0F83A6932; Sat, 28 Nov 2009 13:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 qz1tj2f3chyB; Sat, 28 Nov 2009 13:30:45 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 365C13A6930; Sat, 28 Nov 2009 13:30:45 -0800 (PST) Received: from [92.40.30.65] (92.40.30.65.sub.mbb.three.co.uk [92.40.30.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 28 Nov 2009 21:30:38 +0000 Message-ID: <4B11964A.6@isode.com> Date: Sat, 28 Nov 2009 21:29:46 +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: Samuel Weiler References: <4B03AD81.9090103@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-melnikov-imap-keywords-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 21:30:46 -0000 Samuel Weiler wrote: > On Wed, 18 Nov 2009, Alexey Melnikov wrote: > >>> And for the common-use: >>> >>> Registration of an IMAP keyword intended for common use (whether or >>> not they use the "$" prefix) requires Expert Review [RFC5226]. IESG >>> appoints one or more Expert Reviewer, one of which is designated as >>> the primary Expert Reviewer. IMAP keywords intended for common use >>> SHOULD be standardized in IETF Consensus [RFC5226] documents. ... >>> In cases when an IMAP >>> Keyword being registered is already deployed, Expert Reviewers >>> should favour registering it over requiring perfect documentation. >>> >>> Would it be better to say: "requires either IETF Consensus or Expert >>> Review"? >> >> Not everybody is subscribed to ietf or ietf-announce mailing lists, >> so I would like for all common use registrations to go through the >> expert. > > I don't like the logic (while not everybody is subscribed to the > lists, your expert surely could be, People have complained about traffic on the ietf mailing list during plenaries. > and it's easy from an AD to punt the doc to the expert). That part is easy, yes. > That said, since you want everything to go through the expert, to > avoid confusion, I suggest removing the citation to the inapplicable > 5226 metric: "IETF Consensus [RFC5226]". Ok, I will try to clarify. >>> (For example: do the registrations made in this doc have to go >>> through Expert Review? >> >> No, because they are a part of the document that creates the registry >> ;-). >> >>> Isn't it enough to have them in a consensus doc?") And how do you >>> expect the expert to encourage/enforce the SHOULD, given the "favour >>> registering it over requiring perfect documentation" guideline? >>> Again, the current text isn't as clear as I'd like. >> >> This is intentional. This is a judgment call by the expert. > > This sounds inconsistent. Yes, but it is a fact of life. It is not worse than the current situation where people just deploy stuff without bring it to any standard mailing list. > I'm hearing "it's within the scope of the expert's judgement to > require an IETF Consensus doc" and "In cases when an IMAP Keyword > being registered is already deployed, Expert Reviewers should favour > registering it over requiring perfect documentation." If I were an > implementer who got told "you need a consensus doc", I'd be more than > a little tempted to go ahead and deploy, then reapply for the > registration. Well, if one works for Microsoft, Google, Mozilla, etc. (not trying to pick on anybody), then one does it every time. Hopefully Expert Review is low enough bar to tempt people (if tempt is the right word here at all) to register. From ekr@networkresonance.com Sun Nov 29 16:40:32 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626053A69F6; Sun, 29 Nov 2009 16:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB4vUjk9REoP; Sun, 29 Nov 2009 16:40:31 -0800 (PST) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 28C873A6781; Sun, 29 Nov 2009 16:40:31 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id DBE146C3D38; Sun, 29 Nov 2009 16:41:23 -0800 (PST) Date: Sun, 29 Nov 2009 16:41:22 -0800 From: Eric Rescorla To: secdir@ietf.org, draft-saito-mmusic-sdp-ike@tools.ietf.org, mmusic@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091130004123.DBE146C3D38@kilo.networkresonance.com> Subject: [secdir] Review of draft-saito-mmusic-sdp-ike-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 00:40:32 -0000 This document describes a mechanism whereby a SIP/SDP exchange can be used to kick off an IPsec association. The idea seems to be that I have the AOR for some machine behind a NAT or a firewall and I want to set up an IPsec tunnel. So, I use SIP address resolution and then SIP to signal to it and then set up an IPsec SA as if it were a media connection. GENERAL COMMENTS 1. Use Cases When I reviewed this document back in 2007, I was sort of lukewarm on it. The authors list some use cases, but I don't find them that convincing: o Sharing media using a framework developed by Digital Living Network Alliance (DLNA) or similar protocols over VPN between two user devices. o Remote desktop applications over VPN initiated by SIP call. As an additional function of click-to-call, a customer service agent can access a customer's PC remotely to troubleshoot the problem while talking with the customer over the phone. o Accessing and controlling medical equipment (medical robotics) remotely to monitor the elderly in a rural area (remote care services). o Local area network (LAN)-based gaming protocol based on peer-to- peer rather than via a gaming server. My skepticism is that setting up a VPN for applications like this seems like overkill. VPNs have a bunch of ancillary security implications that aren't really necessary for these applications. It's important to remember that IPsec provides not only a network connectivity function but also a firewalling function. (RFC 4301 S 2.1), and I worry that we're confusing these two to some extent. Consider the last case, the gaming system. In this case, we don't want to open a generic VPN connection, we want to open a connection directly to the gaming up. Why is IPsec a good mechanism here? The other examples seem to raise the same issue. 2. Coordination Of Multiple Elements This brings me to another issue, the tight coordination required between multiple elements on the home network. Again, in the gaming setting, we have: - The IPsec Security Policy Database (SPD) - The user's SIP stack (e.g., softphone) - The gaming app which is consuming the traffic As I understand the current proposal, what has to happen here is: - A call comes into the SIP stack - The SIP stack somehow notifies the gaming app (or maybe it has preexisting policy) - The gaming app agrees to accept the connection - The gaming app then generates the appropriate SPD entry(s) - The gaming app notifies the SIP stack that it's OK - The SIP call is accepted - ICE is run to establish connectivity - The IKE stack runs to set up the IKE channel. This seems like a heck of a lot of interlocking pieces to set up what's basically an app-to-app connection. Of course, you could also put the SIP stack into the gaming app, but that's ridiculously heavyweight for this purpose. I should also mention that in terms of implementation complexity, ICE seems like a real problem. The issue here is file descriptor and channel management. The obvious way to implement an ICE stack (and the way that mine works) is that the stack opens socket(s) locally and then presents an abstraction to the application which it can then use to read and write on. However, in this case, we have three separate pieces of code (and probably execution contexts) which all need to send/receive data on the same socket: - The ICE stack - The IKE stack - The IPsec stack And the demultiplexing between these is data dependent. Doesn't this mean that we'll need a central dispatcher process whose job it is to hand off the packets to each other module? I'm having trouble visualizing this being something people are willing to implement. 3. Security Model As I understand it, the way that this system is intended to work is that the home system has an ACL indexed by remote AOR. If a SIP call comes through allegedly from a permitted AOR (via RFC 4474) it allows the VPN connection to be established. That seems to place a very large amount of trust in the SIP proxy. In essence you're giving the SIP proxy the keys to your firewall. I can't really see any circumstances in which I would be willing to do that. By contrast, classic IPsec/SSH/SSL VPNs rely on credentials that are immediately on the the remote side. That seems far more secure. I am also concerned about the fairly loose coupling between the authentication at the IKE layer and the firewall hole punching. As I understand it, the SIP/ICE system doesn't do any authentication at all: it just punches a hole and then propagates the packets to the IKE/IPsec system without looking at them at all. I don't see any immediate way to exploit this, but it's not clear to me that it's safe either. 4. Multiplexing Why are you using the same channel for IKE and IPsec tunnelling? IKE supports multiple media channels. This seems like an architectural issue, which is why I have it in general comments. 5. Grammar/Writing This document has a lot of writing/grammatical errors. It really needs a copy-edit pass. DETAILED COMMENTS TECHNICAL S 3. I'm not sure I understand what information the remote host/app has. Is it going to be making calls to my ordinary SIP AOR or to some specialized AOR connected to the app... Forking to multiple registered instances is outside the scope in this use case, so there is only one registered instance for each side. How do you guarantee this? See above about which AOR... S 4. This set of definitions seems clumsy. How do I know if I should be establishing ike-esp or ike-esp-udpencap? Should I be establishing two media channels in parallel? S 8.2. This PSK mechanism seems to introduce a weakness not present in the original IKE-PSK spec: in RFC 4306, you only do the PSK exchange over an encrypted channel established via a DH exchange. That means that an attacker must actively intercept the channel in order to mount a dictionary attack on a PSK which is actually a password. Sending a PSK hash enables an attack by any attacker who can see the data on the SIP channel. Why are you allowing MD2 and MD5? EDITORIAL Abstract: This document specifies how to establish secure media sessions over a virtual private network using Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It You're not establishing a secure media session over a vpn, right? You're establishing a media session to use a vpn over. S 2.2. SIP has a cross-NAT rendezvous mechanism, such as ICE [I-D.ietf-mmusic-ice]. This effective function can be used for "such as ICE"? SIP *is* a cross-NAT rendezvous mechanism. ICE is a mechanism for opening ports through the NAT. Also, since this is the only IETF mechanism "such as" seems weird. specifies the method to exchange the fingerprint of a self-signed specifies a method -Ekr From john-ietf@jck.com Sat Nov 28 14:13:38 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADE63A67CF; Sat, 28 Nov 2009 14:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 hC2MCtQ5epOY; Sat, 28 Nov 2009 14:13:37 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 2E3FF3A6358; Sat, 28 Nov 2009 14:13:37 -0800 (PST) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1NEVXj-000AtJ-Tx; Sat, 28 Nov 2009 17:13:28 -0500 Date: Sat, 28 Nov 2009 17:13:26 -0500 From: John C Klensin To: Alexey Melnikov , Samuel Weiler Message-ID: <8DA1A1011B7EFEC9DB984281@[192.168.1.110]> In-Reply-To: <4B11964A.6@isode.com> References: <4B03AD81.9090103@isode.com> <4B11964A.6@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 30 Nov 2009 00:43:14 -0800 Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-melnikov-imap-keywords-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 22:13:38 -0000 --On Saturday, November 28, 2009 9:29 PM +0000 Alexey Melnikov wrote: >... >> I'm hearing "it's within the scope of the expert's judgement >> to require an IETF Consensus doc" and "In cases when an IMAP >> Keyword being registered is already deployed, Expert >> Reviewers should favour registering it over requiring >> perfect documentation." If I were an implementer who got >> told "you need a consensus doc", I'd be more than a little >> tempted to go ahead and deploy, then reapply for the >> registration. > > Well, if one works for Microsoft, Google, Mozilla, etc. (not > trying to pick on anybody), then one does it every time. > Hopefully Expert Review is low enough bar to tempt people (if > tempt is the right word here at all) to register. Sam, For whatever it is worth, the above exchange goes to the very root of the question of what we think our registration procedures and registries are for, at least when there isn't a scarcity of possible identifiers. One theory is that they should be designed to prevent garbage, or warn people against garbage by the fact that something isn't registered. I think we've seen ample evidence that theory doesn't work, with your comments and Alexey's above both constituting examples. The other is that the main purpose of registration is to provide sufficient information and documentation to promote interoperability by virtue of encouraging people to avoid using the same identifier for different purposes. I'm more optimistic about the second than the first, but it calls for a fairly low bar on registrations. Neither model has much to do with security: registration, no matter how high or low the threshold, won't prevent an attack if someone is inclined to misuse or reuse an identifier in a malicious way. Nor will non-registration help avoid someone finding out what an identifier looks like an attacking whatever it represents if one were inclined to do that... only the most dedicated believer in security through obscurity could believe that non-registration is helpful in that regard and it would be a stretch even then. john From Pasi.Eronen@nokia.com Mon Nov 30 01:20:09 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BC63A6A32; Mon, 30 Nov 2009 01:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 jbXGODdd09lS; Mon, 30 Nov 2009 01:20:05 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 205EA3A6A31; Mon, 30 Nov 2009 01:20:04 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAU9JpU1006756; Mon, 30 Nov 2009 11:19:55 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 11:18:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 11:18:10 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 30 Nov 2009 10:17:57 +0100 From: To: , Date: Mon, 30 Nov 2009 10:17:56 +0100 Thread-Topic: Pasi's AD Notes for November 2009 Thread-Index: AcpxngCNeakTGXMzSt2Yd1bkpYy2lA== Message-ID: <808FD6E27AD4884E94820BC333B2DB774F3118C93B@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2009 09:18:10.0970 (UTC) FILETIME=[096277A0:01CA719E] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for November 2009 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 09:20:09 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - Edited and posted IETF76 SAAG minutes (thanks to Jim Schaad for taking notes!) - Tools work: completed Django 1.x transition; retired bunch of old code; new authentication/authorization code for datatracker. - I've been asked to sponsor draft-marin-eap-frm-fastreauth; waiting for me to take a look and reply to the authors [since 2009-10-26] - Some discussions about the new-work and secdir mailing lists =20 [waiting for Loa since 2009-11-10] - Some discussions related to IODEF/INCH and ARF. Waiting for=20 IETF Trust [since 2009-11-03]. WORKING GROUPS DKIM - draft-ietf-dkim-deployment: currently in AD Evaluation state, waiting for me to read it [since 2009-10-26] - Waiting for Stephen and Barry for new charter text (noting that=20 current work items are completed and adding 4871bis) - I still need to review what to do about errata 1385, 1532, and 1596, and 1942. EMU - EMU WG received a new liaison statement from ITU-T about X.1034;=20 the WG chairs have the token for doing something about it. IPSECME - draft-ietf-ipsecme-ikev2-redirect (not wearing AD hat): now published as RFC 5685. - draft-ietf-ipsecme-ikev2-resumption: in RFC editor queue. - draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat): was approved by IESG, now in RFC editor queue. - draft-ietf-ipsecme-traffic-visibility: waiting for the authors to submit a revised ID [since 2009-11-27] - draft-kanno-ipsecme-camellia-xcbc (not WG item): the authors have asked if I would sponsor this as individual submission. I've sent some questions to them, and I'm currently waiting for their reply [since 2009-10-14] - I need to look at errata 1937 (for RFC 4307) [since 2009-11-02] ISMS KEYPROV - Apparently waiting for the chairs to send some documents my way... PKIX - draft-ietf-pkix-sha2-dsa-ecdsa: in RFC editor queue. - draft-ietf-pkix-rfc4055-update: in RFC editor queue. SASL - draft-ietf-sasl-scram: in RFC editor queue, waiting for GS2. - draft-ietf-sasl-gs2: went through IETF last call; on the agenda=20 of the 2009-12-03 IESG telechat. - (not WG item) draft-melnikov-sasl-scram-ldap: was approved by IESG; now in RFC editor queue. - (not WG item) draft-altman-tls-channel-bindings: went through IETF last call; delayed due to renegotiation discussions;=20 currently waiting for me to do something. =20 SYSLOG - draft-ietf-syslog-sign: waiting for Alex to post a revised ID to address the DISCUSSes [since 2009-11-26] TLS - Did somebody mention renegotiation? (more than 1,000 emails this=20 month...) Currently waiting for the secretariat to start IETF=20 Last Call. - draft-ietf-tls-extractor: waiting for Eric to reply to email [since 2009-10-05]; also in AUTH48. - draft-ietf-tls-rfc4366-bis: it seems we need more text about server_name. Currently waiting until the renegotiation fix=20 progresses. - (not WG item) see SASL WG for draft-altman-tls-channel-bindings - (not WG item) draft-mavrogiannopoulos-rfc5081bis: this was submitted via the independent submission stream, but procedure-wise, it needs to be an IETF stream document. I've offered to sponsor this as non-WG document; waiting for the author to submit a revised ID=20 [since 2009-11-27] OTHER DOCUMENTS DISCUSSES (active -- something happened within last month) - draft-cain-post-inch-phishingextns: waiting for me to =20 take a look at version -07 [since 2009-11-24] - draft-ietf-bmwg-ipsec-meth: waiting for authors to submit a revised ID [since 2009-10-22] - draft-ietf-bmwg-ipsec-term: waiting for authors to reply to my comments or submit a revised ID [since 2009-10-22] - draft-ietf-ntp-autokey: waiting for Ralph's proposal on how to proceed [since 2009-10-19] - draft-turner-deviceowner-attribute: waiting for the author to submit a revised ID [since 2009-11-18] - draft-turner-clearancesponsor-attribute: waiting for the author to submit a revised ID [since 2009-11-18] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-ietf-eai-downgraded-display: discussion ongoing; currently waiting for the authors to reply [since 2009-10-26] - draft-ietf-roll-home-routing-reqs: text agreed, waiting for the authors to submit a revised ID [since 2009-10-29] - draft-ietf-sip-certs: discussion ongoing; currently waiting for the authors to reply [since 2009-10-26] - draft-solinas-rfc4753bis: waiting for authors to reply to my comments [since 2009-09-24] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30, 2009-06-09, 2009-10-29) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] (pinged again on 2009-04-30, 2009-06-09, 2009-10-29) - draft-ietf-dime-diameter-api: waiting for Dan to get WG's opinion=20 on whether this will be useful and if yes, why [since 2009-06-18] - draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping- media-policy-dataset to progress (or more information from Robert) [since 2008-10-28] --end-- From kivinen@iki.fi Mon Nov 30 05:15:23 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0AF28C10C; Mon, 30 Nov 2009 05:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 d5R+tgACQHTB; Mon, 30 Nov 2009 05:15:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9A028C10E; Mon, 30 Nov 2009 05:15:21 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAUDFA3T010520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 15:15:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAUDF9u6010441; Mon, 30 Nov 2009 15:15:09 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19219.50525.634866.512658@fireball.kivinen.iki.fi> Date: Mon, 30 Nov 2009 15:15:09 +0200 From: Tero Kivinen To: Samuel Weiler In-Reply-To: References: <4B03AD81.9090103@isode.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 14 min Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-melnikov-imap-keywords-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 13:15:23 -0000 Samuel Weiler writes: > >> Registration of an IMAP keyword intended for common use (whether or > >> not they use the "$" prefix) requires Expert Review [RFC5226]. IESG > >> appoints one or more Expert Reviewer, one of which is designated as > >> the primary Expert Reviewer. IMAP keywords intended for common use > >> SHOULD be standardized in IETF Consensus [RFC5226] documents. ... > >> In cases when an IMAP > >> Keyword being registered is already deployed, Expert Reviewers > >> should favour registering it over requiring perfect documentation. > >> > >> Would it be better to say: "requires either IETF Consensus or Expert > >> Review"? > > > > Not everybody is subscribed to ietf or ietf-announce mailing lists, so I > > would like for all common use registrations to go through the expert. > > I don't like the logic (while not everybody is subscribed to the > lists, your expert surely could be, and it's easy from an AD to punt > the doc to the expert). Acting as an IANA expert for IKEv2 registries, I have noticed that expert do not get any option to say anything for documents which go through IESG. The IANA registry is just updated without any discussion with expert in those cases. So I do not think whether it affects anything if you say "requires Expert Review" compared to the "requires Expert Review or IETF Consensus", or at least you might want to add explicit text to make it sure that the review policy mandates that all assignments go through the Expert.. -- kivinen@iki.fi From arnt@gulbrandsen.priv.no Mon Nov 30 09:41:03 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08CDF3A6A9C; Mon, 30 Nov 2009 09:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppgv6qSb3ijV; Mon, 30 Nov 2009 09:41:02 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by core3.amsl.com (Postfix) with ESMTP id 163483A6960; Mon, 30 Nov 2009 09:41:02 -0800 (PST) Received: from fri.gulbrandsen.priv.no (kalyani.aox.org [79.140.39.164]) by strange.aox.org (Postfix) with ESMTP id 1B698FA012D; Mon, 30 Nov 2009 17:40:56 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no (HELO lochnagar.gulbrandsen.priv.no) by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.2) with esmtp id 1259602679-44536-44535/5/3 (5 recipients); Mon, 30 Nov 2009 18:37:59 +0100 Message-Id: <7C2n9CkGGHelouPii9YA2A.md5@lochnagar.gulbrandsen.priv.no> Date: Mon, 30 Nov 2009 18:42:30 +0100 From: Arnt Gulbrandsen To: ietf@ietf.org References: <4B03AD81.9090103@isode.com> In-Reply-To: Content-Type: text/plain; format=flowed Mime-Version: 1.0 X-Mailman-Approved-At: Mon, 30 Nov 2009 10:23:07 -0800 Cc: Samuel Weiler , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-melnikov-imap-keywords-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:41:03 -0000 Samuel Weiler answers Alexey: >>> Isn't it enough to have them in a consensus doc?") And how do you >>> expect the expert to encourage/enforce the SHOULD, given the >>> "favour registering it over requiring perfect documentation" >>> guideline? Again, the current text isn't as clear as I'd like. >> >> This is intentional. This is a judgment call by the expert. > > This sounds inconsistent. I'm hearing "it's within the scope of the > expert's judgement to require an IETF Consensus doc" and "In cases > when an IMAP Keyword being registered is already deployed, Expert > Reviewers should favour registering it over requiring perfect > documentation." If I were an implementer who got told "you need a > consensus doc", I'd be more than a little tempted to go ahead and > deploy, then reapply for the registration. That's now how it happens. The consensus issues mostly have been about naming (different names for the same thing), and IMO were caused by lack of knowledge/communication. Merely talking two the expert would likely fix most. Also, I'd like to mention that Lisa asked two people whether they could serve; both of her nominees are people who would be likely to give helpful answers, not send implementers away with one-sentence answer such as "go write a consensus doc". Arnt From Shawn.Emery@Sun.COM Mon Nov 30 11:51:25 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD84328C130; Mon, 30 Nov 2009 11:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhHJqjHCWJjL; Mon, 30 Nov 2009 11:51:24 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 9BCF33A68DF; Mon, 30 Nov 2009 11:51:24 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAUJpG4D013009; Mon, 30 Nov 2009 19:51:17 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTX00300Q4BUF00@mail-amer.sun.com>; Mon, 30 Nov 2009 12:51:16 -0700 (MST) Received: from [10.0.0.5] ([unknown] [174.51.225.48]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTX00GYKTT9A520@mail-amer.sun.com>; Mon, 30 Nov 2009 12:51:09 -0700 (MST) Date: Mon, 30 Nov 2009 12:49:55 -0700 From: Shawn M Emery Sender: Shawn.Emery@Sun.COM To: secdir@ietf.org Message-id: <4B1421E3.7030405@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Cc: draft-ietf-16ng-ipv4-over-802-dot-16-ipcs@tools.ietf.org, iesg@ietf.org, 16ng-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:51:25 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes the frame format required to transmit IPv4 packets over a sublayer of IEEE 802.16 that handles packet based protocols. The I-D also outlines the procedures for MTU and address assignment with said sublayer in the context of IPv4. The security considerations section does exist and defers to the security aspect of the mobile/wireless communication to that which is described in IEEE 802.16. Outside of this they leave security in scope of the underlying network, such as WiMAX. This seems reasonable to me, though it would be nice to have updated links for each of the referenced architectures, see below. General comments(s): None. Editorial comment(s): Abstract: If you're expanding IP then you may want to expand MAC. s/0 = 1/0 =/ s/\nif an MS/ If a MS/ IEEE802_16: Can you provide a link? The http://www.wimaxforum.org/technology/documents URL is invalid. -- Shawn. From stephen.farrell@cs.tcd.ie Mon Nov 30 17:25:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D309C3A6AB2; Mon, 30 Nov 2009 17:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.764, 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 T7jajQbvzVK5; Mon, 30 Nov 2009 17:25:06 -0800 (PST) Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by core3.amsl.com (Postfix) with ESMTP id EF2243A686E; Mon, 30 Nov 2009 17:25:05 -0800 (PST) Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id D705132886; Tue, 1 Dec 2009 01:24:57 +0000 (GMT) Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id nB11OrJ2000761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Dec 2009 01:24:54 GMT Message-ID: <4B147060.4000207@cs.tcd.ie> Date: Tue, 01 Dec 2009 01:24:48 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: draft-ietf-csi-prob@tools.ietf.org, sec-ads@ietf.org, secdir@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Canit-Stats-ID: 58130340 - 690f3ab6f055 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Subject: [secdir] secdir review of draft-ietf-csi-sndp-prob X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 01:25:06 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft is a generally well-written description of some issues with securing neighbour discovery when proxies are involved. As a problem statement draft I find it just fine. I have two minor security comments and a few nits below. Stephen. 1. The suggestion at the end of 4.2 that certificate serial number or time field ordering be used to indicate relationships between end entities seems very hacky. I'd suggest either deleting that if its felt to be unlikely used, or else, if its actually likely to be used, then documenting how it could actually work 2. 7.2 mentions "signed, non-repudiable certificates" which is a horribly odd phrase. Hopefully that's just sloppy language. (s/signed, non-repudiable//), but if not, then its a concern (the concern being that non-repudiation in protocols is mythical). Nits: 1. 2nd last para of 3.1: fix word ordering in last sentence, think it ought say: Such a message would be valid according to the SEND specification, if the Target Address and the source IPv6 address of the Neighbor Advertisement weren't different [RFC3971]. 2. 2.2.4 1st para: similar word ordering, maybe: The router or CA may then be able to certify proxying for only a subset of the prefixes for which it is certified. 3. 1st sentence of 7.2: s/The certificagte delegation/Certificate delegation/ From hilarie@purplestreak.com Mon Nov 30 18:19:29 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7613A6A04; Mon, 30 Nov 2009 18:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG05Jw87Ob9t; Mon, 30 Nov 2009 18:19:28 -0800 (PST) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 9B5D73A6405; Mon, 30 Nov 2009 18:19:28 -0800 (PST) Received: from mx01.mta.xmission.com ([166.70.13.211]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NFIWJ-0004Gj-Df; Mon, 30 Nov 2009 19:31:15 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NFIKl-0001Cv-7H; Mon, 30 Nov 2009 19:19:20 -0700 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-6) with ESMTP id nB12IwCd022304; Mon, 30 Nov 2009 19:18:58 -0700 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id nB12IvHB022301; Mon, 30 Nov 2009 19:18:57 -0700 Date: Mon, 30 Nov 2009 19:18:57 -0700 Message-Id: <200912010218.nB12IvHB022301@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com) Cc: hartmans-ietf@mit.edu, lha@apple.com, iesg@ietf.org Subject: [secdir] Review of draft-lha-gssapi-delegate-policy-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 02:19:29 -0000 Review of draft-lha-gssapi-delegate-policy-04 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 last call comments. The document describes an augmentation of the semantics of the GSSAPI service delegation policy. It allows a client to ask if there is a policy allowing delegation of the service. This is a something of a policy band-aid. The API currently supports only unconditional delegation. This change allows a client to learn if the local policy supports it. The decision might involve tier of Kerberos inter-realm servers, and the API is charged with enforcing the policy of assuring that all tickets agree that delegation is permitted. The change is minimal, involving no over-the-wire changes, but I imagine it is only part of the tip of a policy iceberg. If clients are to make policy decisions about something as complex as delegation, ultimately they will need more specific information, I would imagine. The security of the mechanism depends on how wise the administrators are when configuring the delegation policy, but the clients have no insight into how the decision was reached. I recommend that the security considerations section make some comment about why a client would or would not make use of this new mechanism. Perhaps it should be avoided for security-critical services ("don't delegate, even if it is allowed")? Or should it always be used? ----------------------- Section 2. Typo --- "to allow and administrator" should be "to allow an administrator" Section 4. Grammar --- "If the initiator set both ... " should be "sets". Last paragraph "the the" should be "to the". "There state" should be "their state". Section 5. Grammar. When the initiator uses deleg_policy_req_flag, the GSS-API Kerberos mechanism, in addition to the service tickets' OK-AS- DELEGATE flag, the MUST examine all cross realm tickets in the traversal from the user's initial ticket-granting-ticket (TGT) to the service ticket. Suggested rewording If the initiator sets the deleg_policy_req_flag, the GSS-API Kerberos mechanism MUST examine the OK-AS-DELEGATE flag in the service ticket, and it MUST examine all cross realm tickets in the traversal from the user's initial ticket-granting-ticket (TGT) to the service ticket. Section 7. Failure to specify deleg_policy_req_flag on the part of the client can at worst result in NOT delegating credentials -- fails closed, a desirable security property. Suggested rewording. A client's failure to specify deleg_policy_req_flag can at worst result in NOT delegating credentials. This means that the client does not expand its trust, which is generally safer than the alternative.