From secdir-bounces@ietf.org Fri Sep 26 14:27:52 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D953A6984; Fri, 26 Sep 2008 14:27:52 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02813A68FE for ; Fri, 26 Sep 2008 14:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnJBJdxwWo0N for ; Fri, 26 Sep 2008 14:27:51 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 0A2163A6984 for ; Fri, 26 Sep 2008 14:27:50 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id m8QLS2Kv026563 for ; Fri, 26 Sep 2008 17:28:02 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id m8QLS2Mj026560 for ; Fri, 26 Sep 2008 17:28:02 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 26 Sep 2008 17:28:02 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Fri, 26 Sep 2008 17:28:02 -0400 (EDT) Subject: [secdir] testing X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Sep 26 14:33:50 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D21B3A6896; Fri, 26 Sep 2008 14:33:50 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50CB3A68B2 for ; Fri, 26 Sep 2008 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQMlbaD1u9TG for ; Fri, 26 Sep 2008 14:32:23 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id AF6E33A6896 for ; Fri, 26 Sep 2008 14:32:22 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Fri, 26 Sep 2008 14:32:34 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 m8QLWUuM005607 for ; Fri, 26 Sep 2008 16:32:30 -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 m8QLWVjE006099 for ; Fri, 26 Sep 2008 16:32:31 -0500 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Sep 2008 17:32:30 -0400 Date: Fri, 26 Sep 2008 17:32:28 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@mint To: secdir@ietf.org Message-ID: MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2008 21:32:30.0782 (UTC) FILETIME=[6173BDE0:01C9201F] Subject: [secdir] testing4 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Fri Sep 26 14:38:17 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506133A6932; Fri, 26 Sep 2008 14:38:17 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50DCF3A6A7C for ; Fri, 26 Sep 2008 14:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxn9TxrBz2if for ; Fri, 26 Sep 2008 14:28:10 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A2DCF3A68AA for ; Fri, 26 Sep 2008 14:28:10 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.2) with ESMTP id m8QLSKrj026622 for ; Fri, 26 Sep 2008 17:28:20 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.2/Submit) with ESMTP id m8QLSKLc026619 for ; Fri, 26 Sep 2008 17:28:20 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 26 Sep 2008 17:28:20 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (fledge.watson.org [127.0.0.1]); Fri, 26 Sep 2008 17:28:20 -0400 (EDT) Subject: [secdir] testing2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Sep 29 09:55:09 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EB03A6A08; Mon, 29 Sep 2008 09:55:09 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229013A68B2 for ; Fri, 26 Sep 2008 14:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQv3LIZrbyfb for ; Fri, 26 Sep 2008 14:31:54 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id EC3873A6896 for ; Fri, 26 Sep 2008 14:31:53 -0700 (PDT) Received: from source ([157.185.61.2]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 26 Sep 2008 14:32:04 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 m8QLW3Rc005595 for ; Fri, 26 Sep 2008 16:32:03 -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 m8QLW4s2006081 for ; Fri, 26 Sep 2008 16:32:04 -0500 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Sep 2008 17:32:03 -0400 Date: Fri, 26 Sep 2008 17:32:01 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@mint To: secdir@ietf.org Message-ID: MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2008 21:32:03.0532 (UTC) FILETIME=[5135B8C0:01C9201F] X-Mailman-Approved-At: Mon, 29 Sep 2008 09:55:09 -0700 Subject: [secdir] testing3 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Sep 29 12:23:45 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897733A69D3; Mon, 29 Sep 2008 12:23:45 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BF23A69ED for ; Mon, 29 Sep 2008 12:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.352 X-Spam-Level: X-Spam-Status: No, score=-4.352 tagged_above=-999 required=5 tests=[AWL=1.647, BAYES_00=-2.599, J_CHICKENPOX_53=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 1XC+wR+IoN4g for ; Mon, 29 Sep 2008 12:20:51 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 978963A69D3 for ; Mon, 29 Sep 2008 12:20:51 -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 m8TJL5U9016841; Mon, 29 Sep 2008 15:21:05 -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 m8TJL0cn016810 for ; Mon, 29 Sep 2008 15:21:00 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m8TJKr0d023347 for ; Mon, 29 Sep 2008 15:20:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id 1665112E7A01 for ; Mon, 29 Sep 2008 15:20:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4817A422C; Mon, 29 Sep 2008 15:20:23 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org, secdir@mit.edu Date: Mon, 29 Sep 2008 15:20:23 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: draft-stjohns-sipso-05@tools.ietf.org Subject: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines an IPV6 option for labeling the sensitivity of packets on trusted networks. The idea is that all of the components that handle these sensitive packets must support this option. Each component that handles a packet in this architecture needs to be trusted to apply appropriate security policy and not to disclose the packet in environments where the packet is outside of the appropriate sensitivity range. summary: This document is basically ready for publication as an informational document. However significant concerns are present if the IESG plans to continue with its current course of publishing on the standards track. Fixing these concerns will require work, but is definitely doable if there is sufficient consensus. process concern: This document is being sponsored as a proposed standard. However as indicated by the last paragraph in section 1 before section 1.1 this document is a follow-on to RFC 1108, which the IETF deprecated and moved to historic. As that paragraph points out, this option has been in *limited deployment* throughout the history of the internet. While this specification does not specifically invoke the language of RFC 2026 regarding applicability statements, I think that the applicability level "limited use" maps well onto the language of section 1 of this draft. It seems that RFC 2026 recommends against standards-track for technical specifications that have an applicability of "limited use," and I wonder if there is adequate consensus within the IETF community that has considered this RFC 2026 recommendation to overturn that BCP recommendation. I specifically call this issue out for community discussion and recommend that the IESG consider it when evaluating this document. There is a second, less serious process issue. As the draft points out, we chose to move RFC 1108 to historic; has there been adequate discussion to overrule that consensus or otherwise determine it does not apply to the current TS? I consider this less serious because a plausible rationale is presented in the document: we believed IPsec would make these labels unnecessary but now have operational experience that is not the case. If this document is going to be published on the standards track, I think it needs significant revision to come in line with current security best practice BCPs. It's poor form for the security community to enforce these BCPs on other areas' documents but not to meet our own standards; see major comments below. Major Comments: The security of the mechanism described in this document depends critically on participants being trustworthy and trusted. I think the document would be improved significantly by a prominent definition of trustworthy that made specific reference to the Internet threat model and explained how the threat model here differs from that model. Section 8 proposes that AH is the mandatory-to-implement security mechanism for this option. Do we still believe that is appropriate given RFC 4301's move away from AH as a mandatory-to-implement service? This document does not provide a mandatory to implement automated key management solution as required by RFC 4107. It seems like IKE or IKEV2 would be the best mechanism to recommend. If you recommend IKE, be sure to follow the guidance of draft-bellovin-useipsec; if you require IKEV2 be sure to follow similar guidelines. As we know, BCP 61 requires a strong mandatory-to-implement security mechanism for Internet protocols. That mechanism needs to be sufficient for use over the open Internet. We have been very reluctant to accept weaker security mechanisms because some standards-track protocol is not intended for use on the open Internet; BCP 61 says we have consensus that is not how we do things. I question whether AH is sufficient as a BCP 61 mandatory-to-implement mechanism. The entire point of this IPV6 option is to limit disclosure of confidential and classified information. In order to meet that security objective on the open Internet, some confidentiality mechanism is required. I strongly recommend that if this TS is published on the standards track,ESP with confidentially be required. This document referrs to SIPSO-IPsec interactions in a number of places, but never outlines processing rules for systems that implement both IPsec and SIPSO. Does the label go inside or outside of IPsec? (presumably the label should be protected) Section 1.3 discusses deployment involving systems that are not aware of the option. It proposes that the last intermediate system needs to strip the label. Why? It's in an ignore-if-you-don't-understand option. The document requires that if there is a label inside and outside an AH header, that these labels must be the same. Why is this a valid use of a 2119 MUST? What security or interoperability problem results if for example the outer label dominates the inner label? As far as I can tell this requirement gets in the way of tunneling arbitrary IP traffic. The document describes several times how to compare labels. I really hope these explanations are all consistent; as best I can tell they are. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Sep 29 12:29:28 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7C33A6A12; Mon, 29 Sep 2008 12:29:28 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436FA3A6A12 for ; Mon, 29 Sep 2008 12:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.352 X-Spam-Level: X-Spam-Status: No, score=-4.352 tagged_above=-999 required=5 tests=[AWL=1.647, BAYES_00=-2.599, J_CHICKENPOX_53=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 Vz2nAdpoGtqc for ; Mon, 29 Sep 2008 12:29:28 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id EC09428C0DE for ; Mon, 29 Sep 2008 12:29:27 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8TJTfod019280; Mon, 29 Sep 2008 15:29:41 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8TJTe9W019271 for ; Mon, 29 Sep 2008 15:29:40 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m8TJTXi1006318 for ; Mon, 29 Sep 2008 15:29:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id 86BA912E8322 for ; Mon, 29 Sep 2008 15:29:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 017D6422C; Mon, 29 Sep 2008 15:29:03 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org, secdir@mit.edu Date: Mon, 29 Sep 2008 15:20:23 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: draft-stjohns-sipso@tools.ietf.org Subject: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines an IPV6 option for labeling the sensitivity of packets on trusted networks. The idea is that all of the components that handle these sensitive packets must support this option. Each component that handles a packet in this architecture needs to be trusted to apply appropriate security policy and not to disclose the packet in environments where the packet is outside of the appropriate sensitivity range. summary: This document is basically ready for publication as an informational document. However significant concerns are present if the IESG plans to continue with its current course of publishing on the standards track. Fixing these concerns will require work, but is definitely doable if there is sufficient consensus. process concern: This document is being sponsored as a proposed standard. However as indicated by the last paragraph in section 1 before section 1.1 this document is a follow-on to RFC 1108, which the IETF deprecated and moved to historic. As that paragraph points out, this option has been in *limited deployment* throughout the history of the internet. While this specification does not specifically invoke the language of RFC 2026 regarding applicability statements, I think that the applicability level "limited use" maps well onto the language of section 1 of this draft. It seems that RFC 2026 recommends against standards-track for technical specifications that have an applicability of "limited use," and I wonder if there is adequate consensus within the IETF community that has considered this RFC 2026 recommendation to overturn that BCP recommendation. I specifically call this issue out for community discussion and recommend that the IESG consider it when evaluating this document. There is a second, less serious process issue. As the draft points out, we chose to move RFC 1108 to historic; has there been adequate discussion to overrule that consensus or otherwise determine it does not apply to the current TS? I consider this less serious because a plausible rationale is presented in the document: we believed IPsec would make these labels unnecessary but now have operational experience that is not the case. If this document is going to be published on the standards track, I think it needs significant revision to come in line with current security best practice BCPs. It's poor form for the security community to enforce these BCPs on other areas' documents but not to meet our own standards; see major comments below. Major Comments: The security of the mechanism described in this document depends critically on participants being trustworthy and trusted. I think the document would be improved significantly by a prominent definition of trustworthy that made specific reference to the Internet threat model and explained how the threat model here differs from that model. Section 8 proposes that AH is the mandatory-to-implement security mechanism for this option. Do we still believe that is appropriate given RFC 4301's move away from AH as a mandatory-to-implement service? This document does not provide a mandatory to implement automated key management solution as required by RFC 4107. It seems like IKE or IKEV2 would be the best mechanism to recommend. If you recommend IKE, be sure to follow the guidance of draft-bellovin-useipsec; if you require IKEV2 be sure to follow similar guidelines. As we know, BCP 61 requires a strong mandatory-to-implement security mechanism for Internet protocols. That mechanism needs to be sufficient for use over the open Internet. We have been very reluctant to accept weaker security mechanisms because some standards-track protocol is not intended for use on the open Internet; BCP 61 says we have consensus that is not how we do things. I question whether AH is sufficient as a BCP 61 mandatory-to-implement mechanism. The entire point of this IPV6 option is to limit disclosure of confidential and classified information. In order to meet that security objective on the open Internet, some confidentiality mechanism is required. I strongly recommend that if this TS is published on the standards track,ESP with confidentially be required. This document referrs to SIPSO-IPsec interactions in a number of places, but never outlines processing rules for systems that implement both IPsec and SIPSO. Does the label go inside or outside of IPsec? (presumably the label should be protected) Section 1.3 discusses deployment involving systems that are not aware of the option. It proposes that the last intermediate system needs to strip the label. Why? It's in an ignore-if-you-don't-understand option. The document requires that if there is a label inside and outside an AH header, that these labels must be the same. Why is this a valid use of a 2119 MUST? What security or interoperability problem results if for example the outer label dominates the inner label? As far as I can tell this requirement gets in the way of tunneling arbitrary IP traffic. The document describes several times how to compare labels. I really hope these explanations are all consistent; as best I can tell they are. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Sep 29 12:31:06 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089353A6AC3; Mon, 29 Sep 2008 12:31:06 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4473A6AC3 for ; Mon, 29 Sep 2008 12:31:05 -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 BvPrsMFZIa3m for ; Mon, 29 Sep 2008 12:31:04 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id C0AF53A67E5 for ; Mon, 29 Sep 2008 12:31:04 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8TJVAkH019783; Mon, 29 Sep 2008 15:31: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 m8TJV7wF019755 for ; Mon, 29 Sep 2008 15:31:07 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m8TJUn6j009043 for ; Mon, 29 Sep 2008 15:30:49 -0400 (EDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7D36F116CDD8; Mon, 29 Sep 2008 15:30:25 -0400 (EDT) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m8TJUBrt023704; Mon, 29 Sep 2008 15:30:11 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <3DED2A0C-2548-4FB1-B22A-DC625ED8C9EF@nist.gov> From: Tim Polk Date: Mon, 29 Sep 2008 15:30:30 -0400 To: Barry Leiba , Sam Hartman X-Mailer: Apple Mail (2.753.1) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: secdir@mit.edu Subject: Re: [secdir] We need nominations X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Folks, (Sam & Barry: Thanks for starting this thread. I have been remiss in not doing so myself.) It is critically important that the NomCom have the best candidates possible to choose from. The IETF's work deserves and demands the best people available! Please take some time and check out the NomCom '08 website, https://wiki.tools.ietf.org/group/nomcom/08/ review the requirements, and please, please submit nominations for people that you feel could best serve the interests of the community. Nominating yourself is more than acceptable... that way, nomcom knows that you are willing to serve!) As Barry said, don't be shy. While this list is an obvious target for security area nominations, please consider nominating people for other Area Director positions, or for the IAB or IAOC. All of these folks play an important role, and I understand we are short on nominations across the board. Again, thanks to Sam and Barry for raising the topic. Friday October 3 is coming fast, and I appreciate the reminder. Thanks, Tim Polk On Sep 29, 2008, at 2:48 PM, Barry Leiba wrote: > Sam says... >> Folks, this Friday, October 3 is the deadline to nominate people for >> IETF leadership positions. We could really use some security AD >> nominations. I'd appreciate it if you could take a few moments to >> think about who would make a good AD and then nominate them. > > I'll add that the NomCom needs candidates, EVEN IF IT ENDS UP RE- > APPOINTING Tim. > Putting yourself or your buddy into the ring does NOT mean that you > want Tim to > be replaced. For many reasons, the system only works if the NomCom > has real > choices. So don't be shy. > > Barry > > _______________________________________________ > secdir mailing list > secdir@mit.edu > https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Mon Sep 29 12:43:28 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973BF3A6ACC; Mon, 29 Sep 2008 12:43:28 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DEC3A6AD8 for ; Mon, 29 Sep 2008 12:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=1.854, 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 GF6Mqfd-VFt6 for ; Mon, 29 Sep 2008 12:43:23 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 877833A6ACC for ; Mon, 29 Sep 2008 12:43: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 m8TJhboG023678; Mon, 29 Sep 2008 15:43:37 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8TJhZOR023667 for ; Mon, 29 Sep 2008 15:43:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m8TJhSKH001702 for ; Mon, 29 Sep 2008 15:43:29 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id 75C3E11675B6 for ; Mon, 29 Sep 2008 15:43:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC3D2422C; Mon, 29 Sep 2008 15:42:59 -0400 (EDT) From: Sam Hartman To: Barry Leiba References: Date: Mon, 29 Sep 2008 15:42:59 -0400 In-Reply-To: (Barry Leiba's message of "Mon, 29 Sep 2008 14:48:08 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: secdir@MIT.EDU Subject: Re: [secdir] We need nominations X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Barry" == Barry Leiba writes: Barry> Sam says... >> Folks, this Friday, October 3 is the deadline to nominate >> people for IETF leadership positions. We could really use some >> security AD nominations. I'd appreciate it if you could take a >> few moments to think about who would make a good AD and then >> nominate them. Barry> I'll add that the NomCom needs candidates, EVEN IF IT ENDS Barry> UP RE-APPOINTING Tim. Putting yourself or your buddy into Barry> the ring does NOT mean that you want Tim to be replaced. Barry> For many reasons, the system only works if the NomCom has Barry> real choices. So don't be shy. Yes! If you'd rather Tim be picked, but would be willing to serve if selected, then by all means, nominate yourself, and tell us that. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 03:28:15 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE1F3A67C1; Tue, 30 Sep 2008 03:28:15 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797D33A67F6 for ; Mon, 29 Sep 2008 13:05:56 -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 h1jQEqej+HBs for ; Mon, 29 Sep 2008 13:05:55 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 49B4E3A67A5 for ; Mon, 29 Sep 2008 13:05:55 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8TK67qX030165; Mon, 29 Sep 2008 16:06:07 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8TK61TW030084 for ; Mon, 29 Sep 2008 16:06:01 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m8TK5oIr011661 for ; Mon, 29 Sep 2008 16:05:50 -0400 (EDT) Received: from nutshell.tislabs.com (ns1.tislabs.com [192.94.214.100]) by mit.edu (Spam Firewall) with ESMTP id D0BD410FFD2E for ; Mon, 29 Sep 2008 16:05:26 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m8TK42iB014674; Mon, 29 Sep 2008 16:04:02 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjPaiQC; Mon, 29 Sep 08 16:04:02 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 3E5DD3F443; Mon, 29 Sep 2008 16:02:31 -0400 (EDT) To: dward@cisco.com, edward.jankiewicz@sri.com, msec@ietf.org, ospf@ietf.org, rcallon@juniper.net, rpsec@ietf.org, secdir@mit.edu, sidr@ietf.org, tsvwg@ietf.org In-Reply-To: <48D96507.4000207@sri.com> Message-Id: <20080929200231.3E5DD3F443@pecan.tislabs.com> Date: Mon, 29 Sep 2008 16:02:31 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 30 Sep 2008 03:28:13 -0700 Cc: sandy@tislabs.com Subject: Re: [secdir] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >What (if any) current initiatives are there that would support automated >key exchange for OSFPv3 authentication? You have msec on the list of recipients, which is where I (not an active participant, mind you) think the answer lies. Both GDOI (RFC 3547) and GSAKMP (RFC 4535) are group key management protocols, which is what OSPFv3 needs. Unfortunately, both assume the existence of a group controller that plays an important role in distributing keys. In other words, the very democratic all-are-equal many-to-many model of OSPF might find it difficult to map to the envisioned group security architecture. I suppose it might be possible to consider the Designated Router as the group controller, but as the DR is elected, that might be a difficult fit. Even if you solve the group key management problem for OSPFv3, you still have the difficulty to doing anti-replay in a multicast environment. Manral presented a draft some years ago to the rpsec working group about the crypto vulnerabilities of routing protocols, and concentrated for OSPFv3 on replay vulnerabilities. Unfortunately, that did not go anywhere. Just for fun, I'm adding the routing area ADs and the secdir on this list. This is one of those cross-disciplinary concerns that has the right people in several different wgs and areas. The more the merrier, right? The one quibble I have is that the tsvwg probably has little to do with this problem - the transport for OSPFv3 is IP, not TCP, and IP is not the level of stuff their charter looks at. (And sorry for the late reply to your messages, I've been mulling the options.) --Sandy --------- In reply to ------------------------ Date: Tue, 23 Sep 2008 17:52:07 -0400 From: Ed Jankiewicz To: ospf@ietf.org, rpsec@ietf.org, sidr@ietf.org, msec@ietf.org, tsvwg@ietf.org Subject: [RPSEC] Authentication for OSPFv3 I am not an active follower of these lists but have a question. Please reply off-list directly to ed.jankiewicz@sri.com or copy me if this triggers relevant discussion on your list. What (if any) current initiatives are there that would support automated key exchange for OSFPv3 authentication? RFC 4552 relies upon pre-shared secret keys for generating message digest, but some of my constituents have issues with manual generation, distribution and configuration of keys in their IPv6 network deployment. Is any of the current work on IKE revisions applicable, any work being done in your working group, or do you know of any OSPF-specific solution being developed somewhere? Thanks. -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www.ietf.org/mailman/listinfo/rpsec _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 03:28:15 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0383A68C4; Tue, 30 Sep 2008 03:28:15 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2C928C131 for ; Mon, 29 Sep 2008 14:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXgkj8cKB0-4 for ; Mon, 29 Sep 2008 14:21:49 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id AF1D928C13B for ; Mon, 29 Sep 2008 14:21:49 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8TLM3Md020009; Mon, 29 Sep 2008 17:22:03 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8TLM1Nl020001 for ; Mon, 29 Sep 2008 17:22:01 -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 m8TLLqdQ028350 for ; Mon, 29 Sep 2008 17:21:52 -0400 (EDT) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id 8903F12EF169; Mon, 29 Sep 2008 17:21:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EE73DAF67E; Mon, 29 Sep 2008 21:21:27 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 54063AF647; Mon, 29 Sep 2008 21:21:27 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id A3F8C8386BE; Mon, 29 Sep 2008 17:03:06 -0400 (EDT) Date: Mon, 29 Sep 2008 17:03:05 -0400 From: "Steven M. Bellovin" To: Sam Hartman Message-ID: <20080929170305.4740f779@cs.columbia.edu> In-Reply-To: References: Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: X-Mailman-Approved-At: Tue, 30 Sep 2008 03:28:13 -0700 Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Mon, 29 Sep 2008 15:20:23 -0400 Sam Hartman wrote: > Section 8 proposes that AH is the mandatory-to-implement security > mechanism for this option. Do we still believe that is > appropriate given RFC 4301's move away from AH as a > mandatory-to-implement service? As discussed way back when, when we'd agreed on what became 2401 et seq., the IETF preferred that security labels be part of the credential, and hence implicit in the security association, rather than being part of the IPsec header. Now -- here, the use of IPsec is to protect the security label, rather than the data -- but does it actually do that in any useful way? If the security option is really end-to-end, we don't need it, per the above. If it's hop-by-hop -- and it's using a v6 hop-by-hop option -- AH doesn't provide useful protection unless packets are digitally signed rather than MACed. > > As we know, BCP 61 requires a strong mandatory-to-implement security > mechanism for Internet protocols. That mechanism needs to be > sufficient for use over the open Internet. We have been very > reluctant to accept weaker security mechanisms because some > standards-track protocol is not intended for use on the open Internet; > BCP 61 says we have consensus that is not how we do things. I > question whether AH is sufficient as a BCP 61 mandatory-to-implement > mechanism. The entire point of this IPV6 option is to limit > disclosure of confidential and classified information. In order to > meet that security objective on the open Internet, some > confidentiality mechanism is required. I strongly recommend that if > this TS is published on the standards track,ESP with confidentially be > required. I don't agree. The purpose of AH in this spec is to protect certain information that's in the clear. (As noted, though, I don't think it does it properly.) Protection of the underlying data is the business of a separate layer or sublayer. > > This document referrs to SIPSO-IPsec interactions in a number of > places, but never outlines processing rules for systems that implement > both IPsec and SIPSO. Does the label go inside or outside of IPsec? > (presumably the label should be protected) > Very important -- see above. > > The document requires that if there is a label inside and outside an > AH header, that these labels must be the same. Why is this a valid > use of a 2119 MUST? What security or interoperability problem results > if for example the outer label dominates the inner label? > As far as I can tell this requirement gets in the way of tunneling > arbitrary IP traffic. It guards against someone tampering with the outer label, causing the packet to be misrouted perhaps. Note 7.3.1 on TCP considerations. (Also note that 7.3.1 disagrees with 793 on the treatment of security labels in section 3.6 of 793. At the least, this shoudl be noted. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 03:28:15 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 371C93A68EE; Tue, 30 Sep 2008 03:28:15 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FA828C0E9 for ; Tue, 30 Sep 2008 03:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 XzrehDhrpwZz for ; Tue, 30 Sep 2008 03:22:25 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id C92C428C0DE for ; Tue, 30 Sep 2008 03:22:24 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UAMaU8012402; Tue, 30 Sep 2008 06:22:38 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UAMXaU012389 for ; Tue, 30 Sep 2008 06:22:33 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m8UAML3x029703 for ; Tue, 30 Sep 2008 06:22:21 -0400 (EDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 57F8D12C67D4 for ; Tue, 30 Sep 2008 06:22:00 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m8UALSYj018033; Tue, 30 Sep 2008 13:21:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 13:21:44 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Sep 2008 13:21:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Sep 2008 13:21:41 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201BCD0ED@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pasi's AD notes for September 2008 Thread-Index: Acki5lSXKuX1vLTvTBqkzPDzTEQ8XA== From: To: , X-OriginalArrivalTime: 30 Sep 2008 10:21:43.0952 (UTC) FILETIME=[561FD900:01C922E6] X-Nokia-AV: Clean X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m8UAMXaU012389 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: X-Mailman-Approved-At: Tue, 30 Sep 2008 03:28:13 -0700 Subject: [secdir] Pasi's AD notes for September 2008 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi all, Here's again a short status update about what things are going on = from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - There have been two security-related BoF requests for IETF73: OAuth (in the applications area), and Content Rights Management (in the security area). For the latter, Tim and I have recommended = having a bar BoF first. = - SecDir mailing list is in the process of being moved from mit.edu = to ietf.org servers. - I've spent some time this month on tools development and IESG process improvements -- nothing is ready yet, but hopefully soon.. WORKING GROUPS DKIM - draft-ietf-dkim-ssp: in Publication Requested, waiting for = me to read it. - Waiting for WG to send list of RFC errata IDs the WG agrees on. EMU - draft-ietf-emu-gpsk: in AD Evaluation -- waiting for revised = ID that reflects the new WG consensus on MAC length/key size = issue before going to IETF last call (since 2008-08-25) - A liaison statement reply was sent to ITU-T SG 17 regarding X.1034, = "Guidelines on EAP-based authentication and key management in a = data communication network". - IESG appointed Joe Salowey as the designated expert for IANA = allocation of EAP Type Codes - (not WG item) draft-arkko-eap-aka-kdf =EDs now in IETF Last Call IPSECME - Lots of emails that I need to read (but haven't done so yet) - (not wearing AD hat) I sent my "things that need to be looked at" = list about IKEv2bis to the mailing list; I need to check that = they got entered in the issue tracker, too. ISMS - It seems the discussion has largely converged; I'm waiting for revised IDs to read and review. KEYPROV - I sent more comments regarding PSKC; I need to read the replies and participate in discussion. - I need to review and comment DSKPP, too. = SASL - I replied to Frank Ellermann's appeal about WG chairs' handling = of draft-ietf-sasl-crammd5. - Waiting for charter update text from the chairs (>6 months) SYSLOG - draft-ietf-syslog-transport-tls: a revised version addressing Chris Newman's DISCUSS should be posted in a couple of days. - draft-ietf-syslog-sign: there has been a bunch of replies to my AD evaluation comments that I need to read and process, but I = haven't done so yet. TLS - (not WG item) draft-rescorla-tls-suiteb is now in IETF Last Call. - (not WG item) draft-hajjeh-tls-identity-protection: IESG reviewed this independent submission to the RFC Editor, and recommended not publishing it. OTHER DOCUMENTS - draft-ietf-capwap-*: I've been working with Pat and others, and I think we're done (except that agreed text needs to be = edited in, and some editorial nits fixed). - draft-ietf-avt-rtcpssm: no news; waiting for Joerg to explore "feedback debug" messages. - draft-santesson-digestbind: I read this and sent comments to Stefan. - PKCS #1/RFC 3447 update: waiting for James Randall to post an update including the various errata. - draft-mattsson-srtp-store-and-forward: I've promised to read = this and send comments, but haven't done so yet. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I've promised = to read this once there's a new version. - "Security roadmap for routing protocols": I've promised to read and comment this once Gregory sends something. = DISCUSSES (active -- something happened within last month) - draft-ietf-capwap-protocol-binding-ieee80211: text agreed, waiting for authors to submit a revised ID [since 2008-09-26] - draft-ietf-lemonade-msgevent: waiting for authors to submit a revised ID [since 2008-09-08] - draft-ietf-mip6-whyauthdataoption: waiting for authors to submit = a revised ID [since 2008-09-08] - draft-ietf-mipshop-mstp-solution: the authors have replied to = my comments; I need to read the replies [since 2008-09-26] - draft-ietf-nfsv4-rpcsec-gss-v2: waiting for authors to reply to my comments [since 2008-09-25] - draft-ietf-sieve-refuse-reject: waiting for authors to reply to my comments [since 2008-09-11] - draft-ietf-sipping-race-examples: waiting for document shepherd or Jon to comment the "Updates" issue [since 2008-09-26] - draft-ietf-v6ops-addcon: the changes in version -10 were sent to 6MAN WG for review; I'll clear once this has happened = [expected to happen on 2008-10-01] - draft-mraihi-inch-thraud: version -07 addressed almost all of = my comments; waiting for authors to send RFC Editor Note text fixing the IANA issue, too [since 2008-09-02] DISCUSSES (stalled -- I haven't heard anything from the authors = or document shepherd for over one month) - draft-cain-post-inch-phishingextns: waiting for authors to reply = to my comments or submit a revised ID [since 2008-08-28] - draft-cam-winget-eap-fast-provisioning: waiting for authors to = reply to my comments or submit a revised ID [since 2008-08-28] - draft-hautakorpi-sipping-uri-list-handling-refused: text agreed, = waiting for authors to submit a revised ID [since 2008-07-03] - draft-ietf-enum-experiences: talked briefly with Jon Peterson = in Dublin -- waiting to hear more from the authors and/or Jon [since 2008-07-31] - draft-ietf-pce-pcep: new version -15 addressed some comments from other ADs; some discussions about my comments has occured; waiting for proposed text or revised ID [since 2008-06-16] - draft-ietf-pwe3-pw-atm-mib: waiting for authors to reply to my comments or submit a revised ID [since 2008-07-02] - draft-zhou-emu-fast-gtc: changes probably agreed, waiting for authors to submit a revised ID to see exact text [since 2008-08-28] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-ietf-bfd-base: waiting for authors to reply to my = comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-multihop: waiting for authors to reply to = my comments or submit a revised ID [since 2008-06-05] - draft-ietf-bfd-v4v6-1hop: waiting for authors to reply to = my comments or submit a revised ID [since 2008-06-05] - draft-ietf-shim6-proto: waiting for Erik to propose something = to solve IPsec interaction issue [since 2008-06-18] - draft-ietf-simple-imdn: waiting for authors to reply to my = comments or submit a revised ID [since 2008-05-14] - draft-ietf-sipping-sbc-funcs: new version (-06) addressed all comments except one; text agreed for the remaining one, waiting for RFC editor note or revised ID [since 2008-06-17] - draft-ietf-tsvwg-emergency-rsvp: this document has large = number of discusses/abstains; waiting for Magnus to figure out next steps [since 2008-06-03] --end-- _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 03:30:10 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0F828C10D; Tue, 30 Sep 2008 03:30:10 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57AC53A68C2 for ; Tue, 30 Sep 2008 03:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.969 X-Spam-Level: X-Spam-Status: No, score=-6.969 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM1=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAHgFKKa0GJr for ; Tue, 30 Sep 2008 03:29:04 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 4590E3A67C1 for ; Tue, 30 Sep 2008 03:29:04 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UASpft013275; Tue, 30 Sep 2008 06:28:51 -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 m8RKV2Us032713 for ; Sat, 27 Sep 2008 16:31:04 -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 m8RKUqRs000245 for ; Sat, 27 Sep 2008 16:30:52 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu (Spam Firewall) with ESMTP id 95C99B670EE for ; Sat, 27 Sep 2008 16:30:50 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EA33A6800; Sat, 27 Sep 2008 13:30:35 -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 EED1828C235 for ; Tue, 23 Sep 2008 13:54:23 -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 f+6LfzdOmALY for ; Tue, 23 Sep 2008 13:54:22 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 064EF28C234 for ; Tue, 23 Sep 2008 13:54:21 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1KiEtp-0005Su-80 for public-new-work-dist@listhub.w3.org; Tue, 23 Sep 2008 20:54:21 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KiEto-0005S5-Cz for public-new-work@listhub.w3.org; Tue, 23 Sep 2008 20:54:20 +0000 Received: from homer.w3.org ([128.30.52.30]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1KiEtg-0006Yf-2S; Tue, 23 Sep 2008 16:54:20 -0400 Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id CCF044F330; Tue, 23 Sep 2008 16:53:46 -0400 (EDT) From: "Ian B. Jacobs" To: public-new-work@w3.org Organization: W3C Date: Tue, 23 Sep 2008 15:53:44 -0500 Message-Id: <1222203224.29140.80.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1KiEtg-0006Yf-2S e32eec9b24c57cbded09a55ea080ec16 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/27 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Tue, 23 Sep 2008 20:54:21 +0000 X-Mailman-Approved-At: Sat, 27 Sep 2008 13:30:33 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 30 Sep 2008 06:28:47 -0400 X-BeenThere: secdir@mit.edu List-Archive: X-Mailman-Approved-At: Tue, 30 Sep 2008 03:30:09 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: Web Services Resource Access (WSRA) Working Group (until 2008-10-24) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Web Services Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Services Resource Access (WSRA) Working Group: http://www.w3.org/2008/08/ws/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 2008-10-24 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 Yves Lafon, Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2002/ws/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260-9447 _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 03:30:10 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1BA28C112; Tue, 30 Sep 2008 03:30:10 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F623A6839 for ; Tue, 30 Sep 2008 03:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_48=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 FoYRc8HYjwLe for ; Tue, 30 Sep 2008 03:29:11 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E226A28C0DC for ; Tue, 30 Sep 2008 03:29: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 m8UASqWk013280; Tue, 30 Sep 2008 06:28:52 -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 m8U1s1R8023144 for ; Mon, 29 Sep 2008 21:54:01 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m8U1rpJT027030 for ; Mon, 29 Sep 2008 21:53:51 -0400 (EDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mit.edu (Spam Firewall) with ESMTP id 6B2C9B701D5 for ; Mon, 29 Sep 2008 21:53:25 -0400 (EDT) Received: by fk-out-0910.google.com with SMTP id z22so2716878fkz.6 for ; Mon, 29 Sep 2008 18:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=EumIcmMH2k3Kawxal4Vz3xQUHRpPzI+dO4G5WzZHQNc=; b=VbQAfVgH1WpBqWq98fBh5UtizgzjDvZ+P/sqxZqA6BlAFx517PjgfnrEuWEkdjAxcA 8BlplZ/VnZh2o/xoCFVG3lRmVtu8Xy1K2VVzMf64GLG7N3W17QWAyezOueelykk7IcGy arSQa70qQhK7y+Tho/Bptw25eiFq2mwAHyK2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=mBxoixBJUq96RVtM74TrmrlYWEQ8FBMX2wvPHF6cXTmm4zo8gn0CuOOeHZLNMLvN7c 3Ehfq8suzxePcRcmtQcLkY5p85FA6QRYhLQlRA5gyd22s7RNAnHcfYf0W2irQ+yCT3/V j9lekQuWlbIDGPrYCSMY80ZDpLMmv8CN1xhas= Received: by 10.181.6.5 with SMTP id j5mr2647009bki.34.1222739604886; Mon, 29 Sep 2008 18:53:24 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Mon, 29 Sep 2008 18:53:24 -0700 (PDT) Message-ID: <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Date: Tue, 30 Sep 2008 07:23:24 +0530 From: "Vishwas Manral" To: "Sandy Murphy" In-Reply-To: <20080929200231.3E5DD3F443@pecan.tislabs.com> MIME-Version: 1.0 Content-Disposition: inline References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 30 Sep 2008 06:28:47 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: X-Mailman-Approved-At: Tue, 30 Sep 2008 03:30:09 -0700 Cc: msec@ietf.org, tsvwg@ietf.org, edward.jankiewicz@sri.com, ospf@ietf.org, secdir@mit.edu, rpsec@ietf.org, dward@cisco.com, sidr@ietf.org, rcallon@juniper.net Subject: Re: [secdir] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Sandy, Thanks for refering to my draft in your mail. The same was presented by Dave (Ward) in the last IETF. Regarding the state of the draft, because the RPSEC is closing down, we have been trying to find a home for the draft. We can also solve the problem similarly by something like BTNS(ofcourse Multicast part needs to be thought further) which does not necessarily require any certificate verification - so we may have unauthenticated IKE SA's but then all keys for the CHILD_SA from there are automatically generated. Thanks, Vishwas On 9/30/08, Sandy Murphy wrote: >>What (if any) current initiatives are there that would support automated >>key exchange for OSFPv3 authentication? > > You have msec on the list of recipients, which is where I (not an active > participant, mind you) think the answer lies. Both GDOI (RFC 3547) and > GSAKMP (RFC 4535) are group key management protocols, which is what > OSPFv3 needs. Unfortunately, both assume the existence of a group > controller that plays an important role in distributing keys. In other > words, the very democratic all-are-equal many-to-many model of OSPF might > find it > difficult to map to the envisioned group security architecture. I > suppose it might be possible to consider the Designated Router as the > group controller, but as the DR is elected, that might be a difficult fit. > > Even if you solve the group key management problem for OSPFv3, you still > have the difficulty to doing anti-replay in a multicast environment. > Manral presented a draft some years ago to the rpsec working group about > the crypto vulnerabilities of routing protocols, and concentrated for > OSPFv3 on replay vulnerabilities. Unfortunately, that did not go anywhere. > > Just for fun, I'm adding the routing area ADs and the secdir on this list. > This is one of those cross-disciplinary concerns that has the right people > in several different wgs and areas. The more the merrier, right? > > The one quibble I have is that the tsvwg probably has little to do with this > problem - the transport for OSPFv3 is IP, not TCP, and IP is not the level > of stuff their charter looks at. > > (And sorry for the late reply to your messages, I've been mulling the > options.) > > --Sandy > > --------- In reply to ------------------------ > > Date: Tue, 23 Sep 2008 17:52:07 -0400 > From: Ed Jankiewicz > To: ospf@ietf.org, rpsec@ietf.org, sidr@ietf.org, msec@ietf.org, > tsvwg@ietf.org > Subject: [RPSEC] Authentication for OSPFv3 > > I am not an active follower of these lists but have a question. Please > reply off-list directly to ed.jankiewicz@sri.com or copy me if this > triggers relevant discussion on your list. > > What (if any) current initiatives are there that would support automated > key exchange for OSFPv3 authentication? RFC 4552 relies upon pre-shared > secret keys for generating message digest, but some of my constituents > have issues with manual generation, distribution and configuration of > keys in their IPv6 network deployment. Is any of the current work on > IKE revisions applicable, any work being done in your working group, or > do you know of any OSPF-specific solution being developed somewhere? > > Thanks. > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research > Supporting DISA Standards Engineering Branch > 732-389-1003 or ed.jankiewicz@sri.com > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/rpsec > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 03:46:39 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7B03A6863; Tue, 30 Sep 2008 03:46:39 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3493A68C2 for ; Tue, 30 Sep 2008 03:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzqM3tQ0YTff for ; Tue, 30 Sep 2008 03:46:37 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 081E03A6863 for ; Tue, 30 Sep 2008 03:46:36 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UAkpJH017935; Tue, 30 Sep 2008 06:46:52 -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 m8UAknC6017929 for ; Tue, 30 Sep 2008 06:46:49 -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 m8UAkevA000078 for ; Tue, 30 Sep 2008 06:46:40 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id BF1F9B741D5 for ; Tue, 30 Sep 2008 06:44:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 520C1422C; Tue, 30 Sep 2008 06:44:45 -0400 (EDT) From: Sam Hartman To: "Steven M. Bellovin" References: <20080929170305.4740f779@cs.columbia.edu> Date: Tue, 30 Sep 2008 06:44:45 -0400 In-Reply-To: <20080929170305.4740f779@cs.columbia.edu> (Steven M. Bellovin's message of "Mon, 29 Sep 2008 17:03:05 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: draft-stjohns-sipso-05@tools.ietf.org, secdir@mit.edu, ietf@ietf.org Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Steven" == Steven M Bellovin writes: Steven> On Mon, 29 Sep 2008 15:20:23 -0400 Steven> Sam Hartman wrote: >> Section 8 proposes that AH is the mandatory-to-implement >> security mechanism for this option. Do we still believe that >> is appropriate given RFC 4301's move away from AH as a >> mandatory-to-implement service? Steven> As discussed way back when, when we'd agreed on what Steven> became 2401 et seq., the IETF preferred that security Steven> labels be part of the credential, and hence implicit in Steven> the security association, rather than being part of the Steven> IPsec header. Now -- here, the use of IPsec is to protect Steven> the security label, rather than the data -- but does it Steven> actually do that in any useful way? If the security Steven> option is really end-to-end, we don't need it, per the Steven> above. If it's hop-by-hop -- and it's using a v6 Steven> hop-by-hop option -- AH doesn't provide useful protection Steven> unless packets are digitally signed rather than MACed. Doesn't that sort of depend on 1) who the attackers are 2) who the endpoints of the SA are? As far as I can tell AH would be fine for hop-by-hop SAs to protect packets flowing over a link that cannot be trusted to preserve integrity between two intermediate systems. You could potentially have both an end-to-end SA and a hop-by-hop SA. That says that you trust intermediate systems less than you do the endpoints, but somehow you're still trusting them not to disclose traffic. I'd like to understand the threat model that leads to this better. However, I agree with you that the draft is broken. It seems clearly like it is talking about end-to-end AH, and I agree that doesn't fit the model well at all without digital signatures. >> As we know, BCP 61 requires a strong mandatory-to-implement >> security mechanism for Internet protocols. That mechanism >> needs to be sufficient for use over the open Internet. We have >> been very reluctant to accept weaker security mechanisms >> because some standards-track protocol is not intended for use >> on the open Internet; BCP 61 says we have consensus that is not >> how we do things. I question whether AH is sufficient as a BCP >> 61 mandatory-to-implement mechanism. The entire point of this >> IPV6 option is to limit disclosure of confidential and >> classified information. In order to meet that security >> objective on the open Internet, some confidentiality mechanism >> is required. I strongly recommend that if this TS is published >> on the standards track,ESP with confidentially be required. Steven> I don't agree. The purpose of AH in this spec is to Steven> protect certain information that's in the clear. (As Steven> noted, though, I don't think it does it properly.) Steven> Protection of the underlying data is the business of a Steven> separate layer or sublayer. I made a number of statements and I'd like to explore our disagreement. I'm assuming that we agree about what BCP 61 is trying to do: it's trying to require that IETF protocols have adequate security for the open Internet, because networks will get connected. I seem to recall you buy into that argument:-) Do you disagree with my assertion that from a overall architecture view, anyone who implements this mechanism needs confidentiality to run their packets over the open Internet? If you agree confidentiality is needed somewhere, how do we get interoperability if we don't mandate a confidentiality mechanism here? >> The document requires that if there is a label inside and >> outside an AH header, that these labels must be the same. Why >> is this a valid use of a 2119 MUST? What security or >> interoperability problem results if for example the outer label >> dominates the inner label? As far as I can tell this >> requirement gets in the way of tunneling arbitrary IP traffic. Steven> It guards against someone tampering with the outer label, Steven> causing the packet to be misrouted perhaps. I guess I'm having a hard time seeing why you would have both labels if they serve the same purpose. However I think I was misreading the text. I thought the text was intended to apply to IP within IP--for example an inner label in a ip-in-ip tunnel. If the text is only intended to apply to two copies of the option at the same IP layer, then I agree they need to be the same, although I'd also like an explanation of why you ever do that. Steven> Note 7.3.1 on Steven> TCP considerations. (Also note that 7.3.1 disagrees with Steven> 793 on the treatment of security labels in section 3.6 of Steven> 793. At the least, this shoudl be noted. I had completely missed this. I'll call out the section to the transport ADs Steven> --Steve Bellovin, Steven> http://www.cs.columbia.edu/~smb _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 04:01:23 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A343A67AF; Tue, 30 Sep 2008 04:01:23 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C7D3A67AF for ; Tue, 30 Sep 2008 04:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.392 X-Spam-Level: X-Spam-Status: No, score=-4.392 tagged_above=-999 required=5 tests=[AWL=1.607, BAYES_00=-2.599, J_CHICKENPOX_48=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 ZZVe70ov1e-j for ; Tue, 30 Sep 2008 04:01:21 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 2A53D3A6AC8 for ; Tue, 30 Sep 2008 04:01:21 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UB0oTd021523; Tue, 30 Sep 2008 07:00:50 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UB0ka1021489 for ; Tue, 30 Sep 2008 07:00:46 -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 m8UB0dt8019417 for ; Tue, 30 Sep 2008 07:00:39 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id 14990B7171E for ; Tue, 30 Sep 2008 07:00:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C84D6422C; Tue, 30 Sep 2008 07:00:27 -0400 (EDT) From: Sam Hartman To: "Vishwas Manral" References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Date: Tue, 30 Sep 2008 07:00:27 -0400 In-Reply-To: <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> (Vishwas Manral's message of "Tue, 30 Sep 2008 07:23:24 +0530") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: msec@ietf.org, tsvwg@ietf.org, edward.jankiewicz@sri.com, ospf@ietf.org, secdir@MIT.EDU, Sandy Murphy , rpsec@ietf.org, dward@cisco.com, sidr@ietf.org, rcallon@juniper.net Subject: Re: [secdir] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Vishwas" == Vishwas Manral writes: Vishwas> We can also solve the problem similarly by something like Vishwas> BTNS(ofcourse Multicast part needs to be thought further) Vishwas> which does not necessarily require any certificate Vishwas> verification - so we may have unauthenticated IKE SA's Vishwas> but then all keys for the CHILD_SA from there are Vishwas> automatically generated. Let me see if I understand this approach correctly. I want to interact with OSPF. Somehow there is a group key that is in use on my link. In order to obtain this key, I exchange in an unauthenticated BTNS-style exchange with someone, and as a result of that exchange, obtain the key? First, who do I perform this exchange with? Anyone who currently holds the key? Second, what threats does this protect against? Finally, one of the things we typically desire from BTNS-style protocols is a way to turn them into higher-infrastructure protocols when the infrastructure is available. Can I do that with your approach? How? _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 08:12:34 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA88128C12A; Tue, 30 Sep 2008 08:12:34 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651AD28C115 for ; Tue, 30 Sep 2008 03:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.496 X-Spam-Level: X-Spam-Status: No, score=-4.496 tagged_above=-999 required=5 tests=[AWL=2.103, 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 WEF2A8HQA1BM for ; Tue, 30 Sep 2008 03:34:49 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5718C28C11B for ; Tue, 30 Sep 2008 03:34:49 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UASqjm013285; Tue, 30 Sep 2008 06:28:52 -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 m8THv31G021391 for ; Mon, 29 Sep 2008 13:57:03 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m8THuslr006089 for ; Mon, 29 Sep 2008 13:56:54 -0400 (EDT) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 6389F103D17A for ; Mon, 29 Sep 2008 13:56:30 -0400 (EDT) Received: from gateout01.mbox.net (gateout01-lo [127.0.0.1]) by gateout01.mbox.net (Postfix) with ESMTP id 89D9FCD20F; Mon, 29 Sep 2008 17:56:29 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.45U) with ESMTP id XID041miCR5d4561Xo1; Mon, 29 Sep 2008 17:56:29 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID041miCR5d4561Xo1 Received: from [10.1.1.130] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Sep 2008 11:56:28 -0600 Message-Id: <623ED7C1-9251-4DB4-B95F-BFEC6EB2ABE1@commerce.net> From: Lisa Dusseault To: secdir@mit.edu Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 29 Sep 2008 10:56:27 -0700 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 29 Sep 2008 17:56:28.0959 (UTC) FILETIME=[B2D7C2F0:01C9225C] X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 30 Sep 2008 06:28:47 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: X-Mailman-Approved-At: Tue, 30 Sep 2008 08:12:34 -0700 Cc: Anthony Bryan Subject: [secdir] Digital signature advice and review for content delivery application X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi, Is there somebody on secdir who could volunteer to review and provide advice on the digital signature functionality in this proposal? http://tools.ietf.org/html/draft-bryan-metalink-03 Thanks, Lisa D _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 08:25:28 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1EF3A6B98; Tue, 30 Sep 2008 08:25:28 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3504A3A67AB for ; Tue, 30 Sep 2008 08:25:26 -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 h9lpVXTuM4qH for ; Tue, 30 Sep 2008 08:25:19 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id B58CF3A6833 for ; Tue, 30 Sep 2008 08:25:17 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UFPail014207 for ; Tue, 30 Sep 2008 11:25:37 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UFPW67014194 for ; Tue, 30 Sep 2008 11:25:32 -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 m8UFPMBG024436 for ; Tue, 30 Sep 2008 11:25:22 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id F1A2A104F374 for ; Tue, 30 Sep 2008 11:24:57 -0400 (EDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8UFOkN9023005 for ; Tue, 30 Sep 2008 11:24:46 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8UFOiiv110922 for ; Tue, 30 Sep 2008 09:24:44 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8UFOfmo028753 for ; Tue, 30 Sep 2008 09:24:43 -0600 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8UFOcSK028328; Tue, 30 Sep 2008 09:24:38 -0600 Received: from dyn9002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1222788286.3445; Tue, 30 Sep 2008 11:24:46 -0400 Date: Tue, 30 Sep 2008 11:24:35 -0400 From: Barry Leiba To: Lisa Dusseault , secdir@mit.edu Message-ID: <362BD00981F367CEDD5CF81C@Uranus-009002042072.watson.ibm.com> In-Reply-To: <623ED7C1-9251-4DB4-B95F-BFEC6EB2ABE1@commerce.net> References: <623ED7C1-9251-4DB4-B95F-BFEC6EB2ABE1@commerce.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: Anthony Bryan Subject: Re: [secdir] Digital signature advice and review for content delivery application X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org > Is there somebody on secdir who could volunteer to review and provide > advice on the digital signature functionality in this proposal? > > http://tools.ietf.org/html/draft-bryan-metalink-03 I've given it a brief reading, and here are my initial thoughts: First, I find quite a bit of the document to be sketchy and unclear. That's certainly because I haven't been involved in any of the discussions, but neither will most future readers of it have been. In particular, the descriptions of the elements don't seem to be adequate. For example: > 4.1.6. The "metalink:pieces" Element > > The "metalink:pieces" element is a Text construct that conveys a > human-readable piece information for a file. > I don't know what "human-readable piece information" is, why it's put there, what anyone will do with it, nor whether there'd be value in any particular format for the information. I also don't know whether there's any corresponding machine-readable piece information. For signatures, in particular: > 4.2.14. The "metalink:signature" Element > > The "metalink:signature" element is a Text construct that conveys a > digital signature for a file described in a Metalink Document. > > metalinkSignature = > element metalink:signature { > attribute type { "pgp" }, > metalinkTextConstruct > } I gather from that that "pgp" is the only signature type supported; that's unfortunate. Are there no other attributes that will be needed in order to support different signature types? Planning that now will help extensibility later. >From section 6: > Producers of Metalinks may have sound reasons for signing and/or > encrypting otherwise-unprotected content. I think this downplays the importance of signing these things; I rather think that signing them should become the norm, not the exceptional case that's only used if there are "sound reasons". > Metalink Processors MUST NOT reject an Metalink Document containing > such a signature because they are not capable of verifying it; they > MUST continue processing and MAY inform the user of their failure to > validate the signature. Ooh. I'd want to know why. This is certainly a MUST that I would violate if I had a system that decided it would only accept metalink documents that were signed. And I can definitely see sound reasons for having such a system. > Other elements in an Metalink Document MUST NOT be signed unless > their definitions explicitly specify such a capability. I don't understand this. What is the scope of a signature on a metalink document, then? I should think it would protect the whole document. Is this trying to say that there must not be embedded signatures inside a signed document? If so, then it should be clearer. If it means something else, I don't understand. > Section 4.4.2 of [REC-xmldsig-core] requires support for DSA > signatures and recommends support for RSA signatures. However, > because of the much greater popularity in the market of RSA versus > DSA Yeh, that's odd. I initially thought it was because of the RSA patent, but that expired in 2000, and the W3C document is from 2002. [shrug] I do think it's reasonable for this document to reverse the requirements for RSA and DSA, as it does. Section 9, Security Considerations, seems inadequate. The base section says, essentially, "you're encouraged to use authenticated HTTP under TLS, and you're encouraged to sign the files you're going to transfer" (but not the metalink documnts). There are perfectly good reasons not to use authenticated HTTP (distributing public documents, for instance), but TLS will often still make sense (to confirm the server's identity), signatures on the metadata are still important (preventing attacks that present spurious documents), and so on. Section 9.2 does address that last point somewhat, but (1) I disagree with the "at best" and "at worst" cases there, and (2) there's no recommendation about what to do. I think the severity of potential attacks is greater than what's presented here. I see no reason there shouldn't be a SHOULD here for signing the metalink document, and that would address the broader spoofing issue. Section 9.3 says they "can" be signed, but makes no recommendation. Those are comments from an first look. Barry Leiba IAB member, and DKIM working group chair _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 08:27:35 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5E728C143; Tue, 30 Sep 2008 08:27:35 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA0D28C0EB for ; Tue, 30 Sep 2008 08:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[AWL=1.480, BAYES_00=-2.599, J_CHICKENPOX_48=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 j3M0U9MTnos2 for ; Tue, 30 Sep 2008 08:26:43 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 70E9E28C0FD for ; Tue, 30 Sep 2008 08:26:43 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UFR4aJ015012 for ; Tue, 30 Sep 2008 11:27:04 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UBcIgp031060 for ; Tue, 30 Sep 2008 07:38:18 -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 m8UBcBro009212 for ; Tue, 30 Sep 2008 07:38:11 -0400 (EDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by mit.edu (Spam Firewall) with ESMTP id BCBB9B69C70 for ; Tue, 30 Sep 2008 07:38:09 -0400 (EDT) Received: by mu-out-0910.google.com with SMTP id w8so2122597mue.8 for ; Tue, 30 Sep 2008 04:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=eclQdtcX5SqXeFO8a1LSsbbMqeV6nrM0ZtZWnndHXUw=; b=fLkj41ai4qQEhFfVMLQuA3N3DOeXxKu4MV5V31C1/l1l+0SugITpIxXhaBujaofunG XaOUcj6f9RMZJU/UJEXYJ1+2N+9r+F/QkBxiwFhFrvfg3OBdtHjcMuUCxmBgdi9V/fMv m7Q1h/l9myrMGR/y+vUCnv9wrFhPPcDvEzhwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YUrS6je77g8RgnAbuulzm48kJ5r0OpZZzG2JWa3F9y+gKMr2xn9eyBbS9JRCS9vxFU RX6uOPc9nCWavx/lLIBlUN5esnd7VaxZMFPKRBawHV60+uSHA8g3wS4L1VbiQ0j1bVIf g3BmtSCPgCvyB3G3r0Y1XEoAUfvQfyIpPkTGM= Received: by 10.181.19.15 with SMTP id w15mr3013618bki.46.1222774688587; Tue, 30 Sep 2008 04:38:08 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Tue, 30 Sep 2008 04:38:08 -0700 (PDT) Message-ID: <77ead0ec0809300438v5b126628t69d2388971eb6026@mail.gmail.com> Date: Tue, 30 Sep 2008 17:08:08 +0530 From: "Vishwas Manral" To: "Sam Hartman" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 30 Sep 2008 11:27:03 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: X-Mailman-Approved-At: Tue, 30 Sep 2008 08:27:35 -0700 Cc: msec@ietf.org, tsvwg@ietf.org, edward.jankiewicz@sri.com, ospf@ietf.org, secdir@mit.edu, rpsec@ietf.org, dward@cisco.com, sidr@ietf.org, rcallon@juniper.net Subject: Re: [secdir] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Sam, Thanks for the queries. First off the draft is located at http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 and details issues in security even after the current set of security mechanisms are in place. Some issues are well known in the security community like trying to discourage the use of MD5 and instead use HMAC-SHA1 and HMAC-MD5. We have already got drafts for the same to support them in OSPF and ISIS. The issue we have here is the requirement in IPsec of the deployment of authentication identities and credentials and having a authenticating infrastructure (trusted third-party) reachable even before any of the routes are learned. What I was proposing was to instead start off using IPsec in BTNS mode (with say a GTSM check for IKE packets as the authentication mechanism for IKE packets - and no 3rd aprty authentication) and learn routes. Once this happens an optional second level of stronger authentication can be done as all routes are now available (if it is so desired). So we get the complete IPsec security - except for the fact that we rely on TTL mechanisms for the IKE at the beginning. Do let me know what you think about the idea? Thanks, Vishwas On 9/30/08, Sam Hartman wrote: >>>>>> "Vishwas" == Vishwas Manral writes: > > Vishwas> We can also solve the problem similarly by something like > Vishwas> BTNS(ofcourse Multicast part needs to be thought further) > Vishwas> which does not necessarily require any certificate > Vishwas> verification - so we may have unauthenticated IKE SA's > Vishwas> but then all keys for the CHILD_SA from there are > Vishwas> automatically generated. > > > Let me see if I understand this approach correctly. I want to > interact with OSPF. Somehow there is a group key that is in use on my > link. In order to obtain this key, I exchange in an unauthenticated > BTNS-style exchange with someone, and as a result of that exchange, > obtain the key? > > First, who do I perform this exchange with? Anyone who currently holds the > key? > > Second, what threats does this protect against? > > Finally, one of the things we typically desire from BTNS-style > protocols is a way to turn them into higher-infrastructure protocols when > the infrastructure is available. Can I do that with your approach? How? > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 08:40:05 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69883A6B67; Tue, 30 Sep 2008 08:40:05 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE6C3A6A21 for ; Tue, 30 Sep 2008 08:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_48=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 Mt7k359ZOCom for ; Tue, 30 Sep 2008 08:32:25 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 07E8E3A68D2 for ; Tue, 30 Sep 2008 08:32:24 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UFR4ql015017 for ; Tue, 30 Sep 2008 11:27:04 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UEwcot007304 for ; Tue, 30 Sep 2008 10:58:38 -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 m8UEwVqk018219 for ; Tue, 30 Sep 2008 10:58:32 -0400 (EDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 694C6B5D047 for ; Tue, 30 Sep 2008 10:58:11 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.33,338,1220227200"; d="scan'208";a="22755665" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Sep 2008 14:58:10 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8UEwAXs027514; Tue, 30 Sep 2008 10:58:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8UEwA7G017586; Tue, 30 Sep 2008 14:58:10 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 10:58:10 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 10:58:10 -0400 In-Reply-To: <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: David Ward Date: Tue, 30 Sep 2008 09:57:58 -0500 To: Vishwas Manral X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 30 Sep 2008 14:58:10.0273 (UTC) FILETIME=[F4579510:01C9230C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=823; t=1222786690; x=1223650690; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[sidr]=20[RPSEC]=20Authentication=20for =20OSPFv3 |Sender:=20 |To:=20Vishwas=20Manral=20; bh=tFXiwh+WTtTP0RnByjHyaIO2wgDgC7AL3gGhDmOHzNc=; b=PfzcOQhYIM6dKWm1lS4CGZ3Ewlhh3NU9tTOLxNX5wGyFH6J2tfIi+3klV4 iJJ79+ITAMraESiTBeEbAjGHWhXH73/+iXliTnH+T8J8+WFrwnpcvcHSE5sZ BzKe4y8BnV; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 30 Sep 2008 11:27:03 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: X-Mailman-Approved-At: Tue, 30 Sep 2008 08:40:00 -0700 Cc: msec@ietf.org, tsvwg@ietf.org, OSPF List , Ronald Bonica , secdir@mit.edu, rpsec@ietf.org, David Ward , sidr@ietf.org, Ross Callon Subject: Re: [secdir] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Directions are to send your draft to opsec WG. To get it on their charter, you have to request the doc to become a WG item and then discussion will follow -DWard On Sep 29, 2008, at 8:53 PM, Vishwas Manral wrote: > Hi Sandy, > > Thanks for refering to my draft in your mail. The same was presented > by Dave (Ward) in the last IETF. Regarding the state of the draft, > because the RPSEC is closing down, we have been trying to find a home > for the draft. > > We can also solve the problem similarly by something like > BTNS(ofcourse Multicast part needs to be thought further) which does > not necessarily require any certificate verification - so we may have > unauthenticated IKE SA's but then all keys for the CHILD_SA from there > are automatically generated. > > Thanks, > Vishwas > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 08:40:05 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96003A6BA8; Tue, 30 Sep 2008 08:40:05 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34BC3A6A21 for ; Tue, 30 Sep 2008 08:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, J_CHICKENPOX_48=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 Pmny-+Q3YLpa for ; Tue, 30 Sep 2008 08:37:59 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D7E4D3A6B92 for ; Tue, 30 Sep 2008 08:37: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 m8UFR5Ec015022 for ; Tue, 30 Sep 2008 11:27:05 -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 m8UF8qW5010188 for ; Tue, 30 Sep 2008 11:08:52 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m8UF8hUx005031 for ; Tue, 30 Sep 2008 11:08:44 -0400 (EDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by mit.edu (Spam Firewall) with ESMTP id F3ED51105E60 for ; Tue, 30 Sep 2008 11:08:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 349ABA05F69; Tue, 30 Sep 2008 08:08:19 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27471-08; Tue, 30 Sep 2008 08:08:18 -0700 (PDT) Received: from [IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 4A307A05F6D; Tue, 30 Sep 2008 08:08:17 -0700 (PDT) In-Reply-To: References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Acee Lindem Date: Tue, 30 Sep 2008 11:08:15 -0400 To: David Ward X-Mailer: Apple Mail (2.753.1) X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 30 Sep 2008 11:27:03 -0400 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: X-Mailman-Approved-At: Tue, 30 Sep 2008 08:40:05 -0700 Cc: msec@ietf.org, tsvwg@ietf.org, rpsec@ietf.org, Ronald Bonica , secdir@mit.edu, Vishwas Manral , OSPF List , sidr@ietf.org, Ross Callon Subject: Re: [secdir] [OSPF] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org One thing to take into consideration is that the outcome of our KMART BOF was that nobody deploying networks wanted routing infra-structure based on a third-part verified certificates. Thanks, Acee On Sep 30, 2008, at 10:57 AM, David Ward wrote: > Directions are to send your draft to opsec WG. To get it on their > charter, you have to request the doc to become a WG item and then > discussion will follow > > -DWard > > On Sep 29, 2008, at 8:53 PM, Vishwas Manral wrote: > >> Hi Sandy, >> >> Thanks for refering to my draft in your mail. The same was presented >> by Dave (Ward) in the last IETF. Regarding the state of the draft, >> because the RPSEC is closing down, we have been trying to find a home >> for the draft. >> >> We can also solve the problem similarly by something like >> BTNS(ofcourse Multicast part needs to be thought further) which does >> not necessarily require any certificate verification - so we may have >> unauthenticated IKE SA's but then all keys for the CHILD_SA from >> there >> are automatically generated. >> >> Thanks, >> Vishwas >> >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 08:42:38 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06AD28C15C; Tue, 30 Sep 2008 08:42:38 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6AF28C156 for ; Tue, 30 Sep 2008 08:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.766 X-Spam-Level: X-Spam-Status: No, score=-4.766 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, J_CHICKENPOX_48=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 9FI1raM38-ie for ; Tue, 30 Sep 2008 08:42:32 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 0EF7028C0F0 for ; Tue, 30 Sep 2008 08:42:31 -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 m8UFgrGX020386 for ; Tue, 30 Sep 2008 11:42:53 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UFgqM7020382 for ; Tue, 30 Sep 2008 11:42:52 -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 m8UFggwG003696 for ; Tue, 30 Sep 2008 11:42:43 -0400 (EDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mit.edu (Spam Firewall) with ESMTP id 91C2312FA5C2 for ; Tue, 30 Sep 2008 11:42:19 -0400 (EDT) Received: by mu-out-0910.google.com with SMTP id w8so50165mue.8 for ; Tue, 30 Sep 2008 08:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ZfukToRpUEYzI910/NW2dROJLeFPGQzANQu+xjezZes=; b=Ht9rDJWsO8rad3+Gk7+OUAH4P7aLIriNGiQafd3xA9pK6pK0kQ+hAe2lIfXkahLWJ+ JnJdp51GOstUlw2lIQW/M+OnvlEIM83wEYTgHuOQ7OMUJ+UBD8RqTxdTEx2zLA8GMlOO hsyPD9Lqt8li48SoNYlMHJIs1urEz6nKClChM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=oVX2OzkqQTYvofh/UdIHpKkIlxWLekxJHe6sOlBSyzZbonMjVb3bB813XsOLimwRDz 4HSPUUzWC/zTnW5x2xkbXaj7iE/iRiu+0b8Jn4U5P7YsukhCqx42Gvhm2OBLIhWvnKol 0+ehgjMP//kq34dShjFjXIS53aGF7gEIzZtzc= Received: by 10.180.212.1 with SMTP id k1mr3257295bkg.58.1222789338567; Tue, 30 Sep 2008 08:42:18 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Tue, 30 Sep 2008 08:42:18 -0700 (PDT) Message-ID: <77ead0ec0809300842i200798d5ic45f7996a19d57d@mail.gmail.com> Date: Tue, 30 Sep 2008 21:12:18 +0530 From: "Vishwas Manral" To: "Acee Lindem" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: msec@ietf.org, tsvwg@ietf.org, rpsec@ietf.org, Ronald Bonica , secdir@mit.edu, OSPF List , David Ward , sidr@ietf.org, Ross Callon Subject: Re: [secdir] [OSPF] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org Hi Acee, I agree to what you say and the general sense of the room in the KMART BOF. That is the reason I proposed a BTNS based solution. Which uses GTSM in the IKe to do the first level security. Also as IGP run within an administrative domain we can actually do without third party verification. Hi Dave, Thanks for your help and shepherding as always. The issue about adopting the draft was raised in the OPSEC WG by the chair Joel, however we only had a handful of mails saying the draft was within the scope (though none were opposed to it). Thanks, Vishwas On 9/30/08, Acee Lindem wrote: > One thing to take into consideration is that the outcome of our KMART > BOF was that nobody deploying networks wanted routing infra-structure > based on a third-part verified certificates. > Thanks, > Acee > On Sep 30, 2008, at 10:57 AM, David Ward wrote: > >> Directions are to send your draft to opsec WG. To get it on their >> charter, you have to request the doc to become a WG item and then >> discussion will follow >> >> -DWard >> >> On Sep 29, 2008, at 8:53 PM, Vishwas Manral wrote: >> >>> Hi Sandy, >>> >>> Thanks for refering to my draft in your mail. The same was presented >>> by Dave (Ward) in the last IETF. Regarding the state of the draft, >>> because the RPSEC is closing down, we have been trying to find a home >>> for the draft. >>> >>> We can also solve the problem similarly by something like >>> BTNS(ofcourse Multicast part needs to be thought further) which does >>> not necessarily require any certificate verification - so we may have >>> unauthenticated IKE SA's but then all keys for the CHILD_SA from >>> there >>> are automatically generated. >>> >>> Thanks, >>> Vishwas >>> >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 09:06:14 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1295128C110; Tue, 30 Sep 2008 09:06:14 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FD528C0F0 for ; Tue, 30 Sep 2008 09:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[AWL=1.860, 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 8vh1WI5jwXHo for ; Tue, 30 Sep 2008 09:06:09 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 314FF3A67E7 for ; Tue, 30 Sep 2008 09:06: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 m8UG6A3o028837 for ; Tue, 30 Sep 2008 12:06: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 m8UG68hs028798 for ; Tue, 30 Sep 2008 12:06: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 m8UG60NT023344 for ; Tue, 30 Sep 2008 12:06:00 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu (Spam Firewall) with ESMTP id 7EF65103D5A2 for ; Tue, 30 Sep 2008 12:05:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0A4C0422C; Tue, 30 Sep 2008 12:05:28 -0400 (EDT) From: Sam Hartman To: Acee Lindem References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Date: Tue, 30 Sep 2008 12:05:28 -0400 In-Reply-To: (Acee Lindem's message of "Tue, 30 Sep 2008 11:08:15 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: OSPF List , Ronald Bonica , secdir@MIT.EDU, Vishwas Manral , rpsec@ietf.org, David Ward , sidr@ietf.org, Ross Callon Subject: Re: [secdir] [OSPF] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >>>>> "Acee" == Acee Lindem writes: Acee> One thing to take into consideration is that the outcome of Acee> our KMART BOF was that nobody deploying networks wanted Acee> routing infra-structure based on a third-part verified Acee> certificates. Thanks, Acee Acee> On Sep 30, 2008, at 10:57 AM, David Ward wrote: Hmm. I actually did not get a strong sense of any particular conclusions from that BOF. People made it clear that having the routing infrastructure fail because some security-related third party was unavailable was an operational non-starter. It's certainly true that some people in the room spoke out against certificates. At least some of the reasons given did not actually inherently apply to certificates as a whole although they did create some significant constraints for what would not create operational problems. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 09:13:34 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628C028C184; Tue, 30 Sep 2008 09:13:34 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8223A6B36 for ; Tue, 30 Sep 2008 09:13:33 -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 Jwy46MczbmG1 for ; Tue, 30 Sep 2008 09:13:32 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 8C5FB3A6B60 for ; Tue, 30 Sep 2008 09:13:31 -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 m8UGDaYk031640 for ; Tue, 30 Sep 2008 12:13:36 -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 m8UGDZwP031634 for ; Tue, 30 Sep 2008 12:13:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m8UGDQZ6002343 for ; Tue, 30 Sep 2008 12:13:26 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4F8661153F5C for ; Tue, 30 Sep 2008 12:12:59 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.33,338,1220227200"; d="scan'208";a="84812259" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 30 Sep 2008 16:12:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m8UGCw40002981; Tue, 30 Sep 2008 09:12:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8UGCv3B026482; Tue, 30 Sep 2008 16:12:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 09:12:58 -0700 Received: from [10.32.244.214] ([10.32.244.214]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Sep 2008 09:12:57 -0700 In-Reply-To: <20080929200231.3E5DD3F443@pecan.tislabs.com> References: <20080929200231.3E5DD3F443@pecan.tislabs.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <174D7A1B-7E6F-4B98-94A8-8174803723E1@cisco.com> From: Brian Weis Date: Tue, 30 Sep 2008 09:14:41 -0700 To: Sandy Murphy X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 30 Sep 2008 16:12:57.0962 (UTC) FILETIME=[673694A0:01C92317] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3675; t=1222791178; x=1223655178; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20[Tsvwg]=20[RPSEC]=20Authentication=20fo r=20OSPFv3 |Sender:=20; bh=KjgDb/hr33RoXazjjqvua8isYhWhUH5Kth/XJmjLj5c=; b=vOxaQOecIl33DdvKWNRYvZ0H9rrDVpjXmCTgGtPvSd/FkYUgPD0+fkALUc cILTFKR5kGsuJNbyo9+v8W8UFBeCkm1/a9QMi3TMHrHuhzCDa9F/uOdPREhK mQj65P1qYy; Authentication-Results: sj-dkim-3; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Cc: msec@ietf.org, tsvwg list IETF , edward.jankiewicz@sri.com, ospf@ietf.org, "secdir@MIT.EDU" , rpsec@ietf.org, David Ward , sidr@ietf.org, Ross Callon Subject: Re: [secdir] [Tsvwg] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org On Sep 29, 2008, at 1:02 PM, Sandy Murphy wrote: >> What (if any) current initiatives are there that would support >> automated >> key exchange for OSFPv3 authentication? > > You have msec on the list of recipients, which is where I (not an > active > participant, mind you) think the answer lies. I agree with Sandy. > Both GDOI (RFC 3547) and > GSAKMP (RFC 4535) are group key management protocols, which is what > OSPFv3 needs. Unfortunately, both assume the existence of a group > controller that plays an important role in distributing keys. In > other > words, the very democratic all-are-equal many-to-many model of OSPF > might find it > difficult to map to the envisioned group security architecture. I > suppose it might be possible to consider the Designated Router as the > group controller, but as the DR is elected, that might be a > difficult fit. There is an expired individual I-D that explores several options along these lines: . However, there isn't (in my opinion) an obvious way forward. We can allocate some time on the Minneapolis MSEC WG agenda on this topic if there's sufficient interest. Brian > Even if you solve the group key management problem for OSPFv3, you > still > have the difficulty to doing anti-replay in a multicast environment. > Manral presented a draft some years ago to the rpsec working group > about > the crypto vulnerabilities of routing protocols, and concentrated for > OSPFv3 on replay vulnerabilities. Unfortunately, that did not go > anywhere. > > Just for fun, I'm adding the routing area ADs and the secdir on > this list. > This is one of those cross-disciplinary concerns that has the right > people > in several different wgs and areas. The more the merrier, right? > > The one quibble I have is that the tsvwg probably has little to do > with this > problem - the transport for OSPFv3 is IP, not TCP, and IP is not > the level > of stuff their charter looks at. > > (And sorry for the late reply to your messages, I've been mulling > the options.) > > --Sandy > > --------- In reply to ------------------------ > > Date: Tue, 23 Sep 2008 17:52:07 -0400 > From: Ed Jankiewicz > To: ospf@ietf.org, rpsec@ietf.org, sidr@ietf.org, msec@ietf.org, > tsvwg@ietf.org > Subject: [RPSEC] Authentication for OSPFv3 > > I am not an active follower of these lists but have a question. > Please > reply off-list directly to ed.jankiewicz@sri.com or copy me if this > triggers relevant discussion on your list. > > What (if any) current initiatives are there that would support > automated > key exchange for OSFPv3 authentication? RFC 4552 relies upon pre- > shared > secret keys for generating message digest, but some of my constituents > have issues with manual generation, distribution and configuration of > keys in their IPv6 network deployment. Is any of the current work on > IKE revisions applicable, any work being done in your working > group, or > do you know of any OSPF-specific solution being developed somewhere? > > Thanks. > > -- > Ed Jankiewicz - SRI International > Fort Monmouth Branch Office - IPv6 Research > Supporting DISA Standards Engineering Branch > 732-389-1003 or ed.jankiewicz@sri.com > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/rpsec > -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 09:30:46 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E994528C164; Tue, 30 Sep 2008 09:30:46 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB08228C164 for ; Tue, 30 Sep 2008 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 2cX3bs8EIzzc for ; Tue, 30 Sep 2008 09:30:45 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id CC3A128C159 for ; Tue, 30 Sep 2008 09:30:44 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UGV5Sm004649 for ; Tue, 30 Sep 2008 12:31:05 -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 m8UGV4iu004646 for ; Tue, 30 Sep 2008 12:31:04 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m8UGUu5r004141 for ; Tue, 30 Sep 2008 12:30:56 -0400 (EDT) Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by mit.edu (Spam Firewall) with ESMTP id 46AB91049D36 for ; Tue, 30 Sep 2008 12:30:35 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m8UGTuJa016359; Tue, 30 Sep 2008 12:29:56 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAt_aW8F; Tue, 30 Sep 08 12:29:56 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id C92963F446; Tue, 30 Sep 2008 12:28:23 -0400 (EDT) To: acee@redback.com, vishwas.ietf@gmail.com In-Reply-To: <77ead0ec0809300842i200798d5ic45f7996a19d57d@mail.gmail.com> Message-Id: <20080930162823.C92963F446@pecan.tislabs.com> Date: Tue, 30 Sep 2008 12:28:23 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: MIME-Version: 1.0 Cc: msec@ietf.org, tsvwg@ietf.org, ospf@ietf.org, rbonica@juniper.net, secdir@mit.edu, rpsec@ietf.org, sidr@ietf.org, rcallon@juniper.net Subject: Re: [secdir] [OSPF] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org >I agree to what you say and the general sense of the room in the KMART BOF. >That is the reason I proposed a BTNS based solution. Which uses GTSM >in the IKe to do the first level security. I am not quite sure I understand the use of GTSM here. The need for authentication for OSPF is that you don't trust that everyone on the local broadcast link is OK. GTSM tells you that the sender came from one-hop away, i.e., on the local broadcast link. Since you already know that you don't trust everyone one-hop away, how does the use of GTSM help? --Sandy _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 09:38:14 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D504228C199; Tue, 30 Sep 2008 09:38:14 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5676F28C19B for ; Tue, 30 Sep 2008 09:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 4W4NyHcGtS62 for ; Tue, 30 Sep 2008 09:38:12 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5D4C128C164 for ; Tue, 30 Sep 2008 09:38:12 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UGcVG6007494 for ; Tue, 30 Sep 2008 12:38:31 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m8UGcTMI007483 for ; Tue, 30 Sep 2008 12:38:29 -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 m8UGcMVq023178 for ; Tue, 30 Sep 2008 12:38:22 -0400 (EDT) Received: from nutshell.tislabs.com (ns1.tislabs.com [192.94.214.100]) by mit.edu (Spam Firewall) with ESMTP id 247F9103921F for ; Tue, 30 Sep 2008 12:38:01 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m8UGbaHB016363; Tue, 30 Sep 2008 12:37:36 -0400 (EDT) Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAmAaq9F; Tue, 30 Sep 08 12:37:36 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 558D13F46F; Tue, 30 Sep 2008 12:36:04 -0400 (EDT) To: acee@redback.com, vishwas.ietf@gmail.com In-Reply-To: <77ead0ec0809300842i200798d5ic45f7996a19d57d@mail.gmail.com> Message-Id: <20080930163604.558D13F46F@pecan.tislabs.com> Date: Tue, 30 Sep 2008 12:36:04 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: MIME-Version: 1.0 Cc: msec@ietf.org, tsvwg@ietf.org, ospf@ietf.org, rbonica@juniper.net, secdir@mit.edu, rpsec@ietf.org, sidr@ietf.org, rcallon@juniper.net Subject: Re: [secdir] [OSPF] [sidr] [RPSEC] Authentication for OSPFv3 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org By the way, to everyone who sees this message, the mail chain is really broken. Ed's message did not get to all the wg lists on his message, and I got several "too many recipients" errors on my reply. If you look at the mail archives for the various wg, not any of them have caught all the messages that have been send. I think the secdir archive got most of the messages (except the one that Dave Ward cut down to just the rpsec list :-)), but it is not a public list. I'm not even sure that Ed, who originally posed the question, is seeing the exchange. (Ed's message was attached to my reply, if you saw that.) I was able to push out the messages that got trapped for the sidr list, but if any other wg chairs could do their bit, maybe the conversation will be less fractured. Or maybe we should just all choose one list to do the conversation. --Sandy _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From secdir-bounces@ietf.org Tue Sep 30 13:09:54 2008 Return-Path: X-Original-To: secdir-archive@ietf.org Delivered-To: ietfarch-secdir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2BF28C136; Tue, 30 Sep 2008 13:09:54 -0700 (PDT) X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A0928C10C for ; Tue, 30 Sep 2008 13:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oJ0zw9l-Cs9 for ; Tue, 30 Sep 2008 13:09:52 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id EBAFC28C136 for ; Tue, 30 Sep 2008 13:09:51 -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 m8UK9eVX028974 for ; Tue, 30 Sep 2008 16:09:40 -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 m8UK9dIC028963 for ; Tue, 30 Sep 2008 16:09:39 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m8UK9VUo014993 for ; Tue, 30 Sep 2008 16:09:31 -0400 (EDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B700810C3348 for ; Tue, 30 Sep 2008 16:09:10 -0400 (EDT) Received: from [10.20.30.152] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8UK93X3015195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 13:09:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <224856.81582.qm@web31809.mail.mud.yahoo.com> References: <224856.81582.qm@web31809.mail.mud.yahoo.com> Date: Tue, 30 Sep 2008 13:09:01 -0700 To: saag@ietf.org, secdir@mit.edu From: Paul Hoffman X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Subject: Re: [secdir] [saag] Pasi's AD notes for September 2008 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@ietf.org Errors-To: secdir-bounces@ietf.org At 1:21 PM +0300 9/30/08, wrote: >- There have been two security-related BoF requests for IETF73: > OAuth (in the applications area), and Content Rights Management > (in the security area). For the latter, Tim and I have recommended > having a bar BoF first. At 11:27 AM -0700 9/30/08, Thomas Hardjono wrote: >Not that I'm unsupportive, but I was wondering what is motivating >the IETF to propose such a BOF again at this time :) I do not read Pasi's note as the IETF proposing anything: he said that there was a request for some to have the BoF. The fact that Pasi and Tim have suggested that this be a bar BoF first may give an indication of how excited they are about this work. I, for one, hope to be far, far away from that bar BoF when it happens. --Paul Hoffman, Director --VPN Consortium _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir