From Pasi.Eronen@nokia.com Tue Mar 3 01:47: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 24C983A6908; Tue, 3 Mar 2009 01:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Z0JUqpATFiQV; Tue, 3 Mar 2009 01:47:12 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8EF963A67E7; Tue, 3 Mar 2009 01:47:11 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n239lCJp009547; Tue, 3 Mar 2009 11:47:35 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 11:47:22 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 11:47:17 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 3 Mar 2009 10:47:09 +0100 From: To: , Date: Tue, 3 Mar 2009 10:47:08 +0100 Thread-Topic: Pasi's AD Notes for February 2009 Thread-Index: Acmb5QOdXrbuN9VMT6yMP5mPZ4bxiA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727EA57C871@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2009 09:47:17.0625 (UTC) FILETIME=[0A1CDE90:01C99BE5] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for February 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: Tue, 03 Mar 2009 09:47:13 -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 - (not wearing AD hat): Errata #1628 (for RFC 4742): waiting for NETCONF WG chairs/Dan to confirm this [since 2009-02-26] WORKING GROUPS DKIM - Lot of discussion about draft-ietf-dkim-rfc4871-errata=20 (and I haven't read all the emails). - draft-ietf-dkim-ssp: waiting for the errata dust to settle. - draft-ietf-dkim-overview: I sent my AD review comments;=20 waiting for comments/revised ID [since 2009-02-27] - Waiting for WG to send list of RFC errata IDs (the current ones not related to d=3D/i=3D) the WG agrees on. EMU - draft-ietf-emu-gpsk: now published as RFC 5433 - Discussions about EAP-FAST and EAP-MSCHAPv2 IPSECME - (not WG document) draft-bellovin-useipsec was published as RFC 5406 - draft-ietf-ipsecme-ikev2-redirect went to WGLC ISMS - I hope we're ready to start IETF Last Call very soon KEYPROV - PSKC went to WGLC - IPR disclosure from VeriSign=20 PKIX - Note: I'm shepherding two PKIX drafts where Tim is a co-author - draft-ietf-pkix-ecc-subpubkeyinfo: in RFC Editor queue/AUTH48 --=20 waiting for Sean to get 5378 OK from Microsoft [since 2009-02-07] - draft-ietf-pkix-rfc4055-update: changes needed to address the discusses agreed; waiting for authors to submit a revised ID [since 2009-02-10] SASL - Lot of discussion about SCRAM/GS2 SYSLOG - The main WG documents should come out as RFC 542x any day now - draft-ietf-syslog-sign: I finally reviewed version -24 (apologies for taking so long), and sent my remaining comments (which should=20 be easy to handle); waiting for the authors to submit a revised=20 ID before starting IEF Last Call [since 2009-02-05] TLS - draft-ietf-tls-des-idea: now published as RFC 5469 - draft-ietf-tls-ecdhe-psk: was approved by IESG; now in RFC=20 Editor queue - draft-ietf-tls-psk-new-mac-aes-gcm: now in RFC Editor queue - Verified errata #1585 for RFC 5246 - The tls-authz saga continues... OTHER DOCUMENTS - draft-lebovitz-kmart-roadmap: now that -00 was posted, I have promised to comment and contribute. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I've promised to read this. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. DISCUSSES (active -- something happened within last month) - draft-ietf-bfd-base: version -09 addressed some of my concerns, but not all -- waiting for authors to reply or submit a revised=20 ID [since 2009-02-13] - draft-ietf-calsify-rfc2445bis: waiting for authors to reply to my comment [since 2009-02-02] - draft-ietf-dime-qos-parameters: waiting for authors to propose text or submit a revised ID [since 2009-02-26] - draft-ietf-enum-combined: waiting for authors to reply if they're OK with proposed text [since 2009-02-26] - draft-ietf-idr-flow-spec: waiting for authors to submit=20 a revised ID [since 2009-02-13] - draft-ietf-l2tpext-tdm: waiting for Mark to do something about the downref [since 2009-02-07] - draft-ietf-roll-urban-routing-reqs: version -04 addressed many of my comments; waiting for authors to propose text for the remaining ones [since 2009-02-06] - draft-ietf-softwire-encaps-ipsec: waiting for me to read Lou's email about pre-created SAs [since 2009-02-23]; waiting for the authors to reply about IKE initiator authentication [since 2009-02-23] - draft-ietf-softwire-hs-framework-l2tpv2: waiting for me to read Carlos's email [since 2009-02-26] - draft-igoe-secsh-aes-gcm: waiting for Tim to propose solution to FIPS validation problem and solicit opinions from others=20 [since 2009-02-20] - draft-stjohns-sipso: I think we might have rough agreement on changes;=20 waiting for authors to submit a revised ID [since 2009-02-26] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-cain-post-inch-phishingextns: authors have promised a new version some time in February [since 2009-01-29] - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] - draft-ietf-monami6-multiplecoa: some text agreed, waiting for authors to reply to my remaining comments [since 2009-01-28] - draft-ietf-ospf-lls: waiting for a revised ID or RFC Editor Notes to address my remaining comments [since 2009-01-19] - draft-ietf-radext-management-authorization: waiting for authors to reply to my comments [since 2009-01-28] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] - draft-ietf-sip-xcapevent: waiting for revised ID or RFC Editor Note to fix the ABNF/XML bugs [since 2008-10-24] - draft-ietf-sipping-policy-package: waiting for more information from Mary or Jon [since 2008-10-28] --end--= From secdir-bounces@mit.edu Wed Mar 4 07:41: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 8DF933A6CF6 for ; Wed, 4 Mar 2009 07:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8If0AYu-wMb for ; Wed, 4 Mar 2009 07:41:11 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D07AC3A6CD2 for ; Wed, 4 Mar 2009 07:41: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 n24FfY9l029979 for ; Wed, 4 Mar 2009 10:41:34 -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 n24FfSxM029966 for ; Wed, 4 Mar 2009 10:41:28 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n24FfKi3000085 for ; Wed, 4 Mar 2009 10:41:21 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id C9D9612E4A6A for ; Wed, 4 Mar 2009 10:41:19 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651AF3A6CCF; Wed, 4 Mar 2009 07:40:47 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9886828C31C; Wed, 4 Mar 2009 07:40:45 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090304154045.9886828C31C@core3.amsl.com> Date: Wed, 4 Mar 2009 07:40:45 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu 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: Thu, 05 Mar 2009 00:23:29 -0800 Subject: [secdir] [New-work] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) 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: Wed, 04 Mar 2009 15:41:12 -0000 A modified charter has been submitted for the Routing Over Low power and Lossy networks working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. Routing Over Low power and Lossy networks (roll) ================================================== Last Modified: 2009-02-04 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/roll Chair(s): JP Vasseur David Culler Routing Area Director(s): Ross Callon David Ward Routing Area Advisor: David Ward Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. As shown in a protocol survey existing routing protocols (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and how it is applied. Manageability will be considered with each approach, along with various trade-offs for maintaining low power operation, including the presence of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Wed Mar 4 08:34: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 E1EE53A6867 for ; Wed, 4 Mar 2009 08:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O2LTDwV4uYt for ; Wed, 4 Mar 2009 08:34:47 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 7A9073A6CB7 for ; Wed, 4 Mar 2009 08:34:45 -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 n24GZDHK010142 for ; Wed, 4 Mar 2009 11:35:13 -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 n24GZ6OQ010102 for ; Wed, 4 Mar 2009 11:35:08 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n24GYwD5028699 for ; Wed, 4 Mar 2009 11:34:59 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id E40CF12CF785 for ; Wed, 4 Mar 2009 11:34:57 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E763A6B3C; Wed, 4 Mar 2009 08:34:28 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 299823A6A17; Wed, 4 Mar 2009 08:34:27 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090304163427.299823A6A17@core3.amsl.com> Date: Wed, 4 Mar 2009 08:34:27 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu 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: Thu, 05 Mar 2009 00:23:29 -0800 Subject: [secdir] [New-work] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf) 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: Wed, 04 Mar 2009 16:34:48 -0000 A modified charter has been submitted for the Ad-Hoc Network Autoconfiguration working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------------------------- Last Modified: 2009-02-18 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/autoconf Chair(s): Ryuji Wakikawa [ryuji.wakikawa@gmail.com] Thomas Clausen [T.Clausen@computer.org] Internet Area Director(s): Jari Arkko [jari.arkko@piuha.net] Mark Townsley [townsley@cisco.com] Internet Area Advisor: Jari Arkko [jari.arkko@piuha.net] Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Goals and Milestones: Apr 2009 Submit initial draft on address configuration in ad hoc networks Sep 2009 Submit address configuration draft to IESG as Informational or close WG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Wed Mar 4 13:11:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E69928C4AA for ; Wed, 4 Mar 2009 13:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iNmj4km7UBj for ; Wed, 4 Mar 2009 13:11:35 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E744528C47F for ; Wed, 4 Mar 2009 13:11:34 -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 n24LC3g6006684 for ; Wed, 4 Mar 2009 16:12:03 -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 n24LBl0Y006633 for ; Wed, 4 Mar 2009 16:11:48 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n24LBeDM007581 for ; Wed, 4 Mar 2009 16:11:40 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 30E301230310 for ; Wed, 4 Mar 2009 16:10:59 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1E628C4B5; Wed, 4 Mar 2009 13:10:29 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0FFCD28C33D; Wed, 4 Mar 2009 13:10:28 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090304211028.0FFCD28C33D@core3.amsl.com> Date: Wed, 4 Mar 2009 13:10:28 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu 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: Thu, 05 Mar 2009 00:23:29 -0800 Subject: [secdir] [New-work] WG Review: Recharter of Network File System Version 4 (nfsv4) 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: Wed, 04 Mar 2009 21:11:36 -0000 A modified charter has been submitted for the Network File System Version 4 working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. Network File System Version 4 (nfsv4) ====================================== Last Modified: 2009-02-10 Current Status: Active Working Group Chair(s): Brian Pawlowski Spencer Shepler Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Technical Advisor(s): Leif Johansson Mailing Lists: General Discussion: nfsv4@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/nfsv4 Archive: http://www.ietf.org/mail-archive/web/nfsv4/index.html Description of Working Group: NFS Version 4 is the IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the working group is chartered to (1) maintain the existing NFSv4, NFSv4.1 and related specifications, such as RPC and XDR, (2) progress these specifications along the standards track, (3) develop a protocol to create a federated namespace using NFSv4's existing referral mechanisms. (1) NFS version 4.0 maintenance Under this charter item, the WG correct errors and ambiguities in the protocol currently specified in RFC 3530 and advances it along the standards track. Extensions of any other kind are out of scope under this charter item. (2) NFS Version 4.1 Maintenance As with NFSv4.0, the WG will address errors or ambiguities in the NFSv4.1 protocol and related specifications in support of progressing implementations. (3) RPC and XDR protocol maintenance The NFSv4 protocol depends on two related specifications: ONC RPC and XDR. Similar to charter item (1), the WG may correct errors and ambiguities in the ONC RPC and XDR protocols currently specified by RFCs 1831, 1833 and 2203. In conjunction with the advancement of the NFSv4 specification along the standards track, the WG will also work on the advancements of its ONC RPC and XDR dependencies. The WG will also update the ONC RPC specification for compatibility with IPv6. Additionally, it will create an IANA registry for RPC program numbers and seed it with a registry Sun has been maintaining. (4) Federated Namespace The NFSv4 protocol provides a referral mechanism that allows a server to redirect a client to another server. The working group will produce documents describing a mechanism for creating a federated namespace (single global name space for a set of NFSv4 servers) using the NFSv4 protocol's referral capabilities. The file system federation protocol will enable file access and namespace traversal across collections of independently administered fileservers. No modifications will be made to the NFS client to server protocol. Milestones: DONE WG Last Call for RPC and NFS RDMA drafts DONE WG Last Call for rfc1831bis (RPC version 2) DONE WG Last Call for NFSv4 minor version 1 DONE WG Last Call for NFSv4.1 block/volume layout DONE WG Last Call for NFSv4.1 Object-based layout DONE Submit NFS Minor Version 1 to IESG for publication as a Propoased Standard DONE Submit pNFS Block/Volume Layout to IESG for publication as a Propoased Standard DONE Submit Object-based pNFS Operations to IESG for publication as a Proposed Standard Sep 2009 WG Last Call for rfc3530bis (NFS version 4) May 2009 WG Last Call for "Requirements for Federated File Systems" draft-ietf-nfsv4-federated-fs-reqts-01 Oct 2009 WG Last Call for "Administration Protocol for Federated Filesystems" draft-ietf-nfsv4-federated-fs-admin-00.txt Oct 2009 WG Last Call for "NSDB Protocol for Federated Filesystems" draft-ietf-nfsv4-federated-fs-protocol-00.txt _______________________________________________ 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 weiler@watson.org Fri Mar 6 20:42:01 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A603A6984 for ; Fri, 6 Mar 2009 20:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuAGDRmSYIm0 for ; Fri, 6 Mar 2009 20:42:00 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 5BFD53A693F for ; Fri, 6 Mar 2009 20:42:00 -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 n274gUlp075148 for ; Fri, 6 Mar 2009 23:42:30 -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 n274gUDo075144 for ; Fri, 6 Mar 2009 23:42:30 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 6 Mar 2009 23:42:30 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Fri, 06 Mar 2009 23:42:30 -0500 (EST) Subject: [secdir] assignments for March 10th/13th 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 Mar 2009 04:42:01 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Donald Eastlake is next in the rotation. -- Sam For telechat 2009-03-10 (please review no later than Tuesday) Richard Barnes T draft-ietf-ntp-ntpv4-proto-11 Paul Hoffman T draft-ietf-behave-turn-13 Susan Thomson T draft-jones-dime-3gpp-eps-command-codes-02 Hannes Tschofenig T draft-ietf-lemonade-profile-bis-12 Sean Turner T draft-ietf-netconf-tls-07 Sam Weiler T draft-ietf-softwire-security-requirements-06 Nico Williams T draft-ietf-netlmm-pmipv6-heartbeat-05 Larry Zhu T draft-ietf-ntp-ntpv4-mib-05 Last calls and special requests: Derek Atkins draft-ietf-roll-building-routing-reqs-05 Rob Austein draft-p2pi-cooper-workshop-report-01 Uri Blumenthal draft-ietf-lemonade-streaming-09 Pat Cain draft-crocker-email-arch-11 Ran Canetti draft-ietf-avt-seed-srtp-09 Charles Clancy draft-ietf-ccamp-gmpls-ason-routing-ospf-07 Dave Cridland draft-ietf-lemonade-notifications-10 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Lakshminath Dondeti draft-ietf-pce-global-concurrent-optimization-08 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Vidya Narayanan draft-ietf-sip-saml-05 Joe Salowey draft-ietf-geopriv-lis-discovery-07 Sam Weiler draft-chown-v6ops-rogue-ra-02 Nico Williams draft-ietf-v6ops-ra-guard-02 Larry Zhu draft-thaler-v6ops-teredo-extensions-02 Glen Zorn draft-ietf-roll-indus-routing-reqs-04 From dave.cridland@isode.com Sat Mar 7 01:07: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 4D0CB3A69C6 for ; Sat, 7 Mar 2009 01:07:03 -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 aa-S0AptVlYx for ; Sat, 7 Mar 2009 01:07:02 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 66BE73A6A81 for ; Sat, 7 Mar 2009 01:06:58 -0800 (PST) Received: from peirce.dave.cridland.net ([217.155.137.61]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 7 Mar 2009 09:07:16 +0000 References: In-Reply-To: Message-Id: <1289.1236416833.491989@peirce.dave.cridland.net> Date: Sat, 07 Mar 2009 09:07:13 +0000 From: Dave Cridland To: MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Cc: Security Area Directorate Subject: Re: [secdir] assignments for March 10th/13th 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, 07 Mar 2009 09:07:03 -0000 On Sat Mar 7 04:42:30 2009, Samuel Weiler wrote: > Dave Cridland > draft-ietf-lemonade-notifications-10 I've been a fairly active member of this working group, so while I can certainly review this, I'm not sure I'd add anything useful. Can you swap me with something else? Dave. > Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 > Lakshminath Dondeti > draft-ietf-pce-global-concurrent-optimization-08 > Julien Laganier draft-ietf-sip-certs-07 > Catherine Meadows draft-ietf-speechsc-mrcpv2-17 > Vidya Narayanan draft-ietf-sip-saml-05 > Joe Salowey > draft-ietf-geopriv-lis-discovery-07 > Sam Weiler draft-chown-v6ops-rogue-ra-02 > Nico Williams draft-ietf-v6ops-ra-guard-02 > Larry Zhu > draft-thaler-v6ops-teredo-extensions-02 > Glen Zorn > draft-ietf-roll-indus-routing-reqs-04 > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir -- From secdir-bounces@mit.edu Mon Mar 9 03:00: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 D85043A6811 for ; Mon, 9 Mar 2009 03:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=2.200, 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 tG01oj0xld+M for ; Mon, 9 Mar 2009 03:00:49 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 825493A6A19 for ; Mon, 9 Mar 2009 03:00:49 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n29A1MSm024833 for ; Mon, 9 Mar 2009 06:01:22 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n29A1JiL024805 for ; Mon, 9 Mar 2009 06:01:20 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n29A1B7L024724 for ; Mon, 9 Mar 2009 06:01:12 -0400 (EDT) Received: from a.mx.secunet.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 6FED714594EA for ; Mon, 9 Mar 2009 06:01:11 -0400 (EDT) Received: from a.mx.secunet.com (a.mx.secunet.com [213.68.205.161]) by mit.edu with ESMTP id E8VFNBHDffnQlHvc for ; Mon, 09 Mar 2009 06:01:11 -0400 (EDT) Received: from localhost (alg3 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 36ADF20C0A1; Mon, 9 Mar 2009 11:01:10 +0100 (CET) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 6CF2E20C078; Mon, 9 Mar 2009 11:01:09 +0100 (CET) Received: from [10.208.1.240] ([10.208.1.240]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 11:01:09 +0100 Message-ID: <49B4E8E4.6070900@secunet.com> Date: Mon, 09 Mar 2009 11:01:08 +0100 From: Johannes Merkle User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: iesg-secretary@ietf.org, iesg@ietf.org X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 09 Mar 2009 10:01:09.0353 (UTC) FILETIME=[F856FD90:01C9A09D] 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 Mar 2009 08:02:28 -0700 Cc: "Lochter, Manfred" , secdir@mit.edu, ietf-secretariat-reply@ietf.org, rfc-editor@rfc-editor.org Subject: [secdir] [Fwd: New Version Notification - draft-lochter-pkix-brainpool-ecc-03.txt] 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 Mar 2009 10:00:54 -0000 IESG, kindly by informed that the RFC-to-be draft-lochter-pkix-brainpool-ecc-02.txt has been updated to draft-lochter-pkix-brainpool-ecc-03.txt in response to independent review. Best regards, Johannes Merkle -------- Original Message -------- Subject: New Version Notification - draft-lochter-pkix-brainpool-ecc-03.txt Date: Fri, 6 Mar 2009 16:30:02 -0800 (PST) From: ID Tracker To: manfred.lochter@bsi.bund.de, johannes.merkle@secunet.com, draft-lochter-pkix-brainpool-ecc@tools.ietf.org,tim.polk@nist.gov New version (-03) has been submitted for draft-lochter-pkix-brainpool-ecc-03.txt. http://www.ietf.org/internet-drafts/draft-lochter-pkix-brainpool-ecc-03.txt _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From Pasi.Eronen@nokia.com Tue Mar 10 00:30: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 52F6328C129 for ; Tue, 10 Mar 2009 00:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 3itQi+LLsHFn for ; Tue, 10 Mar 2009 00:30:36 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 57EDD28C0F8 for ; Tue, 10 Mar 2009 00:30:36 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2A7UlMq012786 for ; Tue, 10 Mar 2009 09:31:07 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 09:30:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 09:30:34 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 10 Mar 2009 08:30:34 +0100 From: To: Date: Tue, 10 Mar 2009 08:30:31 +0100 Thread-Topic: SecDir lunch at IETF74 Thread-Index: AcmhUhgC6gxjRI2oSjGiSI+2iwruaA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1CB1A96@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Mar 2009 07:30:34.0471 (UTC) FILETIME=[198B2770:01C9A152] X-Nokia-AV: Clean Subject: [secdir] SecDir lunch at IETF74 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 Mar 2009 07:30:38 -0000 Folks, We'll have the Security Directorate lunch on Tuesday as before. We are still waiting on a room assignment, but will send the room =20 number as soon as we get it from the secretariat.=20 As usual, bring your own lunch and we will discuss what's=20 going on in the area and around the IETF.=20 Best regards,=20 Pasi & Tim = From rbarnes@bbn.com Tue Mar 10 19:49: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 293653A6B29; Tue, 10 Mar 2009 19:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTwpIwUfWbiJ; Tue, 10 Mar 2009 19:49:17 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 36A853A6923; Tue, 10 Mar 2009 19:49:16 -0700 (PDT) Received: from [128.89.255.165] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LhEVy-0005rh-Al; Tue, 10 Mar 2009 22:49:50 -0400 Message-ID: <49B726CD.9040107@bbn.com> Date: Tue, 10 Mar 2009 22:49:49 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: IESG , SECDIR , IETF Discussion , draft-ietf-ntp-ntpv4-proto@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-ietf-ntp-ntpv4-proto-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, 11 Mar 2009 02:49:18 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an update to the Network Time Protocol, a mechanism that Internet hosts can use to synchronize their clocks. I have strong reservations about the security mechanisms specified in this document. The central security requirement for this protocol is that protocol endpoints be authenticated and that messages be integrity-protected. These protections are provided primarily by signing messages with a custom MD5-based MAC (i.e., not HMAC-MD5), as in NTPv3, although extensions are included to enable the use of the Autokey scheme for using X.509 certificates to authenticate digital signatures. Both of these schemes are a little bit troubling. For the MAC scheme: In addition to using a custom MAC instead of a more standard one, the MAC relies on the MD5 hash function, for which there are known algorithms to find collisions. I would expect the document to either or both of: 1. Replace MD5 with a stronger hash 2. Argue that the weaknesses in MD5 do not lead to MAC vulnerabilities The document seems to take the latter approach by referring to an NDSS paper on hash transitions. However, this paper does not address the vulnerabilities of MD5-based MACs in any detail (the closest it comes is to say that "because TLS uses HMAC, the current collision-only attacks most likely do not represent a threat"), much less consider the special MAC used by NTP (v3 and v4). I would suggest the authors find a better, more specific reference, or incorporate a mechanism for hash agility. For the Autokey scheme: I have not reviewed Autokey thoroughly, but my initial impression is that it is a far more complicated scheme than is necessary for the simple distribution and revocation of keys for NTP. (ISTM that it would suffice to have, e.g., a simple format for specifying keys and KEYIDs, encapsulated in S/MIME and distributed either out of band or in a special payload type.) In any case, it seems inappropriate for a Standards-track document to refer to a cryptographic protocol described only in a university-internal technical report. Such a scheme should be subject to the same standard of review as other cryptographic systems used within IETF protocols. The document properly notes that as specified, broadcast clients are vulnerable to DoS attacks from some broadcast servers, but only says that "Access controls and/or cryptographic authentication means should be provided for additional security in such cases." This text should be replaced with something more precise, even if only to say "Protections against these attacks is left to future work" without specifying what the solution would look like. From Hannes.Tschofenig@gmx.net Wed Mar 11 00:55: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 EF1BE3A6A1F for ; Wed, 11 Mar 2009 00:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRh6-IEg79uV for ; Wed, 11 Mar 2009 00:55:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B2D0E3A69EC for ; Wed, 11 Mar 2009 00:55:53 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2009 07:56:28 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp014) with SMTP; 11 Mar 2009 08:56:28 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/3DKY9e7f3hDhYSLhPOCSfJT3LWPe+dXrW+nCrK0 srzTrr085BcVg/ From: "Hannes Tschofenig" To: "'SECDIR'" , Date: Wed, 11 Mar 2009 09:57:33 +0200 Message-ID: <085d01c9a21f$0a20afd0$0201a8c0@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: AcmiHwjo2XhVgLVNQWeDit9U2h4CzQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.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, 11 Mar 2009 07:55:55 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a profile of IMAP, mail submission and Sieve protocol for usage of performance constraints devices. This document does not define new security mechanisms (or other extensions). It points to the security related aspects associated with the profiled version (e.g., the pawn ticket -- a fancy name for a simple concept). This is a good document. Only a few minor editor comments and a question regarding the IANA consideration section: The RFC Editor always edits my documents to have a capitalized subject headers. E.g.: s/Summary of the required support/Summary of the Required Support s/Message size declaration/Message Size Declaration s/Lemonade Submission Servers MUST provide a service as described in [SUBMIT], and MUST support the following./ Lemonade Submission Servers MUST provide a service as described in [SUBMIT], and MUST support the following extensions. s/Lemonade Message Stores MUST provide a service as described in [IMAP], and MUST support the following./Lemonade Message Stores MUST provide a service as described in [IMAP], and MUST support the following extensions. s/(See [SMTP-BURL] for more details)./(see [SMTP-BURL] for more details). s/Therefore /Therefore, s/Server-to-client notifications transforms/server-to-client notifications transforms s/the Notification filter generates/the notification filter generates First occurance of OMA write Open Mobile Alliance (OMA) "When clients submit new messages, link protection such as [TLS] guards against an eavesdropper seeing the contents of the submitted message." Maybe use "confidentially protection, such as TLS [TLS]," instead of link protection The IANA consideration section says "This document defines the URL-PARTIAL IMAP capability Section 5.7.1. IANA is requested to add this extension to the IANA IMAP Capability registry.". Section 5.7.1 only references another specification where this capability is defined, at least that's my reading. This document only defines a profile and does not require any IANA considerations. Here is what Section 5.7.1 says: " 5.7.1. Support for PARTIAL in CATENATE and URLAUTH [IMAP-URL] introduced a new syntactic element for referencing a byte range of a message/body part. This is done using the ;PARTIAL= field. If an IMAP server supports PARTIAL in IMAP URL used in CATENATE and URLAUTH extensions, then it MUST advertise the URL- PARTIAL capability in the CAPABILITY response/response code. " Ciao Hannes From dave.cridland@isode.com Wed Mar 11 03:02: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 754FD28C1E2 for ; Wed, 11 Mar 2009 03:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSKV8jLpnBYf for ; Wed, 11 Mar 2009 03:02:03 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5722328C116 for ; Wed, 11 Mar 2009 03:02:03 -0700 (PDT) Received: from peirce.dave.cridland.net ([217.155.137.61]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 11 Mar 2009 10:02:25 +0000 References: <085d01c9a21f$0a20afd0$0201a8c0@nsnintra.net> In-Reply-To: <085d01c9a21f$0a20afd0$0201a8c0@nsnintra.net> Message-Id: <26116.1236765744.072949@peirce.dave.cridland.net> Date: Wed, 11 Mar 2009 10:02:24 +0000 From: Dave Cridland To: Hannes Tschofenig MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Cc: draft-ietf-lemonade-profile-bis@tools.ietf.org, Security Area Directorate Subject: Re: [secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.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, 11 Mar 2009 10:02:04 -0000 On Wed Mar 11 07:57:33 2009, Hannes Tschofenig wrote: > I have reviewed this document as part of the security directorate's > ongoing > effort to review all IETF documents being processed by the IESG. > These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these > comments just > like any other last call comments. > > Thanks for the very thorough review. I think the vast majority of your comments we'll accept without question. > Section 5.7.1 only references another specification where this > capability is > defined, at least that's my reading. This document only defines a > profile > and does not require any IANA considerations. > > Here is what Section 5.7.1 says: > > " > 5.7.1. Support for PARTIAL in CATENATE and URLAUTH > > [IMAP-URL] introduced a new syntactic element for referencing a > byte > range of a message/body part. This is done using the ;PARTIAL= > field. If an IMAP server supports PARTIAL in IMAP URL used in > CATENATE and URLAUTH extensions, then it MUST advertise the URL- > PARTIAL capability in the CAPABILITY response/response code. > " > > [IMAP-URL] defines how to construct a URL which references a byte-range within a body part, and this is newer than CATENATE or URLAUTH. In particular, IMAP-URL only defines syntax, not protocol, and doesn't define where the various URL forms can be used at all. CATENATE and URLAUTH are both defined with the assumption that they only handle URLs without this newer parameter, so the Profile document defines a new capability to signal that CATENATE and URLAUTH can be used with byte-range URLs as well as whole-part URLs. So yes, the profile does need to define a new capability not defined within any of the referenced specifications. I'll have a think about how this can be made clearer - if you've suggestions, they'd be most welcome. Dave. From paul.hoffman@vpnc.org Wed Mar 11 07:04:28 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 05CBE3A68AF for ; Wed, 11 Mar 2009 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfsUwF1dlc94 for ; Wed, 11 Mar 2009 07:04:22 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2E6253A6955 for ; Wed, 11 Mar 2009 07:04:21 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2BE4s0f014281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 07:04:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 11 Mar 2009 07:04:52 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@cisco.com Subject: [secdir] Secdir review of draft-ietf-behave-turn-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:04:28 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. First off, I apologize for the extreme lateness of this review; it was a calendaring failure on my part. This document deals adequately with the security issues of the protocol. Basically, the document says that TURN servers will most likely rely on STUN's authentication mechanism, which is probably sufficient for most scenarios. For those scenarios that need more security (particularly encryption), TURN-over-TLS is defined in a fairly straight-forward fashion as an extension of STUN-over-TLS. The security considerations section is much better than average, particularly for a protocol where it is likely that many implementers will probably punt on authentication and not even think about encryption wiht TLS. Having said that, Figure 2 should be revised to show the expected chain of events *including* the STUN authentication. Without this, an implementer could be confused where the authentication would be. This is covered better in section 16, but should be shown in the early example as well. I note that authentication in TURN is a SHOULD, not a MUST, but I think that is reasonable for the expected deployment scenarios for TURN. Also, only TURN requests, not indications, are authenticated; this is covered in good detail in the document. There is a very large number of security-related SHOULDs in the document that do not have "except where" clauses, but I didn't find any it wasn't clear that the clause would read "except where you don't really care about security anyway". In section 4, it says: For each allocation, the server SHOULD generate a new random nonce when the allocation is first attempted following the randomness recommendations in [RFC4086] and SHOULD expire the nonce at least once every hour during the lifetime of the allocation. I did not understand the one-hour expiration; more explanation here about why nonce regeneration is tied to an arbitrary time and not a session should be given (or, probably, this should be changed to actually tie the nonce regeneration to the end of the session). --Paul Hoffman, Director --VPN Consortium From housley@vigilsec.com Wed Mar 11 07:30:02 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0590A3A67D2 for ; Wed, 11 Mar 2009 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFzmClfAPhcq for ; Wed, 11 Mar 2009 07:29:57 -0700 (PDT) Received: from smtpout.capalon.com (smtpout.capalon.com [63.208.156.20]) by core3.amsl.com (Postfix) with ESMTP id 9F0243A6817 for ; Wed, 11 Mar 2009 07:29:57 -0700 (PDT) Received: from localhost (viruscan [8.8.40.174]) by smtpout.capalon.com (Postfix) with ESMTP id 6260578866E for ; Wed, 11 Mar 2009 10:21:13 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.4.5 (20070130) (Debian) at capalon.com Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by smtpout.capalon.com (Postfix) with SMTP id 1285B78867C for ; Wed, 11 Mar 2009 10:20:53 -0400 (EDT) Received: (qmail 16998 invoked by uid 0); 11 Mar 2009 14:30:09 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.144.212) by woodstock.binhost.com with SMTP; 11 Mar 2009 14:30:09 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Mar 2009 10:16:51 -0400 To: Paul Hoffman ,secdir@ietf.org From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090311142053.1285B78867C@smtpout.capalon.com> Cc: rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@cisco.com Subject: Re: [secdir] Secdir review of draft-ietf-behave-turn-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:30:02 -0000 Does this mean MUST implement and SHOULD use? At 10:04 AM 3/11/2009, Paul Hoffman wrote: >I note that authentication in TURN is a SHOULD, not a MUST, but I >think that is reasonable for the expected deployment scenarios for TURN. From Hannes.Tschofenig@gmx.net Wed Mar 11 07:45: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 7ED223A68E6 for ; Wed, 11 Mar 2009 07:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 sR+nIs8l4KaU for ; Wed, 11 Mar 2009 07:45:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 221F03A6818 for ; Wed, 11 Mar 2009 07:45:45 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2009 14:46:21 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp040) with SMTP; 11 Mar 2009 15:46:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18V3OB2gB8VNFFJ3j0ydUPukLdM7stxInVmfRhsx/ /GrdBkJPAFxIMH From: "Hannes Tschofenig" To: "'Dave Cridland'" References: <085d01c9a21f$0a20afd0$0201a8c0@nsnintra.net> <26116.1236765744.072949@peirce.dave.cridland.net> Date: Wed, 11 Mar 2009 16:47:27 +0200 Message-ID: <090a01c9a258$4cc83220$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <26116.1236765744.072949@peirce.dave.cridland.net> Thread-Index: AcmiMIT7eM2iqp0zSGuTY2RCHZv0IgAHcaug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: draft-ietf-lemonade-profile-bis@tools.ietf.org, 'Security Area Directorate' Subject: Re: [secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.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, 11 Mar 2009 14:45:50 -0000 Hi Dave, Thanks for your quick response. >> Section 5.7.1 only references another specification where this >> capability is >> defined, at least that's my reading. This document only defines a >> profile >> and does not require any IANA considerations. >> >> Here is what Section 5.7.1 says: >> >> " >> 5.7.1. Support for PARTIAL in CATENATE and URLAUTH >> >> [IMAP-URL] introduced a new syntactic element for referencing a >> byte >> range of a message/body part. This is done using the ;PARTIAL= >> field. If an IMAP server supports PARTIAL in IMAP URL used in >> CATENATE and URLAUTH extensions, then it MUST advertise the URL- >> PARTIAL capability in the CAPABILITY response/response code. >> " >> >> >[IMAP-URL] defines how to construct a URL which references a >byte-range within a body part, and this is newer than CATENATE or >URLAUTH. In particular, IMAP-URL only defines syntax, not protocol, >and doesn't define where the various URL forms can be used at all. > >CATENATE and URLAUTH are both defined with the assumption that they >only handle URLs without this newer parameter, so the Profile >document defines a new capability to signal that CATENATE and URLAUTH >can be used with byte-range URLs as well as whole-part URLs. > >So yes, the profile does need to define a new capability not defined >within any of the referenced specifications. > >I'll have a think about how this can be made clearer - if you've >suggestions, they'd be most welcome. Ok. Now I believe I understood this better. [IMAP-URL] defines a URL scheme for referencing objects on an IMAP server. It does not define how you actually use the URL in order to get the referenced objects. In any case, the ABNF for the URL is defined in that document and it contains tokens that refer to specifications that are used in the IMAP context, for example URLAUTH specified in RFC 4467. As such, they define the semantic for these tokens. So, now you would like to use the token PARTIAL with the IMAP-URL. There isn't really a separate registry of parameters for usage with the IMAP-URL, as far as I can tell from my quick read. Section 11 of RFC 5092 only says "Elements not defined here can be found in [ABNF], [IMAP4], [IMAPABNF], or [URI-GEN]." Hence, this seems to mean that the tokens have to be registered in http://www.iana.org/assignments/imap4-capabilities in order to be usable for the IMAP-URL. Hence, you have to register the URL-PARTIAL token in http://www.iana.org/assignments/imap4-capabilities in order to get this to work. Is this roughly a correct summary? What section in http://tools.ietf.org/html/draft-ietf-lemonade-profile-bis-12 describes the semantic of the URL-PARTIAL token? You refer to Section 5.7.1 in the IANA consideration section but that section doesn't really say anything in that regard. Btw, maybe you should replace "5.7.1. Support for PARTIAL in CATENATE and URLAUTH" with "5.7.1. Support for URL-PARTIAL in CATENATE and URLAUTH" Ciao Hannes > >Dave. > From paul.hoffman@vpnc.org Wed Mar 11 08:11:01 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A44D3A6810 for ; Wed, 11 Mar 2009 08:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 L8boa7Qa5wQT for ; Wed, 11 Mar 2009 08:10:55 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5F60528C0F1 for ; Wed, 11 Mar 2009 08:10:55 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2BFBOex019032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 08:11:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090311142053.0F97D78839E@smtpout.capalon.com> References: <20090311142053.0F97D78839E@smtpout.capalon.com> Date: Wed, 11 Mar 2009 08:11:23 -0700 To: Russ Housley , secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@cisco.com Subject: Re: [secdir] Secdir review of draft-ietf-behave-turn-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:11:01 -0000 At 10:16 AM -0400 3/11/09, Russ Housley wrote: >Does this mean MUST implement and SHOULD use? Good question, and I think the answer is that the document does not *require* that authentication be implemented. That is, I couldn't find a place where it said one way or another. I will defer to the document authors to answer that one. --Paul Hoffman, Director --VPN Consortium From alexey.melnikov@isode.com Wed Mar 11 09:05:41 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A2428C158 for ; Wed, 11 Mar 2009 09:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 DcdxHRWzFqAP for ; Wed, 11 Mar 2009 09:05:39 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 985623A6BAB for ; Wed, 11 Mar 2009 09:05:38 -0700 (PDT) Received: from [172.16.2.107] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 11 Mar 2009 16:06:12 +0000 Message-ID: <49B7E152.3000004@isode.com> Date: Wed, 11 Mar 2009 16:05:38 +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: Hannes Tschofenig References: <085d01c9a21f$0a20afd0$0201a8c0@nsnintra.net> <26116.1236765744.072949@peirce.dave.cridland.net> <090a01c9a258$4cc83220$0201a8c0@nsnintra.net> In-Reply-To: <090a01c9a258$4cc83220$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lemonade-profile-bis@tools.ietf.org, 'Security Area Directorate' Subject: Re: [secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.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, 11 Mar 2009 16:05:41 -0000 Hannes Tschofenig wrote: >Hi Dave, > > Hi Hannes, >Thanks for your quick response. > > >>>Section 5.7.1 only references another specification where this >>>capability is >>>defined, at least that's my reading. This document only defines a >>>profile >>>and does not require any IANA considerations. >>> >>>Here is what Section 5.7.1 says: >>> >>>" >>>5.7.1. Support for PARTIAL in CATENATE and URLAUTH >>> >>> [IMAP-URL] introduced a new syntactic element for referencing a >>>byte >>> range of a message/body part. This is done using the ;PARTIAL= >>> field. If an IMAP server supports PARTIAL in IMAP URL used in >>> CATENATE and URLAUTH extensions, then it MUST advertise the URL- >>> PARTIAL capability in the CAPABILITY response/response code. >>>" >>> >>> >>[IMAP-URL] defines how to construct a URL which references a >>byte-range within a body part, and this is newer than CATENATE or >>URLAUTH. In particular, IMAP-URL only defines syntax, not protocol, >>and doesn't define where the various URL forms can be used at all. >> >>CATENATE and URLAUTH are both defined with the assumption that they >>only handle URLs without this newer parameter, so the Profile >>document defines a new capability to signal that CATENATE and URLAUTH >>can be used with byte-range URLs as well as whole-part URLs. >> >>So yes, the profile does need to define a new capability not defined >>within any of the referenced specifications. >> >>I'll have a think about how this can be made clearer - if you've >>suggestions, they'd be most welcome. >> >> >Ok. Now I believe I understood this better. > > >[IMAP-URL] defines a URL scheme for referencing objects on an IMAP server. >It does not define how you actually use the URL in order to get the >referenced objects. > Correct. >In any case, the ABNF for the URL is defined in that >document and it contains tokens that refer to specifications that are used >in the IMAP context, for example URLAUTH specified in RFC 4467. As such, >they define the semantic for these tokens. > Right. >So, now you would like to use the token PARTIAL with the IMAP-URL. There >isn't really a separate registry of parameters for usage with the IMAP-URL, >as far as I can tell from my quick read. > Correct. >Section 11 of RFC 5092 only says >"Elements not defined here can be found in [ABNF], [IMAP4], [IMAPABNF], or >[URI-GEN]." Hence, this seems to mean that the tokens have to be registered >in http://www.iana.org/assignments/imap4-capabilities in order to be usable >for the IMAP-URL. > > New tokens have to be registered, yes. What actually happened was that RFC 4469 and RFC 4467 references the old IMAP URL RFC (RFC 2192). When the updated IMAP URL (RFC 5092) spec was finished, it contained an extra syntactic element - PARTIAL. However in order for an IMAP client to know if such token can be used with a particular CATENATE/URLAUTH capable servers, a new IMAP capability key needs to be advertised by the server. >Hence, you have to register the URL-PARTIAL token in >http://www.iana.org/assignments/imap4-capabilities in order to get this to >work. > >Is this roughly a correct summary? > > More or less. >What section in >http://tools.ietf.org/html/draft-ietf-lemonade-profile-bis-12 describes the >semantic of the URL-PARTIAL token? You refer to Section 5.7.1 in the IANA >consideration section but that section doesn't really say anything in that >regard. > > I am not sure what is your concern here. Section 5.7.1 currently says: [IMAP-URL] introduced a new syntactic element for referencing a byte range of a message/body part. This is done using the ;PARTIAL= field. If an IMAP server supports PARTIAL in IMAP URL used in CATENATE and URLAUTH extensions, then it MUST advertise the URL- PARTIAL capability in the CAPABILITY response/response code. >Btw, maybe you should replace >"5.7.1. Support for PARTIAL in CATENATE and URLAUTH" >with >"5.7.1. Support for URL-PARTIAL in CATENATE and URLAUTH" > > The latter is slightly more confusing, IMHO, as one IMAP extension isn't typically included in another. Maybe replace "PARTIAL" with ";PARTIAL=" IMAP URL element"? From Nicolas.Williams@sun.com Wed Mar 11 10:32: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 731E928C115 for ; Wed, 11 Mar 2009 10:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.725 X-Spam-Level: X-Spam-Status: No, score=-5.725 tagged_above=-999 required=5 tests=[AWL=0.321, 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 95iHdh10Kc8A for ; Wed, 11 Mar 2009 10:32:12 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id E2BA028C11A for ; Wed, 11 Mar 2009 10:32:10 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2BHWkgj009543 for ; Wed, 11 Mar 2009 17:32:46 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 n2BHWjgW041782 for ; Wed, 11 Mar 2009 11:32:45 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2BHG5Pq021375; Wed, 11 Mar 2009 12:16:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2BHG0FO021374; Wed, 11 Mar 2009 12:16:00 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 11 Mar 2009 12:16:00 -0500 From: Nicolas Williams To: secdir@ietf.org Message-ID: <20090311171600.GE9992@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Cc: vijay@wichorus.com, tim.polk@nist.gov, Pasi.Eronen@nokia.com, suresh.krishnan@ericsson.com, nishi@stoke.com, rkoodli@starentnetworks.com, julien.IETF@laposte.net Subject: [secdir] secdir review of draft-ietf-netlmm-pmipv6-heartbeat-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:32: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. Sorry I'm late with this review. This document defines a heartbeat protocol for Proxy Mobile IPv6 "anchors" (LMA -- Local Mobility Anchor) and "gateways" (MAG -- Mobility Access Gateway). These heartbeat messages carry no information that is useful to eavesdroppers, and are sent relatively infrequently (no more often than every 30 seconds). Heartbeats are used to detect dead/restarted LMAs/MAGs. I have found no security issues with this document. Nico -- From turners@ieca.com Wed Mar 11 20:07:48 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E403A69E6 for ; Wed, 11 Mar 2009 20:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 pXTtrm2Ssc0J for ; Wed, 11 Mar 2009 20:07:48 -0700 (PDT) Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by core3.amsl.com (Postfix) with SMTP id BBCA63A6800 for ; Wed, 11 Mar 2009 20:07:47 -0700 (PDT) Received: (qmail 15140 invoked from network); 12 Mar 2009 03:08:24 -0000 Received: from unknown (HELO ?192.168.1.2?) (turners@96.241.7.200 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 12 Mar 2009 03:08:24 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: QlFTOLUVM1l.feNzRFH1UboylXryhUpC6YoEd1ysUHbNfGlf05eOzioxRaqrxRTBv_Q9ZMiXTdvYmxu8Z.d0Cqu0XdXW3m8KYbwuNTtRB9Fk865QhIcBpaezCYsuTAfjUvNa5zqkIEPttZVqLyBcQZ720.wBZ5wUg8B1bQW9qYeRjJnBN6tVGHp7PtdPww-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B87CAC.6000105@ieca.com> Date: Wed, 11 Mar 2009 23:08:28 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: secdir , draft-ietf-netconf-tls@tools.ietf.org, Tim Polk , Pasi Eronen , netconf-chairs@tools.ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-ietf-netconf-tls-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 03:07:48 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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 doing this so late. This document defines how to use TLS to secure NETCONF exchanges. I don't have any security issues but I do I have a question about the last paragraph in 2.1. It says that TLS 1.2 MUST be supported and that future versions of TLS will also be supported and those mandatory to implement algorithms MUST also be supported. is that also saying that an implementation must support all future version of TLS too? spt From mbadra@gmail.com Thu Mar 12 02:14: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 87A583A6ACD; Thu, 12 Mar 2009 02:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 IuG7yaGxlecB; Thu, 12 Mar 2009 02:14:23 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id E7E103A67CC; Thu, 12 Mar 2009 02:14:22 -0700 (PDT) Received: by fxm24 with SMTP id 24so296943fxm.37 for ; Thu, 12 Mar 2009 02:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=F4pTcGYAODDd/5k5+4878MdIvBKYZA4KzQEwpyausGE=; b=T95eQaKRIL9zWjTyaDr3oeYjtkoPHAXuSZ9Y7XuNbN56c5e8zez2h8YiBsv0KYWj5o 1jZAVRkGkBSYQw9u+BzPTB0Nb0iv3bz5pfazmBLHVE3S4XaMmiK5YkvCRbI871aKvvXO B8wJzO+ZYw/p7Mp57etKPglqKes5iKu3nvTqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=SjRCY7Etmx3z7jb1cgduvoyZmdrPGIlzvRKTMXdOMpA+ClM9cyu3bL5+cE5jo+Hlzs AzGaXwwBpmv4vc2/6yc+CN9Ikd9mGwLyXhSYrtBWvWKRfkZPqxvZ7bgZDMx5+PP/Td9j JBe0TeX9i1c5dvP4yQPGFvm9H6ki6Fs7Eyjok= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.72.15 with SMTP id u15mr6621330fga.33.1236849299537; Thu, 12 Mar 2009 02:14:59 -0700 (PDT) In-Reply-To: <49B87CAC.6000105@ieca.com> References: <49B87CAC.6000105@ieca.com> Date: Thu, 12 Mar 2009 10:14:59 +0100 X-Google-Sender-Auth: 12d7e8a47b7d9f8c Message-ID: From: Badra To: Sean Turner Content-Type: multipart/alternative; boundary=000e0cd2a18023c0450464e86b4f X-Mailman-Approved-At: Thu, 12 Mar 2009 08:23:15 -0700 Cc: secdir , Tim Polk , Pasi Eronen , draft-ietf-netconf-tls@tools.ietf.org, iesg@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-netconf-tls-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 09:14:25 -0000 --000e0cd2a18023c0450464e86b4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Sean Turner, Thank you for your review. > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > I apologize for doing this so late. > > This document defines how to use TLS to secure NETCONF exchanges. > > I don't have any security issues but I do I have a question about the last > paragraph in 2.1. It says that TLS 1.2 MUST be supported and that future > versions of TLS will also be supported and those mandatory to implement > algorithms MUST also be supported. is that also saying that an > implementation must support all future version of TLS too? > > This document is assumed to apply to future versions of TLS, in which case the mandatory to implement cipher suite for the implemented version MUST be supported. If a future TLS version is implemented, so the mandatory cipher suite of that version must also be supported. But this doesn't mean it is mandatory to support any future TLS versions. Best regards Badra --000e0cd2a18023c0450464e86b4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Sean Turner,
Thank you for your review.

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

I apologize for doing this = so late.

This document defines how to use TLS to secure NETCONF exchanges.
I don't have any security issues but I do I have a question about the= last paragraph in 2.1. =A0It says that TLS 1.2 MUST be supported and that = future versions of TLS will also be supported and those mandatory to implem= ent algorithms MUST also be supported. =A0is that also saying that an imple= mentation must support all future version of TLS too?

=A0
=A0 =A0This document is assumed to apply to
=A0=A0 future versions = of TLS, in which case the mandatory to implement
=A0=A0 cipher suite for= the implemented version MUST be supported.
=A0
If a future TLS version is implemented, so the mandatory cipher suite = of that version must also be supported. But this doesn't mean it is man= datory to support any future TLS versions.
=A0
Best regards
Badra
--000e0cd2a18023c0450464e86b4f-- From philip_matthews@magma.ca Thu Mar 12 16:18:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC2C3A6B09 for ; Thu, 12 Mar 2009 16:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j6UaZcCXZ4k for ; Thu, 12 Mar 2009 16:18:05 -0700 (PDT) Received: from mail-08.primus.ca (mail11.primus.ca [216.254.141.178]) by core3.amsl.com (Postfix) with ESMTP id 649E13A696F for ; Thu, 12 Mar 2009 16:18:05 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LhuAk-0005BX-1Z; Thu, 12 Mar 2009 19:18:42 -0400 Message-Id: <5B811D30-3006-43BE-803B-6379BFCD54CE@magma.ca> From: Philip Matthews To: Paul Hoffman , Russ Housley In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 12 Mar 2009 19:18:36 -0400 References: <20090311142053.0F97D78839E@smtpout.capalon.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Mailman-Approved-At: Fri, 13 Mar 2009 11:34:06 -0700 Cc: Rohan Mahy , Jonathan Rosenberg , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-behave-turn-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 23:18:06 -0000 On Wed, 11-Mar-09, at 11:11 , Paul Hoffman wrote: > At 10:16 AM -0400 3/11/09, Russ Housley wrote: >> Does this mean MUST implement and SHOULD use? > > Good question, and I think the answer is that the document does not > *require* that authentication be implemented. That is, I couldn't > find a place where it said one way or another. I will defer to the > document authors to answer that one. Section 4 (General Behavior) says: In addition, the server SHOULD demand that all requests from the client be authenticated, using the Long-Term Credential mechanism described in [RFC5389], and the client MUST be prepared to authenticate requests if required. Thus clients will interoperate with a server, regardless of whether it requires authentication or not. There is no statement about what servers must implement, just what they should do. However, I think that most people recognize that the security of TURN is pretty poor without authentication, unless TLS transport is used. - Philip From philip_matthews@magma.ca Thu Mar 12 16:50:31 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F683A6C36 for ; Thu, 12 Mar 2009 16:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiZOghPaTt-x for ; Thu, 12 Mar 2009 16:50:30 -0700 (PDT) Received: from mail-06.primus.ca (mail11.primus.ca [216.254.141.178]) by core3.amsl.com (Postfix) with ESMTP id 976443A6C33 for ; Thu, 12 Mar 2009 16:50:30 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Lhug7-0004xG-1D; Thu, 12 Mar 2009 19:51:08 -0400 Message-Id: From: Philip Matthews To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 12 Mar 2009 19:51:03 -0400 References: X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] X-Mailman-Approved-At: Fri, 13 Mar 2009 11:34:06 -0700 Cc: rohan@ekabal.com, jdrosen@cisco.com, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-behave-turn-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 23:50:31 -0000 Paul: Thanks very much for your review. I am very glad to hear that TURN has good security. Security has been a concern of the authors and various members of the WG, however most of us do not have a strong security background. See replies in-line. On Wed, 11-Mar-09, at 10:04 , Paul Hoffman 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. > > First off, I apologize for the extreme lateness of this review; it > was a calendaring failure on my part. > > This document deals adequately with the security issues of the > protocol. Basically, the document says that TURN servers will most > likely rely on STUN's authentication mechanism, which is probably > sufficient for most scenarios. For those scenarios that need more > security (particularly encryption), TURN-over-TLS is defined in a > fairly straight-forward fashion as an extension of STUN-over-TLS. I will note that we don't expect TURN over TLS to be very popular, because the TLS session goes only from the client to the server, and does not cover the server-to-peer portion of the path. Any client at all concerned about security will encrypt its data, and thus the encryption provided by TLS becomes a second layer of encryption. Furthermore, the reliable in-order delivery mechanism of TCP is undesirable in many applications of TURN (e.g., VoIP). TURN has been a work-in-progress for quite some time, and was actually started before DTLS was invented. The authors are well-aware that DTLS might be more appropriate for TURN, but have strongly resisted adding it to the base spec in the interest of finishing TURN while avoiding "feature creep". > > > The security considerations section is much better than average, > particularly for a protocol where it is likely that many > implementers will probably punt on authentication and not even think > about encryption wiht TLS. > > Having said that, Figure 2 should be revised to show the expected > chain of events *including* the STUN authentication. Without this, > an implementer could be confused where the authentication would be. > This is covered better in section 16, but should be shown in the > early example as well. I am confused by this request, as Figure 2 _already_ shows the STUN authentication (e.g., the 401 Unauthorized response). The only thing not included are the details of the credential exchange, but figure 2 is in the Overview section where attribute details have been omitted from all the figures in order to focus on the high-level message exchange. > > > I note that authentication in TURN is a SHOULD, not a MUST, but I > think that is reasonable for the expected deployment scenarios for > TURN. Also, only TURN requests, not indications, are authenticated; > this is covered in good detail in the document. There is a very > large number of security-related SHOULDs in the document that do not > have "except where" clauses, but I didn't find any it wasn't clear > that the clause would read "except where you don't really care about > security anyway". > > In section 4, it says: > For each allocation, the server SHOULD generate a new > random nonce when the allocation is first attempted following the > randomness recommendations in [RFC4086] and SHOULD expire the nonce > at least once every hour during the lifetime of the allocation. > I did not understand the one-hour expiration; more explanation here > about why nonce regeneration is tied to an arbitrary time and not a > session should be given (or, probably, this should be changed to > actually tie the nonce regeneration to the end of the session). Note that what the above paragraph says is: * For each TURN session, generate a new nonce at the start of the session, * During the lifetime of each session, generate a new nonce at least once every hour. The one-hour expiration was a late addition, mainly because we couldn't find any better guidance on how rapidly nonces should be expired. In the absence of more concrete guidance, one hour seems about right to us. - Philip From weiler@watson.org Fri Mar 13 12:25: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 3BAC23A6B4C for ; Fri, 13 Mar 2009 12:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 prlhCpOIjSdt for ; Fri, 13 Mar 2009 12:25:11 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 9695D3A6B4F for ; Fri, 13 Mar 2009 12:25:00 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n2DJPcSL067539 for ; Fri, 13 Mar 2009 15:25:38 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n2DJPcJv067536 for ; Fri, 13 Mar 2009 15:25:38 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 13 Mar 2009 15:25:38 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Fri, 13 Mar 2009 15:25:38 -0400 (EDT) Subject: [secdir] assignments for March 20th 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, 13 Mar 2009 19:25:14 -0000 The next IESG telechat is April 2nd, after the San Francisco meeting. Several of the docs that had been scheduled for yesterday's telechat have instead been deferred 'til then -- if you had such a doc that you were particularly interested in, you have another three weeks to argue with the editors and, in some cases, the new ADs. :-) Congratulations to Tim on being reappointed for another term. Sam Hartman is next in the rotation. And the usual link to instructions and related resources: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-04-02 Ran Canetti TR draft-ietf-kitten-gssapi-channel-bindings-06 Donald Eastlake TR draft-ietf-mpls-ldp-capabilities-03 Sam Weiler T draft-ietf-softwire-security-requirements-07 Last calls and special requests: Derek Atkins draft-ietf-roll-building-routing-reqs-05 Rob Austein draft-p2pi-cooper-workshop-report-01 Uri Blumenthal draft-ietf-lemonade-streaming-09 Pat Cain draft-crocker-email-arch-11 Ran Canetti draft-ietf-avt-seed-srtp-09 Charles Clancy draft-ietf-ccamp-gmpls-ason-routing-ospf-07 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Lakshminath Dondeti draft-ietf-pce-global-concurrent-optimization-08 Donald Eastlake draft-ietf-dime-mip6-split-16 Shawn Emery draft-ietf-lemonade-notifications-10 Stephen Farrell draft-ietf-ipfix-exporting-type-02 Tobias Gondrom draft-ietf-netlmm-grekey-option-06 Phillip Hallam-Baker R draft-ietf-radext-design-07 Phillip Hallam-Baker R draft-atlas-icmp-unnumbered-06 Steve Hanna draft-peterson-rai-rfc3427bis-01 David Harrington draft-ietf-rmt-pi-norm-revised-09 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Vidya Narayanan draft-ietf-sip-saml-06 Joe Salowey draft-ietf-geopriv-lis-discovery-07 Sam Weiler draft-chown-v6ops-rogue-ra-03 Nico Williams draft-ietf-v6ops-ra-guard-02 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Glen Zorn draft-ietf-roll-indus-routing-reqs-04 From suresh.krishnan@ericsson.com Fri Mar 13 15:20: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 508953A6830 for ; Fri, 13 Mar 2009 15:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 yCcfeNWL33Jf for ; Fri, 13 Mar 2009 15:20:44 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 85A633A69EB for ; Fri, 13 Mar 2009 15:20:44 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n2DMSx9v022487; Fri, 13 Mar 2009 17:29:01 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:20:54 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 17:20:54 -0500 Message-ID: <49BADC36.4010902@ericsson.com> Date: Fri, 13 Mar 2009 18:20:38 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Nicolas Williams References: <20090311171600.GE9992@Sun.COM> In-Reply-To: <20090311171600.GE9992@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Mar 2009 22:20:54.0755 (UTC) FILETIME=[F9C0DB30:01C9A429] Cc: vijay@wichorus.com, secdir@ietf.org, tim.polk@nist.gov, Pasi.Eronen@nokia.com, nishi@stoke.com, rkoodli@starentnetworks.com, julien.IETF@laposte.net Subject: Re: [secdir] secdir review of draft-ietf-netlmm-pmipv6-heartbeat-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 22:20:45 -0000 Hi Nico, Thanks for taking the time to review this document. Regards Suresh On 11/03/09 01:16 PM, Nicolas Williams wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Sorry I'm late with this review. > > This document defines a heartbeat protocol for Proxy Mobile IPv6 > "anchors" (LMA -- Local Mobility Anchor) and "gateways" (MAG -- Mobility > Access Gateway). > > These heartbeat messages carry no information that is useful to > eavesdroppers, and are sent relatively infrequently (no more often than > every 30 seconds). Heartbeats are used to detect dead/restarted > LMAs/MAGs. > > I have found no security issues with this document. > > Nico From Hannes.Tschofenig@gmx.net Wed Mar 18 01:55: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 2DB7628C1A0 for ; Wed, 18 Mar 2009 01:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, GB_I_LETTER=-2, 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 J5Yb+K+1Shm1 for ; Wed, 18 Mar 2009 01:55:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 34B5A28C1B0 for ; Wed, 18 Mar 2009 01:55:21 -0700 (PDT) Received: (qmail invoked by alias); 18 Mar 2009 08:56:03 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp064) with SMTP; 18 Mar 2009 09:56:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/a4sBunlfaPi/DWd+Y8XkPnM0c16PI7hxr783s1l 9XeGp6qojpfd3N From: "Hannes Tschofenig" To: "'Security Area Directorate'" Date: Wed, 18 Mar 2009 10:57:14 +0200 Message-ID: <000301c9a7a7$890fa250$9c11a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C9A7B8.4C987250" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acmnp4hrMsAAWt8eRgCo6a29viHzmA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5,0.51 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: Wed, 18 Mar 2009 08:55:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C9A7B8.4C987250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I would like to point you to the Open Web authentication BOF on Monday, 1300-1500, in Continental 4. Your security related review comments are highly appreciated. Here is the link to the latest version of the OAuth draft: http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt Ciao Hannes >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf Of ext Eran Hammer-Lahav >Sent: 10 March, 2009 07:34 >To: oauth@ietf.org >Subject: Re: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt > >Forgot to mention the blog post is: > >http://www.hueniverse.com/hueniverse/2009/03/oauth-core-10-reborn.html > >EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf >> Of Eran Hammer-Lahav >> Sent: Monday, March 09, 2009 10:20 PM >> To: oauth@ietf.org >> Subject: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt >> >> I spent the last 3 days writing the entire spec from scratch (except >> for the security consideration section which was just >adjusted to the >> new terminology). The new revision is based on feedback I collected >> over the past year for the original specification. The main >> differences >> are: >> >> * Terminology. Gone are the confusing terms (consumer, >request token, >> consumer key, etc.). Instead I am using terms from the HTTP spec, >> slightly adjusted. >> >> * Structure. The previous revision mixed authentication with >> authorization and had very little reason to the way >normative text was >> placed across sections. The new structure splits the spec in >two. The >> first part talks about how to make authenticated requests using two >> sets of credentials. The second part offers a method (one of >many) for >> getting a token via redirection. >> >> * Encoding. The biggest issue with the previous revision was >confusion >> over parameter encoding and the signature base string. I cleaned up >> that section, added new examples, and removed a couple >instruction to >> encode the signature (bugs). If followed to the letter, the >spec would >> break all existing implementations... The good thing is it is >> confusing enough that most people understood it the wrong way (which >> is actually the right way). Take a look at the old section >about PLAINTEXT: >> >> --- >> oauth_signature is set to the concatenated encoded values of the >> Consumer Secret and Token Secret, separated by a '&' >character (ASCII >> code 38), even if either secret is empty. The result MUST be encoded >> again. >> --- >> >> 'The result MUST be encoded again' is just plain wrong. It >is encoded >> again but according to the parameter transmission method, not the >> special way OAuth does it, and the spec as written would actually >> double encode it. >> >> * Normative requirements. The spec previously contained many >MUSTs and >> SHOULDs about stuff that could not be verified like >documentation and >> obtaining client credentials. I took out all the ones that didn't >> actually made any practical difference. >> >> I'm sure there is more, since this is practically a brand new spec >> (same exact protocol). Please read and provide feedback. >> >> EHL >> >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org >> Sent: Monday, March 09, 2009 4:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-hammer-oauth-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : The OAuth Core Protocol >> Author(s) : E. Hammer-Lahav, B. Cook >> Filename : draft-hammer-oauth-01.txt >> Pages : 33 >> Date : 2009-03-09 >> >> This document specifies the OAuth core protocol. OAuth provides a >> method for clients to access server resources on behalf of another >> party (such a different client or an end user). It also provides a >> redirection-based user agent process for end users to >authorize access >> to clients by substituting their credentials (typically, a username >> and password pair) with a different set of delegation- specific >> credentials. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >_______________________________________________ >oauth mailing list >oauth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > ------=_NextPart_000_0004_01C9A7B8.4C987250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OAuth

