From secdir-bounces@mit.edu Wed Apr 1 02:19:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0566628C10A for ; Wed, 1 Apr 2009 02:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=2.929, 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 4Wmiiv-rjLHt for ; Wed, 1 Apr 2009 02:19:20 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id EBCC428C16A for ; Wed, 1 Apr 2009 02:19:19 -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 n319KJbl019812 for ; Wed, 1 Apr 2009 05:20:19 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n319KIsf019809 for ; Wed, 1 Apr 2009 05:20:18 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n319KAht004901 for ; Wed, 1 Apr 2009 05:20:10 -0400 (EDT) Received: from doar.tau.ac.il (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 4DC9715B6476 for ; Wed, 1 Apr 2009 05:20:09 -0400 (EDT) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by mit.edu with ESMTP id 4v9WlSVc9nedQ63L for ; Wed, 01 Apr 2009 05:20:09 -0400 (EDT) Received-SPF: pass (mit.edu: domain of canetti@post.tau.ac.il designates 132.66.16.26 as permitted sender) receiver=mit.edu; client_ip=132.66.16.26; envelope-from=canetti@post.tau.ac.il; Received: from [132.67.110.213] (lap-canetti1.cs.tau.ac.il [132.67.110.213]) by doar.tau.ac.il (Postfix) with ESMTP id F09BCBEFB; Wed, 1 Apr 2009 12:20:08 +0300 (IDT) Message-ID: <49D331C6.7000407@post.tau.ac.il> Date: Wed, 01 Apr 2009 12:20:06 +0300 From: canetti User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: secdir@mit.edu, kitten@ietf.org, Ran Canetti X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] Security review of draft-ietf-kitten-gssapi-channel-bindings-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 09:19:21 -0000 *I have reviewed this document as part of the security directorate's *ongoing effort to review all IETF documents being processed by the *IESG. These comments were written primarily for the benefit of the *security area directors. Document editors and WG chairs should treat *these comments just like any other last call comments. This is a very short document. It describes a more generic way of formatting the API for channel bindings. The move to a more generic format is welcome. One potential objection here, however, is to the requirement that compliant implementations MUST interpret the API as having the new format. This may have backwards compatibility issues, and for no apparent good reason. It might be better to specify the format so that an implementation will be able to take also older API formats. (Since this is not an interoperability or security-sensitive issue, there seems to be no reason for the IETF to MANDATE one way over another.) Best, Ran _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Wed Apr 1 07:14:29 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AF53A691A for ; Wed, 1 Apr 2009 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amQD1C26MXZJ for ; Wed, 1 Apr 2009 07:14:29 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D08CB3A6830 for ; Wed, 1 Apr 2009 07:14:28 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n31EFSFl011807 for ; Wed, 1 Apr 2009 10:15:28 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n31EFRvx011804 for ; Wed, 1 Apr 2009 10:15:27 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n31EFMGq001824 for ; Wed, 1 Apr 2009 10:15:22 -0400 (EDT) Received: from jackfruit.srv.cs.cmu.edu (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 6213717CDD45 for ; Wed, 1 Apr 2009 10:15:21 -0400 (EDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by mit.edu with ESMTP id 601xnHKNxAb7NNJ5 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 01 Apr 2009 10:15:21 -0400 (EDT) Received: from [192.168.1.108] (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n31EF75J015692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 10:15:08 -0400 (EDT) Date: Wed, 01 Apr 2009 10:15:08 -0400 From: Jeffrey Hutzelman To: canetti , secdir@mit.edu, kitten@ietf.org, Ran Canetti Message-ID: In-Reply-To: <200904010920.n319KOb5006961@mx03.srv.cs.cmu.edu> References: <200904010920.n319KOb5006961@mx03.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: Re: [secdir] Security review of draft-ietf-kitten-gssapi-channel-bindings-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:14:30 -0000 --On Wednesday, April 01, 2009 12:20:06 PM +0300 canetti wrote: > > > > *I have reviewed this document as part of the security directorate's > *ongoing effort to review all IETF documents being processed by the > *IESG. These comments were written primarily for the benefit of the > *security area directors. Document editors and WG chairs should treat > *these comments just like any other last call comments. > > > This is a very short document. It describes a more generic way of > formatting the API for channel bindings. The move to a more generic > format is welcome. One potential objection here, however, is to the > requirement that compliant implementations MUST interpret the API as > having the new format. This may have backwards compatibility issues, and > for no apparent good reason. It might be better to specify the format so > that an implementation will be able to take also older API formats. > (Since this is not an interoperability or security-sensitive issue, there > seems to be no reason for the IETF to MANDATE one way over another.) Since it's the only one that applies to implementatios, I assume you're referring to the requirement that, when bindings of the GSS-API to a particular programming language model channel bindings as octet strings, the input be treated as corresponding only to the application-data portion of the channel bindings structure rather than some (unspecified) encoding of the channel bindings structure. This requirement is needed for interoperability. GSS-API mechanisms supporting channel bindings are responsible for checking that the channel bindings claimed by the initiator and acceptor are the same, and failing the authentication process otherwise. This is typically done by transferring an integrity-protected copy of the channel bindings data or a hash thereof. Naturally, for this to work it is important that when the channel bindings are actually the same, so are the data strings used by the mechanism implementations at both ends. More generally, it is important that for any given set of channel binding data, the data string used to represent that data by any given mechanism always be the same. This is accomplished at three layers... - By defining abstract interfaces between GSS-API applications and the GSS-API framework or mechanism, including what information about channel bindings must be passed down. This is done in RFC2743, updated and clarified by the present document. - By defining concrete bindings to the abstract interfaces in various specific programming languages. This is done in RFC2744 for C, and by RFC2853 (to be updated by a current KITTEN document) for Java. - By defining, for each mechanism, the procedure for transforming the abstract channel binding information into a particular octet string used to verify channel bindings on the wire. What the present requirement is about is insuring that, when the concrete bindings for a particular language provide only for a single octet string rather than for all of the elements in the GSS-CHANNEL-BINDINGS structure, the interpretation of that octet string is consistent from one implementation to the next. Note that this is not a change to the API; it is a clarification which improves interoperability by requiring all implementations of an ambiguous API to resolve the ambiguity in the same way. -- Jeff _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Wed Apr 1 14:59: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 BEA0A3A6867 for ; Wed, 1 Apr 2009 14:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 s1ZIa5ffd8xD for ; Wed, 1 Apr 2009 14:59:10 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id C81263A6863 for ; Wed, 1 Apr 2009 14:59:10 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n31M0ADB001402 for ; Wed, 1 Apr 2009 18:00:10 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n31M08l3001394 for ; Wed, 1 Apr 2009 18:00:08 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n31M04va004566 for ; Wed, 1 Apr 2009 18:00:04 -0400 (EDT) Received: from sca-ea-mail-3.sun.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 60373151ED0C for ; Wed, 1 Apr 2009 18:00:00 -0400 (EDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by mit.edu with ESMTP id u0o606rK612XRF52 for ; Wed, 01 Apr 2009 18:00:00 -0400 (EDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n31LxxpB019862 for ; Wed, 1 Apr 2009 22:00:00 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 n31LxxeI033226 for ; Wed, 1 Apr 2009 15:59:59 -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 n31LZfdX015565; Wed, 1 Apr 2009 16:35:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31LZaVl015564; Wed, 1 Apr 2009 16:35:36 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 16:35:36 -0500 From: Nicolas Williams To: canetti Message-ID: <20090401213536.GT9992@Sun.COM> References: <49D331C6.7000407@post.tau.ac.il> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <49D331C6.7000407@post.tau.ac.il> User-Agent: Mutt/1.5.7i X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: kitten@ietf.org, secdir@mit.edu Subject: Re: [secdir] Security review of draft-ietf-kitten-gssapi-channel-bindings-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:59:11 -0000 On Wed, Apr 01, 2009 at 12:20:06PM +0300, canetti 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! I know that Jeff has already answered this... > This is a very short document. It describes a more generic way of > formatting the API for channel bindings. The move to a more generic > format is welcome. One potential objection here, however, is to the > requirement that compliant implementations MUST interpret the API as > having the new format. This may have backwards compatibility issues, > and for no apparent good reason. It might be better to specify the > format so that an implementation will be able to take also older API > formats. (Since this is not an interoperability or security-sensitive > issue, there seems to be no reason for the IETF to MANDATE one way > over another.) Let's pick a programming language, say, Python, and suppose that the Python bindings of the GSS-API followed RFC2743 with regards to channel binding. An implementation of those bindings AND of the Kerberos V GSS-API mechanism (RFCs 1964 and 4121) would have to decide how to map the RFC2743 "OCTET STRING" channel binding input to the mechanism's channel binding (which is defined in terms of RFC2744's gss_channel_bindings_struct C struct rather than "OCTET STRING"). Two implementations of such bindings would fail to interop when using channel bindings if the implementors decided this matter differently. Worse, suppose that you had a Python bindings implementation that mapped the RFC2743 OCTET STRING channel binding input to then initiator_address field of the RFC2744 gss_channel_bindings_struct C struct. Then you could not interop with C implementations of the same application protocol when using channel binding[*]. IMO the only reasonable decision for the implementors would be to map the RFC2743 OCTET STRING channel binding input to the RFC2744 application_data field of gss_channel_bindings_struct. And indeed, this may require changing some of the putative implementations of the putative Python bindings of the GSS-API. I don't see any alternatives. [*] Only RFC2744 application_data makes sense for channel binding nowadays. Use of network addresses for channel binding was long ago abandoned -- think of NATs :( -- and anyways, channel binding to cryptographically secure channels makes much sense, while channel binding to network addresses does not make much sense at all. Nico -- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From Nicolas.Williams@sun.com Wed Apr 1 15:08: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 44DA23A6867 for ; Wed, 1 Apr 2009 15:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.751 X-Spam-Level: X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, FAKE_REPLY_C=2.012, 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 PZZMCm3uHMdM for ; Wed, 1 Apr 2009 15:08:44 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 56A663A672F for ; Wed, 1 Apr 2009 15:08:44 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n31M9jSc015929 for ; Wed, 1 Apr 2009 22:09:45 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 n31M9i0N041352 for ; Wed, 1 Apr 2009 16:09:44 -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 n31M0Sq6015619 for ; Wed, 1 Apr 2009 17:00:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31M0Srw015618 for secdir@ietf.org; Wed, 1 Apr 2009 17:00:28 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 17:00:28 -0500 From: Nicolas Williams To: secdir@ietf.org Message-ID: <20090401220028.GK1155@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D331C6.7000407@post.tau.ac.il> User-Agent: Mutt/1.5.7i Subject: Re: [secdir] Security review of draft-ietf-kitten-gssapi-channel-bindings-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 22:08:45 -0000 [Re-sending to secdir@ietf.org.] On Wed, Apr 01, 2009 at 12:20:06PM +0300, canetti 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! I know that Jeff has already answered this... > This is a very short document. It describes a more generic way of > formatting the API for channel bindings. The move to a more generic > format is welcome. One potential objection here, however, is to the > requirement that compliant implementations MUST interpret the API as > having the new format. This may have backwards compatibility issues, > and for no apparent good reason. It might be better to specify the > format so that an implementation will be able to take also older API > formats. (Since this is not an interoperability or security-sensitive > issue, there seems to be no reason for the IETF to MANDATE one way > over another.) Let's pick a programming language, say, Python, and suppose that the Python bindings of the GSS-API followed RFC2743 with regards to channel binding. An implementation of those bindings AND of the Kerberos V GSS-API mechanism (RFCs 1964 and 4121) would have to decide how to map the RFC2743 "OCTET STRING" channel binding input to the mechanism's channel binding (which is defined in terms of RFC2744's gss_channel_bindings_struct C struct rather than "OCTET STRING"). Two implementations of such bindings would fail to interop when using channel bindings if the implementors decided this matter differently. Worse, suppose that you had a Python bindings implementation that mapped the RFC2743 OCTET STRING channel binding input to then initiator_address field of the RFC2744 gss_channel_bindings_struct C struct. Then you could not interop with C implementations of the same application protocol when using channel binding[*]. IMO the only reasonable decision for the implementors would be to map the RFC2743 OCTET STRING channel binding input to the RFC2744 application_data field of gss_channel_bindings_struct. And indeed, this may require changing some of the putative implementations of the putative Python bindings of the GSS-API. I don't see any alternatives. [*] Only RFC2744 application_data makes sense for channel binding nowadays. Use of network addresses for channel binding was long ago abandoned -- think of NATs :( -- and anyways, channel binding to cryptographically secure channels makes much sense, while channel binding to network addresses does not make much sense at all. Nico -- From Pasi.Eronen@nokia.com Wed Apr 1 23:56: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 9E9E13A6867; Wed, 1 Apr 2009 23:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 w3G9IhTwzoko; Wed, 1 Apr 2009 23:56:35 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AD7F93A683F; Wed, 1 Apr 2009 23:56:34 -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 n326vNXu021276; Thu, 2 Apr 2009 01:57:35 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:57:22 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:57:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 09:57:12 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 08:57:12 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Thu, 2 Apr 2009 08:57:11 +0200 From: To: , Date: Thu, 2 Apr 2009 08:57:15 +0200 Thread-Topic: Pasi's AD Notes for March 2009 Thread-Index: AcmzYEFJsaTcqRp8Q8qZVH+8Hexk4w== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F218F802@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: 02 Apr 2009 06:57:12.0339 (UTC) FILETIME=[3FAE4E30:01C9B360] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for March 2009 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 06:56:36 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - I and Tim need to edit the SAAG minutes and post them [since 2009-03-26] - We have received a liaison statement from ITU-T SG 17; I and Tim=20 need to organize a response. - (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 - draft-ietf-dkim-rfc4871-errata: lots of emails that I haven't read yet. - draft-ietf-dkim-ssp: waiting for the errata dust to settle=20 (probably small changes to Section 2.7, either editorial or technical,=20 are needed no matter how this turns out) - draft-ietf-dkim-overview: waiting for authors to submit a revised ID addressing my AD review comments (except perhaps the first=20 one -- that may require more discussion) and Barry's editorial=20 nits (off-list 2008-10-28...2008-11-12) [since 2009-02-27] - Waiting for WG to send list of RFC errata IDs (the non-controversial ones, not related to d=3D/i=3D) the WG agrees on. EMU - (not WG items) New RFCs: RFC 5421 and 5422 IPSECME - (not wearing hats) draft-ietf-ipsecme-ikev2-ipv6-config: I promised to update the draft (clean it, address TBDs) so it would be ready=20 for WGLC (as Experimental) if this path is chosen by WG. ISMS - draft-ietf-isms-secshell, draft-ietf-isms-tmsm, and draft-ietf-isms-transport-security-model: going to IETF last call - draft-ietf-isms-radius-usage: waiting for me to do my AD=20 review [since 2009-03-27] - Discussions about rechartering; waiting for concrete proposal =20 from David/Jeff/Wes/etc. KEYPROV - Lots of emails I need to read since IETF74... PKIX - Note: I'm shepherding two PKIX drafts where Tim is a co-author - draft-ietf-pkix-ecc-subpubkeyinfo: now published as RFC 5480 - draft-ietf-pkix-rfc4055-update: was approved by IESG, now in=20 RFC Editor queue SASL - Some progress on SCRAM/GS2 SYSLOG - Four new RFCs: RFC 5424, 5425, 5426, 5427 - draft-ietf-syslog-sign: waiting for me to read version -25=20 [since 2009-03-31] - Discussions about rechartering (either in SEC or OPS area) or closing down. TLS - draft-ietf-tls-ecdhe-psk: now published as RFC 5489 - draft-ietf-tls-psk-new-mac-aes-gcm: now published as RFC 5487 - (not WG item) draft-rescorla-tls-suiteb: now published as RFC 5430 - (not WG item yet) Apparently some folks are interested in getting draft-rescorla-tls-extended-random published (and an implementation exists). I was hoping to see a presentation in San Francisco, but that didn't happen -- perhaps something happens on the mailing list. - (not WG item yet) I need to talk with the chairs and Michael about what to do with Mobi-D OTHER DOCUMENTS - draft-lebovitz-kmart-roadmap: I need to read this and=20 comment/contribute. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. DISCUSSES (active -- something happened within last month) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] - draft-ietf-btns-connection-latching: waiting for me to read the new version -09 [since 2009-03-26] - draft-ietf-calsify-rfc2445bis: changes agreed, waiting for=20 the authors to submit a revised ID [since 2009-03-31] - draft-ietf-l2tpext-tdm: waiting for authors to submit a revised ID and Ralph to re-do the IETF last call [since 2009-02-07] - draft-ietf-monami6-multiplecoa: some text agreed; discussed the IPsec problem in IETF74, and came to rough agreement on how to solve it; waiting for authors to propose concrete text [since 2009-03-24] - draft-ietf-ospf-lls: version -07 did not address my comments; waiting for a revised ID or RFC Editor Notes [since 2009-03-19] - draft-ietf-softwire-encaps-ipsec: I think we roughly agreed on how to solve the initiator authentication problem; waiting for authors to propose concrete text [since 2009-03-27] - draft-igoe-secsh-aes-gcm: waiting for Tim to send email to=20 secsh list/other folks [since 2009-03-22] 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-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-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] (but talked briefly with Radia at IETF74) - 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 Thu Apr 2 15:16:09 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E153A6A71 for ; Thu, 2 Apr 2009 15:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.924 X-Spam-Level: X-Spam-Status: No, score=-4.924 tagged_above=-999 required=5 tests=[AWL=1.675, 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 GZJWRKSrVbSH for ; Thu, 2 Apr 2009 15:16:08 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 480C43A68DD for ; Thu, 2 Apr 2009 15:16:08 -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 n32MH9ER018739 for ; Thu, 2 Apr 2009 18:17:09 -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 n32MH6mj018733 for ; Thu, 2 Apr 2009 18:17:06 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n32MGwu6015081 for ; Thu, 2 Apr 2009 18:16:58 -0400 (EDT) Received: from leela.webpack.hosteurope.de (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 1C13717765D6 for ; Thu, 2 Apr 2009 18:16:48 -0400 (EDT) Received: from leela.webpack.hosteurope.de (leela.webpack.hosteurope.de [217.115.142.65]) by mit.edu with ESMTP id zpxnWGaFbQNlltuy for ; Thu, 02 Apr 2009 18:16:48 -0400 (EDT) Received: from guestbroadband.plus.com ([84.92.231.211] helo=[172.24.32.4]); authenticated by leela.webpack.hosteurope.de running ExIM using esmtpa id 1LpVDI-0008G4-1W; Fri, 03 Apr 2009 00:16:44 +0200 Message-ID: <49D53957.4000606@gondrom.org> Date: Thu, 02 Apr 2009 23:16:55 +0100 From: Tobias Gondrom User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: secdir@mit.edu X-bounce-key: webpack.hosteurope.de; tobias.gondrom@gondrom.org; 1238710609; 24eb21f5; 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 Cc: jonne.soininen@nsn.com, kleung@cisco.com, mkhalil@nortel.com, jari.arkko@piuha.net, iesg@ietf.org, sgundave@cisco.com, amuhanna@nortel.com Subject: [secdir] SECDIR review of draft-ietf-netlmm-grekey-option-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:16:09 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, the document is clear and ok, although I am not that particularly strong with MIPv6 etc. >From the review I have one simple Question and one comment: 1. simple maybe stupid Question: Section 6.4 Status codes: What do you mean with the abbrevation "TBD" in this text? e.g. "GRE KEY OPTION NOT REQUIRED (TBD less than 128)" 2. COMMENT on Section 9 Security Considerations: Considering the potential risks, I find it unnecessary weak to state that the there described security mechanisms "can be used". The section should use the stronger term of "SHOULD be" used instead throughout the whole section. Additionally in the last paragraph:"In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for protecting a mobile node's data traffic is optional." should rather use the term "recommended"/"RECOMMENDED" instead of "optional". Best regards, Tobias _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Thu Apr 2 15:51: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 1BB0628C104 for ; Thu, 2 Apr 2009 15:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 EYPo98YO1+sQ for ; Thu, 2 Apr 2009 15:51:10 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 1581228C0F2 for ; Thu, 2 Apr 2009 15:51:09 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n32MqAYj023237 for ; Thu, 2 Apr 2009 18:52:10 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n32Mq9Vj023229 for ; Thu, 2 Apr 2009 18:52:09 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n32Mq284005920 for ; Thu, 2 Apr 2009 18:52:02 -0400 (EDT) Received: from zrtps0kp.nortel.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id F1C58177856A for ; Thu, 2 Apr 2009 18:52:01 -0400 (EDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by mit.edu with ESMTP id SG2AkbFI0MqJBFjm (version=TLSv1 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 02 Apr 2009 18:52:01 -0400 (EDT) Received-SPF: pass (mit.edu: domain of AMUHANNA@nortel.com designates 47.140.192.56 as permitted sender) receiver=mit.edu; client_ip=47.140.192.56; envelope-from=AMUHANNA@nortel.com; X-ASG-Whitelist: Barracuda Reputation X-ASG-Whitelist: Barracuda Reputation Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n32Mpl129730; Thu, 2 Apr 2009 22:51:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Apr 2009 17:51:45 -0500 Message-ID: In-Reply-To: <49D53957.4000606@gondrom.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] SECDIR review of draft-ietf-netlmm-grekey-option-06 Thread-Index: Acmz4LqHSMq+qaqEQtmOGc+KCOqKhAAAR8oQ References: <49D53957.4000606@gondrom.org> From: "Ahmad Muhanna" To: "Tobias Gondrom" , X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id n32Mq9Vj023229 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: Thu, 02 Apr 2009 22:45:41 -0700 Cc: jonne.soininen@nsn.com, kleung@cisco.com, Mohamed Khalil , jari.arkko@piuha.net, iesg@ietf.org, sgundave@cisco.com Subject: Re: [secdir] SECDIR review of draft-ietf-netlmm-grekey-option-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:51:11 -0000 Hi Tobias, Thanks for the review and comments. Please see comments inline. Regards, Ahmad > -----Original Message----- > From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org] > Sent: Thursday, April 02, 2009 5:17 PM > To: secdir@mit.edu > Cc: iesg@ietf.org; Muhanna, Ahmad (RICH1:2H10); Khalil, > Mohamed (RICH2:2S20); sgundave@cisco.com; kleung@cisco.com; > vidyan@qualcomm.com; jonne.soininen@nsn.com; jari.arkko@piuha.net > Subject: [secdir] SECDIR review of draft-ietf-netlmm-grekey-option-06 > > Hello, > > I have reviewed this document as part of the security > directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written > primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments > just like any other last call comments. > > Overall, the document is clear and ok, although I am not that > particularly strong with MIPv6 etc. > > From the review I have one simple Question and one comment: > 1. simple maybe stupid Question: Section 6.4 Status codes: > What do you mean with the abbrevation "TBD" in this text? > e.g. "GRE KEY OPTION NOT REQUIRED (TBD less than 128)" [Ahmad] What it means is this Status code will be allocated from the same namespace as the Status code for MIP6 BA. The "TBD" will be replaced by the proper number by IANA and since it is NOT a rejection code, it needs to be the next available number less than 128. > > 2. COMMENT on Section 9 Security Considerations: > Considering the potential risks, I find it unnecessary weak > to state that the there described security mechanisms "can be > used". The section should use the stronger term of "SHOULD > be" used instead throughout the whole section. [Ahmad] These risks are inherited from the base Proxy MIP6 protocol. A recommendation of SHOULD in this specification which whole objective is to facilitate a dynamic negotiation of the uplink and downlink GRE keys using the existing Proxy MIP6 and MIPv6 signaling could be considered an over specification on top of the base protocol. > Additionally in the last paragraph:"In Proxy Mobile IPv6 > [RFC5213], the use of IPsec [RFC4301] for protecting a mobile > node's data traffic is optional." should rather use the term > "recommended"/"RECOMMENDED" instead of "optional". [Ahmad] Actually, the same text is used in RFC5213 (Proxy Mobile IPv6) which bases its reasoning on RFC3775 which states that it is optional. The following is the text from RFC5213 under section 4. " ............................................. As in Mobile IPv6 [RFC3775], the use of IPsec for protecting a mobile node's data traffic is optional. " If we state here it is RECOMMENDED, we may be introducing a requirement that is stronger than what in RFC5213. This specification does not introduce any new requirement on top of PMIPv6 with respect to protecting the mobile node's data traffic. > > > Best regards, > > Tobias > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From weiler+secdir@watson.org Fri Apr 3 09:44: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 81A963A6922 for ; Fri, 3 Apr 2009 09:44: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 OkR1-MH32aeR for ; Fri, 3 Apr 2009 09:44:03 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 86D193A67BD for ; Fri, 3 Apr 2009 09:44:03 -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 n33Gj5Mv064669 for ; Fri, 3 Apr 2009 12:45:05 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n33Gj5he064666 for ; Fri, 3 Apr 2009 12:45:05 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 3 Apr 2009 12:45:05 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 03 Apr 2009 12:45:05 -0400 (EDT) Subject: [secdir] Assignments for April 10th X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:44:04 -0000 Quite a number of new assignments, some of them on the telechat agenda for April 23rd. Radia Perlman 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 Charlie Kaufman T draft-ietf-pce-global-concurrent-optimization-10 Sam Weiler T draft-ietf-softwire-security-requirements-07 For telechat 2009-04-23 Phillip Hallam-Baker TR draft-atlas-icmp-unnumbered-06 Scott Kelly T draft-ietf-dccp-serv-codes-08 Stephen Kent T draft-ietf-dhc-container-opt-05 Sandy Murphy T draft-ietf-tcpm-tcpsecure-11 Hilarie Orman T draft-ietf-tcpm-ecnsyn-08 For telechat 2009-05-07 Shawn Emery T draft-ietf-lemonade-notifications-10 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 Donald Eastlake draft-ietf-dime-mip6-split-16 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 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Angelos Keromytis draft-ietf-isms-secshell-15 Julien Laganier draft-ietf-sip-certs-07 Julien Laganier draft-ietf-isms-tmsm-16 Barry Leiba draft-ietf-isms-transport-security-model-12 Chris Lonvick draft-ietf-pkix-3281update-04 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ncook-urlauth-accessid-02 Chris Newman draft-thomson-beep-async-02 Magnus Nystrom draft-ietf-mpls-p2mp-te-mib-08 Joe Salowey draft-ietf-geopriv-lis-discovery-09 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 secdir-bounces@mit.edu Sat Apr 4 07:36: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 C36983A6860 for ; Sat, 4 Apr 2009 07:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 D10oihdaYmwj for ; Sat, 4 Apr 2009 07:36:29 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 9527C3A6889 for ; Sat, 4 Apr 2009 07:36:29 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n34EbWo5011298 for ; Sat, 4 Apr 2009 10:37:32 -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 n34EbUEv011288 for ; Sat, 4 Apr 2009 10:37:30 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n34EbLEh002981 for ; Sat, 4 Apr 2009 10:37:21 -0400 (EDT) Received: from doar.tau.ac.il (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id E640A157FA2A for ; Sat, 4 Apr 2009 10:37:20 -0400 (EDT) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by mit.edu with ESMTP id 2E5oVtSU4NG6oRiG for ; Sat, 04 Apr 2009 10:37:20 -0400 (EDT) Received-SPF: pass (mit.edu: domain of canetti@post.tau.ac.il designates 132.66.16.26 as permitted sender) receiver=mit.edu; client_ip=132.66.16.26; envelope-from=canetti@post.tau.ac.il; Received: from [192.168.0.101] (c-98-224-221-50.hsd1.mi.comcast.net [98.224.221.50]) by doar.tau.ac.il (Postfix) with ESMTP id 9A753BEFA; Sat, 4 Apr 2009 17:37:17 +0300 (IDT) Message-ID: <49D70E1A.7050306@post.tau.ac.il> Date: Sat, 04 Apr 2009 10:36:58 +0300 From: canetti User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams References: <49D331C6.7000407@post.tau.ac.il> <20090401213536.GT9992@Sun.COM> In-Reply-To: <20090401213536.GT9992@Sun.COM> 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 Cc: kitten@ietf.org, secdir@mit.edu Subject: Re: [secdir] Security review of draft-ietf-kitten-gssapi-channel-bindings-06 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 14:36:31 -0000 Thanks Jeff and Nico for the tutorial. The current specification does seem very reasonable. Best, Ran Nicolas Williams wrote: > On Wed, Apr 01, 2009 at 12:20:06PM +0300, canetti 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! > > I know that Jeff has already answered this... > >> This is a very short document. It describes a more generic way of >> formatting the API for channel bindings. The move to a more generic >> format is welcome. One potential objection here, however, is to the >> requirement that compliant implementations MUST interpret the API as >> having the new format. This may have backwards compatibility issues, >> and for no apparent good reason. It might be better to specify the >> format so that an implementation will be able to take also older API >> formats. (Since this is not an interoperability or security-sensitive >> issue, there seems to be no reason for the IETF to MANDATE one way >> over another.) > > Let's pick a programming language, say, Python, and suppose that the > Python bindings of the GSS-API followed RFC2743 with regards to channel > binding. > > An implementation of those bindings AND of the Kerberos V > GSS-API mechanism (RFCs 1964 and 4121) would have to decide how to map > the RFC2743 "OCTET STRING" channel binding input to the mechanism's > channel binding (which is defined in terms of RFC2744's > gss_channel_bindings_struct C struct rather than "OCTET STRING"). Two > implementations of such bindings would fail to interop when using > channel bindings if the implementors decided this matter differently. > > Worse, suppose that you had a Python bindings implementation that mapped > the RFC2743 OCTET STRING channel binding input to then initiator_address > field of the RFC2744 gss_channel_bindings_struct C struct. Then you > could not interop with C implementations of the same application > protocol when using channel binding[*]. > > IMO the only reasonable decision for the implementors would be to map > the RFC2743 OCTET STRING channel binding input to the RFC2744 > application_data field of gss_channel_bindings_struct. And indeed, this > may require changing some of the putative implementations of the > putative Python bindings of the GSS-API. I don't see any alternatives. > > [*] Only RFC2744 application_data makes sense for channel binding > nowadays. Use of network addresses for channel binding was long ago > abandoned -- think of NATs :( -- and anyways, channel binding > to cryptographically secure channels makes much sense, while channel > binding to network addresses does not make much sense at all. > > Nico _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From charliek@microsoft.com Sun Apr 5 21:33:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39913A6BF3; Sun, 5 Apr 2009 21:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXuwXq5MmQt1; Sun, 5 Apr 2009 21:33:14 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2E58D3A6AD2; Sun, 5 Apr 2009 21:31:38 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sun, 5 Apr 2009 21:32:43 -0700 Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.110.52]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Sun, 5 Apr 2009 21:32:43 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "jpv@cisco.com" , "adrian.farrel@huawei.com" , "ylee@huawei.com" , "jeanlouis.leroux@orang-ftgroup.com" , "daniel@olddog.co.uk" , "oki@ice.uec.ac.jp" Date: Sun, 5 Apr 2009 21:32:40 -0700 Thread-Topic: Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt Thread-Index: Acm2cLhdyiJwz3TsSCmvAAIifRK4qg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F009AC6CE159924ABD1E8B51049B9B5C7128C7BD0DNAEXMSGC103re_" MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 04:33:20 -0000 --_000_F009AC6CE159924ABD1E8B51049B9B5C7128C7BD0DNAEXMSGC103re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any= other last call comments. Feel free to forward to any appropriate forum. This I-D defines some extensions to the protocol defined in RFC 5440, and s= ince those extensions do not affect the security sensitivity of the protoco= l in any significant way, the document appropriately refers to that one for= Security Considerations. That said, the Security Considerations section of RFC 5440 is somewhat dubi= ous. It requires that implementations of this protocol MUST support TCP-MD5= (RFC 2385) as a security mechanism, with recommendations that they impleme= nt TCP-AUTH when it becomes available. It notes that TLS and IPsec might be= preferable at some point in the future if key management issues can be res= olved. TCP-MD5 (and its successor TCP-AUTH/TCP-AO) were developed to solve = some specialized problems associated with BGP - in particular, the ability = to maintain a TCP connection for an indefinite period (often counted in yea= rs) surviving reboots of the endpoints. Its keying is manual, which quickly= becomes unworkable as the number of endpoints rises. In response, it is co= mmon to use group keys (where the same key is used to protect all of the co= nnections within a realm). TCP-MD5 also provides no confidentiality of data= , in spite of the fact that this I-D says the data carried by this protocol= may be somewhat sensitive. This reviewer believes that TLS or IPsec would have been a better choice (a= nd given the current state of the world, TLS would be the better of the two= ), and that the developers of this protocol should consider supporting one = of those in the future. Manual keying could still be used with those protoc= ols, though it would be better to issue certificates to the various endnode= s. These certificates need not (and perhaps should not) chain to a commerci= al root; they could be issued by the same administrators who today configur= e the shared keys. But... there is no reason to hold up approval of the updates in this docume= nt. Protecting the protocol by authenticating the endpoints and protecting = the integrity of the data seems both necessary and sufficient; I don't see = any need to include any other forms of security analysis. =3D=3D=3D=3D=3D I found the following minor (typo-level) issues: p4 para 4 line 8: distributed -> distributing p4 para 5 line 6: promote -> promotes p5 para 2 line 10: preemption -> ??? (**I suspect you didn't mean preemptio= n, but I can't guess what word you meant) p9 para 3 line 1: regards -> regard p10 para 1 line 7: LSP -> LSPs (**though perhaps some different wording cha= nge would be better) p15 section 5.2 line 3: computation -> computations p18 defn MU line 2: all link -> all links p18 defn mU line 2: all link -> all links There are several places (beginning with section 5.4 defn Type) which read = "To be defined by IANA (suggested value =3D 5)". Unless there are multiple = revisions to this protocol going on in parallel (such that the values assig= ned might depend on the order in which the documents are advanced), I belie= ve the normal protocol is for an I-D to just specify the new value and repe= at it in the IANA considerations section (which this document does). That w= ill minimize work for the RFC editor. --_000_F009AC6CE159924ABD1E8B51049B9B5C7128C7BD0DNAEXMSGC103re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I am reviewing this document as part of the security directorate's ongoing effor= t to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. = ; Document editors and WG chairs should treat these comments just like any ot= her last call comments. Feel free to forward to any appropriate forum.

 

This I-D defines some extensions to the protocol defin= ed in RFC 5440, and since those extensions do not affect the security sensitivity= of the protocol in any significant way, the document appropriately refers to t= hat one for Security Considerations.

 

That said, the Security Considerations section of RFC = 5440 is somewhat dubious. It requires that implementations of this protocol MUST support TCP-MD5 (RFC 2385) as a security mechanism, with recommendations th= at they implement TCP-AUTH when it becomes available. It notes that TLS and IP= sec might be preferable at some point in the future if key management issues can be resolved. TCP-MD5 (and its successor TCP-AUTH/TCP-AO) were developed to sol= ve some specialized problems associated with BGP – in particular, the ability to maintain a TCP connection for an indefinite period (often counte= d in years) surviving reboots of the endpoints. Its keying is manual, which quic= kly becomes unworkable as the number of endpoints rises. In response, it is com= mon to use group keys (where the same key is used to protect all of the connect= ions within a realm). TCP-MD5 also provides no confidentiality of data, in spite= of the fact that this I-D says the data carried by this protocol may be somewh= at sensitive.

 

This reviewer believes that TLS or IPsec would have be= en a better choice (and given the current state of the world, TLS would be the better of the two), and that the developers of this protocol should conside= r supporting one of those in the future. Manual keying could still be used wi= th those protocols, though it would be better to issue certificates to the var= ious endnodes. These certificates need not (and perhaps should not) chain to a commercial root; they could be issued by the same administrators who today configure the shared keys.

 

But… there is no reason to hold up approval of t= he updates in this document. Protecting the protocol by authenticating the endpoints and protecting the integrity of the data seems both necessary and sufficient; I don’t see any need to include any other forms of securi= ty analysis.

 

=3D=3D=3D=3D=3D

I found the following minor (typo-level) issues:<= /o:p>

 

p4 para 4 line 8: distributed -> distributing<= /o:p>

p4 para 5 line 6: promote -> promotes

p5 para 2 line 10: preemption -> ??? (**I suspect y= ou didn’t mean preemption, but I can’t guess what word you meant)<= o:p>

p9 para 3 line 1: regards -> regard

p10 para 1 line 7: LSP -> LSPs (**though perhaps so= me different wording change would be better)

p15 section 5.2 line 3: computation -> computations=

p18 defn MU line 2: all link -> all links

p18 defn mU line 2: all link -> all links

 

There are several places (beginning with section 5.4 d= efn Type) which read “To be defined by IANA (suggested value =3D 5)”= ;. Unless there are multiple revisions to this protocol going on in parallel (= such that the values assigned might depend on the order in which the documents a= re advanced), I believe the normal protocol is for an I-D to just specify the = new value and repeat it in the IANA considerations section (which this document does). That will minimize work for the RFC editor.

 

--_000_F009AC6CE159924ABD1E8B51049B9B5C7128C7BD0DNAEXMSGC103re_-- From Shawn.Emery@Sun.COM Sun Apr 5 23:09: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 80D473A69F2; Sun, 5 Apr 2009 23:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.000, 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 MV73lupYeAr8; Sun, 5 Apr 2009 23:09:47 -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 909D73A6926; Sun, 5 Apr 2009 23:09:47 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n366AqNh026209; Mon, 6 Apr 2009 06:10:52 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHO00H0012O5B00@mail-amer.sun.com>; Mon, 06 Apr 2009 00:10:52 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHO00BYN1642A20@mail-amer.sun.com>; Mon, 06 Apr 2009 00:10:52 -0600 (MDT) Date: Mon, 06 Apr 2009 00:09:45 -0600 From: Shawn M Emery Sender: Shawn.Emery@Sun.COM To: secdir@ietf.org, draft-ietf-lemonade-notifications@tools.ietf.org, lemonade-chairs@tools.ietf.org, iesg@ietf.org Message-id: <49D99CA9.5010703@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Subject: [secdir] Review of draft-ietf-lemonade-notifications-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 06:09: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. This information draft describes guidance for notification and filtering designs in IMAP. This includes server to server notifications, considering server to client scenarios. The security consideration section does exist and suggests that notification and filtering messages be integrity checked and private. This is to ensure that sensitive information is not divulged or to prevent DoS attacks on the client, etc. Correctly, this draft does not go into details on the mechanisms to provide integrity and privacy of said messages, but relies on the other associated drafts, such as notify and sieve, to describe specific issues of security. Editorial comment(s): As a layman reading this article, the terminology used in the abstract and introduction were unclear of what context "notification" means. Adding a little more text would be helpful for these sections. Shawn. -- From mnot@mnot.net Mon Apr 6 02:36:56 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF743A6BEB for ; Mon, 6 Apr 2009 02:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[AWL=-2.096, 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 nQDtHEcZQ6VY for ; Mon, 6 Apr 2009 02:36:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 1A2AA3A6945 for ; Mon, 6 Apr 2009 02:36:56 -0700 (PDT) Received: from [192.168.1.1] (unknown [209.131.62.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6B64FD05B4 for ; Mon, 6 Apr 2009 05:38:00 -0400 (EDT) Message-Id: <35C1C6C6-F924-408E-98AF-59A881B0A3B6@mnot.net> From: Mark Nottingham 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: Mon, 6 Apr 2009 19:37:57 +1000 X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Mon, 06 Apr 2009 02:53:06 -0700 Subject: [secdir] Soliciting reviews for Cross-Origin Resource Sharing 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, 06 Apr 2009 09:36:57 -0000 [ with my IETF/W3C Liaison hat on ] Members of the WebApps WG in the W3C have brought Cross-Origin Resource Sharing (CORS) to my attention, and asked for review/input from IETF folks. http://www.w3.org/TR/2009/WD-cors-20090317/ > This document defines a mechanism to enable client-side cross-origin > requests. Specifications that want to enable cross-origin requests > in an API they define can use the algorithms defined by this > specification. If such an API is used on http://example.org > resources, a resource on http://hello-world.examplecan opt in using > the mechanism described by this specification (e.g., specifying > Access-Control-Allow-Origin: http://example.org as response header), > which would allow that resource to be fetched cross-origin from http://example.org > . The document's status section contains information about how to provide feedback to them. I know that generally the security directorate review process is for review of IETF documents, but this document does have the potential for impacting IETF technologies, and is directly security-related. If the directorate is unable to provide a review, please forward this to the appropriate folks in the IETF security community who may be interested in providing individual reviews and feedback to the WG. Cheers, -- Mark Nottingham http://www.mnot.net/ From adrian@olddog.co.uk Mon Apr 6 05:43: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 82EA33A6C55; Mon, 6 Apr 2009 05:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok0FvvgzaNW3; Mon, 6 Apr 2009 05:43:02 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 707953A682A; Mon, 6 Apr 2009 05:41:05 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n36CfrXW001461; Mon, 6 Apr 2009 13:41:53 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n36CfqkR001443; Mon, 6 Apr 2009 13:41:52 +0100 Message-ID: <98F842EE286D4AFEA7928AEFB5E00788@your029b8cecfe> From: "Adrian Farrel" To: "Charlie Kaufman" , "Young Lee" References: Date: Mon, 6 Apr 2009 13:41:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Dan King , secdir , jpv@cisco.com, iesg@ietf.org, Eiji Oki , jeanlouis.leroux@orang-ftgroup.com, Adrian Farrel Subject: Re: [secdir] Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:43:03 -0000 Hi Charlie, Thanks for your detailed review. Wrt the security section in 5440, this text was arrived at after quite a lot (understatement) of debate with the SecDir and Security ADs. We in the PCE working group are not security experts, but we were able to represent that the TCP relationships are of a similar order of magnitude to those used in BGP. On the strength of this, the recommendations in the Security Considerations section were drawn up and agreed. With respect to the typos (I'm responding so the document Editor can be clear what to do - Young, please wait until you do an update after IESG review) > p4 para 4 line 8: distributed -> distributing "distributed" is correct. > p4 para 5 line 6: promote -> promotes Yes > p5 para 2 line 10: preemption -> ??? (**I suspect you didn't > mean preemption, but I can't guess what word you meant) Agree that the sentence is suffering from lack of context, but preemption was meant. OLD Note that other preemption can also help reducing the fragmentation issues. NEW Note that other techniques, including LSP preemption, can also be uused to help reduce the fragmentation issues within the network. > p9 para 3 line 1: regards -> regard Leave it for the RFC Editor to decide which is correct US English. > p10 para 1 line 7: LSP -> LSPs (**though perhaps some different > wording change would be better) Agree OLD This scenario assumes that the bandwidth of existing TE LSP is kept during the migration which is required in optical networks. NEW This scenario assumes that the bandwidth of existing TE LSPs remains the same during the migration steps: something that is required in optical networks. > p15 section 5.2 line 3: computation -> computations Yes > p18 defn MU line 2: all link -> all links Yes > p18 defn mU line 2: all link -> all links Yes > There are several places (beginning with section 5.4 defn Type) which read > "To > be defined by IANA (suggested value = 5)". Unless there are multiple > revisions > to this protocol going on in parallel (such that the values assigned might > depend > on the order in which the documents are advanced), I believe the normal > protocol > is for an I-D to just specify the new value and repeat it in the IANA > considerations > section (which this document does). That will minimize work for the RFC > editor. There are several PCEP I-Ds in the pipeline at the same time. Suggested values help the RFC Editor coordinate these documents, but allocaiton is strictly the purview of the IANA. Cheers, Adrian ----- Original Message ----- From: "Charlie Kaufman" To: ; ; ; "adrian.farrel@huawei.com" ; ; ; ; Sent: Monday, April 06, 2009 5:32 AM Subject: Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum. This I-D defines some extensions to the protocol defined in RFC 5440, and since those extensions do not affect the security sensitivity of the protocol in any significant way, the document appropriately refers to that one for Security Considerations. That said, the Security Considerations section of RFC 5440 is somewhat dubious. It requires that implementations of this protocol MUST support TCP-MD5 (RFC 2385) as a security mechanism, with recommendations that they implement TCP-AUTH when it becomes available. It notes that TLS and IPsec might be preferable at some point in the future if key management issues can be resolved. TCP-MD5 (and its successor TCP-AUTH/TCP-AO) were developed to solve some specialized problems associated with BGP - in particular, the ability to maintain a TCP connection for an indefinite period (often counted in years) surviving reboots of the endpoints. Its keying is manual, which quickly becomes unworkable as the number of endpoints rises. In response, it is common to use group keys (where the same key is used to protect all of the connections within a realm). TCP-MD5 also provides no confidentiality of data, in spite of the fact that this I-D says the data carried by this protocol may be somewhat sensitive. This reviewer believes that TLS or IPsec would have been a better choice (and given the current state of the world, TLS would be the better of the two), and that the developers of this protocol should consider supporting one of those in the future. Manual keying could still be used with those protocols, though it would be better to issue certificates to the various endnodes. These certificates need not (and perhaps should not) chain to a commercial root; they could be issued by the same administrators who today configure the shared keys. But... there is no reason to hold up approval of the updates in this document. Protecting the protocol by authenticating the endpoints and protecting the integrity of the data seems both necessary and sufficient; I don't see any need to include any other forms of security analysis. ===== I found the following minor (typo-level) issues: p4 para 4 line 8: distributed -> distributing p4 para 5 line 6: promote -> promotes p5 para 2 line 10: preemption -> ??? (**I suspect you didn't mean preemption, but I can't guess what word you meant) p9 para 3 line 1: regards -> regard p10 para 1 line 7: LSP -> LSPs (**though perhaps some different wording change would be better) p15 section 5.2 line 3: computation -> computations p18 defn MU line 2: all link -> all links p18 defn mU line 2: all link -> all links There are several places (beginning with section 5.4 defn Type) which read "To be defined by IANA (suggested value = 5)". Unless there are multiple revisions to this protocol going on in parallel (such that the values assigned might depend on the order in which the documents are advanced), I believe the normal protocol is for an I-D to just specify the new value and repeat it in the IANA considerations section (which this document does). That will minimize work for the RFC editor. From charliek@microsoft.com Mon Apr 6 10:37:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD11528C0DD; Mon, 6 Apr 2009 10:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C37rLW9Z+V+G; Mon, 6 Apr 2009 10:37:21 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 800E73A6774; Mon, 6 Apr 2009 10:37:21 -0700 (PDT) Received: from tk5-expfs-c107.redmond.corp.microsoft.com (157.54.69.47) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 6 Apr 2009 10:38:27 -0700 Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.110.52]) by tk5-expfs-c107.redmond.corp.microsoft.com ([157.54.69.47]) with mapi; Mon, 6 Apr 2009 10:38:27 -0700 From: Charlie Kaufman To: Adrian Farrel , Young Lee Date: Mon, 6 Apr 2009 10:38:25 -0700 Thread-Topic: Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt Thread-Index: Acm2tT7JU5uEajoJQp+NpDDso0hAYgAJ5zDg Message-ID: References: <98F842EE286D4AFEA7928AEFB5E00788@your029b8cecfe> In-Reply-To: <98F842EE286D4AFEA7928AEFB5E00788@your029b8cecfe> 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 Cc: Eiji, secdir , Adrian Farrel , "jpv@cisco.com" , "iesg@ietf.org" , "jeanlouis.leroux@orange-ftgroup.com" , Oki , Dan King Subject: Re: [secdir] Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:37:22 -0000 Adrian Farrel wrote: >Wrt the security section in 5440, this text was arrived at after quite a l= ot >(understatement) of debate with the SecDir and Security ADs. We in the PCE >working group are not security experts, but we were able to represent that >the TCP relationships are of a similar order of magnitude to those used in >BGP. On the strength of this, the recommendations in the Security >Considerations section were drawn up and agreed. I suspected something like that happened, and I didn't intend to criticize the authors of RFC5440 (and certainly not of this I-D). It was more an invitation to the security directorate to consider the role of TCP-MD5 vs. TLS or IPsec in future protocols. TCP-AUTH should either be advanced as a general purpose lightweight replacement or it should be limited to uses where backward compatibility is an issue. (I believe the latter would be more appropriate). Today its status is more ambiguous. --Charlie -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Monday, April 06, 2009 5:42 AM To: Charlie Kaufman; Young Lee Cc: secdir; iesg@ietf.org; jpv@cisco.com; jeanlouis.leroux@orang-ftgroup.co= m; Dan King; Eiji Oki; Adrian Farrel Subject: Re: Secdir review of draft-ietf-pce-global-concurrent-optimization= -10.txt Hi Charlie, Thanks for your detailed review. Wrt the security section in 5440, this text was arrived at after quite a lo= t (understatement) of debate with the SecDir and Security ADs. We in the PCE = working group are not security experts, but we were able to represent that = the TCP relationships are of a similar order of magnitude to those used in = BGP. On the strength of this, the recommendations in the Security Considera= tions section were drawn up and agreed. With respect to the typos (I'm responding so the document Editor can be cle= ar what to do - Young, please wait until you do an update after IESG review) > p4 para 4 line 8: distributed -> distributing "distributed" is correct. > p4 para 5 line 6: promote -> promotes Yes > p5 para 2 line 10: preemption -> ??? (**I suspect you didn't mean=20 > preemption, but I can't guess what word you meant) Agree that the sentence is suffering from lack of context, but preemption w= as meant. OLD Note that other preemption can also help reducing the fragmentation issues. NEW Note that other techniques, including LSP preemption, can also be uused = to help reduce the fragmentation issues within the network. > p9 para 3 line 1: regards -> regard Leave it for the RFC Editor to decide which is correct US English. > p10 para 1 line 7: LSP -> LSPs (**though perhaps some different=20 > wording change would be better) Agree OLD This scenario assumes that the bandwidth of existing TE LSP is kept during the migration which is required in optical networks. NEW This scenario assumes that the bandwidth of existing TE LSPs remains the same during the migration steps: something that is required in optical networks. > p15 section 5.2 line 3: computation -> computations Yes > p18 defn MU line 2: all link -> all links Yes > p18 defn mU line 2: all link -> all links Yes > There are several places (beginning with section 5.4 defn Type) which=20 > read "To be defined by IANA (suggested value =3D 5)". Unless there are=20 > multiple revisions to this protocol going on in parallel (such that=20 > the values assigned might depend on the order in which the documents=20 > are advanced), I believe the normal protocol is for an I-D to just=20 > specify the new value and repeat it in the IANA considerations section=20 > (which this document does). That will minimize work for the RFC=20 > editor. There are several PCEP I-Ds in the pipeline at the same time. Suggested values help the RFC Editor coordinate these documents, but alloca= iton is strictly the purview of the IANA. Cheers, Adrian ----- Original Message ----- From: "Charlie Kaufman" To: ; ; ; "adrian.farrel@hua= wei.com" ; ; ; ; Sent: Monday, April 06, 2009 5:32 AM Subject: Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum. This I-D defines some extensions to the protocol defined in RFC 5440, and since those extensions do not affect the security sensitivity of the protocol in any significant way, the document appropriately refers to that one for Security Considerations. That said, the Security Considerations section of RFC 5440 is somewhat dubious. It requires that implementations of this protocol MUST support TCP-MD5 (RFC 2385) as a security mechanism, with recommendations that they implement TCP-AUTH when it becomes available. It notes that TLS and IPsec might be preferable at some point in the future if key management issues ca= n be resolved. TCP-MD5 (and its successor TCP-AUTH/TCP-AO) were developed to solve some specialized problems associated with BGP - in particular, the ability to maintain a TCP connection for an indefinite period (often counte= d in years) surviving reboots of the endpoints. Its keying is manual, which quickly becomes unworkable as the number of endpoints rises. In response, i= t is common to use group keys (where the same key is used to protect all of the connections within a realm). TCP-MD5 also provides no confidentiality o= f data, in spite of the fact that this I-D says the data carried by this protocol may be somewhat sensitive. This reviewer believes that TLS or IPsec would have been a better choice (and given the current state of the world, TLS would be the better of the two), and that the developers of this protocol should consider supporting one of those in the future. Manual keying could still be used with those protocols, though it would be better to issue certificates to the various endnodes. These certificates need not (and perhaps should not) chain to a commercial root; they could be issued by the same administrators who today configure the shared keys. But... there is no reason to hold up approval of the updates in this document. Protecting the protocol by authenticating the endpoints and protecting the integrity of the data seems both necessary and sufficient; I don't see any need to include any other forms of security analysis. =3D=3D=3D=3D=3D I found the following minor (typo-level) issues: p4 para 4 line 8: distributed -> distributing p4 para 5 line 6: promote -> promotes p5 para 2 line 10: preemption -> ??? (**I suspect you didn't mean preemption, but I can't guess what word you meant) p9 para 3 line 1: regards -> regard p10 para 1 line 7: LSP -> LSPs (**though perhaps some different wording change would be better) p15 section 5.2 line 3: computation -> computations p18 defn MU line 2: all link -> all links p18 defn mU line 2: all link -> all links There are several places (beginning with section 5.4 defn Type) which read "To be defined by IANA (suggested value =3D 5)". Unless there are multiple revisions to this protocol going on in parallel (such that the values assigned might depend on the order in which the documents are advanced), I believe the normal protocol is for an I-D to just specify the new value and repeat it in the IANA considerations section (which this document does). That will minimize work for the RFC editor. From d3e3e3@gmail.com Wed Apr 8 19:48:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7B53A697F; Wed, 8 Apr 2009 19:48:06 -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 PxEEumpTYPBB; Wed, 8 Apr 2009 19:48:06 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id DCD653A6960; Wed, 8 Apr 2009 19:48:05 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so383536and.4 for ; Wed, 08 Apr 2009 19:49:13 -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=pjuJLnKm1fsZdEz7zY9NpRJ0Qa5QEUYniujyGYANjCY=; b=GZUkiNbuPl3mOQz3gSsKBmiEXoygjt6cwMpUq6O39wXgrYmrYw2I2nhoqLFS26SR3S lPKAEirUDApnoEhB1sYss7NrWXVEeZ9mRSS4Fppx4cVny/aJ0bkfY4irlWWzOhSSeNAo eHQtQM9KOFEqoHSjgvUm+Fr/qUoq/1+SoEIEU= 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=EvDlgeC+ObPZD90WuAKZj6ahOhRka/MUmwXl1ivyl6gvIdrCZ51lFV+kYmu7myocWH PEMkT4wmVRA0yAU34QacapLBZXp2D+TN6ehreby9Xr4mSc462YAbjaUsWIhA+4YOuXgi mqvrLofn5tNf6X0HR+F6e96D215kACOlmBR1E= MIME-Version: 1.0 Received: by 10.100.108.2 with SMTP id g2mr3605851anc.118.1239245345759; Wed, 08 Apr 2009 19:49:05 -0700 (PDT) Date: Wed, 8 Apr 2009 22:49:05 -0400 Message-ID: <1028365c0904081949p3d5c0975w60b73af97aae03e0@mail.gmail.com> From: Donald Eastlake To: iesg@ietf.org, secdir@ietf.org, David Frascone , jouni@gmail.com, Hannes.Tschofenig@gmx.net, julien.bournelle@orange-ftgroup.com, gerardo.giaretta@gmail.com, madjid.nakhjiri@motorola.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] draft-ietf-dime-mip6-split-16.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, 09 Apr 2009 02:48:06 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document primarily specifies the interaction between a Mobile IP Home Agent and a Diameter server when an IPv6 Mobile Mode wants to bootstrap its operations dynamically through interaction between its Home Agent and the Diameter server of a Mobile Service Provider. General: I'm always a bit suspicious of draft that include several options and alternatives. These at least make the document more complex and increase the probability that some security flaw in one of the options/alternatives will be overlooked. Security: The Security Considerations section of this draft is pretty short and primarily refers to the Security Considerations of three other RFCs. It appears that the referenced documents, particularly RFC 5026 and the RFCs referenced by the Securities Considerations section of RFC 5026, are adequate. Nits: Given that the first two messages in the Figure 2 message flow diagram are annotated "(1)" and "(2)", it would seem like a good idea to add those annotations at an appropriate place in the subsequent text. "a IKEv2" -> "an IKEv2". First paragraph of 5.1: "a number AVPs" -> "a number of AVPs". Second paragraph of 5.2.1: "with a replay protection related information" -> "with replay protection related information". 9.5: "values" -> "value". 10: "in in" -> "in". Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com From clonvick@cisco.com Thu Apr 9 09:08: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 0A6883A6D17; Thu, 9 Apr 2009 09:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+VO6kzZUKCk; Thu, 9 Apr 2009 09:08:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 651CD3A6CC1; Thu, 9 Apr 2009 09:08:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,161,1238976000"; d="scan'208";a="169342539" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 09 Apr 2009 16:09:45 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n39G9jq3016564; Thu, 9 Apr 2009 09:09:45 -0700 Received: from sjc-cde-010.cisco.com (sjc-cde-010.cisco.com [128.107.183.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n39G9jTX010177; Thu, 9 Apr 2009 16:09:45 GMT Date: Thu, 9 Apr 2009 09:09:45 -0700 (PDT) From: Chris Lonvick To: turners@ieca.com, housley@vigilsec.com, stephen.farrell@cs.tcd.ie, iesg@ietf.org, secdir@ietf.org, Stephen Kent , Stefan Santesson Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=457; t=1239293385; x=1240157385; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20SECDIR=20review=20of=20draft-ietf-pkix-3281upda te-04.txt |Sender:=20; bh=9rSq8q4EBG60sXu68rLpCCYjP4PikAjRBJ6qJCv00tE=; b=W7JCvuvLzi6/QQdSx0yN8XevlumEZG6xQ8Cp4tBVdJXbt8Oqu18EiwhuPI pK+GEO09b2bURbN73J0qK/PnaylJwN01WjszEHTAEqCk5yBBJuN9Bmw+OWFR gq4Dy0Vxb8; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [secdir] SECDIR review of draft-ietf-pkix-3281update-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:08:38 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I find the document to be clear and functional, and have no qualms about it becoming an RFC. Regards, Chris From hartmans@mit.edu Thu Apr 9 09:57:05 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326B43A6B64; Thu, 9 Apr 2009 09:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfcqVFOkirFN; Thu, 9 Apr 2009 09:57:04 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 32BC63A6A75; Thu, 9 Apr 2009 09:57:04 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 10E59414D; Thu, 9 Apr 2009 12:57:48 -0400 (EDT) To: ietf@ietf.org, ipfix-chairs@tools.ietf.org, secdir@ietf.org, draft-ietf-ipfix-file@tools.ietf.org From: Sam Hartman Date: Thu, 09 Apr 2009 12:57:47 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] secdir review of draft-ietf-ipfix-file-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:57:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies a file format for storing and transporting flow data. Typically the flow data will be collecting in the IPFIX format, although it is of course potentially possibly to convert other flow data to use this format; section 6 discusses such a case. I urge the IESG to get specific additional review from the law enforcement/security investigation community surrounding the handling of evidence in an ongoing investigation prior to approving this draft. Section 4 cites that use case as a significant motivation. However, I'm concerned that the requirements in section 5 and thus the resulting protocol are inadequate to that community's needs. Section 3 talks about advantages of the file format including that files can be concatenated or split on message boundaries. There is no file header or trailer. However there are records such as those described in 8.1.3 that describe metadata for the file. Particularly in investigation environments it seems problematic to get into a situation where the file has metadata that claims inaccurately to describe the file especially when this happens using mechanisms explicitly supported by the file format and the situation cannot be detected. In the document use case I think you want a mechanism to confirm that a file has not been added to or removed from. Section 7.3.4 requires using the file write time as the export time. That seems potentially problematic in an investigation. TPerhaps the message details option in 8.1.4 is supposed to handle this; if so, text explaining how this works should be added to 7.3.4. The handling of authentication seems problematic. The text points out that TLS can be used to provide transient authentication from the exporter to collector. Discussion of the lack of data origin authentication (authentication that can be verified after the fact by a third party) needs to be added to the security considerations section; this seems important for the 7.3.4 use case. I'm not asking for digital signatures to be added at the exporter, simply for discussion of the consequences on having hop-by-hop authentication. However there is a more serious lack on the authentication front. There is no way for a file writer to describe the authenticated identity of the exporter. I'd expect 8.1.3 and 8.1.4 to include attributes to describe the TLS identity of the exporter. The template in 8.1.1 uses md5. There's insufficient documentation for me to tell whether the cryptographic properties, particularly collision resistance, are important to this use of md5. My guess is that they are and thus md5 may not be the best hash to use. Is a per-message checksum really the right granularity? The security considerations section is very weak. From weiler@watson.org Thu Apr 9 14:12:29 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A12793A68DC for ; Thu, 9 Apr 2009 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 RM5ndTNdbdZD for ; Thu, 9 Apr 2009 14:12:28 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id BE6533A67E4 for ; Thu, 9 Apr 2009 14:12:28 -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 n39LDZnA040833 for ; Thu, 9 Apr 2009 17:13:35 -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 n39LDZZg040830 for ; Thu, 9 Apr 2009 17:13:35 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 9 Apr 2009 17:13:35 -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, 09 Apr 2009 17:13:36 -0400 (EDT) Subject: [secdir] Assignments for April 16th X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 21:12:29 -0000 Juergen Schoenwaelder 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-23 Charles Clancy T draft-ietf-ccamp-gmpls-ason-routing-ospf-08 Phillip Hallam-Baker TR draft-atlas-icmp-unnumbered-06 Scott Kelly T draft-ietf-dccp-serv-codes-08 Sandy Murphy T draft-ietf-tcpm-tcpsecure-11 Hilarie Orman T draft-ietf-tcpm-ecnsyn-08 Radia Perlman T draft-ietf-pana-statemachine-10 Joe Salowey T draft-ietf-dhc-container-opt-05 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-10 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 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 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Angelos Keromytis draft-ietf-isms-secshell-15 Julien Laganier draft-ietf-sip-certs-07 Julien Laganier draft-ietf-isms-tmsm-16 Barry Leiba draft-ietf-isms-transport-security-model-12 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ncook-urlauth-accessid-02 Chris Newman draft-thomson-beep-async-02 Magnus Nystrom draft-ietf-mpls-p2mp-te-mib-08 Eric Rescorla draft-ietf-isms-radius-usage-05 Joe Salowey draft-ietf-geopriv-lis-discovery-09 Stefan Santesson http://www.w3.org/TR/2009/WD-cors-20090317/ 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 Chris.Newman@Sun.COM Thu Apr 9 16:53:56 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3397C3A6CEF for ; Thu, 9 Apr 2009 16:53:56 -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.101, 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 iHVlzcnDw0Sz for ; Thu, 9 Apr 2009 16:53:55 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 7E6743A6834 for ; Thu, 9 Apr 2009 16:53:55 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n39Nt17c005183 for ; Thu, 9 Apr 2009 16:55:01 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; format=flowed; charset=us-ascii Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHU00I00Y65R100@fe-sfbay-10.sun.com> for secdir@ietf.org; Thu, 09 Apr 2009 16:55:01 -0700 (PDT) Received: from [10.0.1.2] ([unknown] [10.1.110.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHU00AKLYFNHG00@fe-sfbay-10.sun.com>; Thu, 09 Apr 2009 16:55:01 -0700 (PDT) Date: Thu, 09 Apr 2009 16:54:59 -0700 From: Chris Newman In-reply-to: Sender: Chris.Newman@Sun.COM To: secdir-secretary@mit.edu Message-id: X-Mailer: Mulberry/4.0.8 (Mac OS X) References: Cc: secdir@ietf.org Subject: [secdir] proto shepherd doing own secdir review? 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, 09 Apr 2009 23:53:56 -0000 Question: I got assigned a document for which I'm PROTO shepherd. I don't see a conflict of interest for this particular document, and I've already completed the review, but I don't know if there's a standard practice to reassign such documents to a different secdir reviewer. Thanks, - Chris --On April 3, 2009 12:45:05 -0400 Samuel Weiler wrote: > Quite a number of new assignments, some of them on the telechat agenda > for April 23rd. Radia Perlman is next in the rotation. > > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > ... > Chris Newman draft-thomson-beep-async-02 From weiler@watson.org Fri Apr 10 00:10:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF323A6D41 for ; Fri, 10 Apr 2009 00:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 GPicDmgRiZ1W for ; Fri, 10 Apr 2009 00:10:10 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B10A23A6D44 for ; Fri, 10 Apr 2009 00:10:10 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3A7BICe094978; Fri, 10 Apr 2009 03:11:18 -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 n3A7BH1e094975; Fri, 10 Apr 2009 03:11:17 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 10 Apr 2009 03:11:17 -0400 (EDT) From: Samuel Weiler To: Chris Newman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 10 Apr 2009 03:11:18 -0400 (EDT) Cc: secdir@ietf.org Subject: Re: [secdir] proto shepherd doing own secdir review? 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, 10 Apr 2009 07:10:12 -0000 On Thu, 9 Apr 2009, Chris Newman wrote: > I got assigned a document for which I'm PROTO shepherd. I don't see a > conflict of interest for this particular document, and I've already completed > the review, but I don't know if there's a standard practice to reassign such > documents to a different secdir reviewer. The standard practice is to assign the documents to someone else, but I don't always catch these. If you (or anyone) get a document that you're an editor of, proto shepherd for, or otherwise closely involved with, just drop me a note. -- Sam From ietfdbh@comcast.net Fri Apr 10 12:55:29 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB8A3A6B68 for ; Fri, 10 Apr 2009 12:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdtXI5xbj8Fy for ; Fri, 10 Apr 2009 12:55:28 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 38E8C3A680C for ; Fri, 10 Apr 2009 12:55:28 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id dv1B1b0071HzFnQ53vwGi4; Fri, 10 Apr 2009 19:56:16 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id dvwc1b00F0UQ6dC3avwcZn; Fri, 10 Apr 2009 19:56:37 +0000 From: "David Harrington" To: , , Date: Fri, 10 Apr 2009 15:56:35 -0400 Message-ID: <03a101c9ba16$74bf49f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm6FnPhmb2bGw/9SquiIT3AtmLbSg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'Magnus Westerlund' , 'Lorenzo Vicisano' , adamson@itd.nrl.navy.mil, M.Handley@cs.ucl.ac.uk, cabo@tzi.org, macker@itd.nrl.navy.mil Subject: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 19:55:29 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document specifies a protocol (or an update to a protocol) that provides end-to-end reliable transport of bulk data objects or streams over multicast routing and forwarding services. It also provides a congestion control scheme. It is designed to permit different upper layer services to utilize its services in different ways. I got to this review late, so I went straight to the security considerations first. I found the security requirements wishy-washy. Per BCP61, MUSTs are for implementers, SHOULDs are for deployers. There are few MUSTs or REQUIREDs to guide implementators what MUST be present for interoperable security capabilities in an compliant implementation. There are lots of SHOULDs, RECOMMENDEDs, MAY, can be, is possible, is expected, optionally, etc. in the "Baseline Secure NORM Operation". On the other hand, there are lots of SHALLs and REQUIREDs for how deployers MUST configure their security. I am not sure how interoperable the security for this "standard" will be because there are so many allowable options for how one does security. This protocol is not a security protocol. It is a protocol that utilizes lower layer security services, so maybe this "wishy-washy" approach is the correct approach to serve the real-world needs of NORM implementers and deployers. But I would feel more comfortable with something a bit more solid in terms of what MUST be present for security capabilities in compliant implementations. It might help a lot to separate the security considerations into what MUST be implemented for interoperability, and how deployments SHOULD be configured, and then talk about optional extensions or alternatives. As currently written, I am not sure I could figure out just what an implementer MUST support. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From secdir-bounces@mit.edu Sun Apr 12 09:45:58 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A8A3A68C2 for ; Sun, 12 Apr 2009 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.799 X-Spam-Level: X-Spam-Status: No, score=-7.799 tagged_above=-999 required=5 tests=[AWL=-1.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 vIkL-zayTyPO for ; Sun, 12 Apr 2009 09:45:57 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id ED3773A6C3F for ; Sun, 12 Apr 2009 09:45:40 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n3CGkokm007855 for ; Sun, 12 Apr 2009 12:46:50 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n3CGklCa007852 for ; Sun, 12 Apr 2009 12:46:47 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n3CGkcDj029220 for ; Sun, 12 Apr 2009 12:46:38 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 84A931696264 for ; Sun, 12 Apr 2009 12:46:37 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id aMEyZufaaSM2wUUS for ; Sun, 12 Apr 2009 12:46:37 -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 014B83A683A; Sun, 12 Apr 2009 09:45:26 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914E03A6C9A for ; Thu, 9 Apr 2009 11:29:03 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdle0uCMmh36 for ; Thu, 9 Apr 2009 11:29:02 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id A810A3A6C8E for ; Thu, 9 Apr 2009 11:29:02 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Lrz0q-0002IU-WB for public-new-work-dist@listhub.w3.org; Thu, 09 Apr 2009 18:30:09 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Lrz0p-0002Fd-IQ for public-new-work@listhub.w3.org; Thu, 09 Apr 2009 18:30:07 +0000 Received: from homer.w3.org ([128.30.52.30]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Lrz0h-0005yp-8u; Thu, 09 Apr 2009 18:30:07 +0000 Received: from [IPv6:::1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 015F74EF32; Thu, 9 Apr 2009 14:29:58 -0400 (EDT) Message-Id: <705637D6-C792-434F-9E45-5C979476A214@w3.org> From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 13:29:57 -0500 X-Mailer: Apple Mail (2.930.3) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1Lrz0h-0005yp-8u 5244811a1df532b96075baec86697bb5 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/40 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Thu, 09 Apr 2009 18:30:08 +0000 X-Mailman-Approved-At: Sun, 12 Apr 2009 09:45:25 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 13 Apr 2009 08:05:12 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: SPARQL Working Group (until 2009-05-15) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 16:45:58 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Semantic Web Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the SPARQL Working Group: http://www.w3.org/2009/04/sparql-phase-I-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2009-05-15 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Ivan Herman, Semantic Web Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2001/sw/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From hartmans@mit.edu Mon Apr 13 08:18:57 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633C63A6978; Mon, 13 Apr 2009 08:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRS3VQWXa0sr; Mon, 13 Apr 2009 08:18:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 724563A69CD; Mon, 13 Apr 2009 08:18:56 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0A742414D; Mon, 13 Apr 2009 11:08:59 -0400 (EDT) To: Charlie Kaufman References: <98F842EE286D4AFEA7928AEFB5E00788@your029b8cecfe> From: Sam Hartman Date: Mon, 13 Apr 2009 11:08:59 -0400 In-Reply-To: (Charlie Kaufman's message of "Mon\, 6 Apr 2009 10\:38\:25 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eiji@core3.amsl.com, "jeanlouis.leroux@orange-ftgroup.com" , secdir , "jpv@cisco.com" , Adrian Farrel , Young Lee , Adrian Farrel , Oki , Dan King , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 15:18:57 -0000 >>>>> "Charlie" == Charlie Kaufman writes: s section were drawn up and agreed. Charlie> I suspected something like that happened, and I didn't Charlie> intend to criticize the authors of RFC5440 (and certainly Charlie> not of this I-D). It was more an invitation to the Charlie> security directorate to consider the role of TCP-MD5 Charlie> vs. TLS or IPsec in future protocols. TCP-AUTH should Charlie> either be advanced as a general purpose lightweight Charlie> replacement or it should be limited to uses where Charlie> backward compatibility is an issue. (I believe the latter Charlie> would be more appropriate). Today its status is more I'd strongly encourage the security community to work with the routing community to make a recommendation for new routing protocols. I think there is general agreement in the transport and security community that the factors that make TCP-AO necessary for BGP are a mistake and that we regret the situation although we agree that fixing it is too expensive. I suspect this belief is not shared in the routing area. If I were going to tilt at that windmill I'd try to start by building a consensus that you want to decouple upper layer session state from transport session state: the idea that I have a huge flap when I get a TCP RST is not something we want to do in future protocols. Then I'd try and build consensus behind GTSM+TLS in an integrity only mode as a security solution for new protocols in the routing area that smell like BGP in their transport characteristics (two-parties, traditional transport connection, no multicast). You'd need to be very careful not to be accused of requiring a PKI--self signed certificates, anonymous DH or PSK would be about as much as you could require. Obviously, if someone wanted a PKI, such a protocol could work with that too, but I think requiring or implying a PKI would be viewed as a fatal flaw. >From this starting point it would not hugely surprise me if there were constraints I didn't understand that lead you back to TCP-AO. If you do start down that path, keep in mind: * Concerns about using IPsec, including configuration difficulty, complexity of things like use-ipsec, and implementation problems. Remember Bryan's saag presentation. * The routing community considers needing to talk to OCSP, CRLDPs, SCVP, third parties of any kind really bad when bringing up the routing system. * DOS concerns are huge. There are also a lot of political issues. From jsalowey@cisco.com Mon Apr 13 22:00:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD293A6A08; Mon, 13 Apr 2009 22:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 EApgkRKBeECk; Mon, 13 Apr 2009 22:00:18 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 1497C3A6886; Mon, 13 Apr 2009 22:00:17 -0700 (PDT) Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 14 Apr 2009 05:01:28 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3E51RmC028945; Tue, 14 Apr 2009 15:01:27 +1000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3E51QPd005490; Tue, 14 Apr 2009 05:01:26 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Apr 2009 22:01:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Apr 2009 22:01:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir Review of draft-ietf-dhc-container-opt-05 Thread-Index: Acm8vg+KxFJcGtL+QYWEiOmdeR4JRA== From: "Joseph Salowey (jsalowey)" To: , , , "Dhc Chairs" X-OriginalArrivalTime: 14 Apr 2009 05:01:26.0744 (UTC) FILETIME=[10BD9D80:01C9BCBE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2090; t=1239685287; x=1240549287; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Secdir=20Review=20of=20draft-ietf-dhc-container -opt-05 |Sender:=20; bh=9PxGvYC81iZr4eH8U9tZKFZKs8HoC5tDodjSueNe6yY=; b=VvzaqCKU/av3f+Sls3hnYu/IUjXDqVZ/IqgkAVleyNT8Bpg6nTTRXH8q6a FAfqgw2vAYvWTgorzfS/+M3KkQ5Ze/xPBzBBJUJ9v7uZSGGjNhVeXDCt91ue kdnvAqDI6xazFFx534gpseNe6j0m1ydngHRTgZtVSbmWyuST8tynE=; Authentication-Results: syd-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); Subject: [secdir] Secdir Review of draft-ietf-dhc-container-opt-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 05:00:20 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments.=20 I found no major issues with this document. =20 The security considerations section doesn't really discuss who is trusting whom for what in great detail. I assume that the RG client and RG server implicitly trust one another as they are on the same box and communication between them is outside the scope of the document. I also assume that the SP server treats the RG client and RG server as a single entity and does not care that the options are in control of the RG client before they reach the RG server. Most of this seems obvious, but this might clear things up a bit: "The RG client and RG server are collocated within the RG and are treated as the same entity by the SP server. The communication mechanism between the RG client and RG server is local to the RG and assumed to protect the option from unauthorized access in transit. =20 A rogue server can use this option to pass invalid information to the RG client, which would then be passed to the Client hosts by the RG server. This invalid information could be used to mount a denial of service attack or a man-in-the-middle attack against some applications. Authentication of DHCP messages (RFC 3118 [RFC3118] and section 20 of RFC 3315 [RFC3315]) can be used to ensure that the contents of this option are not altered in transit between the SP DHCP server and RG client." =20 The other comment I have is that I don't think RFC 3118 isn't particularly deployable. I can see it being used between the SP server and RG client where management relationships are in place, but I'm not sure it is very realistic to deploy between client hosts and the RG server. Do other mechanisms such as L2 protection help here? =20 Cheers, Joe From secdir-bounces@mit.edu Tue Apr 14 13:00:29 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659633A6DEF for ; Tue, 14 Apr 2009 13:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.369 X-Spam-Level: X-Spam-Status: No, score=-106.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 RiTkgwWLkaDr for ; Tue, 14 Apr 2009 13:00:28 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id CE9173A6EB9 for ; Tue, 14 Apr 2009 13:00:23 -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 n3EK1Z85019027 for ; Tue, 14 Apr 2009 16:01:35 -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 n3EK1X5n019021 for ; Tue, 14 Apr 2009 16:01:33 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n3EK1O80001647 for ; Tue, 14 Apr 2009 16:01:24 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 881FF1997925 for ; Tue, 14 Apr 2009 16:01:23 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id e78iWeB9MGgMQbvq for ; Tue, 14 Apr 2009 16:01:23 -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 367EF28C1E9; Tue, 14 Apr 2009 13:00:07 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2A50B3A6E0E; Tue, 14 Apr 2009 13:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090414200002.2A50B3A6E0E@core3.amsl.com> Date: Tue, 14 Apr 2009 13:00:02 -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: Tue, 14 Apr 2009 13:11:34 -0700 Subject: [secdir] [New-work] WG Review: Network-Based Mobility Extensions (netext) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 20:00:29 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 21, 2009. Network-Based Mobility Extensions (netext) ------------------------------------------------------------- Last Modified: 2009-04-03 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: http://www.mobileip.jp/mailman/listinfo/netext Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Hosts are not affected, as they still send and receive their packets via the MAG. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing, and is complementary to the initial LMA discovery work in the NETLMM WG. The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. Milestones May 2009 WG chartered July 2009 Initial WG draft on Bulk Refresh September 2009 Initial WG draft on LMA Redirection November 2009 Initial WG draft on Route Optimization December 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC January 2009 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC April 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Apr 14 13:00: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 40DC73A6DEF for ; Tue, 14 Apr 2009 13:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.39 X-Spam-Level: X-Spam-Status: No, score=-106.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 SSkx3zbsqHI1 for ; Tue, 14 Apr 2009 13:00:26 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 34E493A6E7E for ; Tue, 14 Apr 2009 13:00:22 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n3EK1XhJ019016 for ; Tue, 14 Apr 2009 16:01:33 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n3EK1TwO018995 for ; Tue, 14 Apr 2009 16:01:29 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n3EK1JC7023952 for ; Tue, 14 Apr 2009 16:01:19 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 9789719C548F for ; Tue, 14 Apr 2009 16:01:18 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id RescxNDXq135UXS5 for ; Tue, 14 Apr 2009 16:01:17 -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 41F1D3A6EB9; Tue, 14 Apr 2009 13:00:05 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1EA7F3A6DEF; Tue, 14 Apr 2009 13:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090414200002.1EA7F3A6DEF@core3.amsl.com> Date: Tue, 14 Apr 2009 13:00:02 -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: Tue, 14 Apr 2009 13:11:34 -0700 Subject: [secdir] [New-work] WG Review: Multiple InterFaces (mif) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 20:00:31 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 21, 2009. Multiple InterFaces (mif) ------------------------------------------------ Last Modified: 2009-04-02 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to connect to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host connected to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with multiple interfaces. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 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 jouni.nospam@gmail.com Thu Apr 16 05:06:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E2F3A6816; Thu, 16 Apr 2009 05:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 YMFCYVtRyW8g; Thu, 16 Apr 2009 05:06:18 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 2BD843A6D1C; Thu, 16 Apr 2009 05:06:18 -0700 (PDT) Received: by ewy9 with SMTP id 9so369904ewy.37 for ; Thu, 16 Apr 2009 05:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=M0mUfkGf5r+2NBnT3W0Gxj+T684Kr9e9IKuDm+0B1sA=; b=KRnES7GAH1B2oATNg9EHeypjRJHEWbCFHKp3sVI8FpmENILfdVoeXWuGqjvfsR+NQw dWsTqceOt3IIs5eUqY4dqc9SUKWKM3F6Z6fRYaECrvlNgW3n90tMZXlirQusoffq5ZFo puW86Nxxe5IpUj5fMPyD1EbPuHmj6ue6I8fBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=CAkncvxaXQl05wIPQWJL3khYwCWHIfETPy4uOHgB7nVFukarflXSUBkFQRorCqhBYo CRHzLRMh2rmlSsYgB+XqPpFcWBE54CUsYzKCs0HDYAPKV1v+SrYrd1KQSumrjp6aevfR Qrm72EiwRdWaLzggb1sfKOnAIVxNEuS3I24rs= Received: by 10.210.37.11 with SMTP id k11mr1362896ebk.91.1239883650300; Thu, 16 Apr 2009 05:07:30 -0700 (PDT) Received: from ?10.183.180.104? ([192.100.124.156]) by mx.google.com with ESMTPS id 24sm1340822eyx.58.2009.04.16.05.07.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 05:07:29 -0700 (PDT) Message-Id: <4F92B101-6092-444A-A1D2-436EBD42CB5A@gmail.com> From: jouni korhonen To: d3e3e3@gmail.com, "Romascanu, Dan (Dan)" , iesg@ietf.org, secdir@ietf.org, dave@frascone.com, "Hannes (NSN - FI/Espoo) Tschofenig" , julien.bournelle@orange-ftgroup.com, gerardo.giaretta@gmail.com, madjid.nakhjiri@motorola.com 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 v930.3) Date: Thu, 16 Apr 2009 15:07:27 +0300 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Thu, 16 Apr 2009 05:12:45 -0700 Cc: dime@ietf.org Subject: Re: [secdir] [Dime] FW: draft-ietf-dime-mip6-split-16.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, 16 Apr 2009 12:06:19 -0000 Hi Donald, Thanks you for the review. See my comments inline. On Apr 14, 2009, at 1:39 PM, Romascanu, Dan (Dan) wrote: > Have these comments been addressed? > > Dan > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of > Donald Eastlake > Sent: Thursday, April 09, 2009 5:49 AM > To: iesg@ietf.org; secdir@ietf.org; David Frascone; jouni@gmail.com; > Hannes.Tschofenig@gmx.net; julien.bournelle@orange-ftgroup.com; > gerardo.giaretta@gmail.com; madjid.nakhjiri@motorola.com > Subject: draft-ietf-dime-mip6-split-16.txt > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. > Document editors and WG chairs should treat these comments just like > any > other last call comments. > > This document primarily specifies the interaction between a Mobile IP > Home Agent and a Diameter server when an IPv6 Mobile Mode wants to > bootstrap its operations dynamically through interaction between its > Home Agent and the Diameter server of a Mobile Service Provider. > > General: I'm always a bit suspicious of draft that include several > options and alternatives. These at least make the document more > complex > and increase the probability that some security flaw in one of the > options/alternatives will be overlooked. Right.. there is a long history why the document ended like this. It is not an ideal composition, especially when it comes to supporting both RFC6025 (standards track) and RFC4285 (informational), but the WG has been reluctant to divide the document.. > > Security: The Security Considerations section of this draft is pretty > short and primarily refers to the Security Considerations of three > other > RFCs. It appears that the referenced documents, particularly RFC > 5026 and the RFCs referenced by the Securities Considerations > section of > RFC 5026, are adequate. We could try to enhance the security considerations if required. However, that would mostly be briefly spelling out what the referenced documents discuss in detail. > > Nits: > > Given that the first two messages in the Figure 2 message flow diagram > are annotated "(1)" and "(2)", it would seem like a good idea to add > those annotations at an appropriate place in the subsequent text. > > "a IKEv2" -> "an IKEv2". > > First paragraph of 5.1: "a number AVPs" -> "a number of AVPs". > > Second paragraph of 5.2.1: "with a replay protection related > information" -> "with replay protection related information". > > 9.5: "values" -> "value". > > 10: "in in" -> "in". Thanks! I'll fix these. Cheers, Jouni > > > Thanks, > Donald > > ============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From secdir-bounces@mit.edu Thu Apr 16 09:32:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF29028C0EA for ; Thu, 16 Apr 2009 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.742 X-Spam-Level: X-Spam-Status: No, score=-7.742 tagged_above=-999 required=5 tests=[AWL=-1.143, 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 GaQAZV5iCS6n for ; Thu, 16 Apr 2009 09:32:58 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 930CF3A69BA for ; Thu, 16 Apr 2009 09:32:58 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n3GGYAft017750 for ; Thu, 16 Apr 2009 12:34:11 -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 n3GGY70L017717 for ; Thu, 16 Apr 2009 12:34:09 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n3GGXpwr018271 for ; Thu, 16 Apr 2009 12:33:52 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 013F717F72C3 for ; Thu, 16 Apr 2009 12:33:50 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id WVd5JrrdJBjaR5V1 for ; Thu, 16 Apr 2009 12:33:50 -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 E239F3A67C0; Thu, 16 Apr 2009 09:32:36 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25983A6EAF for ; Mon, 13 Apr 2009 09:12:13 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iNhVKdu50Sy for ; Mon, 13 Apr 2009 09:12:12 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id AC4FA3A6E9B for ; Mon, 13 Apr 2009 09:12:12 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1LtOmf-0001qx-Jp for public-new-work-dist@listhub.w3.org; Mon, 13 Apr 2009 16:13:21 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1LtOme-0001pv-Tg for public-new-work@listhub.w3.org; Mon, 13 Apr 2009 16:13:20 +0000 Received: from homer.w3.org ([128.30.52.30]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1LtOmW-0001gj-Fy; Mon, 13 Apr 2009 16:13:20 +0000 Received: from [IPv6:::1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 300404EF8F; Mon, 13 Apr 2009 12:13:12 -0400 (EDT) From: Ian Jacobs To: "David Harrington" In-Reply-To: <049e01c9bc52$18999bb0$0600a8c0@china.huawei.com> References: <705637D6-C792-434F-9E45-5C979476A214@w3.org> <049e01c9bc52$18999bb0$0600a8c0@china.huawei.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 11:13:11 -0500 X-Mailer: Apple Mail (2.930.3) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1LtOmW-0001gj-Fy c5dac58afce7477cd509db62cbcd1366 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/41 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Mon, 13 Apr 2009 16:13:21 +0000 X-Mailman-Approved-At: Thu, 16 Apr 2009 09:32:36 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Thu, 16 Apr 2009 10:10:31 -0700 Cc: public-new-work@w3.org Subject: Re: [secdir] [New-work] Proposed W3C Charter: SPARQL WorkingGroup (until 2009-05-15) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:33:00 -0000 On 13 Apr 2009, at 11:08 AM, David Harrington wrote: > Hi, > > Given that www.w3c.org require a username and password, this draft > charter does not appear to be public. Apologies! Fixed. Thank you for letting me know, _ Ian > > > dbh > >> -----Original Message----- >> From: secdir-bounces@ietf.org >> [mailto:secdir-bounces@ietf.org] On Behalf Of Ian Jacobs >> Sent: Thursday, April 09, 2009 2:30 PM >> To: public-new-work@w3.org >> Subject: [secdir] [New-work] Proposed W3C Charter: SPARQL >> WorkingGroup (until 2009-05-15) >> >> Hello, >> >> Today W3C Advisory Committee Representatives received a Proposal >> to revise the Semantic Web Activity [0] (see the W3C Process >> Document description of Activity Proposals [1]). This proposal >> includes a draft charter for the SPARQL Working Group: >> http://www.w3.org/2009/04/sparql-phase-I-charter.html >> >> As part of ensuring that the community is aware of proposed work >> at W3C, this draft charter is public during the Advisory >> Committee review period. >> >> W3C invites public comments through 2009-05-15 on the >> proposed charter. Please send comments to >> public-new-work@w3.org, which has a public archive: >> http://lists.w3.org/Archives/Public/public-new-work/ >> >> Other than comments sent in formal responses by W3C Advisory >> Committee Representatives, W3C cannot guarantee a response to >> comments. If you work for a W3C Member [2], please coordinate >> your comments with your Advisory Committee Representative. For >> example, you may wish to make public comments via this list and >> have your Advisory Committee Representative refer to it from his >> or her formal review comments. >> >> If you should have any questions or need further information, please >> contact Ivan Herman, Semantic Web Activity Lead . >> >> Thank you, >> >> Ian Jacobs, Head of W3C Communications >> >> [0] http://www.w3.org/2001/sw/ >> [1] >> > http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation >> [2] http://www.w3.org/Consortium/Member/List >> >> >> >> -- >> Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ >> Tel: +1 718 260 9447 >> >> >> _______________________________________________ >> New-work mailing list >> New-work@ietf.org >> https://www.ietf.org/mailman/listinfo/new-work >> _______________________________________________ >> secdir mailing list >> secdir@mit.edu >> https://mailman.mit.edu/mailman/listinfo/secdir >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> > -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From adamson@itd.nrl.navy.mil Thu Apr 16 10:34:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF6328C0F3 for ; Thu, 16 Apr 2009 10:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 z5q6qOqGZ5Pi for ; Thu, 16 Apr 2009 10:34:21 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id E108E28C24C for ; Thu, 16 Apr 2009 10:34:20 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n3GHV8Cn018783; Thu, 16 Apr 2009 13:31:08 -0400 Received: from macsimus.itd.nrl.navy.mil ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009041613310816271 ; Thu, 16 Apr 2009 13:31:08 -0400 Message-Id: <4FC76EA8-D6AC-44C0-AA0F-01D02A7651E6@itd.nrl.navy.mil> From: Brian Adamson To: David Harrington In-Reply-To: <03a101c9ba16$74bf49f0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 13:31:08 -0400 References: <03a101c9ba16$74bf49f0$0600a8c0@china.huawei.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Thu, 16 Apr 2009 10:45:29 -0700 Cc: Magnus Westerlund , secdir@ietf.org, Tim Polk , Pasi Eronen , Brian Adamson , M.Handley@cs.ucl.ac.uk, cabo@tzi.org, Joe Macker , Lorenzo Vicisano Subject: Re: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:34:22 -0000 Dave, Thanks for your comments here. I think the MUSTs/SHOULDs can be clarified and will take a shot at that for you. The NORM spec is a transport protocol and not a security protocol as you point out. The goal of the security discussion was: 1) To identify the requirements upon using lower-layer IPSec to secure the protocol, and 2) Provide the EXT_AUTH header extension as a place-holder for applying a security mechanism as part of the NORM implementation. And to this regard, the RMT working group has another working document "draft-ietf-rmt-simple-auth-for-alc-norm" that makes use of this header extension. My question for you is whether you think we need to specify a specific security approach (e.g., IPSec) for implementations to have an interoperability spec? My personal opinion is that the spec can be interoperable in a "non-secure" fashion (i.e. no use of IPSec or the EXT_AUTH) mechanisms, but recommend that deployers SHOULD deploy NORM with security applied (Either the baseline IPSec approach described or a mechanism that uses the EXT_AUTH extension that is described in a follow-on spec like the "Simple Auth" document in progress). For those deployments to be interoperable, of course they would need to specify the same security mechanism, whatever it is. Perhaps more clearly stating these goals and cleaning up the MUSTs/ SHOULDs usage would satisfy you comments? I think we can accommodate that in a fairly straightforward fashion. best regards, Brian Adamson adamson@itd.nrl.navy.mil On Apr 10, 2009, at 3:56 PM, David Harrington wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document specifies a protocol (or an update to a protocol) that > provides end-to-end reliable transport of bulk data objects or streams > over multicast routing and forwarding services. It also provides a > congestion control scheme. It is designed to permit different upper > layer services to utilize its services in different ways. > > I got to this review late, so I went straight to the security > considerations first. I found the security requirements wishy-washy. > > Per BCP61, MUSTs are for implementers, SHOULDs are for deployers. > > There are few MUSTs or REQUIREDs to guide implementators what MUST be > present for interoperable security capabilities in an compliant > implementation. There are lots of SHOULDs, RECOMMENDEDs, MAY, can be, > is possible, is expected, optionally, etc. in the "Baseline Secure > NORM Operation". > > On the other hand, there are lots of SHALLs and REQUIREDs for how > deployers MUST configure their security. > > I am not sure how interoperable the security for this "standard" will > be because there are so many allowable options for how one does > security. > > This protocol is not a security protocol. It is a protocol that > utilizes lower layer security services, so maybe this "wishy-washy" > approach is the correct approach to serve the real-world needs of NORM > implementers and deployers. But I would feel more comfortable with > something a bit more solid in terms of what MUST be present for > security capabilities in compliant implementations. > > It might help a lot to separate the security considerations into what > MUST be implemented for interoperability, and how deployments SHOULD > be configured, and then talk about optional extensions or > alternatives. As currently written, I am not sure I could figure out > just what an implementer MUST support. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > From ietfdbh@comcast.net Thu Apr 16 11:29: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 7C6053A68B8 for ; Thu, 16 Apr 2009 11:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 GENXtsFaJEas for ; Thu, 16 Apr 2009 11:29:12 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 3372D3A682D for ; Thu, 16 Apr 2009 11:29:12 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA10.westchester.pa.mail.comcast.net with comcast id gCze1b00A17dt5G5AJWSU3; Thu, 16 Apr 2009 18:30:26 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id gJWR1b0020UQ6dC3ZJWRXx; Thu, 16 Apr 2009 18:30:26 +0000 From: "David Harrington" To: "'Brian Adamson'" References: <03a101c9ba16$74bf49f0$0600a8c0@china.huawei.com> <4FC76EA8-D6AC-44C0-AA0F-01D02A7651E6@itd.nrl.navy.mil> Date: Thu, 16 Apr 2009 14:30:23 -0400 Message-ID: <070201c9bec1$68a68980$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm+ua+JTr0YyoTOTuKVMselik4frAAAJrPg In-Reply-To: <4FC76EA8-D6AC-44C0-AA0F-01D02A7651E6@itd.nrl.navy.mil> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: 'Magnus Westerlund' , secdir@ietf.org, 'Tim Polk' , 'Pasi Eronen' , M.Handley@cs.ucl.ac.uk, cabo@tzi.org, 'Joe Macker' , 'Lorenzo Vicisano' Subject: Re: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:29:13 -0000 Hi, To ensure that there is at least one mechanism that every implementation will support in order to guarantee that interoperability is possible between any two implementations, I think you should specify that IPSec is REQUIRED to be supported in all implementations. An alternative is to specify that all implementation MUST support draft-ietf-rmt-simple-auth-for-alc-norm. Since IPSec might already be available in many stacks, and has significant deployment experience so we know there a few unknown gotchas yet to be discovered, I personally think the IPSec approach makes the most sense as a mandatory-to-implement baseline. dbh > -----Original Message----- > From: Brian Adamson [mailto:adamson@itd.nrl.navy.mil] > Sent: Thursday, April 16, 2009 1:31 PM > To: David Harrington > Cc: secdir@ietf.org; Pasi Eronen; Tim Polk; Joe Macker; > cabo@tzi.org; M.Handley@cs.ucl.ac.uk; Lorenzo Vicisano; > Magnus Westerlund; Brian Adamson > Subject: Re: secdir review of draft-ietf-rmt-pi-norm-revised-09 > > Dave, > > > Thanks for your comments here. I think the MUSTs/SHOULDs can be > clarified and will take a shot at that for you. > > The NORM spec is a transport protocol and not a security protocol as > you point out. The goal of the security discussion was: > > 1) To identify the requirements upon using lower-layer IPSec to > secure the protocol, and > > 2) Provide the EXT_AUTH header extension as a place-holder for > applying a security mechanism as part of the NORM > implementation. And > to this regard, the RMT working group has another working document > "draft-ietf-rmt-simple-auth-for-alc-norm" that makes use of this > header extension. > > My question for you is whether you think we need to specify a > specific > security approach (e.g., IPSec) for implementations to have an > interoperability spec? My personal opinion is that the spec can be > interoperable in a "non-secure" fashion (i.e. no use of IPSec or the > EXT_AUTH) mechanisms, but recommend that deployers SHOULD > deploy NORM > with security applied (Either the baseline IPSec approach > described or > a mechanism that uses the EXT_AUTH extension that is described in a > follow-on spec like the "Simple Auth" document in progress). For > those deployments to be interoperable, of course they would need to > specify the same security mechanism, whatever it is. > > Perhaps more clearly stating these goals and cleaning up the MUSTs/ > SHOULDs usage would satisfy you comments? I think we can > accommodate > that in a fairly straightforward fashion. > > best regards, > > > Brian Adamson > adamson@itd.nrl.navy.mil > > > > > On Apr 10, 2009, at 3:56 PM, David Harrington wrote: > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > The document specifies a protocol (or an update to a protocol) that > > provides end-to-end reliable transport of bulk data objects > or streams > > over multicast routing and forwarding services. It also provides a > > congestion control scheme. It is designed to permit different upper > > layer services to utilize its services in different ways. > > > > I got to this review late, so I went straight to the security > > considerations first. I found the security requirements wishy-washy. > > > > Per BCP61, MUSTs are for implementers, SHOULDs are for deployers. > > > > There are few MUSTs or REQUIREDs to guide implementators > what MUST be > > present for interoperable security capabilities in an compliant > > implementation. There are lots of SHOULDs, RECOMMENDEDs, > MAY, can be, > > is possible, is expected, optionally, etc. in the "Baseline Secure > > NORM Operation". > > > > On the other hand, there are lots of SHALLs and REQUIREDs for how > > deployers MUST configure their security. > > > > I am not sure how interoperable the security for this > "standard" will > > be because there are so many allowable options for how one does > > security. > > > > This protocol is not a security protocol. It is a protocol that > > utilizes lower layer security services, so maybe this "wishy-washy" > > approach is the correct approach to serve the real-world > needs of NORM > > implementers and deployers. But I would feel more comfortable with > > something a bit more solid in terms of what MUST be present for > > security capabilities in compliant implementations. > > > > It might help a lot to separate the security considerations > into what > > MUST be implemented for interoperability, and how deployments SHOULD > > be configured, and then talk about optional extensions or > > alternatives. As currently written, I am not sure I could figure out > > just what an implementer MUST support. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > From adamson@itd.nrl.navy.mil Thu Apr 16 12:03: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 50D873A6C92 for ; Thu, 16 Apr 2009 12:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 tY7KI7lDCwMs for ; Thu, 16 Apr 2009 12:02:59 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id AFDA53A6F1B for ; Thu, 16 Apr 2009 12:01:17 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n3GJ1ogQ025047; Thu, 16 Apr 2009 15:01:57 -0400 Received: from macsimus.itd.nrl.navy.mil ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009041615015416919 ; Thu, 16 Apr 2009 15:01:54 -0400 Message-Id: <9679186B-A977-4A33-8335-787D6B4B5884@itd.nrl.navy.mil> From: Brian Adamson To: "David Harrington" In-Reply-To: <070201c9bec1$68a68980$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 15:01:54 -0400 References: <03a101c9ba16$74bf49f0$0600a8c0@china.huawei.com> <4FC76EA8-D6AC-44C0-AA0F-01D02A7651E6@itd.nrl.navy.mil> <070201c9bec1$68a68980$0600a8c0@china.huawei.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Thu, 16 Apr 2009 12:34:09 -0700 Cc: 'Magnus Westerlund' , secdir@ietf.org, 'Tim Polk' , 'Pasi Eronen' , M.Handley@cs.ucl.ac.uk, cabo@tzi.org, 'Joe Macker' , 'Lorenzo Vicisano' Subject: Re: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:03:00 -0000 Thanks Dave, I think it is reasonable to expect that IPSec compatibility can be REQUIRED in a compliant implementation. I have actually run our NORM reference implementation with transport-mode IPSec enabled (different combinations of ESP and/or authentication) with pre-placed keys and security associations and it worked. Since NORM is encapsulated in UDP as currently specified, there was nothing that really needed to be done to make it work with IPsec other than getting the proper mix of security associations into place... as a matter of fact, an implementor would probably have to work hard to make something that wasn't IPSec compatible. I will incorporate your recommendation into the updated draft. Brian Adamson adamson@itd.nrl.navy.mil On Apr 16, 2009, at 2:30 PM, David Harrington wrote: > Hi, > > To ensure that there is at least one mechanism that every > implementation will support in order to guarantee that > interoperability is possible between any two implementations, I think > you should specify that IPSec is REQUIRED to be supported in all > implementations. > > An alternative is to specify that all implementation MUST support > draft-ietf-rmt-simple-auth-for-alc-norm. > > Since IPSec might already be available in many stacks, and has > significant deployment experience so we know there a few unknown > gotchas yet to be discovered, I personally think the IPSec approach > makes the most sense as a mandatory-to-implement baseline. > > dbh > >> -----Original Message----- >> From: Brian Adamson [mailto:adamson@itd.nrl.navy.mil] >> Sent: Thursday, April 16, 2009 1:31 PM >> To: David Harrington >> Cc: secdir@ietf.org; Pasi Eronen; Tim Polk; Joe Macker; >> cabo@tzi.org; M.Handley@cs.ucl.ac.uk; Lorenzo Vicisano; >> Magnus Westerlund; Brian Adamson >> Subject: Re: secdir review of draft-ietf-rmt-pi-norm-revised-09 >> >> Dave, >> >> >> Thanks for your comments here. I think the MUSTs/SHOULDs can be >> clarified and will take a shot at that for you. >> >> The NORM spec is a transport protocol and not a security protocol as > >> you point out. The goal of the security discussion was: >> >> 1) To identify the requirements upon using lower-layer IPSec to >> secure the protocol, and >> >> 2) Provide the EXT_AUTH header extension as a place-holder for >> applying a security mechanism as part of the NORM >> implementation. And >> to this regard, the RMT working group has another working document >> "draft-ietf-rmt-simple-auth-for-alc-norm" that makes use of this >> header extension. >> >> My question for you is whether you think we need to specify a >> specific >> security approach (e.g., IPSec) for implementations to have an >> interoperability spec? My personal opinion is that the spec can be >> interoperable in a "non-secure" fashion (i.e. no use of IPSec or the > >> EXT_AUTH) mechanisms, but recommend that deployers SHOULD >> deploy NORM >> with security applied (Either the baseline IPSec approach >> described or >> a mechanism that uses the EXT_AUTH extension that is described in a > >> follow-on spec like the "Simple Auth" document in progress). For >> those deployments to be interoperable, of course they would need to > >> specify the same security mechanism, whatever it is. >> >> Perhaps more clearly stating these goals and cleaning up the MUSTs/ >> SHOULDs usage would satisfy you comments? I think we can >> accommodate >> that in a fairly straightforward fashion. >> >> best regards, >> >> >> Brian Adamson >> adamson@itd.nrl.navy.mil >> >> >> >> >> On Apr 10, 2009, at 3:56 PM, David Harrington wrote: >> >>> I have reviewed this document as part of the security > directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should > treat >>> these comments just like any other last call comments. >>> >>> The document specifies a protocol (or an update to a protocol) > that >>> provides end-to-end reliable transport of bulk data objects >> or streams >>> over multicast routing and forwarding services. It also provides a >>> congestion control scheme. It is designed to permit different > upper >>> layer services to utilize its services in different ways. >>> >>> I got to this review late, so I went straight to the security >>> considerations first. I found the security requirements > wishy-washy. >>> >>> Per BCP61, MUSTs are for implementers, SHOULDs are for deployers. >>> >>> There are few MUSTs or REQUIREDs to guide implementators >> what MUST be >>> present for interoperable security capabilities in an compliant >>> implementation. There are lots of SHOULDs, RECOMMENDEDs, >> MAY, can be, >>> is possible, is expected, optionally, etc. in the "Baseline Secure >>> NORM Operation". >>> >>> On the other hand, there are lots of SHALLs and REQUIREDs for how >>> deployers MUST configure their security. >>> >>> I am not sure how interoperable the security for this >> "standard" will >>> be because there are so many allowable options for how one does >>> security. >>> >>> This protocol is not a security protocol. It is a protocol that >>> utilizes lower layer security services, so maybe this > "wishy-washy" >>> approach is the correct approach to serve the real-world >> needs of NORM >>> implementers and deployers. But I would feel more comfortable with >>> something a bit more solid in terms of what MUST be present for >>> security capabilities in compliant implementations. >>> >>> It might help a lot to separate the security considerations >> into what >>> MUST be implemented for interoperability, and how deployments > SHOULD >>> be configured, and then talk about optional extensions or >>> alternatives. As currently written, I am not sure I could figure > out >>> just what an implementer MUST support. >>> >>> David Harrington >>> dbharrington@comcast.net >>> ietfdbh@comcast.net >>> dharrington@huawei.com >>> >> >> > From weiler@watson.org Thu Apr 16 13:24: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 9F1163A68EE for ; Thu, 16 Apr 2009 13:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 QKKEcB7gl5yD for ; Thu, 16 Apr 2009 13:24:23 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id AEB063A67DD for ; Thu, 16 Apr 2009 13:24:23 -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 n3GKPaE3074370 for ; Thu, 16 Apr 2009 16:25:36 -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 n3GKPZGb074367 for ; Thu, 16 Apr 2009 16:25:36 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 16 Apr 2009 16:25:35 -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, 16 Apr 2009 16:25:36 -0400 (EDT) Subject: [secdir] Assignments for April 21st/23rd X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:24:24 -0000 Juergen Schoenwaelder 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-23 Charles Clancy T draft-ietf-ccamp-gmpls-ason-routing-ospf-08 Stephen Farrell TR draft-ietf-ipfix-exporting-type-03 Phillip Hallam-Baker TR draft-ietf-radext-design-07 Phillip Hallam-Baker TR draft-atlas-icmp-unnumbered-06 Scott Kelly T draft-ietf-dccp-serv-codes-08 Sandy Murphy T draft-ietf-tcpm-tcpsecure-11 Hilarie Orman T draft-ietf-tcpm-ecnsyn-08 Radia Perlman T draft-ietf-pana-statemachine-10 For telechat 2009-05-07 Angelos Keromytis T draft-ietf-isms-secshell-15 Julien Laganier T draft-ietf-isms-tmsm-16 Barry Leiba T draft-ietf-isms-transport-security-model-12 Juergen Schoenwaelder T draft-ietf-mipshop-mos-dhcp-options-13 Yaron Sheffer T draft-ietf-mipshop-rfc5268bis-01 Last calls and special requests: Derek Atkins draft-ietf-roll-building-routing-reqs-05 Rob Austein draft-p2pi-cooper-workshop-report-01 Pat Cain R draft-crocker-email-arch-12 Ran Canetti draft-ietf-avt-seed-srtp-10 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Steve Hanna draft-peterson-rai-rfc3427bis-01 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ncook-urlauth-accessid-02 Chris Newman draft-ietf-dccp-simul-open-07 Magnus Nystrom draft-ietf-mpls-p2mp-te-mib-08 Eric Rescorla draft-ietf-isms-radius-usage-05 Joe Salowey draft-ietf-geopriv-lis-discovery-09 Hannes Tschofenig draft-ietf-pce-monitoring-04 Sean Turner draft-ietf-ltru-4645bis-10 Carl Wallace draft-ietf-ltru-4646bis-21 Sam Weiler draft-chown-v6ops-rogue-ra-03 Sam Weiler draft-thomson-beep-async-02 Brian Weis draft-ietf-pce-p2mp-app-01 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 turners@ieca.com Thu Apr 16 14:33: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 2D3943A6DAC for ; Thu, 16 Apr 2009 14:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 bpJCAQRkBEhe for ; Thu, 16 Apr 2009 14:33:18 -0700 (PDT) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id C69993A6DA8 for ; Thu, 16 Apr 2009 14:33:17 -0700 (PDT) Received: (qmail 90102 invoked from network); 16 Apr 2009 21:27:51 -0000 Received: from unknown (HELO thunderfish.local) (turners@96.241.94.237 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 16 Apr 2009 21:27:51 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: KN4w2YwVM1nyDroOrZMpWmjNUoMaQsQ8ireki_6P88nFpPlRMnrSd0PExjHJxTK1CTp4miPxssBKC2DHjk_PW4qONG4w9GhZ3HEBo.4QxcBx21y6UNfrCqcnqoQdCF9pIVmjYvnEiL_iS.4YLt15nGL.uFjVXcwNaAF5nzIjkcuJhGFujX5iSKaoFym8NnCbdTLy5OuDUAxHNue3DFcBxVvSbinBGFow7B7U42n0WMI8Tc3TIW.fsCQwy54qAWIeJ3lF0s8a0rLKI2jG2Jp2trj0GvEwB595t7DOxDACNHvcPJx_JTw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E7A2D5.5060702@ieca.com> Date: Thu, 16 Apr 2009 17:27:49 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: secdir , doug@ewellic.org, iesg@ietf.org, Randy Presuhn , Martin Duerst Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Review of draft-ietf-ltru-4645bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:33: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. My heart sank when I was assigned this document because it's 950 pages, but 940ish of the pages are a registry ;) This document provides procedures to update the IANA Language Subtag Registry. The Subtags are copied from ISO documents. I can't think of any security concerns for the procedures themselves. The Security Considerations section points to draft-ietf-ltru-4646bis-21.txt for any issue with tags themselves. Assuming the copy from the ISO document was exact, I support this document becoming an RFC spt From doug@ewellic.org Thu Apr 16 20:56:05 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5733A6BD7 for ; Thu, 16 Apr 2009 20:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9IsuBY2akrf for ; Thu, 16 Apr 2009 20:56:05 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 684BD3A6A45 for ; Thu, 16 Apr 2009 20:55:54 -0700 (PDT) Received: (qmail 17887 invoked from network); 17 Apr 2009 03:50:28 -0000 Received: from unknown (67.166.27.148) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 17 Apr 2009 03:50:27 -0000 Message-ID: From: "Doug Ewell" To: "Sean Turner" , "secdir" , , "Randy Presuhn" , "Martin Duerst" References: <49E7A2D5.5060702@ieca.com> Date: Thu, 16 Apr 2009 21:50:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Thu, 16 Apr 2009 22:47:08 -0700 Subject: Re: [secdir] Review of draft-ietf-ltru-4645bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 03:56:05 -0000 Sean Turner wrote: > My heart sank when I was assigned this document because it's 950 > pages, but 940ish of the pages are a registry ;) > > This document provides procedures to update the IANA Language Subtag > Registry. The Subtags are copied from ISO documents. Not all of them, and not exactly. They are adapted from ISO documents and from the existing Registry according to the process described in the other 10ish pages. > I can't think of any security concerns for the procedures themselves. > The Security Considerations section points to > draft-ietf-ltru-4646bis-21.txt for any issue with tags themselves. > > Assuming the copy from the ISO document was exact, I support this > document becoming an RFC I'm glad to see the support. However, I'd like to be sure it is for the right reasons. Other reviewers who read this and assume the Registry is copied exactly from ISO sources may balk when they find that it is not exact. The text explains everything. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 Editor, draft-ietf-ltru-4645bis http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ From j.schoenwaelder@jacobs-university.de Fri Apr 17 06:07:52 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF7D3A6838; Fri, 17 Apr 2009 06:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQesognkv37A; Fri, 17 Apr 2009 06:07:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EF9B53A67F4; Fri, 17 Apr 2009 06:07:50 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB656C00D4; Fri, 17 Apr 2009 15:09:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dBPwr90JbXkv; Fri, 17 Apr 2009 15:09:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81A43C00C2; Fri, 17 Apr 2009 15:09:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A0632AAB168; Fri, 17 Apr 2009 15:08:42 +0200 (CEST) Date: Fri, 17 Apr 2009 15:08:42 +0200 From: Juergen Schoenwaelder To: gabor.bajko@nokia.com, subir@research.telcordia.com Message-ID: <20090417130842.GA17533@elstar.local> Mail-Followup-To: gabor.bajko@nokia.com, subir@research.telcordia.com, iesg@ietf.org, secdir@ietf.org, mipshop-chairs@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: mipshop-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-mipshop-mos-dhcp-options-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:07:52 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines DHCP options to discover mobility servers. I have some general questions and some security specific questions plus a few editorial nits. General: a) You define "Mobility Services" but in the definition of "Mobility Server" you refer to "Mobility Support Services". Are the terms "Mobility Services" and "Mobility Support Services" the same? If yes, choose one and stick to it. If not, a definition is likely needed to explain the difference. b) The document spells out that multiple IP addresses in a DHCP MoS option are processed in order of preference. Should the document also state explicitly how multiple DHCP MoS options are to be processed? One might assume that multiple DHCP MoS options are processed in decreasing order of preference as well but I think this is not spelled out. c) I am not a DHCP / DHCPv6 person and thus this question might be just show my ignorance - but anyway: Can the new options be used in mixed IPv4/IPv6 environments? Can I obtain IPv4 addresses of Mobility Servers from a DHCPv6 server? Can I obtain IPv6 addresses of Mobility Servers from a DHCP server? Security: d) I think the security considerations should mention that the resolution of DNS names itself is a risk unless DNS security is applied, perhaps with an explicit pointer to the security considerations in . e) The text recommends the use of the DHCP authentication option [RFC3118] or the use of link layer security. And then the third paragraphs starts with "This will also protect the denial of service attacks to DHCP servers". There are three questions here: - What is "This" refering to? Do both the DHCP authentication option and link layer security protect against DoS attacks? Or does "This" refer to link layer security only? - The security services provided by RFC3118 and link layer security are likely not the same. (The RFC3118 option provides me with trust that I am talking to the right server while link layer security likely only provides me trust that I talked to some server on the right link layer endpoint. - I find link layer security somewhat opaque since I am not sure what precisely this stands for. I understand that it will be not a good idea to list link layer specific things here but perhaps spelling out which security services a working link layer security technology must provide would help. My recommendation is to rewrite the security considerations so that the text discusses in one paragraph the usage of RFC3118 and then in a subsequent paragraph the usage of link layer security mechanisms. Right now, the discussion jumps between these two options making it more difficult for me to understand the statements being made. Editorial: - Items (1) and (2) should be moved from the abstract to the end of the introduction. This way, the acronyms are introduced before they are used. - p1: 'a list IP' -> 'a list of IP' - P2: 'an mobile' -> 'a mobile' - p2: 'set of different services' -> 'set of services' - p11: '(as defined in [RFC2131]' -> '(as defined in [RFC2131])' - p12: '(as defined in [RFC2131]' -> '(as defined in [RFC2131])' /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From scott@hyperthought.com Fri Apr 17 11:30:27 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5297328C195 for ; Fri, 17 Apr 2009 11:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO0d8MYeR-5S for ; Fri, 17 Apr 2009 11:30:26 -0700 (PDT) Received: from smtp202.iad.emailsrvr.com (smtp202.iad.emailsrvr.com [207.97.245.202]) by core3.amsl.com (Postfix) with ESMTP id 6DAC43A68B0 for ; Fri, 17 Apr 2009 11:30:26 -0700 (PDT) Received: from relay10.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay10.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id B56611E5DE7; Fri, 17 Apr 2009 14:31:39 -0400 (EDT) Received: by relay10.relay.iad.mlsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 270241EA705; Fri, 17 Apr 2009 14:31:38 -0400 (EDT) Message-ID: <49E8CB08.8040106@hyperthought.com> Date: Fri, 17 Apr 2009 11:31:36 -0700 From: "Scott G. Kelly" User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "iesg@ietf.org" , secdir , dccp-chairs@tools.ietf.org, gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] review of draft-ietf-dccp-serv-codes-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 18:30:27 -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 clarifies the use of service codes in DCCP. It does not define new protocol elements, but instead adds detail that is not present in RFC 4340 ("Datagram Congestion Control Protocol (DCCP)") The security considerations section discusses 4 areas of interest: - Server Port number reuse - Interaction with NATs and firewalls - Interpretation of DCCP Service Codes over-riding traditional use of reserved/Well Known port numbers - Interaction with IPsec and DTLS security I have a couple of minor comments: first, it might be good to explicitly refer to RFC 4340, which has its own security considerations section, since the things discussed there are not discussed here. The second comment relates to the fact that servers supporting these service codes give concrete service identification for a given port more readily than servers not employing service codes. By responding to an inbound connection request, systems not using these codes may indicate that *some* service is or is not available on a given port, but systems using this mechanism immediately provide confirmation (or denial) that a *particular* service is present. This may have implications in terms of port scanning and reconnaissance. --Scott From Radia.Perlman@sun.com Fri Apr 17 12:11: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 62C3F3A6E2D; Fri, 17 Apr 2009 12:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 XnLbWBZtCMvv; Fri, 17 Apr 2009 12:11:37 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 9ECA33A6ADB; Fri, 17 Apr 2009 12:11:37 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KI900EEFEPBVS20@mail-mta.sfvic.sunlabs.com>; Fri, 17 Apr 2009 12:12:47 -0700 (PDT) Received: from [192.168.1.102] ([24.16.44.155]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KI900FCVEPAXD11@mail.sunlabs.com>; Fri, 17 Apr 2009 12:12:47 -0700 (PDT) Date: Fri, 17 Apr 2009 12:12:46 -0700 From: Radia Perlman To: iesg@ietf.org, secdir@ietf.org, vfajardo@tari.toshiba.com, yohba@tari.toshiba.com, pana-chairs@tools.ietf.org Message-id: <49E8D4AE.7030004@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Subject: [secdir] Review of internet-drafts/draft-ietf-pana-statemachine-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 19:11:38 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document writes out the state machines for all the pana functions. I did not scrutinize them all to see if they were accurate, though I did look at a few of them and those were cleanly described and well thought out. It's a bit weird for a document associated with a security protocol to have such a short security considerations section: >>" This document's intent is to describe the PANA state machines fully. >> To this end, any security concerns with this document are likely a >> reflection of security concerns with PANA itself." But really they are correct -- that the security considerations are for the PANA protocol itself. So I see no problems with this document. Radia From jari.arkko@piuha.net Fri Apr 17 13:24:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642423A6840; Fri, 17 Apr 2009 13:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aef3vebX6iTI; Fri, 17 Apr 2009 13:24:18 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4202F3A6931; Fri, 17 Apr 2009 13:24:18 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 95EBF19871D; Fri, 17 Apr 2009 23:25:31 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 2F00C198671; Fri, 17 Apr 2009 23:25:31 +0300 (EEST) Message-ID: <49E8E5AF.9050609@piuha.net> Date: Fri, 17 Apr 2009 23:25:19 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Radia Perlman References: <49E8D4AE.7030004@sun.com> In-Reply-To: <49E8D4AE.7030004@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: pana-chairs@tools.ietf.org, vfajardo@tari.toshiba.com, yohba@tari.toshiba.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of internet-drafts/draft-ietf-pana-statemachine-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 20:24:19 -0000 Radia, Thanks for your review! Jari Radia Perlman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document writes out the state machines for all the pana > functions. I did not scrutinize them all to see if they were accurate, > though I did look at a few of them and those were cleanly described > and well thought out. > > It's a bit weird for a document associated with a security protocol to > have such a short security > considerations section: > >>> " This document's intent is to describe the PANA state machines fully. >>> To this end, any security concerns with this document are likely a >>> reflection of security concerns with PANA itself." > > But really they are correct -- that the security considerations are for > the PANA protocol itself. > > So I see no problems with this document. > > Radia > > > > From hilarie@purplestreak.com Mon Apr 20 07:59: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 2BFB33A6B09 for ; Mon, 20 Apr 2009 07:59: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 dWd6cNy9xZ+C for ; Mon, 20 Apr 2009 07:59:37 -0700 (PDT) Received: from etrn.xmission.com (etrn.xmission.com [198.60.22.17]) by core3.amsl.com (Postfix) with ESMTP id 7A01D3A6A81 for ; Mon, 20 Apr 2009 07:59:37 -0700 (PDT) Received: from [166.70.57.249] (helo=localhost.localdomain) by etrn.xmission.com with esmtp (Exim 4.50) id 1LvuzH-0003VH-R1; Mon, 20 Apr 2009 09:00:47 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id n3KEvaqo010615; Mon, 20 Apr 2009 08:57:36 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id n3KEvWVD010611; Mon, 20 Apr 2009 08:57:32 -0600 Date: Mon, 20 Apr 2009 08:57:32 -0600 Message-Id: <200904201457.n3KEvWVD010611@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: ho set sender to hilarie using -f From: "Hilarie Orman" To: secdir@ietf.org Cc: akuzma@northwestern.edu, david.borman@windriver.com, floyd@icir.org, magnus.westerlund@ericsson.com, a-mondal@northwestern.edu, lars.eggert@nokia.com, kkrama@research.att.com, weddy@grc.nasa.gov Subject: [secdir] Review of draft-ietf-tcpm-ecnsyn-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 14:59:38 -0000 draft-ietf-tcpm-ecnsyn-08.txt I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is an interesting and well-written document, I enjoyed reading it. It is about an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. The TCP initiator can use this information to reduce its initial congestion window. In simulation, there is a compelling argument that this helps to improve response time during heavy congestion.. The draft argues that the mechanism introduces no security problems, using arguments that bound any potential problems by known existing behaviors. I have no reason to believe that the analysis is wrong. My only caveat is that the combined state machine for TCP and ECN seems complicated, I don't know that all cases are really covered by the draft authors. Perhaps someone could do that if this draft ever moves toward standard. Hilarie Orman From sallyfloyd@mac.com Mon Apr 20 09:39:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBAFC3A6D48 for ; Mon, 20 Apr 2009 09:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpDzii-r5r5c for ; Mon, 20 Apr 2009 09:39:30 -0700 (PDT) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by core3.amsl.com (Postfix) with ESMTP id 19BEC3A68AE for ; Mon, 20 Apr 2009 09:39:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [10.0.0.111] ([64.241.37.140]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KIE0088FRNUFC90@asmtp021.mac.com> for secdir@ietf.org; Mon, 20 Apr 2009 09:40:45 -0700 (PDT) Message-id: <3856E125-1798-41BE-B122-9A9484E15E61@mac.com> From: Sally Floyd To: Hilarie Orman In-reply-to: <200904201457.n3KEvWVD010611@localhost.localdomain> Date: Mon, 20 Apr 2009 09:40:44 -0700 References: <200904201457.n3KEvWVD010611@localhost.localdomain> X-Mailer: Apple Mail (2.930.3) Cc: akuzma@northwestern.edu, magnus.westerlund@ericsson.com, david.borman@windriver.com, floyd@icir.org, secdir@ietf.org, a-mondal@northwestern.edu, lars.eggert@nokia.com, kkrama@research.att.com, weddy@grc.nasa.gov Subject: Re: [secdir] Review of draft-ietf-tcpm-ecnsyn-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 16:39:31 -0000 Hilarie - On Apr 20, 2009, at 7:57 AM, Hilarie Orman wrote: > draft-ietf-tcpm-ecnsyn-08.txt > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This is an interesting and well-written document, I enjoyed reading > it. It is about an optional, experimental modification to RFC 3168 to > allow TCP SYN/ACK packets to be ECN-Capable. The TCP initiator can > use this information to reduce its initial congestion window. In > simulation, there is a compelling argument that this helps to improve > response time during heavy congestion.. > > The draft argues that the mechanism introduces no security problems, > using arguments that bound any potential problems by known existing > behaviors. I have no reason to believe that the analysis is wrong. > My > only caveat is that the combined state machine for TCP and ECN seems > complicated, I don't know that all cases are really covered by the > draft authors. Perhaps someone could do that if this draft ever moves > toward standard. Many thanks for the review. I will look at the combined state machine in the final review of the draft. - Sally http://www.icir.org/floyd/ From adamson@itd.nrl.navy.mil Mon Apr 20 14:49: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 41FF23A6E2D; Mon, 20 Apr 2009 14:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 sk6gW530vsIi; Mon, 20 Apr 2009 14:49:38 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 1DD373A6CEC; Mon, 20 Apr 2009 14:49:37 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n3KLnS9o013881; Mon, 20 Apr 2009 17:49:28 -0400 Received: from [192.168.1.201] ([132.250.218.64]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009042017492600606 ; Mon, 20 Apr 2009 17:49:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <070201c9bec1$68a68980$0600a8c0@china.huawei.com> References: <03a101c9ba16$74bf49f0$0600a8c0@china.huawei.com> <4FC76EA8-D6AC-44C0-AA0F-01D02A7651E6@itd.nrl.navy.mil> <070201c9bec1$68a68980$0600a8c0@china.huawei.com> Date: Mon, 20 Apr 2009 17:49:23 -0400 To: "David Harrington" , Spencer Dawkins , General Area Review Team , drafts-lastcall@icann.org From: Brian Adamson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: 'Magnus Westerlund' , secdir@ietf.org, 'Tim Polk' , 'Pasi Eronen' , M.Handley@cs.ucl.ac.uk, cabo@tzi.org, 'Joe Macker' , 'Lorenzo Vicisano' Subject: [secdir] Update: draft-ietf-rmt-pi-norm-revised-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:49:39 -0000 Hello, I have posted an updated version of the NORM draft which addresses Spencer's GEN-ART comments and attempts to clarify the Security Considerations per Dave Harrington's comments and the IANA Consideration per comments from IANA. This update also makes the TFMCC RFC a Normative reference per Magnus' request at the last RMT meeting. best regards, -- Brian __________________________________ Brian Adamson From subir@research.telcordia.com Tue Apr 21 01:07:47 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E463A6B0C; Tue, 21 Apr 2009 01:07:47 -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 a7GBewyUg2hG; Tue, 21 Apr 2009 01:07:46 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 3434F3A69CC; Tue, 21 Apr 2009 01:07:46 -0700 (PDT) Received: from mailee.research.telcordia.com (mailee.research.telcordia.com [192.4.16.29]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n3L890VD015283; Tue, 21 Apr 2009 04:09:00 -0400 (EDT) Received: from [127.0.0.1] ([128.96.58.39]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id EAA01112; Tue, 21 Apr 2009 04:08:59 -0400 (EDT) Message-ID: <49ED7F1E.3020700@research.telcordia.com> Date: Tue, 21 Apr 2009 04:09:02 -0400 From: Subir Das User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gabor.bajko@nokia.com, subir@research.telcordia.com, iesg@ietf.org, secdir@ietf.org, mipshop-chairs@tools.ietf.org References: <20090417130842.GA17533@elstar.local> In-Reply-To: <20090417130842.GA17533@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Apr 2009 02:39:41 -0700 Subject: Re: [secdir] secdir review of draft-ietf-mipshop-mos-dhcp-options-13.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 08:07:47 -0000 Hello Juergen, Thanks for your review and comments. We will address them. Some answers below. regards, -Subir Juergen Schoenwaelder wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document defines DHCP options to discover mobility servers. I have > some general questions and some security specific questions plus a few > editorial nits. > > General: > > a) You define "Mobility Services" but in the definition of "Mobility > Server" you refer to "Mobility Support Services". Are the terms > "Mobility Services" and "Mobility Support Services" the same? If > yes, choose one and stick to it. If not, a definition is likely > needed to explain the difference. > Yes they are the same and will use one. > b) The document spells out that multiple IP addresses in a DHCP MoS > option are processed in order of preference. Should the document > also state explicitly how multiple DHCP MoS options are to be > processed? One might assume that multiple DHCP MoS options are > processed in decreasing order of preference as well but I think > this is not spelled out. > Will clarify this. > c) I am not a DHCP / DHCPv6 person and thus this question might be > just show my ignorance - but anyway: Can the new options be used > in mixed IPv4/IPv6 environments? Can I obtain IPv4 addresses of > Mobility Servers from a DHCPv6 server? Can I obtain IPv6 addresses > of Mobility Servers from a DHCP server? > If the server is configured to operate in a dual stack environment, I do not see any reason why the client can not get the address it is asking for. > Security: > > d) I think the security considerations should mention that the > resolution of DNS names itself is a risk unless DNS security is > applied, perhaps with an explicit pointer to the security > considerations in . > Ok. > e) The text recommends the use of the DHCP authentication option > [RFC3118] or the use of link layer security. And then the third > paragraphs starts with "This will also protect the denial of > service attacks to DHCP servers". There are three questions here: > > - What is "This" refering to? Do both the DHCP authentication > option and link layer security protect against DoS attacks? Or > does "This" refer to link layer security only? > Currently it refers to both. Will rewrite the security section per your suggestions below. > - The security services provided by RFC3118 and link layer security > are likely not the same. (The RFC3118 option provides me with > trust that I am talking to the right server while link layer > security likely only provides me trust that I talked to some > server on the right link layer endpoint. > > - I find link layer security somewhat opaque since I am not sure > what precisely this stands for. I understand that it will be not > a good idea to list link layer specific things here but perhaps > spelling out which security services a working link layer > security technology must provide would help. > > My recommendation is to rewrite the security considerations so that > the text discusses in one paragraph the usage of RFC3118 and then > in a subsequent paragraph the usage of link layer security > mechanisms. Right now, the discussion jumps between these two > options making it more difficult for me to understand the > statements being made. > > Editorial: > > - Items (1) and (2) should be moved from the abstract to the end of > the introduction. This way, the acronyms are introduced before they > are used. > Items (1) and (2) are not intended to be included in the "Abstract". We will separate them. > - p1: 'a list IP' -> 'a list of IP' > > - P2: 'an mobile' -> 'a mobile' > > - p2: 'set of different services' -> 'set of services' > > - p11: '(as defined in [RFC2131]' -> '(as defined in [RFC2131])' > > - p12: '(as defined in [RFC2131]' -> '(as defined in [RFC2131])' > Will correct the above errors. > /js > > From Chris.Newman@Sun.COM Tue Apr 21 18:23:52 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5786C28C25B; Tue, 21 Apr 2009 18:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Yr4P5xc1dt3U; Tue, 21 Apr 2009 18:23:51 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 5525228C113; Tue, 21 Apr 2009 18:23:51 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3M1P4dd021400; Tue, 21 Apr 2009 18:25:06 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; format=flowed; charset=us-ascii Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIH00H00A87KG00@fe-sfbay-10.sun.com>; Tue, 21 Apr 2009 18:25:04 -0700 (PDT) Received: from [10.1.110.5] ([unknown] [10.1.110.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIH00BWYALP0J50@fe-sfbay-10.sun.com>; Tue, 21 Apr 2009 18:25:03 -0700 (PDT) Date: Tue, 21 Apr 2009 18:25:01 -0700 From: Chris Newman Sender: Chris.Newman@Sun.COM To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dccp-simul-open@tools.ietf.org, dccp-chairs@tools.ietf.org Message-id: X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: [secdir] Secdir review of draft-ietf-dccp-simul-open-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 01:23:52 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall: This proposal provides a reasonable architecture for the function the WG desires. I support advancement after some of the issues below are addressed. Section 2.2.1: The reference to draft-ietf-dccp-serv-codes-08 appears to be normative as a "MUST" requirement is placed on a field whose meaning depends on that specification. Section 2.2.2: The "LISTEN1" state is mentioned in the pseudocode, but not the state diagram or figure label. I suspect it should read "LISTEN'" (to match the figure label) or the two should be declared equivalent. Security Considerations The stated threats seem reasonably well described. One potentially significant threat I did not see discussed: This creates a new way to set up a DCCP connection from a client to a server triggered via a SIP/SDP connection setup. If the SIP/SDP connection is unencrypted, an eavesdropper could get the client IP and Port for the to-be-established DCCP connection and generate a DCCP-Listen to the client using its own server-IP/port. So if the client is waiting for a DCCP-Listen from an arbitrary server-IP/port and responds to it, this allows an attacker to redirect the connection without IP spoofing. If, however, the client is told the server-IP and server-port for DCCP through SDP and will only accept a DCCP-Listen from that endpoint, the new threat would be mitigated (leaving the existing DCCP IP spoofing threat). One minor issue I noticed was not mentioned directly: The DCCP base specification Init Cookie option lets a DCCP server avoid having to hold any state until the three-way connection setup handshake has completed. This specification enables an out-of-band mechanism that forces the server to hold state for a connection that has not yet been established. This is a change in the security profile of DCCP, although the impact is minimal and depends on the security features of the out-of-band mechanism (SIP SDP is one such mechanism that provides sufficient security features). Nit: The statement: "A DCCP server SHOULD therefore by default permit generation of DCCP-Listen packets." seems inappropriate in a security considerations section as the recommendation is really unrelated to security. Perhaps that recommendation should be in the normative protocol description. - Chris From trammell@tik.ee.ethz.ch Tue Apr 21 10:28:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2943A6B67 for ; Tue, 21 Apr 2009 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0i79ZMBGFxu for ; Tue, 21 Apr 2009 10:28:58 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 5960E3A68A7 for ; Tue, 21 Apr 2009 10:28:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 73006D934A; Tue, 21 Apr 2009 19:30:13 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nBhj7LkFgu4M; Tue, 21 Apr 2009 19:30:13 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id E1D3DD934D; Tue, 21 Apr 2009 19:30:12 +0200 (MEST) Message-Id: <7C549E55-5EBF-4C50-AC45-0B85C2978C81@tik.ee.ethz.ch> From: Brian Trammell To: hartmans-ietf@mit.edu 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 v930.3) Date: Tue, 21 Apr 2009 19:30:12 +0200 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Tue, 21 Apr 2009 23:54:49 -0700 Cc: draft-ietf-ipfix-file@tools.ietf.org, ipfix-chairs@tools.ietf.org, Dan Romascanu , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ipfix-file-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:28:59 -0000 Sam, Thanks for your comprehensive review and comments; my responses appear inline below... > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > I urge the IESG to get specific additional review from the law > enforcement/security investigation community surrounding the handling > of evidence in an ongoing investigation prior to approving this draft. > Section 4 cites that use case as a significant motivation. However, > I'm concerned that the requirements in section 5 and thus the > resulting protocol are inadequate to that community's needs. > First, while nothing in the document precludes the applicability of these files to law enforcement, nothing in the document is intended to apply specifically to law enforcement; the "security investigation" mentioned in section 4 is intended specifically to refer to an investigation undertaken by a CSIRT with some responsibility within an organizational or jurisdictional scope. I would assume that it is the responsibility of the CSIRT at deployment time to ensure that any information intended to be used as evidence would be handled a way that complies with the rules of evidence for the jurisdiction(s) within which they operate. This document describes a file format. To the extent that other file formats may be handled in a way consistent with the rules of evidence, so can this one. That said, I think we can address these points: > Section 3 talks about advantages of the file format including that > files can be concatenated or split on message boundaries. There is no > file header or trailer. However there are records such as those > described in 8.1.3 that describe metadata for the file. Particularly > in investigation environments it seems problematic to get into a > situation where the file has metadata that claims inaccurately to > describe the file especially when this happens using mechanisms > explicitly supported by the file format and the situation cannot be > detected. In the document use case I think you want a mechanism to > confirm that a file has not been added to or removed from. > Text from section 3 on concatenation/splitting will be removed, since this was intended mainly as a side-benefit, and has other potential issues as well. We would presume that file integrity would be provided by encryption. There is no specification in -03 of an encryption encapsulation, but we would propose CMS as a solution in -04... Both of these points are addressed in more detail in my previous message responding to Margaret Wasserman's comments, sent today to iesg@iesg.org . > Section 7.3.4 requires using the file write time as the export time. > That seems potentially problematic in an investigation. TPerhaps the > message details option in 8.1.4 is supposed to handle this; if so, > text explaining how this works should be added to 7.3.4. > Hm. Excellent point, although in general it is the _flow_ timestamp, not the message timestamp, which would be interesting in an investigation. If it is necessary to know when something was _received_ by the collection system, though, either 8.1.3 and 8.1.4 may be used to address this problem; I'll add text to the -04 rev doing so. > The handling of authentication seems problematic. The text points out > that TLS can be used to provide transient authentication from the > exporter to collector. Discussion of the lack of data origin > authentication (authentication that can be verified after the fact by > a third party) needs to be added to the security considerations > section; this seems important for the 7.3.4 use case. I'm not asking > for digital signatures to be added at the exporter, simply for > discussion of the consequences on having hop-by-hop authentication. > > However there is a more serious lack on the authentication front. > There is no way for a file writer to describe the authenticated > identity of the exporter. I'd expect 8.1.3 and 8.1.4 to include > attributes to describe the TLS identity of the exporter. > Both of these, I think, could be addressed by the specification of interoperable encryption, as above. > The template in 8.1.1 uses md5. There's insufficient documentation > for me to tell whether the cryptographic properties, particularly > collision resistance, are important to this use of md5. My guess is > that they are and thus md5 may not be the best hash to use. > Is a per-message checksum really the right granularity? > It's a simple checksum, meant primarily for error detection during long term storage when files are stored on a medium or within an encapsulation (i.e. filesystem) that does not provide adequate detection of errors (think giant, uncompressed files streamed directly to tape). We are indeed probably better served by recommending the encapsulation of a file within something that provides better error handling, and providing this as a last resort. As a simple checksum, it would appear that the cryptographic properties are not particularly important. > The security considerations section is very weak. > I don't disagree, but some additional guidance on this point would be appreciated. :) Thanks again, and kind regards, Brian From hartmans@mit.edu Wed Apr 22 05:24: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 93EBC3A6CC1 for ; Wed, 22 Apr 2009 05:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPwH5NWOfeT0 for ; Wed, 22 Apr 2009 05:24:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 967933A6C91 for ; Wed, 22 Apr 2009 05:24:23 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8D64F415C; Wed, 22 Apr 2009 08:25:39 -0400 (EDT) To: Brian Trammell References: <7C549E55-5EBF-4C50-AC45-0B85C2978C81@tik.ee.ethz.ch> From: Sam Hartman Date: Wed, 22 Apr 2009 08:25:39 -0400 In-Reply-To: <7C549E55-5EBF-4C50-AC45-0B85C2978C81@tik.ee.ethz.ch> (Brian Trammell's message of "Tue\, 21 Apr 2009 19\:30\:12 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-ipfix-file@tools.ietf.org, Dan Romascanu , ipfix-chairs@tools.ietf.org, hartmans-ietf@mit.edu, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ipfix-file-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 12:24:24 -0000 >>>>> "Brian" == Brian Trammell writes: Brian> Sam, Thanks for your comprehensive review and comments; my >> The handling of authentication seems problematic. The text >> points out that TLS can be used to provide transient >> authentication from the exporter to collector. Discussion of >> the lack of data origin authentication (authentication that can >> be verified after the fact by a third party) needs to be added >> to the security considerations section; this seems important >> for the 7.3.4 use case. I'm not asking for digital signatures >> to be added at the exporter, simply for discussion of the >> consequences on having hop-by-hop authentication. >> >> However there is a more serious lack on the authentication >> front. There is no way for a file writer to describe the >> authenticated identity of the exporter. I'd expect 8.1.3 and >> 8.1.4 to include attributes to describe the TLS identity of the >> exporter. >> Both of these, I think, could be addressed by the specification of Brian> interoperable encryption, as above. No, not really. Using CMS for encryption and integrity will protect a file once created. I had two issues. The first is that the data is not integrity protected end-to-end. The exporter may transport to the collector over TLS. Let's assume that the collector is digitally signing the file. There's a break in the cryptographic protection at the collector: it could modify the data however it likes. When I read the file years later, I have to trust the collector and the exporter, not just the exporter. If you considered that a problem and wanted to fix it, you'd need to add digital signatures at the exporter. Given my understanding of ipfix, that would seem both expensive and unnecessary. So, instead, you should document the issue and explain that the file reader needs to trust the file writer not to modify the contents. The second issue is that the collector has no way to tell the file reader the identity of the exporter. If I have a TLS connection with badguy@evil.example.com, I might trust the data less than data from sensor-53@east.example.net.The identity of the collector could be captured in a CMS signature on the file. However nothing captures the identity of the exporter--not even as an assertion from the collector. >> The template in 8.1.1 uses md5. There's insufficient >> documentation for me to tell whether the cryptographic >> properties, particularly collision resistance, are important to >> this use of md5. My guess is that they are and thus md5 may >> not be the best hash to use. Is a per-message checksum really >> the right granularity? >> It's a simple checksum, meant primarily for error detection during Brian> long term storage when files are stored on a medium or Brian> within an encapsulation (i.e. filesystem) that does not Brian> provide adequate detection of errors (think giant, Brian> uncompressed files streamed directly to tape). OK. md5 seems fine for that. Thanks for the clarification. From apache@request.iana.org Wed Apr 22 14:58: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 1E0973A6D62 for ; Wed, 22 Apr 2009 14:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBsngDEeuqHo for ; Wed, 22 Apr 2009 14:58:02 -0700 (PDT) Received: from request.iana.org (request.iana.org [208.77.188.221]) by core3.amsl.com (Postfix) with ESMTP id 6A29C3A6DE2 for ; Wed, 22 Apr 2009 14:58:02 -0700 (PDT) Received: from request.iana.org (localhost.localdomain [127.0.0.1]) by request.iana.org (8.13.8/8.13.8) with ESMTP id n3MLwBrN024559; Wed, 22 Apr 2009 14:58:11 -0700 Received: (from apache@localhost) by request.iana.org (8.13.8/8.13.8/Submit) id n3MLw7SN024558; Wed, 22 Apr 2009 14:58:07 -0700 From: "Amanda Baber via RT" In-Reply-To: References: <03a101c9ba16$74bf49f0$0600a8c0@china.huawei.com> <4FC76EA8-D6AC-44C0-AA0F-01D02A7651E6@itd.nrl.navy.mil> <070201c9bec1$68a68980$0600a8c0@china.huawei.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #236966 Managed-by: RT 3.8.3pre1 (http://www.bestpractical.com/rt/) RT-Originator: amanda.baber@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 22 Apr 2009 21:58:07 +0000 X-Mailman-Approved-At: Wed, 22 Apr 2009 23:44:36 -0700 Cc: magnus.westerlund@ericsson.com, secdir@ietf.org, tim.polk@nist.gov, Pasi.Eronen@nokia.com, adamson@itd.nrl.navy.mil, M.Handley@cs.ucl.ac.uk, cabo@tzi.org, macker@itd.nrl.navy.mil, lorenzo@vicisano.net Subject: [secdir] [IANA #236966] Re: Last Call: draft-ietf-rmt-pi-norm-revised (NACK-Oriented Reliable Multicast Protocol) to Proposed Standard X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Reply-To: drafts-lastcall@icann.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:58:03 -0000 Hi Brian, A couple of questions about the new IANA Considerations: - Is there an upper limit to the values available in the NORM Stream Control Codes registry? - Is the NORM_CMD Message Sub-types registry open for further assignments? If so, what are the registration procedures and upper limits? Should "0" be marked "Reserved"? Thanks, Amanda IANA On Mon Apr 20 21:50:49 2009, adamson@itd.nrl.navy.mil wrote: > Hello, > > I have posted an updated version of the NORM draft which addresses > Spencer's GEN-ART comments and attempts to clarify the Security > Considerations per Dave Harrington's comments and the IANA > Consideration per comments from IANA. > > This update also makes the TFMCC RFC a Normative reference per > Magnus' request at the last RMT meeting. > > best regards, > From Sandra.Murphy@cobham.com Thu Apr 23 11: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 2D2793A72E1; Thu, 23 Apr 2009 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.315 X-Spam-Level: X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyd0Nbj+1y5f; Thu, 23 Apr 2009 11:18:05 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 923D828C133; Thu, 23 Apr 2009 11:17:57 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n3NIJD0i020873; Thu, 23 Apr 2009 13:19:14 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3NIJC4a025922; Thu, 23 Apr 2009 13:19:12 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 14:19:11 -0400 Date: Thu, 23 Apr 2009 14:19:11 -0400 (Eastern Daylight Time) From: Sandra Murphy To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org, tcpm-chairs@tools.ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 23 Apr 2009 18:19:11.0578 (UTC) FILETIME=[001F6BA0:01C9C440] Subject: [secdir] (no subject) 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, 23 Apr 2009 18:18:06 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I know that I am so late with this review as to be make this pro-forma only. I have no serious security considerations with this document. It presents a mitigation technique against a well-known vulnerability in TCP processing of RST segments, and the increased concern over that the impact of exploits of that vulnerability on Internet infrastructure. I do have document concerns, which I will mention in general and offer to specify more explicitly if deemed valid. This document is intended to update rfc793. That means that it should be very explicit about what text it is replacing and what the new text is. The dicussions of interactions between TCP peers are always difficult to phrase, as most terms are relative to viewpoint. The text in some places is tough to read - who is the sender, who the receiver, etc. The text also uses a lot of different terms to represent the same entity - remote peer, remote end sender, remote TCP endpoint, etc. The term "initial sequence number" has a special meaning in TCP and should be avoided. The text says that this mitigation SHOULD be used "in devices" which typically host apps that are most vulnerable and MIGHT be used elsewhere. Is there a suggestion that this would be under application control? Chosen by the OS vendor (or device vendor)? For those who are using Quagga routers (routing apps on top of intel boxes running some *ix), would this be a socket option? What's the vision here? I don't understand some parts of All TCP stacks MAY implement the following mitigation. TCP stacks which implement this mitigation MUST add an additional input check to any incoming segment. The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return." This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) gets through. Seems that SEG.ACK could fall between the SND.UNA and SND.UNA - MAX.SND.WND, in which case the new code accepts segments that the existing text says "it is ignored". I would read the 793 text as the *ACK* is ignored, which means the new text would accept (and act on) ACKs that are presently ignored. But looking at existing TCP code, it looks like people have interpreted "it is ignored" as the *segment* is ignored, i.e., dropped. In that case, this new text is accepting segments that in existing implementations would be dropped. Is that the intent? (Note: I could be easily wrong about the tcp_input code.) There are some language errors (missed words, punctuation, all that sort of boring stuff) that I could point out, or you could rely on the RFC editor to find. --Sandy From Sandra.Murphy@cobham.com Thu Apr 23 11:19:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AD33A6B42; Thu, 23 Apr 2009 11:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi4gLbtwZme2; Thu, 23 Apr 2009 11:19:35 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A221B3A69EC; Thu, 23 Apr 2009 11:19:35 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n3NIKrqM020902; Thu, 23 Apr 2009 13:20:53 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3NIKr9B025998; Thu, 23 Apr 2009 13:20:53 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 14:20:52 -0400 Date: Thu, 23 Apr 2009 14:20:52 -0400 (Eastern Daylight Time) From: Sandra Murphy To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org, tcpm-chairs@tools.ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 23 Apr 2009 18:20:52.0859 (UTC) FILETIME=[3C7DACB0:01C9C440] Subject: [secdir] review of draft-ietf-tcpm-tcpsecure-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 18:19:36 -0000 (sorry about the resend - thought an empty subject (sorry) might not get through). -_Sandy ---------- Forwarded message ---------- Date: Thu, 23 Apr 2009 14:19:11 -0400 (Eastern Daylight Time) From: Sandra Murphy To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org, tcpm-chairs@tools.ietf.org 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 know that I am so late with this review as to be make this pro-forma only. I have no serious security considerations with this document. It presents a mitigation technique against a well-known vulnerability in TCP processing of RST segments, and the increased concern over that the impact of exploits of that vulnerability on Internet infrastructure. I do have document concerns, which I will mention in general and offer to specify more explicitly if deemed valid. This document is intended to update rfc793. That means that it should be very explicit about what text it is replacing and what the new text is. The dicussions of interactions between TCP peers are always difficult to phrase, as most terms are relative to viewpoint. The text in some places is tough to read - who is the sender, who the receiver, etc. The text also uses a lot of different terms to represent the same entity - remote peer, remote end sender, remote TCP endpoint, etc. The term "initial sequence number" has a special meaning in TCP and should be avoided. The text says that this mitigation SHOULD be used "in devices" which typically host apps that are most vulnerable and MIGHT be used elsewhere. Is there a suggestion that this would be under application control? Chosen by the OS vendor (or device vendor)? For those who are using Quagga routers (routing apps on top of intel boxes running some *ix), would this be a socket option? What's the vision here? I don't understand some parts of All TCP stacks MAY implement the following mitigation. TCP stacks which implement this mitigation MUST add an additional input check to any incoming segment. The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return." This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) gets through. Seems that SEG.ACK could fall between the SND.UNA and SND.UNA - MAX.SND.WND, in which case the new code accepts segments that the existing text says "it is ignored". I would read the 793 text as the *ACK* is ignored, which means the new text would accept (and act on) ACKs that are presently ignored. But looking at existing TCP code, it looks like people have interpreted "it is ignored" as the *segment* is ignored, i.e., dropped. In that case, this new text is accepting segments that in existing implementations would be dropped. Is that the intent? (Note: I could be easily wrong about the tcp_input code.) There are some language errors (missed words, punctuation, all that sort of boring stuff) that I could point out, or you could rely on the RFC editor to find. --Sandy From weiler@watson.org Fri Apr 24 07:47: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 3E3463A701F for ; Fri, 24 Apr 2009 07:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 Blm5ITJ+NYwX for ; Fri, 24 Apr 2009 07:47:24 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 51E723A6BFA for ; Fri, 24 Apr 2009 07:46:40 -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 n3OElLhX006811 for ; Fri, 24 Apr 2009 10:47:22 -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 n3OElLmm006808 for ; Fri, 24 Apr 2009 10:47:21 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 24 Apr 2009 10:47:21 -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]); Fri, 24 Apr 2009 15:47:22 +0100 (BST) Subject: [secdir] Assignments for May 1st X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 14:47:25 -0000 Only two new assignments, to Tom Yu and Nico Williams. Larry Zhu is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-05-07 Phillip Hallam-Baker TR draft-ietf-radext-design-07 Stephen Kent TR draft-ietf-tsvwg-rsvp-proxy-proto-08 Angelos Keromytis T draft-ietf-isms-secshell-15 Julien Laganier T draft-ietf-isms-tmsm-16 Barry Leiba T draft-ietf-isms-transport-security-model-12 Vidya Narayanan T draft-ncook-urlauth-accessid-02 Magnus Nystrom T draft-ietf-mpls-p2mp-te-mib-09 Yaron Sheffer T draft-ietf-mipshop-rfc5268bis-01 Sam Weiler T draft-thomson-beep-async-02 Glen Zorn T draft-ietf-roll-indus-routing-reqs-05 Last calls and special requests: Derek Atkins draft-ietf-roll-building-routing-reqs-05 Rob Austein draft-p2pi-cooper-workshop-report-01 Pat Cain R draft-crocker-email-arch-12 Ran Canetti draft-ietf-avt-seed-srtp-11 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Steve Hanna draft-peterson-rai-rfc3427bis-01 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-17 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Vidya Narayanan draft-ietf-sip-saml-06 Eric Rescorla draft-ietf-isms-radius-usage-05 Joe Salowey draft-ietf-geopriv-lis-discovery-10 Hannes Tschofenig draft-ietf-pce-monitoring-04 Carl Wallace draft-ietf-ltru-4646bis-21 Sam Weiler draft-chown-v6ops-rogue-ra-03 Brian Weis draft-ietf-pce-p2mp-app-01 Nico Williams draft-ietf-v6ops-ra-guard-02 Nico Williams draft-ietf-dkim-overview-11 Tom Yu draft-ietf-dkim-rfc4871-errata-04 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 From yaronf@checkpoint.com Fri Apr 24 13:59:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5123A6A4F; Fri, 24 Apr 2009 13:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 TFWvPNJEFZJY; Fri, 24 Apr 2009 13:59:29 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CA8543A684A; Fri, 24 Apr 2009 13:59:28 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E094030C001; Sat, 25 Apr 2009 00:00:46 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9ABFC2CC002; Sat, 25 Apr 2009 00:00:46 +0300 (IDT) X-CheckPoint: {49F22484-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n3OL0jqO014778; Sat, 25 Apr 2009 00:00:46 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sat, 25 Apr 2009 00:00:45 +0300 From: Yaron Sheffer To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-mipshop-rfc5268bis@tools.ietf.org" , Vijay Devarapalli Date: Sat, 25 Apr 2009 00:00:43 +0300 Thread-Topic: Secdir review of draft-ietf-mipshop-rfc5268bis-01 Thread-Index: AcmHYp24ieqmVErzS/u49aQNwjkO7g9t5VOg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC523A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8E@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8E@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0075_01C9C538.E08CBCD0" MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-mipshop-rfc5268bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 20:59:30 -0000 ------=_NextPart_000_0075_01C9C538.E08CBCD0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG.=A0 = These comments were written primarily for the benefit of the security area directors.=A0 Document editors and WG chairs should treat these comments = just like any other last call comments. This document updates RFC 5268 (itself quite recent) by changing some = ICMP messages into more modern mobility header-carrying messages. I don't = believe this has any security implications. In fact the document includes very thorough Security Considerations, inherited from RFC 5268 and slightly adapted for the new message formats. One issue that came up before the original RFC was published is the protocol's liberality regarding (1) manual keying vs. key management protocols, and (2) the choice of authentication method. The second issue = was rectified by adding the text: "If IKEv2 is used [...] to ensure a = baseline interoperability, the implementations MUST support shared secrets for = mutual authentication." But this leaves the first issue open: manual keying = remains an option. So I propose to add to: "The security associations can be created by using either manual IPsec configuration or a dynamic key negotiation protocol such as IKEv2 [rfc4306]." This new text: "Following the recommendations of RFC 5406 (Sec. 3.3), the use of a key negotiation protocol is RECOMMENDED." Thanks, Yaron ------=_NextPart_000_0075_01C9C538.E08CBCD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNDIxMDA0M1owIwYJKoZIhvcNAQkEMRYEFMI8H+4WU1pp LVDo6K4ZlPj37l7XMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA baIW8zWpsDoaCF+8B0SonkkBYuMPI2MYcG91molU2oCeBMrfKowXb7ZkjOMsNLEvEof3xA1FcvS1 vxBe/84OWo9xS+zljSwY3ChbSSjndB2jMjBqLHb8Af+kRUO+5GebHNahSDwaoDfaUx68pRzm5b1C Ddt/ieFMC45az4WFZTU7GhpGM8g46fcjQRBruAvFI0G8Omsg7mgEoGqblFJA1m6BWJE5knuxoOOE xEq9LqTAE2fMAX4Tmvv+6tlLPfm7ihSyjt5XelU0jsnwjTrTQptCZ/ECdKYzTryu3f8v0Vl7aY4o yq8WT5A2z+GNyE6MrqT0AGOCCWcGMstGUfAtqQAAAAAAAA== ------=_NextPart_000_0075_01C9C538.E08CBCD0-- From tim.polk@nist.gov Mon Apr 27 06:16:20 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD353A69FA for ; Mon, 27 Apr 2009 06:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.772 X-Spam-Level: X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_05=-1.11, 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 0kFEb7H0d0c0 for ; Mon, 27 Apr 2009 06:16:19 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id A05F93A6929 for ; Mon, 27 Apr 2009 06:16:19 -0700 (PDT) Received: from [129.6.224.67] ([129.6.224.67]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n3RDHSB3023955; Mon, 27 Apr 2009 09:17:28 -0400 Message-Id: <7D473624-4457-4297-9E65-3A8DAAC0929E@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: Mon, 27 Apr 2009 09:17:27 -0400 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 Eronen" Subject: [secdir] request for security advisor for roll 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, 27 Apr 2009 13:16:20 -0000 Folks, We have received a request for a security advisor from the Routing Over Low power and Lossy networks (roll) working group. They feel that they have quite a lot of security issues that are going to come up, and they really need some help. Their main expertise is in routing protocols and in the infrastructure of the low-powered (mainly) wireless networks with which they work. The working group is beginning to get some focus on a security framework (not yet a WG I- D), and is just starting protocol work. The time is right for a security advisor to have a real impact. Pasi and I believe that they will need an involved security advisor - someone that will stay current on the mailing list, participate in any security relevant discussions, and assist with the security framework draft. We were wondering if anyone was already planning to participate in roll; assigning an advisor with significant personal interest is a recipe for success! If you hadn't considered it previously, you might want to review the charter to get a sense of the group: http://www.ietf.org/html.charters/roll-charter.html Anyway, please let us know if you are willing to act as security advisor for roll. Thanks, Tim & Pasi From secdir-bounces@mit.edu Mon Apr 27 08:34:43 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7763A6FA0 for ; Mon, 27 Apr 2009 08:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=-2.411, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxduTmm8O1Z4 for ; Mon, 27 Apr 2009 08:34:43 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5F7A43A6A91 for ; Mon, 27 Apr 2009 08:34:41 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n3RFa17Q024138 for ; Mon, 27 Apr 2009 11:36:01 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n3RFa0PS024135 for ; Mon, 27 Apr 2009 11:36:00 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n3RFZpMW007003 for ; Mon, 27 Apr 2009 11:35:51 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id D0EBA1650F2B for ; Mon, 27 Apr 2009 11:35:50 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id y7BNBrhMtzMmLrNM for ; Mon, 27 Apr 2009 11:35:50 -0400 (EDT) X-Barracuda-Envelope-From: new-work-bounces@ietf.org 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 661DA3A6F59; Mon, 27 Apr 2009 08:34:28 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA7B3A6F75 for ; Thu, 23 Apr 2009 12:21:20 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oFG1SryJkUx for ; Thu, 23 Apr 2009 12:21:20 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id D26AC3A6D7E for ; Thu, 23 Apr 2009 12:21:19 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1Lx4VH-00079K-TX for public-new-work-dist@listhub.w3.org; Thu, 23 Apr 2009 19:22:35 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Lx4VH-00078e-1K for public-new-work@listhub.w3.org; Thu, 23 Apr 2009 19:22:35 +0000 Received: from ssh.w3.org ([128.30.52.60] helo=homer.w3.org) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1Lx4V8-0007D1-C4; Thu, 23 Apr 2009 19:22:34 +0000 Received: from [IPv6:::1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8DB0E4EEBA; Thu, 23 Apr 2009 15:22:25 -0400 (EDT) Message-Id: <05CE7706-2C91-4014-AA72-4A4788073D34@w3.org> From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 14:22:25 -0500 X-Mailer: Apple Mail (2.930.3) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1Lx4V8-0007D1-C4 c4ec3ab5ac18974bebcd585c01b017dd X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/42 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Thu, 23 Apr 2009 19:22:35 +0000 X-Mailman-Approved-At: Mon, 27 Apr 2009 08:34:27 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 27 Apr 2009 12:50:36 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: Voice Browser Working Group (until 2009-05-21) 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, 27 Apr 2009 15:34:43 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Voice Browser Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Voice Browser Working Group: http://www.w3.org/2009/04/voice-charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2009-05-21 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Kaz Ashimura, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Voice/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From vijay@wichorus.com Mon Apr 27 14:15: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 629E828C1DB for ; Mon, 27 Apr 2009 14:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.345, 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 Z6HKlhMVouAo for ; Mon, 27 Apr 2009 14:15:30 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 64B5228C180 for ; Mon, 27 Apr 2009 14:15:30 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id kbfF1b0020S2fkCAAlGsBs; Mon, 27 Apr 2009 21:16:52 +0000 Received: from [10.166.254.170] ([38.104.122.206]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id klGc1b00P4THdvq8VlGfTk; Mon, 27 Apr 2009 21:16:50 +0000 Message-ID: <49F620B1.20309@wichorus.com> Date: Mon, 27 Apr 2009 14:16:33 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Yaron Sheffer References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC523A@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC523A@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 27 Apr 2009 23:03:03 -0700 Cc: draft-ietf-mipshop-rfc5268bis@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-mipshop-rfc5268bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:15:31 -0000 Hi Yaron, Yaron Sheffer wrote: > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This document updates RFC 5268 (itself quite recent) by changing some ICMP > messages into more modern mobility header-carrying messages. I don't believe > this has any security implications. In fact the document includes very > thorough Security Considerations, inherited from RFC 5268 and slightly > adapted for the new message formats. > > One issue that came up before the original RFC was published is the > protocol's liberality regarding (1) manual keying vs. key management > protocols, and (2) the choice of authentication method. The second issue was > rectified by adding the text: "If IKEv2 is used [...] to ensure a baseline > interoperability, the implementations MUST support shared secrets for mutual > authentication." But this leaves the first issue open: manual keying remains > an option. So I propose to add to: > > "The security associations can be created by using either manual IPsec > configuration or a dynamic key negotiation protocol such as IKEv2 > [rfc4306]." > > This new text: > > "Following the recommendations of RFC 5406 (Sec. 3.3), the use of a key > negotiation protocol is RECOMMENDED." I don't see this as being applicable to security associations setup between two access routers in the same domain. Note that the access routers need just one security association for protecting the HI and HACK messages for all the mobile nodes. Recommending the use of a key negotiation protocol in this case would be over specification, IMO. Vijay From gorry@erg.abdn.ac.uk Tue Apr 28 00:22:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EAA3A6966; Tue, 28 Apr 2009 00:22:19 -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 5I2KGS8dlgNp; Tue, 28 Apr 2009 00:22:18 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 469783A681A; Tue, 28 Apr 2009 00:22:17 -0700 (PDT) Received: from Gorry-Fairhursts-Laptop-6.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n3S7NJc3026530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2009 08:23:20 +0100 (BST) Message-ID: <49F6AEE7.5070007@erg.abdn.ac.uk> Date: Tue, 28 Apr 2009 08:23:19 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Chris Newman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Tue, 28 Apr 2009 00:36:34 -0700 Cc: dccp-chairs@tools.ietf.org, draft-ietf-dccp-simul-open@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dccp-simul-open-07 - response X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:22:19 -0000 Thanks Chris for your comments, these are really helpful. I've updated my copy of the draft for all of these, except for one, which seems to not be valid - please see below, I'd love to understand whether I have captured this particular comment correctly. Best wishes, Gorry Fairhurst Chris Newman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Overall: This proposal provides a reasonable architecture for the > function the WG desires. I support advancement after some of the issues > below are addressed. > > Section 2.2.1: > > The reference to draft-ietf-dccp-serv-codes-08 appears to be normative > as a "MUST" requirement is placed on a field whose meaning depends on > that specification. > Done. > Section 2.2.2: > > The "LISTEN1" state is mentioned in the pseudocode, but not the state > diagram or figure label. I suspect it should read "LISTEN'" (to match > the figure label) or the two should be declared equivalent. > Corrected, and all have been changed to LISTEN1 - it was not good having a symbol that could essily be overlooked. > Security Considerations > > The stated threats seem reasonably well described. > > One potentially significant threat I did not see discussed: > > This creates a new way to set up a DCCP connection from a client to a > server triggered via a SIP/SDP connection setup. If the SIP/SDP > connection is unencrypted, an eavesdropper could get the client IP and > Port for the to-be-established DCCP connection and generate a > DCCP-Listen to the client using its own server-IP/port. So if the > client is waiting for a DCCP-Listen from an arbitrary server-IP/port and > responds to it, this allows an attacker to redirect the connection > without IP spoofing. If, however, the client is told the server-IP and > server-port for DCCP through SDP and will only accept a DCCP-Listen from > that endpoint, the new threat would be mitigated (leaving the existing > DCCP IP spoofing threat). > I take this to suggest: "The method creates a new way for a client to set up a DCCP connection to a server using out-of-band data, carried on a signaling connection. If the signaling connection is not encrypted, an eavesdropper could see the client IP address and the port for the to-be-established DCCP connection and generate a DCCP-Listen packet towards the client using its own server-IP address and port. This could elicit a response from a client that is waiting for a DCCP-Listen packet from an arbitrary server-IP/port. This would allow an attacker to redirect the connection without IP spoofing. If, however, the client is told the server-IP address and the server-port for the DCCP connection through the signaling connection and will only accept a DCCP-Listen from that endpoint, the new threat would be mitigated (leaving the existing DCCP IP spoofing threat)." - It is good to think of new threats, but I am not sure this one exists. The second para as I write this, assumes that the client actually takes action on receipt of a DCCP-Listen packet. I think this only happens in the case of a triggered retransmission of an already sent request. I therefore do not understand the new threat, is it possible that this actually should read: "The method creates a new way for a client to set up a DCCP connection to a server using out-of-band data, carried on a signaling connection. If the signaling connection is not encrypted, an eavesdropper could see the client IP address and the port for the to-be-established DCCP connection and generate a DCCP-Listen packet towards the client using its own server-IP address and port. However, a client will only respond to a received DCCP-Listen packet if the server-IP address and port match an existing DCCP connection that is in the REQUEST state (section 2.3.2). The method therefore cannot be used to redirect the connection to a different IP address." > One minor issue I noticed was not mentioned directly: > > The DCCP base specification Init Cookie option lets a DCCP server avoid > having to hold any state until the three-way connection setup handshake > has completed. This specification enables an out-of-band mechanism that > forces the server to hold state for a connection that has not yet been > established. This is a change in the security profile of DCCP, although > the impact is minimal and depends on the security features of the > out-of-band > mechanism (SIP SDP is one such mechanism that provides sufficient security > features). > Added. > Nit: > > The statement: > "A DCCP server SHOULD therefore by default permit generation of > DCCP-Listen packets." > seems inappropriate in a security considerations section as the > recommendation is really unrelated to security. Perhaps that > recommendation > should be in the normative protocol description. > Changed in the way you suggested. > - Chris > > From yaronf@checkpoint.com Tue Apr 28 00:41: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 C59463A680A; Tue, 28 Apr 2009 00:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 a71x50jhioX5; Tue, 28 Apr 2009 00:41:35 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1DB183A697F; Tue, 28 Apr 2009 00:41:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7A0B930C001; Tue, 28 Apr 2009 10:42:55 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 26E832CC003; Tue, 28 Apr 2009 10:42:55 +0300 (IDT) X-CheckPoint: {49F6AF45-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n3S7gsqO008185; Tue, 28 Apr 2009 10:42:54 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 28 Apr 2009 10:42:54 +0300 From: Yaron Sheffer To: Vijay Devarapalli Date: Tue, 28 Apr 2009 10:42:51 +0300 Thread-Topic: Secdir review of draft-ietf-mipshop-rfc5268bis-01 Thread-Index: AcnHfX4isqIXn9i3RIOQd2HVTiilfwAVYcKA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55D6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC523A@il-ex01.ad.checkpoint.com> <49F620B1.20309@wichorus.com> In-Reply-To: <49F620B1.20309@wichorus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01C9C7EE.146929F0" MIME-Version: 1.0 Cc: "draft-ietf-mipshop-rfc5268bis@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mipshop-rfc5268bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 07:41:36 -0000 ------=_NextPart_000_0008_01C9C7EE.146929F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vijay, Actually you are proving my point :-) The cost of setting up a security association (e.g. an IKE exchange) will be amortized over many HI/HACK uses. And automatic key management is a BCP for some very good reasons, including: - Limiting the lifetime of keys. - Facilitating algorithm agility. - Enabling the use of shorter shared secrets and/or certificates. - Mitigating the harmful effect of using "widely shared" secrets (where all group members see the same shared secret). - Improving the entropy of encryption keys compared to human generated "random" values. I'm sure there are a few other reasons I've forgotten. Thanks, Yaron > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Tuesday, April 28, 2009 0:17 > To: Yaron Sheffer > Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-mipshop- > rfc5268bis@tools.ietf.org > Subject: Re: Secdir review of draft-ietf-mipshop-rfc5268bis-01 > > Hi Yaron, > > Yaron Sheffer wrote: > > I have reviewed this document as part of the security directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. Document editors and WG chairs should treat these comments > just > > like any other last call comments. > > > > This document updates RFC 5268 (itself quite recent) by changing some > ICMP > > messages into more modern mobility header-carrying messages. I don't > believe > > this has any security implications. In fact the document includes very > > thorough Security Considerations, inherited from RFC 5268 and slightly > > adapted for the new message formats. > > > > One issue that came up before the original RFC was published is the > > protocol's liberality regarding (1) manual keying vs. key management > > protocols, and (2) the choice of authentication method. The second issue > was > > rectified by adding the text: "If IKEv2 is used [...] to ensure a > baseline > > interoperability, the implementations MUST support shared secrets for > mutual > > authentication." But this leaves the first issue open: manual keying > remains > > an option. So I propose to add to: > > > > "The security associations can be created by using either manual IPsec > > configuration or a dynamic key negotiation protocol such as IKEv2 > > [rfc4306]." > > > > This new text: > > > > "Following the recommendations of RFC 5406 (Sec. 3.3), the use of a key > > negotiation protocol is RECOMMENDED." > > I don't see this as being applicable to security associations setup > between two access routers in the same domain. Note that the access > routers need just one security association for protecting the HI and > HACK messages for all the mobile nodes. Recommending the use of a key > negotiation protocol in this case would be over specification, IMO. > > Vijay > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0008_01C9C7EE.146929F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyODA3NDI1MVowIwYJKoZIhvcNAQkEMRYEFF4dZHcZQgk2 y1jDfvM895olO0KqMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA KskSW1yzduf+8MctgxUY1G7ccYNXvgeYx7YhH3JiXkK4wSqbL44F/hg2pGcbKUSPUcjqt+Y+Yl1E Kti/CLzQQSKOFANTKdQ0h7kI6tMRkGwAhPFMByORJrFHQPhobRbuZn1sFn7oK/pVEz+oFPmRZNdt y3evrJQpPl9J13zmajThk1d94O45KNCFQnhUXxQ/5CgU4EJuCJ/3ISP3hNl0HX63tSonzGMYy0ot ft+KbeVfPfGiLJw25Swe5mmYUr+wLEZrYomSifntk017HKpoSkXAAGxUYaaG3YNzjNvzddgQ2aWM awNteyf5y6zKZppaB5sN6HevivYPqXyDtuvy9gAAAAAAAA== ------=_NextPart_000_0008_01C9C7EE.146929F0-- From jari.arkko@piuha.net Tue Apr 28 01:21:10 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EA63A6B22; Tue, 28 Apr 2009 01:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psJaBcY-7s2o; Tue, 28 Apr 2009 01:21:09 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 08D033A6B9C; Tue, 28 Apr 2009 01:20:41 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id B9B7219871D; Tue, 28 Apr 2009 11:22:01 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 793321986E2; Tue, 28 Apr 2009 11:22:01 +0300 (EEST) Message-ID: <49F6BC91.2050404@piuha.net> Date: Tue, 28 Apr 2009 11:21:37 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Yaron Sheffer , Vijay Devarapalli References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66FC8E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC523A@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC523A@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "draft-ietf-mipshop-rfc5268bis@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mipshop-rfc5268bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:21:10 -0000 Yaron, Vijay, First, thank you for the review! I wanted to highlight a historical point, however. I'm not necessarily opposed to the new text (in fact, it seems quite reasonable), but I'll note that RFC 5268 is just 10 months old, and we had all these discussions back then, and the RFC was the result. The purpose of the bis is to change one aspect (ICMP to MH) of the RFC. Jari From vijay@wichorus.com Tue Apr 28 08:49:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E6428C279; Tue, 28 Apr 2009 08:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZcckeJoW52V; Tue, 28 Apr 2009 08:49:17 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 3165228C275; Tue, 28 Apr 2009 08:49:17 -0700 (PDT) Received: from 67.161.28.136 ([67.161.28.136]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Tue, 28 Apr 2009 15:50:35 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 28 Apr 2009 08:50:34 -0700 From: Vijay Devarapalli To: Yaron Sheffer Message-ID: Thread-Topic: Secdir review of draft-ietf-mipshop-rfc5268bis-01 Thread-Index: AcnHfX4isqIXn9i3RIOQd2HVTiilfwAVYcKAABGC7qw= In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55D6@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "draft-ietf-mipshop-rfc5268bis@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mipshop-rfc5268bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 15:49:21 -0000 Hi Yaron, On 4/28/09 12:42 AM, "Yaron Sheffer" wrote: > Hi Vijay, > > Actually you are proving my point :-) No it doesn't. > The cost of setting up a security > association (e.g. an IKE exchange) will be amortized over many HI/HACK uses. The cost of implementing and configuring a key negotiation protocol is not worth it when we are looking at just one IPsec SA for all FMIPv6 related signaling between the access routers. So I don't think having some text that says "a key negotiation protocols is RECOMMENDED" is justified. If deployments don't want to deal with manual IPsec keying (because it is a hassle), they will start using IKEv2 automatically. > And automatic key management is a BCP for some very good reasons, including: > - Limiting the lifetime of keys. > - Facilitating algorithm agility. > - Enabling the use of shorter shared secrets and/or certificates. > - Mitigating the harmful effect of using "widely shared" secrets (where all > group members see the same shared secret). > - Improving the entropy of encryption keys compared to human generated > "random" values. > > I'm sure there are a few other reasons I've forgotten. Almost all of these are not a concern when we talk about access routers in an FMIPv6 domain, IMO. Vijay > > Thanks, > Yaron > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay@wichorus.com] >> Sent: Tuesday, April 28, 2009 0:17 >> To: Yaron Sheffer >> Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-mipshop- >> rfc5268bis@tools.ietf.org >> Subject: Re: Secdir review of draft-ietf-mipshop-rfc5268bis-01 >> >> Hi Yaron, >> >> Yaron Sheffer wrote: >>> I have reviewed this document as part of the security directorate's >> ongoing >>> effort to review all IETF documents being processed by the IESG. These >>> comments were written primarily for the benefit of the security area >>> directors. Document editors and WG chairs should treat these comments >> just >>> like any other last call comments. >>> >>> This document updates RFC 5268 (itself quite recent) by changing some >> ICMP >>> messages into more modern mobility header-carrying messages. I don't >> believe >>> this has any security implications. In fact the document includes very >>> thorough Security Considerations, inherited from RFC 5268 and slightly >>> adapted for the new message formats. >>> >>> One issue that came up before the original RFC was published is the >>> protocol's liberality regarding (1) manual keying vs. key management >>> protocols, and (2) the choice of authentication method. The second issue >> was >>> rectified by adding the text: "If IKEv2 is used [...] to ensure a >> baseline >>> interoperability, the implementations MUST support shared secrets for >> mutual >>> authentication." But this leaves the first issue open: manual keying >> remains >>> an option. So I propose to add to: >>> >>> "The security associations can be created by using either manual IPsec >>> configuration or a dynamic key negotiation protocol such as IKEv2 >>> [rfc4306]." >>> >>> This new text: >>> >>> "Following the recommendations of RFC 5406 (Sec. 3.3), the use of a key >>> negotiation protocol is RECOMMENDED." >> >> I don't see this as being applicable to security associations setup >> between two access routers in the same domain. Note that the access >> routers need just one security association for protecting the HI and >> HACK messages for all the mobile nodes. Recommending the use of a key >> negotiation protocol in this case would be over specification, IMO. >> >> Vijay >> >> Scanned by Check Point Total Security Gateway. From secdir-bounces@mit.edu Tue Apr 28 11:07: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 2D17028C240 for ; Tue, 28 Apr 2009 11:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qML6DSmPGbb for ; Tue, 28 Apr 2009 11:07:10 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 6DA0728C250 for ; Tue, 28 Apr 2009 11:07:01 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n3SI8Mli025938 for ; Tue, 28 Apr 2009 14:08:22 -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 n3SI8LDe025932 for ; Tue, 28 Apr 2009 14:08:21 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n3SI8EGK016206 for ; Tue, 28 Apr 2009 14:08:14 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id E6CD416AFFF1 for ; Tue, 28 Apr 2009 14:08:13 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id wgCSCqHcIgPvDqsI for ; Tue, 28 Apr 2009 14:08:13 -0400 (EDT) X-Barracuda-Envelope-From: new-work-bounces@ietf.org 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 C39F028C29D; Tue, 28 Apr 2009 11:06:36 -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 E54A23A7123; Tue, 28 Apr 2009 11:06:35 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090428180635.E54A23A7123@core3.amsl.com> Date: Tue, 28 Apr 2009 11:06:35 -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: Tue, 28 Apr 2009 11:08:08 -0700 Subject: [secdir] [New-work] WG Review: Open Authentication Protocol (oauth) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:07:12 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 5, 2009. Open Authentication Protocol (oauth) ------------------------------------- Last Modified: 2009-04-06 Current Status: Proposed Working Group Chair(s): TBD Applications Area Director(s): Alexey Melnikov Lisa Dusseault Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources ontheir behalf. * A mechanism for signing HTTP requests with the token- secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to profile OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/draf ts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preferenc e/1.0/drafts/2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts /1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora- farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard Nov 2009 Start Working Group Last Call on the 2-legged HTTP authentication mechanism document Nov 2009 Prepare milestone update to start new work within the scope of the charter Dec 2009 Submit 2-legged HTTP authentication mechanism document to the IESG for consideration as a Proposed Standard _______________________________________________ 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 mdalal@cisco.com Tue Apr 28 11:29:46 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639CA3A6CE5; Tue, 28 Apr 2009 11:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr0XP-qO1Yio; Tue, 28 Apr 2009 11:29:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 72E9D3A7115; Tue, 28 Apr 2009 11:29:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,261,1238976000"; d="scan'208";a="294551574" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2009 18:31:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3SIV4q0000463; Tue, 28 Apr 2009 11:31:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3SIV4i8010141; Tue, 28 Apr 2009 18:31:04 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 11:31:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 11:31:01 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D0749EF90@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-tcpm-tcpsecure-11.txt Thread-Index: AcnEQEPuuq/aWQs7S2CcKQhXnK9eswD6+nhA References: From: "Mitesh Dalal (mdalal)" To: "Sandra Murphy" , , , , X-OriginalArrivalTime: 28 Apr 2009 18:31:03.0947 (UTC) FILETIME=[7CCB0DB0:01C9C82F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4792; t=1240943464; x=1241807464; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20(mdalal)=22=20 |Subject:=20RE=3A=20review=20of=20draft-ietf-tcpm-tcpsecure -11.txt |Sender:=20; bh=TFFy9p85n3XO5XbOTBJhtXhGHZ5Co2HdSjxX1+MxjQM=; b=kEtuZ973PQiW2xDqTKJm1/A7ZMdxa4bRblJBiyMjSo1oNsvXu6H5etCh9G 3ZzmGaiMZyIpK5Te3w0ilG/nbB8eL8tgykWIDwr6uKC7vOVYDUZUY22Apy4G zbujc1jgc8; Authentication-Results: sj-dkim-3; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Mailman-Approved-At: Tue, 28 Apr 2009 11:32:40 -0700 Cc: "Anantha Ramaiah \(ananth\)" Subject: Re: [secdir] review of draft-ietf-tcpm-tcpsecure-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:29:46 -0000 =20 Hi Sandra, Thank you for taking time to review the draft. Please see inline. ---------- Forwarded message ---------- Date: Thu, 23 Apr 2009 14:19:11 -0400 (Eastern Daylight Time) From: Sandra Murphy To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org, tcpm-chairs@tools.ietf.org 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 know that I am so late with this review as to be make this pro-forma only. I have no serious security considerations with this document. It presents a mitigation technique against a well-known vulnerability in TCP processing of RST segments, and the increased concern over that the impact of exploits of that vulnerability on Internet infrastructure. I do have document concerns, which I will mention in general and offer to specify more explicitly if deemed valid. This document is intended to update rfc793. That means that it should be very explicit about what text it is replacing and what the new text is. Mitesh: The mitigation section of the discussed attack does highlight the processing "rules" that are being modified. If you have explicit suggestions to make it better, we welcome it. The dicussions of interactions between TCP peers are always difficult to phrase, as most terms are relative to viewpoint. The text in some places is tough to read - who is the sender, who the receiver, etc. The text also uses a lot of different terms to represent the same entity - remote peer, remote end sender, remote TCP endpoint, etc. Mitesh: We may consider simplifying these terms to remote peer if that helps. Point noted. The term "initial sequence number" has a special meaning in TCP and should be avoided. Mitesh: Can you please elaborate the context?=20 The text says that this mitigation SHOULD be used "in devices" which typically host apps that are most vulnerable and MIGHT be used elsewhere. Is there a suggestion that this would be under application control? Chosen by the OS vendor (or device vendor)? For those who are using Quagga routers (routing apps on top of intel boxes running some *ix), would this be a socket option?=20 What's the vision here? Mitesh: This implementation detail is outside the scope of the document. Although, implementors may make it a compile time option, application dependent control (as you hint with socket option) or may make it mandatory for the stack. I don't understand some parts of All TCP stacks MAY implement the following mitigation. TCP stacks which implement this mitigation MUST add an additional input check to any incoming segment. The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <=3D SEG.ACK <=3D SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return." This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) = <=3D SEG.ACK <=3D SND.NXT) gets through. Seems that SEG.ACK could fall between the SND.UNA and SND.UNA - MAX.SND.WND, in which case the new code accepts segments that the existing text says "it is ignored". I would read the 793 text as the *ACK* is ignored, which means the new text would accept (and act on) ACKs that are presently ignored. But looking at existing TCP code, it looks like people have interpreted "it is ignored" as the *segment* is ignored, i.e., dropped. In that case, this new text is accepting segments that in existing implementations would be dropped.=20 Is that the intent? (Note: I could be easily wrong about the tcp_input code.) Mitesh: I will have to dig and find out, my recollection is hazy but I think this was raised earlier and may have been discussed. There are some language errors (missed words, punctuation, all that sort of boring stuff) that I could point out, or you could rely on the RFC editor to find. Mitesh: Do send us stuff annotated and we can "refine" the document as we move to the finish line. Thanks for your time and input! Mitesh From Pasi.Eronen@nokia.com Wed Apr 29 23:03: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 742F73A6F38; Wed, 29 Apr 2009 23:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 XgzS8Aa5155J; Wed, 29 Apr 2009 23:03:48 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AAE9D3A6DE7; Wed, 29 Apr 2009 23:03:47 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3U64cYm002826; Thu, 30 Apr 2009 09:05:03 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 09:05:01 +0300 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); Thu, 30 Apr 2009 09:04:56 +0300 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 30 Apr 2009 08:04:56 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 30 Apr 2009 08:04:50 +0200 From: To: , Date: Thu, 30 Apr 2009 08:04:48 +0200 Thread-Topic: Pasi's AD Notes for April 2009 Thread-Index: AcnJWZGT/WyCswKLQYqAEVzqNZlasA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F24D4D82@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Apr 2009 06:04:56.0860 (UTC) FILETIME=[965B2DC0:01C9C959] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for April 2009 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:03:49 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - Edited and posted SAAG minutes - We have received a liaison statement from ITU-T SG 17; I and Tim=20 are preparing a response (sent to SAAG list for comments) - Deployed some new code for datatracker.ietf.org, more=20 coming soon... - Some CSS etc. work for the IETF website redesign - IESG will meet face-to-face on May 11-12 - (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 - draft-ietf-dkim-rfc4871-errata: in IETF Last Call (ends 2009-05-08) - draft-ietf-dkim-overview: in IETF Last Call (ends 2009-05-08) - draft-ietf-dkim-ssp: waiting for the WG to converge on text for Section 2.7. - Waiting for WG to send list of RFC errata IDs (the non-controversial ones, not related to d=3D/i=3D) the WG agrees on. EMU - Quiet month IPSECME - Virtual interim meeting scheduled for 2009-05-05 - Some cleaning/fixing of IANA registries for IPsec/IKEv1/IKEv2 - Looking into fixing the IANA registrations of RFC 4543; I have the token to send email to WG list. - (not wearing hats) draft-ietf-ipsecme-ikev2-ipv6-config: I promised to update the draft (clean it, address TBDs) so it would be ready=20 for WGLC (as Experimental) if this path is chosen by WG. ISMS - draft-ietf-isms-secshell, draft-ietf-isms-tmsm, and draft-ietf-isms-transport-security-model, draft-ietf-isms-radius-usage:=20 went through IETF Last Call, on the agenda of the 2009-05-07 IESG=20 telechat. - Discussions about rechartering; waiting for concrete proposal =20 from David/Jeff/Wes/etc. KEYPROV - I need to catch up with the latest emails... PKIX - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for 3281update draft (not a normative reference, but authors preferred it this way). SASL - Lot of emails about SCRAM/GS2 SYSLOG - draft-ietf-syslog-sign: waiting for the authors to propose text for the remaining issue [since 2009-04-06] TLS - Hoping to get Publication Request for draft-ietf-tls-extractor soon... - (not WG items) Two IPR disclosures related to draft-badra-hajjeh-mtls and draft-badra-tls-multiplexing - (not WG item yet) Apparently some folks are interested in getting draft-rescorla-tls-extended-random published (and an implementation exists). I was hoping to see a presentation in San Francisco, but that didn't happen -- perhaps something happens on the mailing list. - (not WG item yet) I need to talk with the chairs and Michael about what to do with Mobi-D OTHER DOCUMENTS - draft-lebovitz-kmart-roadmap: I need to read this and=20 comment/contribute. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. DISCUSSES (active -- something happened within last month) - draft-atlas-icmp-unnumbered: waiting for authors to reply to my comments [since 2009-04-21] - draft-ietf-dime-mip6-split: text ok, waiting for Dan to re-do the IETF last call [since 2009-04-28] - draft-ietf-ipfix-file: waiting for authors to reply to my comments [since 2009-04-23] - draft-ietf-l2tpext-tdm: waiting for Ralph to re-do the IETF=20 last call [since 2009-04-21] - draft-ietf-lemonade-streaming: I think we have rough agreement on the changes; waiting for the authors to submit a revised ID=20 [since 2009-04-28] - draft-ietf-ntp-ntpv4-proto: waiting for authors to reply to my email or submit a revised ID [since 2009-04-16] - draft-ietf-radext-management-authorization: changes agreed, waiting for authors to submit a revised ID [since 2009-04-20] - draft-ietf-softwire-security-requirements: text agreed, waiting for authors to submit a revised ID [since 2009-04-27] - draft-igoe-secsh-aes-gcm: waiting for Tim to conclude what changes are needed to the draft [latest email 2009-04-21] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] - draft-ietf-ospf-lls: version -07 did not address my comments; waiting for a revised ID or RFC Editor Notes [since 2009-03-19] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cain-post-inch-phishingextns: authors have promised a new version some time in February [since 2009-01-29] - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] (but talked briefly with Radia at IETF74) - 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 kent@bbn.com Thu Apr 30 09:27:05 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CD03A6900 for ; Thu, 30 Apr 2009 09:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 BVcBtk2P03o7 for ; Thu, 30 Apr 2009 09:27:04 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8905F3A67F7 for ; Thu, 30 Apr 2009 09:27:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.37]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LzZ7a-0001Oc-Fm; Thu, 30 Apr 2009 12:28:27 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 30 Apr 2009 12:28:24 -0400 To: secdir@core3.amsl.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [secdir] re-review of draft-ietf-tsvwg-rsvp-proxy-proto 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, 30 Apr 2009 16:27:05 -0000 I reviewed the previous version of this document in December. The authors have made changes to address all of the editorial comments I made then. They also responded to the two major technical comments I made. I see no problems with this version of the document. Steve From trammell@tik.ee.ethz.ch Thu Apr 30 09:26: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 EC6713A6E95 for ; Thu, 30 Apr 2009 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 wQpaE81yGKXV for ; Thu, 30 Apr 2009 09:26:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id A89B13A6A91 for ; Thu, 30 Apr 2009 09:26:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5C52FD93DA; Thu, 30 Apr 2009 18:27:57 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cKUg+IUrIpTe; Thu, 30 Apr 2009 18:27:57 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id EE379D93D5; Thu, 30 Apr 2009 18:27:56 +0200 (MEST) Message-Id: <5884D14D-36C2-42A0-87FC-0836B63FE61C@tik.ee.ethz.ch> From: Brian Trammell To: Sam Hartman 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 v930.3) Date: Thu, 30 Apr 2009 18:27:56 +0200 References: <7C549E55-5EBF-4C50-AC45-0B85C2978C81@tik.ee.ethz.ch> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Thu, 30 Apr 2009 09:45:04 -0700 Cc: draft-ietf-ipfix-file@tools.ietf.org, ipfix-chairs@tools.ietf.org, Dan Romascanu , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-ipfix-file-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:26:39 -0000 Sam, Thanks for the comments (and apologies for my delay in replying). I understand the issues now; my comments are inline; in short, I think we can address the integrity protection issue satisfactorily in the following revision of draft... On Apr 22, 2009, at 2:25 PM, Sam Hartman wrote: >>>>>> "Brian" == Brian Trammell writes: > > Brian> Sam, Thanks for your comprehensive review and comments; my >>> The handling of authentication seems problematic. The text >>> points out that TLS can be used to provide transient >>> authentication from the exporter to collector. Discussion of >>> the lack of data origin authentication (authentication that can >>> be verified after the fact by a third party) needs to be added >>> to the security considerations section; this seems important >>> for the 7.3.4 use case. I'm not asking for digital signatures >>> to be added at the exporter, simply for discussion of the >>> consequences on having hop-by-hop authentication. >>> >>> However there is a more serious lack on the authentication >>> front. There is no way for a file writer to describe the >>> authenticated identity of the exporter. I'd expect 8.1.3 and >>> 8.1.4 to include attributes to describe the TLS identity of the >>> exporter. >>> > > Both of these, I think, could be addressed by the specification of > Brian> interoperable encryption, as above. > > No, not really. > Using CMS for encryption and integrity will protect a file once > created. > I had two issues. > > The first is that the data is not integrity protected end-to-end. The > exporter may transport to the collector over TLS. Let's assume that > the collector is digitally signing the file. There's a break in the > cryptographic protection at the collector: it could modify the data > however it likes. When I read the file years later, I have to trust > the collector and the exporter, not just the exporter. Indeed. In the general case, this is also an issue with IPFIX Mediators (which should probably at least be mentioned in the Security Considerations sections of the relevant drafts): IPFIX provides no provision for other than EP-to-CP transport protection. > If you considered that a problem and wanted to fix it, you'd need to > add digital signatures at the exporter. Given my understanding of > ipfix, that would seem both expensive and unnecessary. So, instead, > you should document the issue and explain that the file reader needs > to trust the file writer not to modify the contents. Another way we could address this is by recommending that, when a CP assertion is not sufficient (see below), the deployment be arranged such that the Metering Process writes and protects files directly. The model here is a "sealed box" -- all the metering, storage, and assertion on one device (which presumably only the investigators would have access to)... of course, then you have to trust that the Metering Process is faithfully recording flows from the packets it's seeing, but this problem is way out of scope. > The second issue is that the collector has no way to tell the file > reader the identity of the exporter. If I have a TLS connection with > badguy@evil.example.com, I might trust the data less than data from > sensor-53@east.example.net.The identity of the collector could be > captured in a CMS signature on the file. > However nothing captures the identity of the exporter--not even as > an assertion from the collector. Ahhhh... okay... I do think the assertion from the collector is the way to go here, as you are correct, adding signatures at the message level would be difficult. I presume there is some not too surprising way to do this using CMS... >>> The template in 8.1.1 uses md5. There's insufficient >>> documentation for me to tell whether the cryptographic >>> properties, particularly collision resistance, are important to >>> this use of md5. My guess is that they are and thus md5 may >>> not be the best hash to use. Is a per-message checksum really >>> the right granularity? >>> > > It's a simple checksum, meant primarily for error detection during > Brian> long term storage when files are stored on a medium or > Brian> within an encapsulation (i.e. filesystem) that does not > Brian> provide adequate detection of errors (think giant, > Brian> uncompressed files streamed directly to tape). > > OK. > md5 seems fine for that. Thanks for the clarification. I think we might want to make that clarification in the text, and perhaps point out the advisability of more error-resilient encapsulation. Thanks again, Brian