Hi all,

I would like to point you to the = Open Web authentication BOF on Monday, 1300-1500, in Continental 4. =

Your security related review = comments are highly appreciated. Here is the link to the latest version = of the OAuth draft:

http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt=

Ciao
Hannes

>-----Original = Message-----
>From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org]
>On Behalf Of ext Eran = Hammer-Lahav
>Sent: 10 March, 2009 = 07:34
>To: oauth@ietf.org
>Subject: Re: [oauth] FW: I-D = Action:draft-hammer-oauth-01.txt
>
>Forgot to mention the blog = post is:
>
>http://www.hueniverse.com/hueniverse/2009/03/oauth-core-10-reborn.ht= ml
>
>EHL
>
>> -----Original = Message-----
>> From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
>On Behalf
>> Of Eran = Hammer-Lahav
>> Sent: Monday, March 09, = 2009 10:20 PM
>> To: = oauth@ietf.org
>> Subject: [oauth] FW: = I-D Action:draft-hammer-oauth-01.txt
>>
>> I spent the last 3 days = writing the entire spec from scratch (except
>> for the security = consideration section which was just
>adjusted to the
>> new terminology). The = new revision is based on feedback I collected
>> over the past year for = the original specification. The main
>> differences
>> are:
>>
>> * Terminology. Gone are = the confusing terms (consumer,
>request token,
>> consumer key, etc.). = Instead I am using terms from the HTTP spec,
>> slightly = adjusted.
>>
>> * Structure. The = previous revision mixed authentication with
>> authorization and had = very little reason to the way
>normative text was
>> placed across sections. = The new structure splits the spec in
>two. The
>> first part talks about = how to make authenticated requests using two
>> sets of credentials. = The second part offers a method (one of
>many) for
>> getting a token via = redirection.
>>
>> * Encoding. The biggest = issue with the previous revision was
>confusion
>> over parameter encoding = and the signature base string. I cleaned up
>> that section, added new = examples, and removed a couple
>instruction to
>> encode the signature = (bugs). If followed to the letter, the
>spec would
>> break all existing = implementations... The good thing is it is
>> confusing enough that = most people understood it the wrong way (which
>> is actually the right = way). Take a look at the old section
>about PLAINTEXT:
>>
>> ---
>> oauth_signature is set = to the concatenated encoded values of the
>> Consumer Secret and = Token Secret, separated by a '&'
>character (ASCII
>> code 38), even if = either secret is empty. The result MUST be encoded
>> again.
>> ---
>>
>> 'The result MUST be = encoded again' is just plain wrong. It
>is encoded
>> again but according to = the parameter transmission method, not the
>> special way OAuth does = it, and the spec as written would actually
>> double encode = it.
>>
>> * Normative = requirements. The spec previously contained many
>MUSTs and
>> SHOULDs about stuff = that could not be verified like
>documentation and
>> obtaining client = credentials. I took out all the ones that didn't
>> actually made any = practical difference.
>>
>> I'm sure there is more, = since this is practically a brand new spec
>> (same exact protocol). = Please read and provide feedback.
>>
>> EHL
>>
>>
>>
>> -----Original = Message-----
>> From: = i-d-announce-bounces@ietf.org [mailto:i-d-announce-
>> bounces@ietf.org] On = Behalf Of Internet-Drafts@ietf.org
>> Sent: Monday, March 09, = 2009 4:45 PM
>> To: = i-d-announce@ietf.org
>> Subject: I-D = Action:draft-hammer-oauth-01.txt
>>
>> A New Internet-Draft is = available from the on-line Internet-Drafts
>> directories.
>>
>> =      = Title           : The = OAuth Core Protocol
>> =      Author(s)       : = E. Hammer-Lahav, B. Cook
>> =      = Filename        : = draft-hammer-oauth-01.txt
>> =      = Pages           : = 33
>> =      = Date            : = 2009-03-09
>>
>> This document specifies = the OAuth core protocol.  OAuth provides a
>> method for clients to = access server resources on behalf of another
>> party (such a different = client or an end user).  It also provides a
>> redirection-based user = agent process for end users to
>authorize access
>> to clients by = substituting their credentials (typically, a username
>> and password pair) with = a different set of delegation- specific
>> credentials.
>>
>> A URL for this = Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt=
>>
>> Internet-Drafts are = also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which = will enable a MIME compliant mail reader
>> implementation to = automatically retrieve the ASCII version of the
>> Internet-Draft.
>_______________________________________________
>oauth mailing list
>oauth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>

------=_NextPart_000_0004_01C9A7B8.4C987250-- From secdir-bounces@mit.edu Tue Mar 17 17:38:44 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB0B28C194 for ; Tue, 17 Mar 2009 17:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrJYkkOT5Ddm for ; Tue, 17 Mar 2009 17:38:42 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 69B4B28C18C for ; Tue, 17 Mar 2009 17:38:42 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n2I0dPNb024054 for ; Tue, 17 Mar 2009 20:39:25 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n2I0dOlA024051 for ; Tue, 17 Mar 2009 20:39:24 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n2I0dFdK013700 for ; Tue, 17 Mar 2009 20:39:15 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id C2D3915C6D96 for ; Tue, 17 Mar 2009 20:39:14 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id bROAWupxpFR5sopw for ; Tue, 17 Mar 2009 20:39:14 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B173A681D; Tue, 17 Mar 2009 17:38:29 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A14D33A6873; Tue, 17 Mar 2009 17:38:28 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090318003828.A14D33A6873@core3.amsl.com> Date: Tue, 17 Mar 2009 17:38:28 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu 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: Thu, 19 Mar 2009 03:14:08 -0700 Subject: [secdir] [New-work] WG Review: Locator/ID Separation Protocol (lisp) 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: Wed, 18 Mar 2009 00:38:44 -0000 A new IETF working group has been proposed in the Routing 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, March 24, 2009. Locator/ID Separation Protocol (lisp) -------------------------------------------------- Last Modified: 2009-03-12 Current status: Proposed Working Group Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Mailing Lists: General Discussion: https://www.ietf.org/mailman/listinfo/lisp Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation". The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space and providing persistent identity in the EID space. LISP supports the separation of the Internet address space into Endpoint Identifiers and Routing Locators following a network-based map-and-encap scheme (RFC 1955). It employs EIDs that represent a mixture of locators and identifiers; it could also be classified as a multi-level locator scheme. A number of other approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Wed Mar 18 07:37: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 B8A9628C17E for ; Wed, 18 Mar 2009 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 c-OSiBclVSrh for ; Wed, 18 Mar 2009 07:37:06 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 98AEB28C1FF for ; Wed, 18 Mar 2009 07:37:02 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n2IEbkG3003584 for ; Wed, 18 Mar 2009 10:37:46 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n2IEbiZr003571 for ; Wed, 18 Mar 2009 10:37:45 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n2IEbZne007811 for ; Wed, 18 Mar 2009 10:37:35 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 9728715F57DA for ; Wed, 18 Mar 2009 10:37:34 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id yfWEt8DX2N6AzLD9 for ; Wed, 18 Mar 2009 10:37:34 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062F828C202; Wed, 18 Mar 2009 07:36:40 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 846FD28C0E6; Wed, 18 Mar 2009 07:36:38 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090318143638.846FD28C0E6@core3.amsl.com> Date: Wed, 18 Mar 2009 07:36:38 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu 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: Thu, 19 Mar 2009 03:14:08 -0700 Subject: [secdir] [New-work] WG Review: Dispatch (dispatch) 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: Wed, 18 Mar 2009 14:37:07 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure 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 Wednesday, March 25, 2009. Dispatch (dispatch) -------------------------------------------------- Last Modified: 2009-03-12 Current Status: Proposed Working Group Group Description: The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. Options for handling new work include: - Assigning the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter and establishing consensus for a new WG or Exploratory Group. This option will primarily be used with fairly mature and well-defined efforts. - Rejecting and deferring work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. The DISPATCH WG will also operate as an area wide WG where ideas can be discussed that do not currently have a logical venue for the work to be done. As part of this function, the WG will evaluate SIP Event Packages that were not developed inside some other area working group. Guiding principles will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts so that RAI does not take on more work than it can effectively complete. 3. Looking for commonalities among ongoing development efforts. Such commonalities may indicate the need to develop more general, reusable components. 4. Protecting the architectural integrity of RAI protocols and ensuring that work has general applicability. The WG may take on some of the previous work items from the SIPPING working group to allow a smooth transition. If the group decides that a particular topic needs to be addressed by a new or existing WG, this is still followed by the usual IETF chartering process, including, for instance, IETF-wide review of the proposed changes. Proposal for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Milestones: TBD _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Wed Mar 18 09:29:49 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB91A3A6974 for ; Wed, 18 Mar 2009 09:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Q2MH2Uu1Tfrv for ; Wed, 18 Mar 2009 09:29:49 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D716A28C172 for ; Wed, 18 Mar 2009 09:29:47 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n2IGUULC026440 for ; Wed, 18 Mar 2009 12:30:30 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n2IGUQZh026421 for ; Wed, 18 Mar 2009 12:30:26 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n2IGUGxG025556 for ; Wed, 18 Mar 2009 12:30:17 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 2EECD14A94CD for ; Wed, 18 Mar 2009 12:30:15 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id FKChXhkdWO4zAePT for ; Wed, 18 Mar 2009 12:30:15 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A767F3A6A59; Wed, 18 Mar 2009 09:29:30 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E815A3A69CA; Wed, 18 Mar 2009 09:29:29 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090318162929.E815A3A69CA@core3.amsl.com> Date: Wed, 18 Mar 2009 09:29:29 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu 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: Thu, 19 Mar 2009 03:14:08 -0700 Subject: [secdir] [New-work] WG Review: Session Initiation Protocol Core (SIPCore) 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: Wed, 18 Mar 2009 16:29:50 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure 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 Wednesday, March 25, 2009. Session Initiation Protocol Core (SIPCore) -------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2009-03-12 Group Description: The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the core SIP specifications, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 3265. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications. In this context, "update" means replacing or modifying protocol elements in the above listed RFCs in ways that would affect most or all implementations of those RFCs alone. Extensions to SIP that add new functionality that would not be required of all implementations will be done outside of this WG. The process and requirements for such extensions are documented in RFC 3427bis, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements will be a) interoperability problems that stem from ambiguous or under-defined specification, and b) requirements from other working groups in the RAI Area. Although in general the WG will not work on extensions to SIP, it may take on some previous work items from the SIP working group to allow for a smooth transition. The adoption of new items requires explicit agreement from the AD or rechartering. Goals and Milestones: Mar 2009 Identify requirements for test matrix to move 3261 to Draft Standard Mar 2009 Essential corrections to RFC 3261 (1st batch) to IESG (PS) May 2009 Delivering request-URI and parameters to UAS via proxy to IESG (PS) May 2009 INFO package framework to IESG (PS) _______________________________________________ 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 SRS0=vlvJky=7S=coopercain.com=pcain@yourhostingaccount.com Thu Mar 19 12:33: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 D53E828C14D; Thu, 19 Mar 2009 12:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4zYx21tqlxR; Thu, 19 Mar 2009 12:33:00 -0700 (PDT) Received: from mailout05.yourhostingaccount.com (mailout05.yourhostingaccount.com [65.254.253.45]) by core3.amsl.com (Postfix) with ESMTP id CFD2D3A6A5A; Thu, 19 Mar 2009 12:32:53 -0700 (PDT) Received: from mailscan09.yourhostingaccount.com ([10.1.15.9] helo=mailscan09.yourhostingaccount.com) by mailout05.yourhostingaccount.com with esmtp (Exim) id 1LkNzm-0006Ot-W1; Thu, 19 Mar 2009 15:33:39 -0400 Received: from impout02.yourhostingaccount.com ([10.1.55.2] helo=impout02.yourhostingaccount.com) by mailscan09.yourhostingaccount.com with esmtp (Exim) id 1LkNzm-0006LZ-N6; Thu, 19 Mar 2009 15:33:38 -0400 Received: from authsmtp02.yourhostingaccount.com ([10.1.18.2]) by impout02.yourhostingaccount.com with NO UCE id V7Ze1b00102goRm0000000; Thu, 19 Mar 2009 15:33:38 -0400 X-EN-OrigOutIP: 10.1.18.2 X-EN-IMPSID: V7Ze1b00102goRm0000000 Received: from familyroom4.bc.edu ([136.167.27.76] helo=Familyroom) by authsmtp02.yourhostingaccount.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim) id 1LkNzm-00036n-31; Thu, 19 Mar 2009 15:33:38 -0400 Received: from Familyroom by Familyroom (PGP Universal service); Thu, 19 Mar 2009 15:33:34 -0500 X-PGP-Universal: processed; by Familyroom on Thu, 19 Mar 2009 15:33:34 -0500 From: "Patrick Cain" To: , , Date: Thu, 19 Mar 2009 15:33:21 -0400 Message-ID: <00ff01c9a8c9$957dc3f0$c0794bd0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmovu1So8dPyjC7S422ZIuzOP+3Aw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-EN-UserInfo: 058f9b27fa04b0cf04458fb359a831ba:155e17fc3c7b3afdad05516cd0497062 X-EN-AuthUser: pcain@coopercain.com Sender: "Patrick Cain" X-EN-OrigIP: 136.167.27.76 X-EN-OrigHost: familyroom4.bc.edu Cc: tony@att.net Subject: [secdir] secdir review of draft-crocker-email-arch-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 20:12:34 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is well thought out, but I have some minor comments: 1. The security considerations sections has lots of information and pointers. It looks pretty complete. It even has the every-smtp-rfc-mandatory-reference to spam. :) 2. The document uses a bunch of traditional x.400 messaging terms (e.g., MHS, MTA, MUA) to describe the SMTP mail system. I know it's picky, but if we're going to write a document that uses x.400 terms we may want to cite that work in an informal reference. Pat From dcrocker@bbiw.net Fri Mar 20 11: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 B27F63A6C11; Fri, 20 Mar 2009 11:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+tDriHuT9ML; Fri, 20 Mar 2009 11:03:11 -0700 (PDT) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 99EA53A6C01; Fri, 20 Mar 2009 11:03:08 -0700 (PDT) Received: from [127.0.0.1] (adsl-67-127-54-19.dsl.pltn13.pacbell.net [67.127.54.19]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n2KI3iDX027705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2009 11:03:49 -0700 Message-ID: <49C3DA80.3010100@bbiw.net> Date: Fri, 20 Mar 2009 11:03:44 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Patrick Cain References: <00ff01c9a8c9$957dc3f0$c0794bd0$@com> In-Reply-To: <00ff01c9a8c9$957dc3f0$c0794bd0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9145/Fri Mar 20 07:59:16 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 20 Mar 2009 11:03:50 -0700 (PDT) Cc: iesg@ietf.org, tony@att.net, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-crocker-email-arch-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: Fri, 20 Mar 2009 18:03:12 -0000 Patrick Cain wrote: > 2. The document uses a bunch of traditional x.400 messaging terms (e.g., MHS, > MTA, MUA) to describe the SMTP mail system. I know it's picky, but if we're > going to write a document that uses x.400 terms we may want to cite that work > in an informal reference. Patrick, Thanks for the review. Leaving out x.400 references wasn't an accident, but it also wasn't obvious which way to go. For one thing, in email presentations, I sometimes ask who has not heard of x.400 and it has become a substantial number. (And, for reference, we developed the original UA/MTA model before X.400, through IFIP WG 6.5.) Perhaps more substantive is the potential for confusing the reading: email-arch provides its own definitions, and they are not the same as X.400's. This is especially true for ADMD. (It's a little bit like the discomfort of trying to be precisely use the actual ISO definitions of the 7 layers, when talking about IETF networking protocols. Approximation works well; precision doesn't.) Nonetheless, yeah, it probably makes sense to give a nod to that history. I suggest simply adding a citation to the first reference to UA/MTA in email-arch: > 1.1. History > > The first standardized architecture for networked email specified a simple > split between the user world, in the form of Mail User Agents (MUA), and the > transfer world, in the form of the Mail Handling Service (MHS), which is > composed of Mail Transfer Agents (MTA).*[RFC1506]* The MHS accepts a message from one > User and delivers it to one or more other users, creating a virtual > MUA-to-MUA exchange environment. [RFC1506] Houttuin, J., A Tutorial on Gatewaying between X.400 and Internet Mail , August 1993 The alternative is: [X400] Recommendation F.400/X.400 (06/99), ITU-T, but I prefer the 1506 because it cites IFIP wg6.5 and has some historical discussion. Does that work for you? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Pasi.Eronen@nokia.com Sun Mar 22 09:09: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 4C67F3A67F6 for ; Sun, 22 Mar 2009 09:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGGIVG-8a3-T for ; Sun, 22 Mar 2009 09:09:32 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 60D8B3A67DF for ; Sun, 22 Mar 2009 09:09:32 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2MGAKSs015148 for ; Sun, 22 Mar 2009 11:10:21 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Mar 2009 18:10:17 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Mar 2009 18:10:17 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Sun, 22 Mar 2009 17:10:16 +0100 From: To: Date: Sun, 22 Mar 2009 17:10:15 +0100 Thread-Topic: SecDir lunch at IETF74 Thread-Index: AcmhUhgC6gxjRI2oSjGiSI+2iwruaAJtkiWQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F2071C78@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F1CB1A96@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1CB1A96@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: 22 Mar 2009 16:10:17.0204 (UTC) FILETIME=[B0DB9B40:01C9AB08] X-Nokia-AV: Clean Subject: Re: [secdir] SecDir lunch at IETF74 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 Mar 2009 16:09:33 -0000 The room will be Continental 7&8. Best regards, Pasi=20 > -----Original Message----- > From: secdir-bounces@ietf.org=20 > [mailto:secdir-bounces@ietf.org] On Behalf Of Eronen Pasi=20 > (Nokia-NRC/Helsinki) > Sent: 10 March, 2009 09:31 > To: secdir@ietf.org > Subject: [secdir] SecDir lunch at IETF74 >=20 > Folks, >=20 > We'll have the Security Directorate lunch on Tuesday as before. > We are still waiting on a room assignment, but will send the room =20 > number as soon as we get it from the secretariat.=20 >=20 > As usual, bring your own lunch and we will discuss what's=20 > going on in the area and around the IETF.=20 >=20 > Best regards,=20 > Pasi & Tim=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > = From tim.polk@nist.gov Sun Mar 22 10:53: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 8400A3A69D4 for ; Sun, 22 Mar 2009 10:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 97Dp+C-CJc1F for ; Sun, 22 Mar 2009 10:53:54 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id CBEEE3A67F6 for ; Sun, 22 Mar 2009 10:53:53 -0700 (PDT) Received: from h222110.nist.gov (h222110.nist.gov [129.6.222.110]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n2MHsWqh014821; Sun, 22 Mar 2009 13:54:37 -0400 Message-Id: From: Tim Polk To: secdir@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Mar 2009 09:02:50 -0700 X-Mailer: Apple Mail (2.930.3) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Cc: Pasi Eronen Subject: [secdir] Location for Security Directorate Lunch 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 Mar 2009 17:53:54 -0000 Folks, We have a room assignment for our usual Tuesday Security Directorate lunch: Continental 7 & 8. Hope to see you all there! Thanks, Tim & Pasi... From dcrocker@bbiw.net Mon Mar 23 15:31: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 40EAF28C158; Mon, 23 Mar 2009 15:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8478lut6pNk; Mon, 23 Mar 2009 15:31:37 -0700 (PDT) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 13CC128C121; Mon, 23 Mar 2009 15:31:36 -0700 (PDT) Received: from [130.129.87.235] (dhcp-57eb.meeting.ietf.org [130.129.87.235] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n2NMWCB1026128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 15:32:22 -0700 Message-ID: <49C80DE9.8050905@bbiw.net> Date: Mon, 23 Mar 2009 15:32:09 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Patrick Cain References: <00ff01c9a8c9$957dc3f0$c0794bd0$@com> <49C3DA80.3010100@bbiw.net> <01b401c9ac03$b9268ac0$2b73a040$@com> In-Reply-To: <01b401c9ac03$b9268ac0$2b73a040$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9155/Mon Mar 23 10:26:16 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 23 Mar 2009 15:32:24 -0700 (PDT) Cc: iesg@ietf.org, tony@att.net, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-crocker-email-arch-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 22:31:38 -0000 okey dokey, thanks! d/ Patrick Cain wrote: > Dave, > > Sure that works for me. > > Thanks, > Pat > > -----Original Message----- > From: Dave CROCKER [mailto:dcrocker@bbiw.net] > Sent: Friday, March 20, 2009 2:04 PM ... > [RFC1506] Houttuin, J., A Tutorial on Gatewaying between X.400 and Internet > Mail , August 1993 -- Dave Crocker Brandenburg InternetWorking bbiw.net From SRS0=ocAiku=7W=coopercain.com=pcain@yourhostingaccount.com Mon Mar 23 15:06: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 5BE8B3A6AB9; Mon, 23 Mar 2009 15:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLjJIzWFdjYz; Mon, 23 Mar 2009 15:06:49 -0700 (PDT) Received: from mailout17.yourhostingaccount.com (mailout17.yourhostingaccount.com [65.254.253.136]) by core3.amsl.com (Postfix) with ESMTP id 37A8E3A6A55; Mon, 23 Mar 2009 15:06:49 -0700 (PDT) Received: from mailscan19.yourhostingaccount.com ([10.1.15.19] helo=mailscan19.yourhostingaccount.com) by mailout17.yourhostingaccount.com with esmtp (Exim) id 1LlsJ1-0005PO-4T; Mon, 23 Mar 2009 18:07:39 -0400 Received: from impout02.yourhostingaccount.com ([10.1.55.2] helo=impout02.yourhostingaccount.com) by mailscan19.yourhostingaccount.com with esmtp (Exim) id 1LlsJ0-00038C-Sc; Mon, 23 Mar 2009 18:07:38 -0400 Received: from authsmtp01.yourhostingaccount.com ([10.1.18.1]) by impout02.yourhostingaccount.com with NO UCE id Wm7S1b00601P85W0000000; Mon, 23 Mar 2009 18:07:26 -0400 X-EN-OrigOutIP: 10.1.18.1 X-EN-IMPSID: Wm7S1b00601P85W0000000 Received: from dhcp-1365.meeting.ietf.org ([130.129.19.101] helo=Familyroom) by authsmtp01.yourhostingaccount.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim) id 1LlsIo-0000FF-K3; Mon, 23 Mar 2009 18:07:26 -0400 Received: from Familyroom by Familyroom (PGP Universal service); Mon, 23 Mar 2009 18:07:21 -0500 X-PGP-Universal: processed; by Familyroom on Mon, 23 Mar 2009 18:07:21 -0500 From: "Patrick Cain" To: "'Dave CROCKER'" References: <00ff01c9a8c9$957dc3f0$c0794bd0$@com> <49C3DA80.3010100@bbiw.net> In-Reply-To: <49C3DA80.3010100@bbiw.net> Date: Mon, 23 Mar 2009 18:06:58 -0400 Message-ID: <01b401c9ac03$b9268ac0$2b73a040$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmphjqQGHu3yDQpQXCaUFFEDZUW5ACUNyvg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-EN-UserInfo: 058f9b27fa04b0cf04458fb359a831ba:155e17fc3c7b3afdad05516cd0497062 X-EN-AuthUser: pcain@coopercain.com Sender: "Patrick Cain" X-EN-OrigIP: 130.129.19.101 X-EN-OrigHost: dhcp-1365.meeting.ietf.org Cc: iesg@ietf.org, tony@att.net, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-crocker-email-arch-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:38:47 -0000 Dave, Sure that works for me. Thanks, Pat -----Original Message----- From: Dave CROCKER [mailto:dcrocker@bbiw.net] Sent: Friday, March 20, 2009 2:04 PM To: Patrick Cain Cc: iesg@ietf.org; secdir@ietf.org; tony@att.net Subject: Re: secdir review of draft-crocker-email-arch-11 Patrick Cain wrote: > 2. The document uses a bunch of traditional x.400 messaging terms (e.g., MHS, > MTA, MUA) to describe the SMTP mail system. I know it's picky, but if we're > going to write a document that uses x.400 terms we may want to cite that work > in an informal reference. Patrick, Thanks for the review. Leaving out x.400 references wasn't an accident, but it also wasn't obvious which way to go. For one thing, in email presentations, I sometimes ask who has not heard of x.400 and it has become a substantial number. (And, for reference, we developed the original UA/MTA model before X.400, through IFIP WG 6.5.) Perhaps more substantive is the potential for confusing the reading: email-arch provides its own definitions, and they are not the same as X.400's. This is especially true for ADMD. (It's a little bit like the discomfort of trying to be precisely use the actual ISO definitions of the 7 layers, when talking about IETF networking protocols. Approximation works well; precision doesn't.) Nonetheless, yeah, it probably makes sense to give a nod to that history. I suggest simply adding a citation to the first reference to UA/MTA in email-arch: > 1.1. History > > The first standardized architecture for networked email specified a simple > split between the user world, in the form of Mail User Agents (MUA), and the > transfer world, in the form of the Mail Handling Service (MHS), which is > composed of Mail Transfer Agents (MTA).*[RFC1506]* The MHS accepts a message from one > User and delivers it to one or more other users, creating a virtual > MUA-to-MUA exchange environment. [RFC1506] Houttuin, J., A Tutorial on Gatewaying between X.400 and Internet Mail , August 1993 The alternative is: [X400] Recommendation F.400/X.400 (06/99), ITU-T, but I prefer the 1506 because it cites IFIP wg6.5 and has some historical discussion. Does that work for you? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tim.polk@nist.gov Tue Mar 24 09:25: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 969CD3A6B44 for ; Tue, 24 Mar 2009 09:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.668 X-Spam-Level: X-Spam-Status: No, score=-5.668 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_20=-0.74, 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 7GTS31SKytQN for ; Tue, 24 Mar 2009 09:25:04 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id AC0813A6901 for ; Tue, 24 Mar 2009 09:25:03 -0700 (PDT) Received: from h222148.nist.gov (h222148.nist.gov [129.6.222.148]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n2OGQ1Kw026121; Tue, 24 Mar 2009 12:26:03 -0400 Message-Id: <880E86DF-A666-4522-9FFC-F5C418BE6CB4@nist.gov> From: Tim Polk To: secdir@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 09:25:46 -0700 X-Mailer: Apple Mail (2.930.3) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Subject: [secdir] finding lunch before secdir 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 Mar 2009 16:25:08 -0000 Folks, I just talked with the concierge about finding a quick lunch near the hotel. He recommended the subway a block and a half down Ellis (125 Ellis Street) or the Quiznos a block away on Geary (422 Geary Street). There is also a Jack in the Box next to the the Quiznos on Geary that is probably pretty quick, but I will note the concierge didn't mention it. Thanks, and see you at the meeting. Tim Polk From barryleiba.mailing.lists@gmail.com Tue Mar 24 09:46: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 997E03A6D41 for ; Tue, 24 Mar 2009 09:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp3xf-qExcgD for ; Tue, 24 Mar 2009 09:46:17 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id CC5ED3A6D3C for ; Tue, 24 Mar 2009 09:46:16 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so4139030yxm.49 for ; Tue, 24 Mar 2009 09:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=0fCHoHxbsWJVsWuGoovNGd3BLWQWGP7g1oKcy1XNHX0=; b=Xaqbp4ayv1gYTuDbZoEOb39rFWntUeyx/l/gjZdL5ZZOCxmGzAfM6lJvPDVHUu+HZx UUh4LgdhccxespImGzQguPSzUaGiDk6gqQycpivF86I3BtVj4ulwta4MVLs6zsCZlBg+ yGeZ/u0SFzKjfQKEGkUm3eYYleULZ6/70gS2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=whL1NcVH2Gu08ABG1+tcIyLEhuqIba3TQC9M7tixqp/KYpELBLc9YP7e2M/VFnGuMD nm3iP38DYooaZ90PIaMGDkJVjAUXFQV2r1az40dJyj+KJMhVBLQliXQC68yO+WLsHfa7 RboSprYtcdYBxSl87XMggttivd8CmfmGmZ3Jo= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.100.134.10 with SMTP id h10mr7850968and.53.1237913227348; Tue, 24 Mar 2009 09:47:07 -0700 (PDT) In-Reply-To: <880E86DF-A666-4522-9FFC-F5C418BE6CB4@nist.gov> References: <880E86DF-A666-4522-9FFC-F5C418BE6CB4@nist.gov> Date: Tue, 24 Mar 2009 12:47:07 -0400 X-Google-Sender-Auth: 43343f88cc051130 Message-ID: <6c9fcc2a0903240947l11372g90efb1ecece429ca@mail.gmail.com> From: Barry Leiba To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [secdir] finding lunch before secdir 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 Mar 2009 16:46:17 -0000 Tim cites the Hilton Concierge: > =A0He recommended the subway a block and a half down Ellis (125 Ellis Str= eet) > or the Quiznos a block away on Geary (422 Geary Street). =A0There is also= a > Jack in the Box next to the the Quiznos on Geary that is probably pretty > quick, but I will note the concierge didn't mention it. There's also a Thai place across Taylor from the side entrance to the hotel, and a quickie curry place across O'Farrell from the main entrance. Just in case you'd rather have something other than Subway or Quiznos (or JitB). Barry From tim.polk@nist.gov Tue Mar 24 09:53: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 B89373A6BFF for ; Tue, 24 Mar 2009 09:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHT-3MdNbTzW for ; Tue, 24 Mar 2009 09:53:12 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id D875D28C2F7 for ; Tue, 24 Mar 2009 09:53:00 -0700 (PDT) Received: from h222148.nist.gov (h222148.nist.gov [129.6.222.148]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n2OGrtZ5014630; Tue, 24 Mar 2009 12:53:57 -0400 From: Tim Polk To: Barry Leiba In-Reply-To: <6c9fcc2a0903240947l11372g90efb1ecece429ca@mail.gmail.com> References: <880E86DF-A666-4522-9FFC-F5C418BE6CB4@nist.gov> <6c9fcc2a0903240947l11372g90efb1ecece429ca@mail.gmail.com> Message-Id: <63A514A9-7729-4D01-86CF-881E3F7D877A@nist.gov> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 09:53:40 -0700 X-Mailer: Apple Mail (2.930.3) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Cc: secdir@ietf.org Subject: Re: [secdir] finding lunch before secdir 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 Mar 2009 16:53:13 -0000 Thanks for expanding the list! I suspect I prejudiced the concierge by asking where people could get a sandwich or fast food. On Mar 24, 2009, at 9:47 AM, Barry Leiba wrote: > Tim cites the Hilton Concierge: >> He recommended the subway a block and a half down Ellis (125 Ellis >> Street) >> or the Quiznos a block away on Geary (422 Geary Street). There is >> also a >> Jack in the Box next to the the Quiznos on Geary that is probably >> pretty >> quick, but I will note the concierge didn't mention it. > > There's also a Thai place across Taylor from the side entrance to the > hotel, and a quickie curry place across O'Farrell from the main > entrance. Just in case you'd rather have something other than Subway > or Quiznos (or JitB). > > Barry > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From barryleiba.mailing.lists@gmail.com Tue Mar 24 13:38: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 B360A3A69BD for ; Tue, 24 Mar 2009 13:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LbX0CtNNNlH for ; Tue, 24 Mar 2009 13:38:04 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 159B828C198 for ; Tue, 24 Mar 2009 13:37:47 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so4272032ywh.49 for ; Tue, 24 Mar 2009 13:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WMwNCXSchaDHQg0EqpCZfKpMRyCAsMbKCPBc2qpgcoU=; b=Sn+ryHBp1phBkUHHuj087S7dAwg7nuvdNCcJwVKKQp3jVYREbF6yc/4eOWyqMvtmum oRpR3i5gSGda2HOQzCSoKD77UdQZ2+jlqfRP8uGhTWDjvsPENxSjlMJxwppqMF/T2NxQ Y1wHMOu5HRwvbs0s4WZqmZ2YXbZajhwHhuupM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=gcVqZtk960/epA6gAHYrP+yGS6tQ0J1RRP5DALlc0NcAXfFfzTiK1NhE+f9r+zc9Rs iHpvGRcOYKCK/gG57mV99TZWhrbLI17ANLam1NCIv3SaIior/7VmaDcuGi21ZuORkqzB DARw7Gvr/g5Mg9wHzUpiTdmkcipeoqsM3tnDQ= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.100.126.15 with SMTP id y15mr2692478anc.18.1237927119212; Tue, 24 Mar 2009 13:38:39 -0700 (PDT) Date: Tue, 24 Mar 2009 16:38:39 -0400 X-Google-Sender-Auth: 10015d7f37f8e2b3 Message-ID: <6c9fcc2a0903241338y2e53432di2b9e58973005a219@mail.gmail.com> From: Barry Leiba To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] ISOC IPv6 panel, which conflicted with the SecDir lunch 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 Mar 2009 20:38:04 -0000 Since I missed the SecDir lunch for the ISOC IPv6 panel, I thought I'd give a quick summary of the latter. The session was, as advertised, meant more for the press than for IETF attendees. As such, y'all didn't miss much, though it was a good session. The (brief) presentations were good, there was time for just a few questions, and the answers were effective. I think the press got a good message. The content was basically "IETF72 Plenary Lite", and, in fact, two of the presenters were the same (Lorenzo Colitti and Alain Durand). The message was consistent and not surprising: IPv6 is ready, IPv4 has a limited life, transition is not hard nor expensive, and we should all do it. And the rubber chicken was good -- probably better than Subway, but not as good as the Thai place across the street. Barry From rbarnes@bbn.com Tue Mar 24 13:44: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 697CC28C2E9 for ; Tue, 24 Mar 2009 13:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0flYCgbqlWE for ; Tue, 24 Mar 2009 13:44:23 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A4ED428C157 for ; Tue, 24 Mar 2009 13:44:23 -0700 (PDT) Received: from [128.89.252.49] (helo=dhcp-17f1.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LmDUl-0003d1-Es; Tue, 24 Mar 2009 16:45:11 -0400 Message-ID: <49C94656.4040206@bbn.com> Date: Tue, 24 Mar 2009 13:45:10 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Barry Leiba References: <6c9fcc2a0903241338y2e53432di2b9e58973005a219@mail.gmail.com> In-Reply-To: <6c9fcc2a0903241338y2e53432di2b9e58973005a219@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] ISOC IPv6 panel, which conflicted with the SecDir lunch 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 Mar 2009 20:44:24 -0000 From Ekr's blog:
Leslie Daigle just summed up the situation with IPv6 at today's ISOC IPv6 press event: "It's [IPv6] sort of a broccoli technology; good for you but not necessarily attractive in its own right."
Barry Leiba wrote: > Since I missed the SecDir lunch for the ISOC IPv6 panel, I thought I'd > give a quick summary of the latter. > > The session was, as advertised, meant more for the press than for IETF > attendees. As such, y'all didn't miss much, though it was a good > session. The (brief) presentations were good, there was time for just > a few questions, and the answers were effective. I think the press > got a good message. > > The content was basically "IETF72 Plenary Lite", and, in fact, two of > the presenters were the same (Lorenzo Colitti and Alain Durand). The > message was consistent and not surprising: IPv6 is ready, IPv4 has a > limited life, transition is not hard nor expensive, and we should all > do it. > > And the rubber chicken was good -- probably better than Subway, but > not as good as the Thai place across the street. > > Barry > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From barryleiba.mailing.lists@gmail.com Tue Mar 24 14:33: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 1CFDD3A6B93 for ; Tue, 24 Mar 2009 14:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW-WnJ0SrnOQ for ; Tue, 24 Mar 2009 14:33:13 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 2602028C1C9 for ; Tue, 24 Mar 2009 14:32:45 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so2697600and.4 for ; Tue, 24 Mar 2009 14:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=hLFFLQkf6zvgIsdOOALqTIutTJFL9bsbJw3l8GLSkMM=; b=uvL+8jCH011Wb3TC1l46VLKCDFaIZ9lpLDHjqHfsjsd7yLK4OQ9kQVtUzMZncQt+CV IdMYwUJy7i2gfdNJsfyprV3mW3HUmf4BRKYUNdLM5rOe3DsZJY37iHDmnq282oMgQOdl ZSF0eCZhnjsyLohVqMMER1kOA1n1NMcqGl1R8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=W7jdzkS4Do8ZSIw6zA3/h85EBtZszSfHjpMkzpTnmz/8qxGOvbqeiE5KqKW0qeKkZj kzdtwRcCN1Li1+TRrhRNLyf18vESDvu8qGyNk8uTOfilSNwwYoXpgWyt2omkC7Od+40S y3bmEW49r1/6sqWkFtYvJpoYE5Y/HQI2J/7QU= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.100.6.16 with SMTP id 16mr3010173anf.23.1237930416307; Tue, 24 Mar 2009 14:33:36 -0700 (PDT) In-Reply-To: <49C94656.4040206@bbn.com> References: <6c9fcc2a0903241338y2e53432di2b9e58973005a219@mail.gmail.com> <49C94656.4040206@bbn.com> Date: Tue, 24 Mar 2009 17:33:32 -0400 X-Google-Sender-Auth: faaf0dd970c4c6d6 Message-ID: <6c9fcc2a0903241433q4a7a0e2fo4006d4309494e31a@mail.gmail.com> From: Barry Leiba To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] ISOC IPv6 panel, which conflicted with the SecDir lunch 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 Mar 2009 21:33:14 -0000 > Leslie Daigle just summed up the situation with IPv6 at today's ISOC IPv6 > press event: "It's [IPv6] sort of a broccoli technology; good for you but > not necessarily attractive in its own right." Right... to which my sotto voce comment at the time was, "Mmmmmm, broccoli ! " Barry From weiler@watson.org Wed Mar 25 00:28: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 9BEBD3A681D for ; Wed, 25 Mar 2009 00:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrYk5NFt-fxs for ; Wed, 25 Mar 2009 00:28:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id DE6163A6359 for ; Wed, 25 Mar 2009 00:28:53 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n2P7Th4W057692 for ; Wed, 25 Mar 2009 03:29:43 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n2P7Th0R057689 for ; Wed, 25 Mar 2009 03:29:43 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 25 Mar 2009 03:29:43 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Wed, 25 Mar 2009 03:29:43 -0400 (EDT) Subject: [secdir] Welcome to Dan and Chris X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 07:28:54 -0000 As announced at yesterday's secdir lunch, Chris Newman and Dan Harkins will be joining us. Alexey Melnikov will also be going on an extended holiday, though he'll likely be remaining on the mailing list. -- Sam From weiler@watson.org Thu Mar 26 18:35:28 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 D1FD83A6B51 for ; Thu, 26 Mar 2009 18:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 uhheYPncKaPT for ; Thu, 26 Mar 2009 18:35:28 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id D64C33A6AA4 for ; Thu, 26 Mar 2009 18:35:27 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n2R1aKF7082161 for ; Thu, 26 Mar 2009 21:36:21 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n2R1aKtR082158 for ; Thu, 26 Mar 2009 21:36:20 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 26 Mar 2009 21:36:20 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Thu, 26 Mar 2009 21:36:21 -0400 (EDT) Subject: [secdir] assignments for April 2nd 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, 27 Mar 2009 01:35:28 -0000 There was no assignment email last week. Charlie Kaufman is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-04-09 Ran Canetti TR draft-ietf-kitten-gssapi-channel-bindings-06 Donald Eastlake TR draft-ietf-mpls-ldp-capabilities-03 Sam Weiler T draft-ietf-softwire-security-requirements-07 For telechat 2009-04-23 Phillip Hallam-Baker TR draft-atlas-icmp-unnumbered-06 Last calls and special requests: Derek Atkins draft-ietf-roll-building-routing-reqs-05 Rob Austein draft-p2pi-cooper-workshop-report-01 Ran Canetti draft-ietf-avt-seed-srtp-09 Charles Clancy draft-ietf-ccamp-gmpls-ason-routing-ospf-07 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Lakshminath Dondeti draft-ietf-pce-global-concurrent-optimization-09 Donald Eastlake draft-ietf-dime-mip6-split-16 Shawn Emery draft-ietf-lemonade-notifications-10 Stephen Farrell draft-ietf-ipfix-exporting-type-02 Tobias Gondrom draft-ietf-netlmm-grekey-option-06 Phillip Hallam-Baker R draft-ietf-radext-design-07 Steve Hanna draft-peterson-rai-rfc3427bis-01 David Harrington draft-ietf-rmt-pi-norm-revised-09 Sam Hartman draft-ietf-ipfix-file-03 Paul Hoffman draft-iana-rfc3330bis-06 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Jeffrey Hutzelman draft-ietf-openpgp-camellia-04 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Vidya Narayanan draft-ietf-sip-saml-06 Joe Salowey draft-ietf-geopriv-lis-discovery-08 Sam Weiler draft-chown-v6ops-rogue-ra-03 Nico Williams draft-ietf-v6ops-ra-guard-02 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Glen Zorn draft-ietf-roll-indus-routing-reqs-04 From stephen.farrell@cs.tcd.ie Mon Mar 30 04:43:11 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563FA3A67AC for ; Mon, 30 Mar 2009 04:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.182 X-Spam-Level: X-Spam-Status: No, score=-0.182 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqoXDHaid34j for ; Mon, 30 Mar 2009 04:43:10 -0700 (PDT) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 7D8FD3A68E4 for ; Mon, 30 Mar 2009 04:43:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id C12A11003F56E; Mon, 30 Mar 2009 12:44:06 +0100 (IST) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4SQM-8pmREX; Mon, 30 Mar 2009 12:44:06 +0100 (IST) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id ED5971003F56B; Mon, 30 Mar 2009 12:44:05 +0100 (IST) Message-ID: <49D0B0C4.9010603@cs.tcd.ie> Date: Mon, 30 Mar 2009 12:45:08 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-ipfix-exporting-type@tools.ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tim Polk , Pasi Eronen , ipfix-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-ipfix-exporting-type-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 11:43:11 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a way to include typing information in IPFIX messages. - The security considerations section is just a one liner saying that the same issues apply here as are documented in rfc 5101. In this case that reference is (with the one quibble below:-) sufficient since 5101's security considerations seem to be very comprehensive. - Are the length limits defined somewhere for the strings? E.g. in section 3.3. The concern is buffer overflow etc. so if that's addressed somewhere else that's fine. It may be worth noting this as an additional security consideration since, e.g. the introduction states that collecting processes may use this typing information to store or display otherwise unknown data types. I guess if I could feed a collector arbitrarily complex data types and values I'd be in a good position to try engineer a buffer overrun. Nits: - bottom of p3: s/version of/versions of/ - 3.8 the description is a bit unclear to me (as a naive reader) and the Enterprise bit seems to be referenced here for the 1st time. I'm not at all sure, but it could be that this text is calling for a change to some other RFC (I mean the "SHOULD be cleared" phrase) Regards, Stephen. From paul.hoffman@vpnc.org Mon Mar 30 09:27: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 BFFFD3A6D35 for ; Mon, 30 Mar 2009 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, 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 Njs7FXzubLfA for ; Mon, 30 Mar 2009 09:27:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B5AD83A6D39 for ; Mon, 30 Mar 2009 09:27:41 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2UGSGEA087900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 09:28:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 30 Mar 2009 09:28:14 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: leo.vegoda@icann.org, michelle.cotton@icann.org Subject: [secdir] Secdir review of draft-iana-rfc3330bis-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 Mar 2009 16:27:42 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is essentially a security-free document. Having said that, the one paragraph in the Security Considerations section could use a bit of clarification. It says: The particular assigned values of special-use IPv4 addresses cataloged in this document do not directly raise security issues. However, the Internet does not inherently protect against abuse of these addresses; if you expect (for instance) that all packets from the 10.0.0.0/8 block originate within your subnet, all border routers should filter such packets that originate from elsewhere. Attacks have been mounted that depend on the unexpected use of some of these addresses. I think that "all packets from the 10.0.0.0/8 block" should be "all packets from a private address space such as the 10.0.0.0/8 block or the link local block 169.254.0.0/16". Also, I believe that "all border routers should filter such packets that originate from elsewhere" should be "all routers at the border of your network should filter such packets that originate from outside your network". Please also note the messages on ietf-general from this past weekend; having another example block would help many IETF documents. --Paul Hoffman, Director --VPN Consortium From jhutz@cmu.edu Mon Mar 30 10:52:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027DF3A6BBB; Mon, 30 Mar 2009 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.945 X-Spam-Level: X-Spam-Status: No, score=-5.945 tagged_above=-999 required=5 tests=[AWL=0.654, 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 z3Mw5gSzQdwG; Mon, 30 Mar 2009 10:52:38 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 4298B3A6BB4; Mon, 30 Mar 2009 10:52:38 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n2UHrYG4016955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 13:53:34 -0400 (EDT) Date: Mon, 30 Mar 2009 13:51:13 -0400 From: Jeffrey Hutzelman To: iesg@ietf.org, secdir@ietf.org, dshaw@jabberwocky.com, openpgp-chairs@tools.ietf.org Message-ID: <00542A62F0B6A1F06B80B448@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Subject: [secdir] secdir review of draft-ietf-openpgp-camellia-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 17:52:39 -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. Abstract: This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. Camellia is described in RFC3713, OpenPGP in RFC4880. Pretty much all this document does is allocate the algorithm identifiers required to use Camellia in OpenPGP. It also calls out potential interoperability issues related to choosing a symmetric cipher for use in an OpenPGP message, and has a reasonable security considerations section suggesting steps to be taken when choosing an encryption algorithm. I see no problems with this document. -- Jeff From d3e3e3@gmail.com Tue Mar 31 14:13:40 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFEA28C1A6; Tue, 31 Mar 2009 14:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 V78hGjrbcl4v; Tue, 31 Mar 2009 14:13:40 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id BBFB328C1AA; Tue, 31 Mar 2009 14:13:39 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so3786547ywh.49 for ; Tue, 31 Mar 2009 14:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=x8Q05P7V/kGgHK/PHbQMNIunV2sz6DiVUtksW5r+bPI=; b=dBYBSgG/z5mvNV3lGSNFP1oEEkp7io6jFbWyiIkLiB/BTKPHtUBEwSp1/9QSzjTunn lgdlvdqjn0OmwDBSy6izxzzhWTQcEwvPaFP6gwGM+VfWEoJzPu6F4YgGM8GNmkX+CbmN 7qN3RmfzJR8yEOeq8iNMZ4/Kt2v6red/T7t7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=kV6JHUZKl2DkXU+EHda5HJWWGooPT1TesZazg2BoidXxODLohMWjCr//odQiMK1Thr WCdb7iSWACjnQlEr2w4c3KwY9+kH52IbF3DaFtnGiGdTwf8wRt9QBghPyBYOcW3+YfKg 9F65KDRhC3qJykwiIg2zYFcYsXW1wRYB8iG/w= MIME-Version: 1.0 Received: by 10.100.8.4 with SMTP id 4mr5377318anh.81.1238534078957; Tue, 31 Mar 2009 14:14:38 -0700 (PDT) Date: Tue, 31 Mar 2009 17:14:38 -0400 Message-ID: <1028365c0903311414s2a0c63a3v5399b3fdbcba3445@mail.gmail.com> From: Donald Eastlake To: iesg@ietf.org, secdir@ietf.org, rhthomas@cisco.com, shivani@juniper.net, rahul@juniper.net, jeanlouis.leroux@orange-ftgroup.com, skraza@cisco.com, George Swallow , Loa Andersson , Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] draft-ietf-mpls-ldp-capabilities-03.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 21:13:40 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. These comments should be treated just like any other last call comments. This draft concerns dynamic LDP capability announcement and withdrawal. It's Security Considerations section simply refers to RFC 5306, the LDP Specification. While it doesn't seem to me that RFC 5306 offers much security, mostly saying only talk to people you trust, this referral from draft-ietf-mpls-ldp-capabilities-03.txt appears to correctly summarize the security considerations for this draft. nits: Section 2, fourth dash point OLD - Includes an IANA considerations section that requests IANA for assignment of code point for the optional parameter corresponding NEW - Includes an IANA considerations section that requests IANA assignment of a code point for the optional parameter corresponding Section 3: 2nd paragraph: insert "a" or "the" after "The format of". Page 5/6: do not split ASCII art over a page boundary. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com