From mailman-bounces@ietf.org Fri Oct 1 05:27:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09660 for ; Fri, 1 Oct 2004 05:27:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDJq7-0002ZG-CX for isms-archive@ietf.org; Fri, 01 Oct 2004 05:36:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJIB-0001fW-PC for isms-archive@ietf.org; Fri, 01 Oct 2004 05:01:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: isms-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:00:30 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for isms-archive@ietf.org: List Password // URL ---- -------- isms@lists.ietf.org riufwi https://www1.ietf.org/mailman/options/isms/isms-archive%40ietf.org From isms-bounces@ietf.org Fri Oct 8 14:36:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19666; Fri, 8 Oct 2004 14:36:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzkx-0005Sl-U2; Fri, 08 Oct 2004 14:46:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzTg-00049q-5A; Fri, 08 Oct 2004 14:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzHj-0001ew-JL for isms@megatron.ietf.org; Fri, 08 Oct 2004 14:16:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17823 for ; Fri, 8 Oct 2004 14:16:08 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzRj-0004wJ-Ax for isms@ietf.org; Fri, 08 Oct 2004 14:26:27 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i98IG1Bj020199 for ; Fri, 8 Oct 2004 14:16:02 -0400 (EDT) Message-Id: <200410081816.i98IG1Bj020199@ginger.cmf.nrl.navy.mil> To: isms@ietf.org X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 08 Oct 2004 14:16:01 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Isms] Reminder: ISMS proposals due October 18th X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Howdy everyone, This is just a friendly reminder to everyone that ISMS candidates submissions are due by October 18th (the cutoff for -00 submissions for the upcoming IETF). Submissions do not need to be full-fledged, but should at least give a general overview of the proposed solution. In addition to this deadline, if you want your proposal considered as a candidate by the WG, you must respond to this note to the WG mailing list with the file name of the proposal draft. --Ken, your friendly ISMS WG co-chair _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Oct 10 10:06:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12174; Sun, 10 Oct 2004 10:06:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGeVB-0008C6-TJ; Sun, 10 Oct 2004 10:16:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGeGq-0005KC-7K; Sun, 10 Oct 2004 10:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGeG1-0004Ut-Cy for isms@megatron.ietf.org; Sun, 10 Oct 2004 10:01:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11740 for ; Sun, 10 Oct 2004 10:01:03 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGeQL-00087e-K2 for isms@ietf.org; Sun, 10 Oct 2004 10:11:47 -0400 Received: from dialin-145-254-223-167.arcor-ip.net (dialin-145-254-223-167.arcor-ip.net [145.254.223.167]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B52401BAC4D for ; Sun, 10 Oct 2004 16:00:28 +0200 (CEST) Date: Sun, 10 Oct 2004 16:00:38 +0200 From: Juergen Quittek To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th Message-ID: <2147483647.1097424038@dialin-145-254-223-167.arcor-ip.net> In-Reply-To: <200410081816.i98IG1Bj020199@ginger.cmf.nrl.navy.mil> References: <200410081816.i98IG1Bj020199@ginger.cmf.nrl.navy.mil> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit --On 08.10.2004 14:16 h -0400 Ken Hornstein wrote: > Howdy everyone, > > This is just a friendly reminder to everyone that ISMS candidates submissions > are due by October 18th (the cutoff for -00 submissions for the upcoming > IETF). Submissions do not need to be full-fledged, but should at least give > a general overview of the proposed solution. At the BoF session in San Diego, five proposals were under discussion: - EUSM - External User security Model draft-kaushik-snmp-external-usm-00.txt - KSM - Kerberos Security Model draft-hornstein-snmpv3-ksm-02.txt - SBSM - Session-Based Security Model draft-hardaker-snmp-session-sm-02.txt - MIASMA - Minimally Integrated Access Security Module Application - TLS - Transport Layer Security no presentation but some participants considered this as a candidate For EUSM, KSM and SBSM we have current Internet drafts and I think all of them are sufficient for evaluating the proposal (although more elaboration would be desirable in one or the other case). There has been no visible activity concerning MIASMA and TLS. Does anybody have a strong feeling that these should be considered in our evaluation of proposals? If yes, please speak up on this list and/or contact Randy Presuhn (randy_presuhn@mindspring.com) for MIASMA or Juergen Schoenwaelder (j.schoenwaelder@iu-bremen.de) for TLS. > In addition to this deadline, if you want your proposal considered as a > candidate by the WG, you must respond to this note to the WG mailing > list with the file name of the proposal draft. Please do so also for the three proposals where there are already I-Ds available. We need a contact person for each proposal who is willing to answer questions from the evaluators. (In the IPFIX protocol evaluation we called these people 'protocol advocates'.) Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Oct 10 12:18:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21848; Sun, 10 Oct 2004 12:18:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGgZe-0001rC-1G; Sun, 10 Oct 2004 12:29:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGgOB-0004OV-CE; Sun, 10 Oct 2004 12:17:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGgLD-0003Nj-Rj for isms@megatron.ietf.org; Sun, 10 Oct 2004 12:14:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21638 for ; Sun, 10 Oct 2004 12:14:32 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGgVY-0001mj-UC for isms@ietf.org; Sun, 10 Oct 2004 12:25:18 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9AGE16H003828; Sun, 10 Oct 2004 09:14:01 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 10 Oct 2004 09:14:02 -0700 Message-ID: From: "McDonald, Ira" To: "'Juergen Quittek'" , isms@ietf.org Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Sun, 10 Oct 2004 09:14:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi, I'm strongly in favor of consideration of TLS (or rather DTLS, per Eric Rescorla's draft, so that connection-mode issues/behaviors are not introduced). I'm willing to be a co-editor, but we'd need a more expert SNMPv3 co-editor too. Perhaps Juergen Schoenwaelder would be interested? Cheers, - Ira, co-editor of Printer MIB v2 and Finisher MIB PS - The latest draft of DTLS (19 July 2004) is: ftp://ftp.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Juergen Quittek Sent: Sunday, October 10, 2004 10:01 AM To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th --On 08.10.2004 14:16 h -0400 Ken Hornstein wrote: > Howdy everyone, > > This is just a friendly reminder to everyone that ISMS candidates submissions > are due by October 18th (the cutoff for -00 submissions for the upcoming > IETF). Submissions do not need to be full-fledged, but should at least give > a general overview of the proposed solution. At the BoF session in San Diego, five proposals were under discussion: - EUSM - External User security Model draft-kaushik-snmp-external-usm-00.txt - KSM - Kerberos Security Model draft-hornstein-snmpv3-ksm-02.txt - SBSM - Session-Based Security Model draft-hardaker-snmp-session-sm-02.txt - MIASMA - Minimally Integrated Access Security Module Application - TLS - Transport Layer Security no presentation but some participants considered this as a candidate For EUSM, KSM and SBSM we have current Internet drafts and I think all of them are sufficient for evaluating the proposal (although more elaboration would be desirable in one or the other case). There has been no visible activity concerning MIASMA and TLS. Does anybody have a strong feeling that these should be considered in our evaluation of proposals? If yes, please speak up on this list and/or contact Randy Presuhn (randy_presuhn@mindspring.com) for MIASMA or Juergen Schoenwaelder (j.schoenwaelder@iu-bremen.de) for TLS. > In addition to this deadline, if you want your proposal considered as a > candidate by the WG, you must respond to this note to the WG mailing > list with the file name of the proposal draft. Please do so also for the three proposals where there are already I-Ds available. We need a contact person for each proposal who is willing to answer questions from the evaluators. (In the IPFIX protocol evaluation we called these people 'protocol advocates'.) Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Oct 10 22:25:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04559; Sun, 10 Oct 2004 22:25:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGq2R-0004Ms-Oo; Sun, 10 Oct 2004 22:35:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGpqy-00062f-H1; Sun, 10 Oct 2004 22:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGpqT-0005vp-J7 for isms@megatron.ietf.org; Sun, 10 Oct 2004 22:23:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04400 for ; Sun, 10 Oct 2004 22:23:26 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGq0u-0004LP-1c for isms@ietf.org; Sun, 10 Oct 2004 22:34:17 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id EE6FF11D804; Sun, 10 Oct 2004 19:23:24 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: From: Wes Hardaker Organization: Sparta Date: Sun, 10 Oct 2004 19:23:24 -0700 In-Reply-To: (Ira McDonald's message of "Sun, 10 Oct 2004 09:14:00 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >>>>> On Sun, 10 Oct 2004 09:14:00 -0700, "McDonald, Ira" said: Ira> I'm strongly in favor of consideration of TLS (or rather DTLS, Ira> per Eric Rescorla's draft, so that connection-mode Ira> issues/behaviors are not introduced). Part of the motivation the ADs had in making a early deadline was to not delay for protocol options that don't have energy behind them. In my view, there are two solutions which meet my security needs: SBSM and the potential TLS. Thus, I would love to see a TLS solution documented so we should consider it. Eric's draft, however, is not a solution that can be considered by the WG, IMHO. It is a building block (a very good one), but it itself is not complete. There are many other issues to be worked out. I guess the chairs will have to decide what a minimum candidate must consist of. But just saying "lets use TLS" isn't sufficient, IMHO without a better description of how it will be used, how authentication will be done within it, how it will be passed to the SNMPv3 layer, how any other SNMPv3 specific things will be done on top of it (such as engineid learning), etc. I think all these problems are solvable, and I'd encourage someone to put together a quick draft describing the architecture they'd like to propose that solves the whole problem not just the transport problem. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 11 18:51:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07375; Mon, 11 Oct 2004 18:51:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH9Bo-00077k-4a; Mon, 11 Oct 2004 19:02:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH8nq-00040n-AT; Mon, 11 Oct 2004 18:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH8ft-0000l9-7Q for isms@megatron.ietf.org; Mon, 11 Oct 2004 18:29:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05734 for ; Mon, 11 Oct 2004 18:29:46 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH8qU-0006iW-G6 for isms@ietf.org; Mon, 11 Oct 2004 18:40:47 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 81BC511D804; Mon, 11 Oct 2004 15:29:43 -0700 (PDT) To: Juergen Quittek Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: <200410081816.i98IG1Bj020199@ginger.cmf.nrl.navy.mil> <2147483647.1097424038@dialin-145-254-223-167.arcor-ip.net> From: Wes Hardaker Organization: Sparta Date: Mon, 11 Oct 2004 15:29:43 -0700 In-Reply-To: <2147483647.1097424038@dialin-145-254-223-167.arcor-ip.net> (Juergen Quittek's message of "Sun, 10 Oct 2004 16:00:38 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >>>>> On Sun, 10 Oct 2004 16:00:38 +0200, Juergen Quittek said: Juergen> - SBSM - Session-Based Security Model Juergen> draft-hardaker-snmp-session-sm-02.txt Formally, I'd like this one to be considered. I should have a new -03 draft by the 18th but if I don't make it please consider the current -02 draft a submission instead. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 11 18:54:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07658; Mon, 11 Oct 2004 18:54:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH9EO-0007C3-Nb; Mon, 11 Oct 2004 19:05:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH8nq-000414-SN; Mon, 11 Oct 2004 18:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH8gl-0000qO-Bt for isms@megatron.ietf.org; Mon, 11 Oct 2004 18:30:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05789 for ; Mon, 11 Oct 2004 18:30:40 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH8rM-0006je-KE for isms@ietf.org; Mon, 11 Oct 2004 18:41:42 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 8C57C11D804; Mon, 11 Oct 2004 15:30:38 -0700 (PDT) To: Juergen Quittek Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: <200410081816.i98IG1Bj020199@ginger.cmf.nrl.navy.mil> <2147483647.1097424038@dialin-145-254-223-167.arcor-ip.net> From: Wes Hardaker Organization: Sparta Date: Mon, 11 Oct 2004 15:30:38 -0700 In-Reply-To: <2147483647.1097424038@dialin-145-254-223-167.arcor-ip.net> (Juergen Quittek's message of "Sun, 10 Oct 2004 16:00:38 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c >>>>> On Sun, 10 Oct 2004 16:00:38 +0200, Juergen Quittek said: Juergen> We need a contact person for each proposal who is willing to Juergen> answer questions from the evaluators. For SBSM that would be me. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 11 19:21:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09742; Mon, 11 Oct 2004 19:21:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH9e7-0007n7-N1; Mon, 11 Oct 2004 19:32:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9NF-0007cQ-HG; Mon, 11 Oct 2004 19:14:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9Jk-0006LP-Ud for isms@megatron.ietf.org; Mon, 11 Oct 2004 19:11:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08739 for ; Mon, 11 Oct 2004 19:10:57 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH9UM-0007Tf-Js for isms@ietf.org; Mon, 11 Oct 2004 19:21:59 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2004 16:16:29 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9BNAKYJ029215; Mon, 11 Oct 2004 16:10:21 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (dhcp-171-71-254-193.cisco.com [171.71.254.193]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUQ12079; Mon, 11 Oct 2004 16:09:28 -0700 (PDT) Message-Id: <6.0.0.22.0.20041011160432.03d86670@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 11 Oct 2004 16:10:23 -0700 To: Juergen Quittek From: Kaushik Narayan Subject: Re: [Isms] Reminder: ISMS proposals due October 18th In-Reply-To: <2147483647.1097424038@dialin-145-254-223-167.arcor-ip.net> References: <200410081816.i98IG1Bj020199@ginger.cmf.nrl.navy.mil> <2147483647.1097424038@dialin-145-254-223-167.arcor-ip.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Hi Juergen, Please find my reply inline. At 07:00 AM 10/10/2004, Juergen Quittek wrote: >--On 08.10.2004 14:16 h -0400 Ken Hornstein wrote: > >>Howdy everyone, >> >>This is just a friendly reminder to everyone that ISMS candidates submissions >>are due by October 18th (the cutoff for -00 submissions for the upcoming >>IETF). Submissions do not need to be full-fledged, but should at least give >>a general overview of the proposed solution. > >At the BoF session in San Diego, five proposals were under discussion: > > - EUSM - External User security Model > draft-kaushik-snmp-external-usm-00.txt I am trying to get an -01 version of the draft by the 18th of October. I will try my best to get that in, if I am unable to get that done, please consider the current version for submission. >>In addition to this deadline, if you want your proposal considered as a >>candidate by the WG, you must respond to this note to the WG mailing >>list with the file name of the proposal draft. > >Please do so also for the three proposals where there are already I-Ds >available. We need a contact person for each proposal who is willing >to answer questions from the evaluators. (In the IPFIX protocol >evaluation we called these people 'protocol advocates'.) I would be the contact person for the EUSM proposal. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 11:49:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01655; Thu, 14 Oct 2004 11:49:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI82S-000569-Vz; Thu, 14 Oct 2004 12:01:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7ow-0003Oe-Bv; Thu, 14 Oct 2004 11:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7jX-0001o0-7N for isms@megatron.ietf.org; Thu, 14 Oct 2004 11:41:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01134 for ; Thu, 14 Oct 2004 11:41:37 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI7uj-0004vT-5v for isms@ietf.org; Thu, 14 Oct 2004 11:53:13 -0400 Received: from [192.168.2.52] (YahooBB219059144059.bbtec.net [219.59.144.59]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 15B681BAC4D for ; Thu, 14 Oct 2004 17:41:05 +0200 (CEST) Date: Thu, 14 Oct 2004 17:41:01 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: <2147483647.1097775661@[192.168.2.52]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Isms] selection criteria for ISMS proposals X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Dear all, We should start discussing selection criteria for proposed ISMS solutions. Wes, at the end of the last BoF meeting you showed a slide that compared some solutions. Could put the list of criteria on this slide in an email that we can use as starting point for our discussion? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 14:32:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13720; Thu, 14 Oct 2004 14:32:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIAZl-00009b-Kc; Thu, 14 Oct 2004 14:43:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIAOE-0001VS-0A; Thu, 14 Oct 2004 14:31:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIAIn-0000ju-36 for isms@megatron.ietf.org; Thu, 14 Oct 2004 14:26:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13440 for ; Thu, 14 Oct 2004 14:26:09 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIATx-0008Uv-L8 for isms@ietf.org; Thu, 14 Oct 2004 14:37:46 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9EIPbKb011871; Thu, 14 Oct 2004 11:25:37 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PYVLBS>; Thu, 14 Oct 2004 11:25:37 -0700 Message-ID: From: "McDonald, Ira" To: "'Wes Hardaker'" , "McDonald, Ira" Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Thu, 14 Oct 2004 11:25:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi Wes, I've tried (without success) to figure out how to write a short I-D that satisfies your requests below. A few thoughts I had: - EngineID could be derived by a hash of the PKI certificate of the SNMP Agent - otherwise, EngineID discovery looks impossible to me (because a DTLS agent should NOT accept or respond to ANY traffic not authenticated at the DTLS session level) - usm/vacmSecurityName could reasonably be derived by truncating the SHA-1 (160-bit) hash of the PKI certificate of the requester (SNMP Manager) to 128 bits and converting nibbles to hex digits (to satisfy 'SnmpAdminString' constraints), which would yield 32 octets. - authentication and message integrity must be handled by DTLS - encryption (if any) must be handled by SNMPv3, because otherwise the USM MIB won't work with DTLS Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Sunday, October 10, 2004 10:23 PM To: McDonald, Ira Cc: 'Juergen Quittek'; isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th >>>>> On Sun, 10 Oct 2004 09:14:00 -0700, "McDonald, Ira" said: Ira> I'm strongly in favor of consideration of TLS (or rather DTLS, Ira> per Eric Rescorla's draft, so that connection-mode Ira> issues/behaviors are not introduced). Part of the motivation the ADs had in making a early deadline was to not delay for protocol options that don't have energy behind them. In my view, there are two solutions which meet my security needs: SBSM and the potential TLS. Thus, I would love to see a TLS solution documented so we should consider it. Eric's draft, however, is not a solution that can be considered by the WG, IMHO. It is a building block (a very good one), but it itself is not complete. There are many other issues to be worked out. I guess the chairs will have to decide what a minimum candidate must consist of. But just saying "lets use TLS" isn't sufficient, IMHO without a better description of how it will be used, how authentication will be done within it, how it will be passed to the SNMPv3 layer, how any other SNMPv3 specific things will be done on top of it (such as engineid learning), etc. I think all these problems are solvable, and I'd encourage someone to put together a quick draft describing the architecture they'd like to propose that solves the whole problem not just the transport problem. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 16:14:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24881; Thu, 14 Oct 2004 16:14:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICAZ-0002W9-Hb; Thu, 14 Oct 2004 16:25:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBxC-0003Zw-U7; Thu, 14 Oct 2004 16:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBpX-00085R-HC for isms@megatron.ietf.org; Thu, 14 Oct 2004 16:04:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23500 for ; Thu, 14 Oct 2004 16:04:04 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIC0k-0002FW-IT for isms@ietf.org; Thu, 14 Oct 2004 16:15:43 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9FA109974; Thu, 14 Oct 2004 22:03:25 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02515-04; Thu, 14 Oct 2004 22:03:24 +0200 (CEST) Received: from james (G43b8.g.pppool.de [80.185.67.184]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 740AD98F5; Thu, 14 Oct 2004 22:03:24 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CIBop-0000cG-Cc; Thu, 14 Oct 2004 22:03:23 +0200 Date: Thu, 14 Oct 2004 22:03:23 +0200 From: Juergen Schoenwaelder To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th Message-ID: <20041014200323.GA2351@james> Mail-Followup-To: "McDonald, Ira" , 'Wes Hardaker' , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Thu, Oct 14, 2004 at 11:25:37AM -0700, McDonald, Ira wrote: > A few thoughts I had: > > - EngineID could be derived by a hash of the PKI > certificate of the SNMP Agent > > - otherwise, EngineID discovery looks impossible > to me (because a DTLS agent should NOT accept > or respond to ANY traffic not authenticated > at the DTLS session level) Not sure I can follow. What is the problem with engine ID discovery? > - usm/vacmSecurityName could reasonably be derived > by truncating the SHA-1 (160-bit) hash of the > PKI certificate of the requester (SNMP Manager) > to 128 bits and converting nibbles to hex digits > (to satisfy 'SnmpAdminString' constraints), > which would yield 32 octets. Sounds pretty ugly. I think what is needed is user authentication on top of an encrypted secure channel. And that should tie into existing authentication mechanisms. (I think this was what people really asked for - but I admit that I have not been at the BOF so I might be totally disconnected.) > - authentication and message integrity must be > handled by DTLS I don't think DTLS does authentication. > - encryption (if any) must be handled by SNMPv3, > because otherwise the USM MIB won't work with DTLS I think the primary purpose of TLS or DTLS is to do encryption. Am I confused? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 16:17:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25309; Thu, 14 Oct 2004 16:17:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICEA-0002br-AR; Thu, 14 Oct 2004 16:29:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBxQ-0003oL-1r; Thu, 14 Oct 2004 16:12:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBun-0001y2-Nf for isms@megatron.ietf.org; Thu, 14 Oct 2004 16:09:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24298 for ; Thu, 14 Oct 2004 16:09:31 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIC61-0002OS-69 for isms@ietf.org; Thu, 14 Oct 2004 16:21:09 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id BFF0811D805; Thu, 14 Oct 2004 13:09:25 -0700 (PDT) To: Juergen Quittek Subject: Re: [Isms] selection criteria for ISMS proposals References: <2147483647.1097775661@[192.168.2.52]> From: Wes Hardaker Organization: Sparta Date: Thu, 14 Oct 2004 13:09:25 -0700 In-Reply-To: <2147483647.1097775661@[192.168.2.52]> (Juergen Quittek's message of "Thu, 14 Oct 2004 17:41:01 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede >>>>> On Thu, 14 Oct 2004 17:41:01 +0200, Juergen Quittek said: Juergen> Wes, at the end of the last BoF meeting you showed a slide Juergen> that compared some solutions. Could put the list of criteria Juergen> on this slide in an email that we can use as starting point Juergen> for our discussion? Actually, that list was a list of security features found in each protocol and was not a reference to requirements that the WG should consider (though obviously some would be and some wouldn't). That point was frequently misunderstood at the meeting, because people saw that some administrative ones (must not modify SNMPv3) weren't in it and some of the points that are in it they didn't care about and didn't want it to be a requirement... sigh... I was just trying to show a slide to talk about ;-) Anyway, I also sent it out a long time ago to the list. Here it is again, however. MIASMA isn't listed in it as it was new the last time I created it. We could update it if it will be in consideration (currently no one has stood up for it yet... We only have EUSM and SBSM responses so far?). Someone should word the charter requirements/comments into single-line sentences as well. USM EUSM SBSM TLS KRB5 --------------------------------------- Can use account infrastructure No AAA Yes Yes 1/2 (2) Flexible identification methods No AAA Yes Yes 1/2 (2) session-keys; No Yes Yes Yes central(1) ident != integrity (pair-wise dynamic keys) Negotiated auth/priv algorithms No No Yes Yes central(1) Negotiated SNMP Params (3) Yes Yes Yes No (5) Yes (4) True replay protection No No Yes Yes Yes True reordering protection No No 1/2 (9) Yes No TCP Yes Yes Yes Yes Yes UDP Yes Yes Yes Yes (6) Yes Others (ATM, ...) Yes Yes Yes No No Identity protection No No Yes No No Compression No No Yes Yes No PFS No No Yes Yes No (8) Anonymous but protected No ? Yes Yes No (== anon authentication; multiple integrity sessions) Different authorization types = No No Yes ? No Different Access Rights In use by other protocols No No No Yes Yes Defined Yes Yes Yes No Yes Implemented Yes Partial Partial No Yes Deployed Yes No No No Yes --------------------------------------- USM EUSM SBSM TLS KRB5 Notes: (1) central = the KDC picks what to use based on config, what the server/service supports and what the user/client supports. IE, the kdc controls the client/server negotiations. (2) It is probably possible to generate krb5 tickets from alternative mechanisms rather than negotiating typically kerberos through the KDC, though the work has not been standardized to date. (3) The important SNMP parameter that needs negotiation is the SNMP EngineID to be used for the contextEngineID. Not negotiating this would require administrators to hand-populate management stations with context engine IDs in addition to ip addresses, etc. Currently, applications get around this when using USM by assuming that the negotiated security engine ID should be the default context engine ID to use unless the user has directly specified a different one to use. (4) Ken Hornstein's KSM proposal negotiates this (in a yet-unpublished version of the draft). It's not a part of kerberos, but part of how kerberos is used in the model. (5) TLS doesn't provide generic negotiation so any negotiation would have to happen in the draft defining how TLS was to be used. It would likely have to happen *after* tls got started. (6) There is work that has been done to make TLS work over UDP: "Datagram Transport Layer Security", Eric Rescorla, 13-Jan-04, It's not standardized yet though. see (7) below as well. (8) The session keys are randomly generated, but enclosed in the tickets which are encrypted with the host and client secret keys which are long lived. If those are compromised then all previous traffic is also compromised if it was kept because the session keys can be extracted at any time after the host/client keys are broken. (9) SBSM provides true reordering protection if you set a sequence window size of 1, otherwise its a configurable level of reordering support. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 16:20:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25551; Thu, 14 Oct 2004 16:20:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICGB-0002fd-69; Thu, 14 Oct 2004 16:31:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIC3X-0007uL-Bx; Thu, 14 Oct 2004 16:18:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIC0Y-0006KA-Ux for isms@megatron.ietf.org; Thu, 14 Oct 2004 16:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24995 for ; Thu, 14 Oct 2004 16:15:28 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICBm-0002YB-Se for isms@ietf.org; Thu, 14 Oct 2004 16:27:07 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id BFDFD11D805; Thu, 14 Oct 2004 13:15:26 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: From: Wes Hardaker Organization: Sparta Date: Thu, 14 Oct 2004 13:15:26 -0700 In-Reply-To: (Ira McDonald's message of "Thu, 14 Oct 2004 11:25:37 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 >>>>> On Thu, 14 Oct 2004 11:25:37 -0700, "McDonald, Ira" said: Ira> I've tried (without success) to figure out how to Ira> write a short I-D that satisfies your requests below. Good! (well, not the without success part... but maybe I can help) Ira> - EngineID could be derived by a hash of the PKI Ira> certificate of the SNMP Agent I don't think that existing implementations should be required to change their existing context engine IDs because a different security model is suddenly needed. The security model should not need to dictate the format of the context engine ID, thus I wouldn't consider this solution. Ira> - otherwise, EngineID discovery looks impossible Ira> to me (because a DTLS agent should NOT accept Ira> or respond to ANY traffic not authenticated Ira> at the DTLS session level) I don't think so. DTLS should get things started from a secure-transport point of view, which it will do. The context engine ID isn't needed till the first processing of a real request is needed. The context engineID could be learned through security parameter settings being passed either through the DTLS session inside the protected portion of the DTLS session or by doing it afterward (DTLS comes up and the first request through it should be an empty GET which will trigger a DTLS-specific engineID report like USMs, or a GET to a special OID that always returns the default contextEngineID). The later solution requiring an extra round trip though. Ira> - usm/vacmSecurityName could reasonably be derived Ira> by truncating the SHA-1 (160-bit) hash of the Ira> PKI certificate of the requester (SNMP Manager) Ira> to 128 bits and converting nibbles to hex digits Ira> (to satisfy 'SnmpAdminString' constraints), Ira> which would yield 32 octets. Ack. No! Please! If so, at a minimum please provide a mapping table so that you could map a certificate to a SM compliant security user name. Please don't use a raw hash result. Ira> - authentication and message integrity must be Ira> handled by DTLS Yes. Ira> - encryption (if any) must be handled by SNMPv3, Ira> because otherwise the USM MIB won't work with DTLS Why does it need to? -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 17:06:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03485; Thu, 14 Oct 2004 17:06:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICyj-00050L-0L; Thu, 14 Oct 2004 17:17:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICNw-0006rt-Uj; Thu, 14 Oct 2004 16:39:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIC5N-0000ON-Q9 for isms@megatron.ietf.org; Thu, 14 Oct 2004 16:20:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25627 for ; Thu, 14 Oct 2004 16:20:27 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICGb-0002gA-RK for isms@ietf.org; Thu, 14 Oct 2004 16:32:06 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id CCAE611D805; Thu, 14 Oct 2004 13:20:25 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: <20041014200323.GA2351@james> From: Wes Hardaker Organization: Sparta Date: Thu, 14 Oct 2004 13:20:25 -0700 In-Reply-To: <20041014200323.GA2351@james> (Juergen Schoenwaelder's message of "Thu, 14 Oct 2004 22:03:23 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 >>>>> On Thu, 14 Oct 2004 22:03:23 +0200, Juergen Schoenwaelder said: >> - otherwise, EngineID discovery looks impossible >> to me (because a DTLS agent should NOT accept >> or respond to ANY traffic not authenticated >> at the DTLS session level) Juergen> Not sure I can follow. What is the problem with engine ID Juergen> discovery? In a new security model based on DTLS or TLS how does the manager learn the default contextEngineID of the agent? Either: 1) this must be "learned" somewhere in the protocol (tools implementing USM do this now by assuming that the contextEngineID will be the same as the securityEngineID if the user doesn't explicitly specify one, though this practice is not documented in the RFCs I don't think). 2) The contextEngineID under a new TLS based protocol will be forced to be entered by the manager. This is not scalable in my opinion. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 17:25:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07758; Thu, 14 Oct 2004 17:25:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDHF-0006Jl-3R; Thu, 14 Oct 2004 17:36:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICzO-0005E7-34; Thu, 14 Oct 2004 17:18:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICSE-00004y-4e for isms@megatron.ietf.org; Thu, 14 Oct 2004 16:44:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29226 for ; Thu, 14 Oct 2004 16:44:03 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICdQ-0003d5-N3 for isms@ietf.org; Thu, 14 Oct 2004 16:55:42 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1AD3196EB; Thu, 14 Oct 2004 22:43:33 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04457-07; Thu, 14 Oct 2004 22:43:32 +0200 (CEST) Received: from james (G484c.g.pppool.de [80.185.72.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id DFA407CA6; Thu, 14 Oct 2004 22:43:31 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CICRe-0001ex-LI; Thu, 14 Oct 2004 22:43:30 +0200 Date: Thu, 14 Oct 2004 22:43:25 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Reminder: ISMS proposals due October 18th Message-ID: <20041014204325.GA6370@james> Mail-Followup-To: Wes Hardaker , "McDonald, Ira" , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Thu, Oct 14, 2004 at 01:15:26PM -0700, Wes Hardaker wrote: > The context engineID could be learned through security parameter > settings being passed either through the DTLS session inside the > protected portion of the DTLS session or by doing it afterward (DTLS > comes up and the first request through it should be an empty GET which > will trigger a DTLS-specific engineID report like USMs, or a GET to a > special OID that always returns the default contextEngineID). The > later solution requiring an extra round trip though. Forgive me my ignorance, but is it not possible to discover the engine ID in pretty much the same way as we do it today with USM? Perhaps we can even run USM (or a slightly simplified version of that) in noAuth/noPriv mode if there is a secure transport providing encryption, integrity protection and so on. The real question is actually how to do the user authentication and where to fit that into the architecture we have. Technically, it would be cool to have a SASL hook for that (TLS and SASL seems to be a common combination which I use daily - even to ship this email to you). The end of all this, however, is that it is not going to be very lightweight in terms of the number of messages required. So for polling something that fits into a single packet every once in a while, SNMP over [D]TLS will be expensive and we still need to figure out how much benefit there actually is in using DTLS/UDP instead of TLS/TCP... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 17:39:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09562; Thu, 14 Oct 2004 17:39:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDVO-0006jY-S4; Thu, 14 Oct 2004 17:51:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDBa-00026A-Lj; Thu, 14 Oct 2004 17:30:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CID93-0001V4-Ci for isms@megatron.ietf.org; Thu, 14 Oct 2004 17:28:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08153 for ; Thu, 14 Oct 2004 17:28:18 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDKH-0006Pc-1u for isms@ietf.org; Thu, 14 Oct 2004 17:39:58 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 774AB11D805; Thu, 14 Oct 2004 14:28:13 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: <20041014204325.GA6370@james> From: Wes Hardaker Organization: Sparta Date: Thu, 14 Oct 2004 14:28:12 -0700 In-Reply-To: <20041014204325.GA6370@james> (Juergen Schoenwaelder's message of "Thu, 14 Oct 2004 22:43:25 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 >>>>> On Thu, 14 Oct 2004 22:43:25 +0200, Juergen Schoenwaelder said: Juergen> Forgive me my ignorance, but is it not possible to discover the Juergen> engine ID in pretty much the same way as we do it today with USM? Juergen> Perhaps we can even run USM (or a slightly simplified version of Juergen> that) in noAuth/noPriv mode if there is a secure transport providing Juergen> encryption, integrity protection and so on. Thats one of the things I just suggested in a different note, yes. Its not that its not solvable (I've thought of multiple ways)... It's just it needs to be decided how its going to be done. Juergen> The real question is actually how to do the user Juergen> authentication and where to fit that into the architecture we Juergen> have. Thats the other piece, as discussed in the other messages as well (with no solution and I had been waiting for you to mention SASL so thanks ;-) Now, do you have an architecture for using it with DTLS and SNMP yet that you can share (quickly!)? Juergen> The end of all this, however, is that it is not going to be Juergen> very lightweight in terms of the number of messages Juergen> required. So for polling something that fits into a single Juergen> packet every once in a while, SNMP over [D]TLS will be Juergen> expensive and we still need to figure out how much benefit Juergen> there actually is in using DTLS/UDP instead of TLS/TCP... Can you write up a TLS/TCP architecture before Monday? I'd love to read it! I actually think someone should write up a generic one for TLS for the common pieces (authentication mapping; engineID discussions) in general and leave the UDP/TCP transport half to its own part which was independent from the other things that need to be solved. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 18:09:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12414; Thu, 14 Oct 2004 18:09:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDyY-0007PT-Li; Thu, 14 Oct 2004 18:21:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDlC-0002ye-1v; Thu, 14 Oct 2004 18:07:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDZV-0006WE-TR for isms@megatron.ietf.org; Thu, 14 Oct 2004 17:55:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10972 for ; Thu, 14 Oct 2004 17:55:38 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDkj-00076m-9S for isms@ietf.org; Thu, 14 Oct 2004 18:07:18 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A74F76737; Thu, 14 Oct 2004 23:55:08 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08085-06; Thu, 14 Oct 2004 23:55:07 +0200 (CEST) Received: from james (G596c.g.pppool.de [80.185.89.108]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 6236196A7; Thu, 14 Oct 2004 23:55:07 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CIDYv-0001r3-Tw; Thu, 14 Oct 2004 23:55:06 +0200 Date: Thu, 14 Oct 2004 23:55:00 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Reminder: ISMS proposals due October 18th Message-ID: <20041014215500.GA7125@james> Mail-Followup-To: Wes Hardaker , "McDonald, Ira" , isms@ietf.org References: <20041014204325.GA6370@james> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Thu, Oct 14, 2004 at 02:28:12PM -0700, Wes Hardaker wrote: > Juergen> The real question is actually how to do the user > Juergen> authentication and where to fit that into the architecture we > Juergen> have. > > Thats the other piece, as discussed in the other messages as well > (with no solution and I had been waiting for you to mention SASL so > thanks ;-) Now, do you have an architecture for using it with DTLS > and SNMP yet that you can share (quickly!)? I am thinking first. There are some non-trivial questions to answer and I first want to get a good feeling how to work things into the architecture we have. (Perhaps hacking an implementation is easier than getting things folded into the architecture. ;-) > Can you write up a TLS/TCP architecture before Monday? I'd love to > read it! I'd love to read it as well. There is not much time left. > I actually think someone should write up a generic one for TLS for the > common pieces (authentication mapping; engineID discussions) in general > and leave the UDP/TCP transport half to its own part which was > independent from the other things that need to be solved. I think there are differences between TLS/TCP and DTLS/UDP. With TCP, you can easily have an endpoint which accepts plain SNMP/TCP and SNMP/TLS/TCP connections and you can keep the easily separate. With DTLS, this won't be as easy. There are also a bunch of question how you would support SASL. Do you do an ad-hoc SASL exchange before you declare the SNMP/TLS session to be open for SNMP or do you SNMP style messages to actually wrap a SASL exchange, potentially running the SASL exchange as part of the security model box of the architecture. There are serious design decisions here and it is unlikely that these will be solved by Monday. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 18:21:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14436; Thu, 14 Oct 2004 18:21:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIEA2-0007go-1Y; Thu, 14 Oct 2004 18:33:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDvT-0000JK-GS; Thu, 14 Oct 2004 18:18:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDok-00059z-Ps for isms@megatron.ietf.org; Thu, 14 Oct 2004 18:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12659 for ; Thu, 14 Oct 2004 18:11:23 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDzy-0007Qo-PW for isms@ietf.org; Thu, 14 Oct 2004 18:23:04 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 00A9F11D805; Thu, 14 Oct 2004 15:11:17 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: <20041014204325.GA6370@james> <20041014215500.GA7125@james> From: Wes Hardaker Organization: Sparta Date: Thu, 14 Oct 2004 15:11:17 -0700 In-Reply-To: <20041014215500.GA7125@james> (Juergen Schoenwaelder's message of "Thu, 14 Oct 2004 23:55:00 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 >>>>> On Thu, 14 Oct 2004 23:55:00 +0200, Juergen Schoenwaelder said: Juergen> There are also a bunch of question how you would support Juergen> SASL. Do you do an ad-hoc SASL exchange before you declare Juergen> the SNMP/TLS session to be open for SNMP or do you SNMP style Juergen> messages to actually wrap a SASL exchange, potentially Juergen> running the SASL exchange as part of the security model box Juergen> of the architecture. There are serious design decisions here Juergen> and it is unlikely that these will be solved by Monday. The chairs would have to answer how much of an complete architecture it needs to have to be considered. I'd write up both possibilities most likely and say the choice needs to be made in the future. The intent of the deadline was to have a thought out architecture that was believed to be suitable so we could consider it as a path forward. I don't think it needs to be perfect, just plausible. I'd assume that it'd be ok to define both solutions or pick one that you like and we can debate whether that solution was right after it gets selected as the candidate to work on. If there are so many people interested in a TLS solution, how come no-one is willing to do the work? If thats the case, then even if we all agreed that TLS is the right way to go would be we better off if no one agreed to do it? We need an author to step forward with enthusiasm ASAP. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 18:34:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15343; Thu, 14 Oct 2004 18:34:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIELt-0007vH-RV; Thu, 14 Oct 2004 18:45:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIE8q-0003Zk-At; Thu, 14 Oct 2004 18:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIE1b-0002g6-Eb for isms@megatron.ietf.org; Thu, 14 Oct 2004 18:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14638 for ; Thu, 14 Oct 2004 18:24:39 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIECp-0007jn-QI for isms@ietf.org; Thu, 14 Oct 2004 18:36:20 -0400 Received: from h-68-166-37-35.snvacaid.dynamic.covad.net ([68.166.37.35] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CIE1Y-00000I-00 for isms@ietf.org; Thu, 14 Oct 2004 15:24:40 -0700 Message-ID: <001a01c4b23c$ac713a20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2147483647.1097775661@[192.168.2.52]> Subject: Re: [Isms] selection criteria for ISMS proposals Date: Thu, 14 Oct 2004 15:25:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi - > From: "Wes Hardaker" > To: "Juergen Quittek" > Cc: > Sent: Thursday, October 14, 2004 1:09 PM > Subject: Re: [Isms] selection criteria for ISMS proposals ... > ago to the list. Here it is again, however. MIASMA isn't listed in > it as it was new the last time I created it. We could update it if it > will be in consideration (currently no one has stood up for it > yet... We only have EUSM and SBSM responses so far?). ... I also have seen no interest in MIASMA, so I haven't been planning to submit it. (Just in case there was any question.) Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 14 20:04:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23372; Thu, 14 Oct 2004 20:04:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIFlw-0001Kt-IB; Thu, 14 Oct 2004 20:16:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIFZi-00012S-7v; Thu, 14 Oct 2004 20:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIFVH-0008WV-MH for isms@megatron.ietf.org; Thu, 14 Oct 2004 19:59:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23054 for ; Thu, 14 Oct 2004 19:59:24 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIFgW-0001F2-CZ for isms@ietf.org; Thu, 14 Oct 2004 20:11:06 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA05041; Thu, 14 Oct 2004 18:58:47 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9ENwls20947; Thu, 14 Oct 2004 16:58:47 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Oct 2004 16:57:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Thu, 14 Oct 2004 16:57:38 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD8A8@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Reminder: ISMS proposals due October 18th Thread-Index: AcSyPDvtkMId585gQ7KyRzYRbBpM4AAC9whQ From: "Fleischman, Eric" To: "Wes Hardaker" , "McDonald, Ira" X-OriginalArrivalTime: 14 Oct 2004 23:57:39.0003 (UTC) FILETIME=[95DF90B0:01C4B249] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Friends, I've seriously considered securing SNMPv3 via TLS. I concluded that it = was an enhancement for the SNMPv3 privacy provisions, but that it was = not a significant improvement for the authentication/authorization needs = that we were seeking in our environment. Rather, what I really wanted = was to leverage our existing key management infrastructure into SNMPv3 = so that we could create consistent system wide (and multi-application) = security policies. This is why my own preference is for approaches that = leverage PKI or Kerberos or some other existing key management system.=20 I know that an articulation of what key management systems are more = desirable for our community to support is inherently controversial, to = the extent of being a non-starter (i.e., probably a waste of time). = However, speaking from my own very parochial knot hole, a PKI-based = approach would be very much in synch with the strategic goals of my = employer for our own internal networked systems. Therefore, my own = preference, when considering ISMS alternatives, are for systems that = support PKI. --Eric -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Thursday, October 14, 2004 3:11 PM To: McDonald, Ira Cc: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th >>>>> On Thu, 14 Oct 2004 23:55:00 +0200, Juergen Schoenwaelder = said: Juergen> There are also a bunch of question how you would support Juergen> SASL. Do you do an ad-hoc SASL exchange before you declare Juergen> the SNMP/TLS session to be open for SNMP or do you SNMP style Juergen> messages to actually wrap a SASL exchange, potentially Juergen> running the SASL exchange as part of the security model box Juergen> of the architecture. There are serious design decisions here Juergen> and it is unlikely that these will be solved by Monday. The chairs would have to answer how much of an complete architecture it needs to have to be considered. I'd write up both possibilities most likely and say the choice needs to be made in the future. The intent of the deadline was to have a thought out architecture that was believed to be suitable so we could consider it as a path forward. I don't think it needs to be perfect, just plausible. I'd assume that it'd be ok to define both solutions or pick one that you like and we can debate whether that solution was right after it gets selected as the candidate to work on. If there are so many people interested in a TLS solution, how come no-one is willing to do the work? If thats the case, then even if we all agreed that TLS is the right way to go would be we better off if no one agreed to do it? We need an author to step forward with enthusiasm ASAP. --=20 Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 05:18:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08297; Fri, 15 Oct 2004 05:18:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIOPF-0001jv-P2; Fri, 15 Oct 2004 05:29:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIOCt-0005T7-6q; Fri, 15 Oct 2004 05:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIOCd-0005JI-Fj for isms@megatron.ietf.org; Fri, 15 Oct 2004 05:16:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08233 for ; Fri, 15 Oct 2004 05:16:44 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIONx-0001ia-U9 for isms@ietf.org; Fri, 15 Oct 2004 05:28:30 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C21429A83; Fri, 15 Oct 2004 11:16:14 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06420-07; Fri, 15 Oct 2004 11:16:13 +0200 (CEST) Received: from james (unknown [212.201.49.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E531D96D1; Fri, 15 Oct 2004 11:16:13 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CIOC5-0000Wl-Gu; Fri, 15 Oct 2004 11:16:13 +0200 Date: Fri, 15 Oct 2004 11:16:13 +0200 From: Juergen Schoenwaelder To: "Fleischman, Eric" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th Message-ID: <20041015091613.GA2004@james> Mail-Followup-To: "Fleischman, Eric" , Wes Hardaker , "McDonald, Ira" , isms@ietf.org References: <5B58696DB20B9140AD20E0685C573A6404FDD8A8@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDD8A8@xch-nw-09.nw.nos.boeing.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On Thu, Oct 14, 2004 at 04:57:38PM -0700, Fleischman, Eric wrote: > I've seriously considered securing SNMPv3 via TLS. I concluded that it > was an enhancement for the SNMPv3 privacy provisions, but that it was > not a significant improvement for the authentication/authorization needs > that we were seeking in our environment. Rather, what I really wanted > was to leverage our existing key management infrastructure into SNMPv3 > so that we could create consistent system wide (and multi-application) > security policies. This is why my own preference is for approaches that > leverage PKI or Kerberos or some other existing key management system. I am using SASL enabled protocols all the day and so I would think that authenticating SNMP users via SASL should fit at least some operational requirements. Sure, in a kerberos environment, leveraging kerberos services makes sense. The problem I see is that not all environments are the same nor that all SNMP interaction patterns are the same. So searching for the holy grail is kind of doomed to failure (and that probably reduces my enthusiam here a bit). > I know that an articulation of what key management systems are more > desirable for our community to support is inherently controversial, > to the extent of being a non-starter (i.e., probably a waste of time). Exactly. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 10:32:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06608; Fri, 15 Oct 2004 10:32:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITJe-0000Wr-GB; Fri, 15 Oct 2004 10:44:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIT5b-0006E6-EA; Fri, 15 Oct 2004 10:29:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CISvi-0003rG-6U for isms@megatron.ietf.org; Fri, 15 Oct 2004 10:19:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04525 for ; Fri, 15 Oct 2004 10:19:35 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIT75-0000AU-JD for isms@ietf.org; Fri, 15 Oct 2004 10:31:24 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9FEJTp2005265 for ; Fri, 15 Oct 2004 10:19:29 -0400 (EDT) Message-Id: <200410151419.i9FEJTp2005265@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th In-Reply-To: <20041014215500.GA7125@james> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 15 Oct 2004 10:19:29 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >There are also a bunch of question how you would support SASL. Do you >do an ad-hoc SASL exchange before you declare the SNMP/TLS session to >be open for SNMP or do you SNMP style messages to actually wrap a SASL >exchange, potentially running the SASL exchange as part of the security >model box of the architecture. There are serious design decisions here >and it is unlikely that these will be solved by Monday. One point to bring up regarding the combination of SASL & TLS: Crypto geeks that I know scream bloody murder when people do things like perform a SASL authentication and use TLS for link encryption. This is because there is no binding between the authentication of the session and the encryption, and since most of the time TLS is negoitated anonymously, that means you can be put in the unenviable position of having a successful authentication complete, but be completely open to a man-in-the-middle attack. If you're going to do just TLS, then that's fine ... the positives and negatives of that approach are well understood. But if you're combining SASL & TLS, you might be giving yourself a false sense of security. Most SASL people would prefer that you use the encryption offered by SASL mechanisms (when it is available, of course ... not all mechanisms support encryption). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 10:57:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10602; Fri, 15 Oct 2004 10:57:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIThU-0001MR-Sn; Fri, 15 Oct 2004 11:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITQf-0005ny-TO; Fri, 15 Oct 2004 10:51:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITH4-0002cJ-Hb for isms@megatron.ietf.org; Fri, 15 Oct 2004 10:41:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08578 for ; Fri, 15 Oct 2004 10:41:39 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITSR-0000tf-I6 for isms@ietf.org; Fri, 15 Oct 2004 10:53:28 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8B93F9C7E; Fri, 15 Oct 2004 16:41:09 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27352-02; Fri, 15 Oct 2004 16:41:08 +0200 (CEST) Received: from james (unknown [212.201.49.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id B49139A83; Fri, 15 Oct 2004 16:41:08 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CITGW-0000jn-Md; Fri, 15 Oct 2004 16:41:08 +0200 Date: Fri, 15 Oct 2004 16:41:08 +0200 From: Juergen Schoenwaelder To: Ken Hornstein Subject: Re: [Isms] Reminder: ISMS proposals due October 18th Message-ID: <20041015144108.GA2833@james> Mail-Followup-To: Ken Hornstein , isms@ietf.org References: <20041014215500.GA7125@james> <200410151419.i9FEJTp2005265@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410151419.i9FEJTp2005265@ginger.cmf.nrl.navy.mil> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Fri, Oct 15, 2004 at 10:19:29AM -0400, Ken Hornstein wrote: > Crypto geeks that I know scream bloody murder when people do things > like perform a SASL authentication and use TLS for link encryption. > This is because there is no binding between the authentication of the > session and the encryption, and since most of the time TLS is > negoitated anonymously, that means you can be put in the unenviable > position of having a successful authentication complete, but be > completely open to a man-in-the-middle attack. If you're going to do > just TLS, then that's fine ... the positives and negatives of that > approach are well understood. But if you're combining SASL & TLS, you > might be giving yourself a false sense of security. Most SASL people > would prefer that you use the encryption offered by SASL mechanisms > (when it is available, of course ... not all mechanisms support > encryption). Not sure I understand this. Many protocols use TLS and SASL in combination. Are you saying they are all broken? Or are you saying that cleartext SASL authentication over TLS is broken and you should really be using a stronger SASL mechanism? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 11:14:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11903; Fri, 15 Oct 2004 11:14:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITyH-0001k1-4i; Fri, 15 Oct 2004 11:26:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITkP-0001aV-IC; Fri, 15 Oct 2004 11:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITe7-0000a2-Fv for isms@megatron.ietf.org; Fri, 15 Oct 2004 11:05:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11293 for ; Fri, 15 Oct 2004 11:05:28 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CITpR-0001YZ-K2 for isms@ietf.org; Fri, 15 Oct 2004 11:17:17 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9FF51US006254 for ; Fri, 15 Oct 2004 11:05:16 -0400 (EDT) Message-Id: <200410151505.i9FF51US006254@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th In-Reply-To: <20041015144108.GA2833@james> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 15 Oct 2004 11:05:02 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 >Not sure I understand this. Many protocols use TLS and SASL in >combination. Are you saying they are all broken? Many protocols provide the _option_ to do both. I think doing one _or the other_ is fine. >Or are you saying >that cleartext SASL authentication over TLS is broken and you should >really be using a stronger SASL mechanism? If you're doing a cleartext SASL authentication over TLS ... well, I hesitate to call that "SASL", even. I consider that basically TLS (yes, I know it's using the SASL framework, but let's put that aside for the moment). I'll try to give you a clearer example. Let's say that someone authenticates a SASL protocol via GSSAPI (aka Kerberos) but encrypts the session via TLS (and for the sake of argument, let's say that it was anonymous TLS, but I don't think that's an unfair assumption). Now, you _might_ think that you were protected against a man-in-the-middle attack, because Kerberos protects against that ... but, sadly, you are not. The TLS connection is not "signed" by the GSSAPI authentication; due to the layers involved, it doesn't even know that it's happening. That means that after you authenticate via GSSAPI, a sufficiently sophisticated attacker could insert any commands he or she wants into the data stream. This gives Kerberos people fits, because they know that if you either used the SASL-provided encryption (which in the GSSAPI case uses a session key derived from the Kerberos exchange, which is protected against MITM) or had some way of signing the TLS DH parameters via the GSSAPI authentication exchange, you'd be protected. There has been some work on the latter front (see the "channel bindings" draft by Nico Williams, draft-williams-gssapi-channel-bindings-00.txt), but I'm not sure it will be ready in time for what we need. If you don't consider this a huge problem, then that's fine ... I just feel I would be remiss if I didn't bring it up. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 12:21:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17209; Fri, 15 Oct 2004 12:21:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIV0m-0003Ov-MS; Fri, 15 Oct 2004 12:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUXp-0004JV-Jg; Fri, 15 Oct 2004 12:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIURY-0002as-LD for isms@megatron.ietf.org; Fri, 15 Oct 2004 11:56:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15578 for ; Fri, 15 Oct 2004 11:56:33 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUcw-0002rv-4N for isms@ietf.org; Fri, 15 Oct 2004 12:08:23 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 19F4E11D805; Fri, 15 Oct 2004 08:56:32 -0700 (PDT) To: Ken Hornstein Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: <200410151505.i9FF51US006254@ginger.cmf.nrl.navy.mil> From: Wes Hardaker Organization: Sparta Date: Fri, 15 Oct 2004 08:56:32 -0700 In-Reply-To: <200410151505.i9FF51US006254@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Fri, 15 Oct 2004 11:05:02 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >>>>> On Fri, 15 Oct 2004 11:05:02 -0400, Ken Hornstein said: Ken> If you don't consider this a huge problem, then that's fine ... I Ken> just feel I would be remiss if I didn't bring it up. I'm not a SASL expert at all as its one of the systems I haven't looked much into the details of. More generically, however, the standard solution is to provide a cryptographic binding between the inner authentication layer and the outer layer secure transport. The only way to do this, generally, is to have a generated key passed between the two layers so that they can be bound together through an authentication hash that ties the two connections together. I'm not sure if a TLS/SASL combination can support this but I'd hope so. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 12:46:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19224; Fri, 15 Oct 2004 12:46:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVPA-0003xF-1r; Fri, 15 Oct 2004 12:58:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIV7i-00048T-OK; Fri, 15 Oct 2004 12:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIV1w-00031u-1K for isms@megatron.ietf.org; Fri, 15 Oct 2004 12:34:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18025 for ; Fri, 15 Oct 2004 12:34:09 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVDK-0003g7-Gs for isms@ietf.org; Fri, 15 Oct 2004 12:45:59 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9FGXNrk017316; Fri, 15 Oct 2004 09:33:23 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PYWD35>; Fri, 15 Oct 2004 09:33:23 -0700 Message-ID: From: "McDonald, Ira" To: "'Ken Hornstein'" , isms@ietf.org Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Fri, 15 Oct 2004 09:33:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Hi, I've been looking at this very differently, because of the unlinked SASL (or whatever) above TLS encryption, which allows a whole bunch of man-in-the-middle attacks, I've assumed: (1) DTLS with _both_ CLIENT (SNMP Manager) and SERVER (SNMP Agent) public key certificate-based authentication during the DTLS handshake (no anonymous DTLS sessions allowed). (2) Use of the TLS session resume option (which works fine with DTLS) to make even the short exchanges efficient, after creating an initial DTLS session. (3) Optional use of DTLS encryption (if there is strong mutual authentication and message integrity hashes, then the need for encryption is not automatic). I would urge that SASL (or any other mechanism) _not_ be introduced - no additional security is achieved. I suggest using TLS Server Name Indication, Client Certificate URL, and Trusted CA Indication extensions defined in RFC 3546 (which documents TLS extensions useful for wireless clients, i.e., resource-constrained clients). I'll be off the air for about 24 hours, because of a trip out-of-town. I'll tune in again Saturday. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Ken Hornstein Sent: Friday, October 15, 2004 11:05 AM To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th >Not sure I understand this. Many protocols use TLS and SASL in >combination. Are you saying they are all broken? Many protocols provide the _option_ to do both. I think doing one _or the other_ is fine. >Or are you saying >that cleartext SASL authentication over TLS is broken and you should >really be using a stronger SASL mechanism? If you're doing a cleartext SASL authentication over TLS ... well, I hesitate to call that "SASL", even. I consider that basically TLS (yes, I know it's using the SASL framework, but let's put that aside for the moment). I'll try to give you a clearer example. Let's say that someone authenticates a SASL protocol via GSSAPI (aka Kerberos) but encrypts the session via TLS (and for the sake of argument, let's say that it was anonymous TLS, but I don't think that's an unfair assumption). Now, you _might_ think that you were protected against a man-in-the-middle attack, because Kerberos protects against that ... but, sadly, you are not. The TLS connection is not "signed" by the GSSAPI authentication; due to the layers involved, it doesn't even know that it's happening. That means that after you authenticate via GSSAPI, a sufficiently sophisticated attacker could insert any commands he or she wants into the data stream. This gives Kerberos people fits, because they know that if you either used the SASL-provided encryption (which in the GSSAPI case uses a session key derived from the Kerberos exchange, which is protected against MITM) or had some way of signing the TLS DH parameters via the GSSAPI authentication exchange, you'd be protected. There has been some work on the latter front (see the "channel bindings" draft by Nico Williams, draft-williams-gssapi-channel-bindings-00.txt), but I'm not sure it will be ready in time for what we need. If you don't consider this a huge problem, then that's fine ... I just feel I would be remiss if I didn't bring it up. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 12:48:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19519; Fri, 15 Oct 2004 12:48:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVQw-0003zs-8a; Fri, 15 Oct 2004 13:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIV7p-0004A7-AT; Fri, 15 Oct 2004 12:40:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIV3r-0003NL-2q for isms@megatron.ietf.org; Fri, 15 Oct 2004 12:36:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18107 for ; Fri, 15 Oct 2004 12:36:08 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVFF-0003iV-Ol for isms@ietf.org; Fri, 15 Oct 2004 12:47:58 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9FGZtQv008597 for ; Fri, 15 Oct 2004 12:36:03 -0400 (EDT) Message-Id: <200410151636.i9FGZtQv008597@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 15 Oct 2004 12:35:56 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >More generically, however, the standard solution is to provide a >cryptographic binding between the inner authentication layer and the >outer layer secure transport. The only way to do this, generally, is >to have a generated key passed between the two layers so that they can >be bound together through an authentication hash that ties the two >connections together. I'm not sure if a TLS/SASL combination can >support this but I'd hope so. Sure, everyone agrees that this is what _should_ happen. It's just that there is no defined protocol to exchange this hash, no one has decided on which hash algorithm to use or how to negotiate the hash algorithm, nor the format of this hash, and AFAIK neither the SASL or TLS APIs provide a way to get or set the necessary key. So, essentially, this _doesn't_ happen today. And if we defined a TLS/SASL authentication framework for SNMP, it wouldn't happen unless we waited for the community (likely the SASL community) to solve the problem. They're working on it, but I get the sense it's not going to happen anytime soon. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 12:50:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19829; Fri, 15 Oct 2004 12:50:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVSu-00046X-CU; Fri, 15 Oct 2004 13:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVG8-0006Ht-F1; Fri, 15 Oct 2004 12:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVBK-0004kT-W0 for isms@megatron.ietf.org; Fri, 15 Oct 2004 12:43:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18661 for ; Fri, 15 Oct 2004 12:43:51 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVMk-0003r6-3w for isms@ietf.org; Fri, 15 Oct 2004 12:55:42 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9FGhnCJ008801 for ; Fri, 15 Oct 2004 12:43:49 -0400 (EDT) Message-Id: <200410151643.i9FGhnCJ008801@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th In-Reply-To: <20041014215500.GA7125@james> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 15 Oct 2004 12:43:49 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >> Thats the other piece, as discussed in the other messages as well >> (with no solution and I had been waiting for you to mention SASL so >> thanks ;-) Now, do you have an architecture for using it with DTLS >> and SNMP yet that you can share (quickly!)? > >I am thinking first. There are some non-trivial questions to answer >and I first want to get a good feeling how to work things into the >architecture we have. (Perhaps hacking an implementation is easier >than getting things folded into the architecture. ;-) As a WG chair, I'd gladly accept a submission for consideration even if it wasn't fully fleshed out. From the note I sent out a little while ago: Submissions do not need to be full-fledged, but should at least give a general overview of the proposed solution. So even if there are unanswered questions, I get the sense you have enough now to get it on the table. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 13:23:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22156; Fri, 15 Oct 2004 13:23:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVyc-0004pX-2f; Fri, 15 Oct 2004 13:34:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVia-0004L3-KB; Fri, 15 Oct 2004 13:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVhc-00049a-TK for isms@megatron.ietf.org; Fri, 15 Oct 2004 13:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21762 for ; Fri, 15 Oct 2004 13:17:13 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVt1-0004hU-2F for isms@ietf.org; Fri, 15 Oct 2004 13:29:04 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id C47B511D805; Fri, 15 Oct 2004 10:17:11 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: From: Wes Hardaker Organization: Sparta Date: Fri, 15 Oct 2004 10:17:10 -0700 In-Reply-To: (Ira McDonald's message of "Fri, 15 Oct 2004 09:33:22 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >>>>> On Fri, 15 Oct 2004 09:33:22 -0700, "McDonald, Ira" said: Ira> (1) DTLS with _both_ CLIENT (SNMP Manager) and SERVER Ira> (SNMP Agent) public key certificate-based Ira> authentication during the DTLS handshake Ira> (no anonymous DTLS sessions allowed). The goal of the WG, though, is to tie in with existing secure infrastructures. The number of people using client side certs is very very small and is not expected to grow enough by the time we need to release a ISMS solution specification. I don't think it would be wise to only use certificate based authentication, especially from the client side. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 13:24:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22266; Fri, 15 Oct 2004 13:24:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIW0D-0004s6-Ey; Fri, 15 Oct 2004 13:36:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVnW-0004wR-K5; Fri, 15 Oct 2004 13:23:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVix-0004Ma-WA for isms@megatron.ietf.org; Fri, 15 Oct 2004 13:18:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21860 for ; Fri, 15 Oct 2004 13:18:36 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIVuL-0004io-Rq for isms@ietf.org; Fri, 15 Oct 2004 13:30:27 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9FHHseU020578; Fri, 15 Oct 2004 10:17:55 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PYW1RM>; Fri, 15 Oct 2004 10:17:55 -0700 Message-ID: From: "McDonald, Ira" To: "McDonald, Ira" , "'Ken Hornstein'" , isms@ietf.org Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Fri, 15 Oct 2004 10:17:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Hi, One more assumption: (4) SNMP over DTLS requires a separate well-known port (like the much-maligned HTTPS), because the client (SNMP Manager) must know that the DTLS handshake always comes first (the use of an Upgrade header like RFC 2817 in the application traffic doesn't make any sense). Cheers, - Ira PS - Ken just made a very good point about the lack of hooks in SASL and TLS (OpenSSL) APIs for passing the cryptographic hash back and forth - that should convince people to force mutual authentication in the DTLS layer. Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of McDonald, Ira Sent: Friday, October 15, 2004 12:33 PM To: 'Ken Hornstein'; isms@ietf.org Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Hi, I've been looking at this very differently, because of the unlinked SASL (or whatever) above TLS encryption, which allows a whole bunch of man-in-the-middle attacks, I've assumed: (1) DTLS with _both_ CLIENT (SNMP Manager) and SERVER (SNMP Agent) public key certificate-based authentication during the DTLS handshake (no anonymous DTLS sessions allowed). (2) Use of the TLS session resume option (which works fine with DTLS) to make even the short exchanges efficient, after creating an initial DTLS session. (3) Optional use of DTLS encryption (if there is strong mutual authentication and message integrity hashes, then the need for encryption is not automatic). I would urge that SASL (or any other mechanism) _not_ be introduced - no additional security is achieved. I suggest using TLS Server Name Indication, Client Certificate URL, and Trusted CA Indication extensions defined in RFC 3546 (which documents TLS extensions useful for wireless clients, i.e., resource-constrained clients). I'll be off the air for about 24 hours, because of a trip out-of-town. I'll tune in again Saturday. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Ken Hornstein Sent: Friday, October 15, 2004 11:05 AM To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th >Not sure I understand this. Many protocols use TLS and SASL in >combination. Are you saying they are all broken? Many protocols provide the _option_ to do both. I think doing one _or the other_ is fine. >Or are you saying >that cleartext SASL authentication over TLS is broken and you should >really be using a stronger SASL mechanism? If you're doing a cleartext SASL authentication over TLS ... well, I hesitate to call that "SASL", even. I consider that basically TLS (yes, I know it's using the SASL framework, but let's put that aside for the moment). I'll try to give you a clearer example. Let's say that someone authenticates a SASL protocol via GSSAPI (aka Kerberos) but encrypts the session via TLS (and for the sake of argument, let's say that it was anonymous TLS, but I don't think that's an unfair assumption). Now, you _might_ think that you were protected against a man-in-the-middle attack, because Kerberos protects against that ... but, sadly, you are not. The TLS connection is not "signed" by the GSSAPI authentication; due to the layers involved, it doesn't even know that it's happening. That means that after you authenticate via GSSAPI, a sufficiently sophisticated attacker could insert any commands he or she wants into the data stream. This gives Kerberos people fits, because they know that if you either used the SASL-provided encryption (which in the GSSAPI case uses a session key derived from the Kerberos exchange, which is protected against MITM) or had some way of signing the TLS DH parameters via the GSSAPI authentication exchange, you'd be protected. There has been some work on the latter front (see the "channel bindings" draft by Nico Williams, draft-williams-gssapi-channel-bindings-00.txt), but I'm not sure it will be ready in time for what we need. If you don't consider this a huge problem, then that's fine ... I just feel I would be remiss if I didn't bring it up. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 13:31:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22978; Fri, 15 Oct 2004 13:31:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIW6x-00051v-Le; Fri, 15 Oct 2004 13:43:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVqM-0005WO-5h; Fri, 15 Oct 2004 13:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVoi-0005Bq-5D for isms@megatron.ietf.org; Fri, 15 Oct 2004 13:24:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22260 for ; Fri, 15 Oct 2004 13:24:32 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIW06-0004qu-9P for isms@ietf.org; Fri, 15 Oct 2004 13:36:23 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9FHNq9L020909; Fri, 15 Oct 2004 10:23:52 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PYW1TF>; Fri, 15 Oct 2004 10:23:52 -0700 Message-ID: From: "McDonald, Ira" To: "'Wes Hardaker'" , "McDonald, Ira" Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Fri, 15 Oct 2004 10:23:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi Wes, We're not talking about general 'clients'. We're talking about a _small_ number of certificates for _authorized_ SNMP Managers. The infrastructure overhead is trivial. The server side certificates can be built right into the SNMP devices by the manufacturers (although the privilege of THOSE certificates in a customer enterprise network is another question). Per the thread with Ken, client authentication at a 'higher layer' (SASL) really can't be made to work, without some unacceptable weakening of security. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Friday, October 15, 2004 1:17 PM To: McDonald, Ira Cc: 'Ken Hornstein'; isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th >>>>> On Fri, 15 Oct 2004 09:33:22 -0700, "McDonald, Ira" said: Ira> (1) DTLS with _both_ CLIENT (SNMP Manager) and SERVER Ira> (SNMP Agent) public key certificate-based Ira> authentication during the DTLS handshake Ira> (no anonymous DTLS sessions allowed). The goal of the WG, though, is to tie in with existing secure infrastructures. The number of people using client side certs is very very small and is not expected to grow enough by the time we need to release a ISMS solution specification. I don't think it would be wise to only use certificate based authentication, especially from the client side. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 13:40:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23620; Fri, 15 Oct 2004 13:40:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWFy-0005Db-2r; Fri, 15 Oct 2004 13:52:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVy4-0006i4-12; Fri, 15 Oct 2004 13:34:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVul-00063X-Uv for isms@megatron.ietf.org; Fri, 15 Oct 2004 13:30:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22887 for ; Fri, 15 Oct 2004 13:30:48 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIW69-00050k-Nl for isms@ietf.org; Fri, 15 Oct 2004 13:42:39 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9FHUbp1010074 for ; Fri, 15 Oct 2004 13:30:43 -0400 (EDT) Message-Id: <200410151730.i9FHUbp1010074@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 15 Oct 2004 13:30:37 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 >(4) SNMP over DTLS requires a separate well-known > port (like the much-maligned HTTPS), because > the client (SNMP Manager) must know that the > DTLS handshake always comes first (the use > of an Upgrade header like RFC 2817 in the > application traffic doesn't make any sense). Another minor nit ... I always hear protocol geeks gnash their teeth about running TLS-based protocols on a different port (that's why many protocols now have STARTTLS or something similar with them). It may not be possible to turn on DTLS in-line (I will confess that I don't fully understand it all yet) but I'm sure someone's going to complain about it. --Ken >PS - Ken just made a very good point about the lack >of hooks in SASL and TLS (OpenSSL) APIs for passing >the cryptographic hash back and forth - that should >convince people to force mutual authentication in >the DTLS layer. I have to echo Wes's comments here ... one requirement of the output of this working group is that the security system fit in with _existing_ infrastructures, not require the creation of new security infrastructures (this was a major complaint of USM). This is non-negotiable. A PKI-only solution is a non-starter, IMHO (not speaking as a WG chair here). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 13:44:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23775; Fri, 15 Oct 2004 13:44:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWJK-0005Gt-AI; Fri, 15 Oct 2004 13:56:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVyx-0006qW-CI; Fri, 15 Oct 2004 13:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVvq-0006D2-3V for isms@megatron.ietf.org; Fri, 15 Oct 2004 13:31:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23002 for ; Fri, 15 Oct 2004 13:31:54 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIW7E-00052G-F2 for isms@ietf.org; Fri, 15 Oct 2004 13:43:45 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9FHVnqJ010104 for ; Fri, 15 Oct 2004 13:31:49 -0400 (EDT) Message-Id: <200410151731.i9FHVnqJ010104@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 15 Oct 2004 13:31:49 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >Per the thread with Ken, client authentication at a >'higher layer' (SASL) really can't be made to work, >without some unacceptable weakening of security. Please note that I was talking about the combination of SASL and an external encryption layer (like TLS). If you just did SNMP-SASL over TCP and used the encryption provided by SASL, I think that security would be perfectly reasonable (I'm not saying that there wouldn't be other problems with such a proposal ... I'm just saying that I can't see any security related issues). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 13:44:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23839; Fri, 15 Oct 2004 13:44:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIWJg-0005Hs-Tk; Fri, 15 Oct 2004 13:56:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIW0S-0006zB-2M; Fri, 15 Oct 2004 13:36:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIVxQ-0006V5-So for isms@megatron.ietf.org; Fri, 15 Oct 2004 13:33:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23173 for ; Fri, 15 Oct 2004 13:33:33 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIW8o-00054w-SH for isms@ietf.org; Fri, 15 Oct 2004 13:45:24 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 8507A11D805; Fri, 15 Oct 2004 10:33:31 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: From: Wes Hardaker Organization: Sparta Date: Fri, 15 Oct 2004 10:33:31 -0700 In-Reply-To: (Ira McDonald's message of "Fri, 15 Oct 2004 10:23:51 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 >>>>> On Fri, 15 Oct 2004 10:23:51 -0700, "McDonald, Ira" said: Ira> We're not talking about general 'clients'. We're talking about a Ira> _small_ number of certificates for _authorized_ SNMP Managers. Ira> The infrastructure overhead is trivial. Its not the number of managers is small (though I disagree thats a safe assumption, but lets leave that aside for the moment). Its that you need to get those certificates into the boxes in question. That is a management burden. It costs additional resources to configure all those boxes with your management server certificates. Users today already have existing authentication mechanisms. They've repeatedly said they don't want another one, which is one of the reasons this WG was created. But by offering them certificates, you *are* offering them another one instead of tying in with something existing. Ira> The server side certificates can be built right into the SNMP Ira> devices by the manufacturers (although the privilege of THOSE Ira> certificates in a customer enterprise network is another Ira> question). I agree thats a solution that can help deployment of the server side certificates. Though you have trust chain issues that still need to be dealt with, but having a cert built in the box is a start. Replacing it needs to be dealt with too, of course. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 15 17:18:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22541; Fri, 15 Oct 2004 17:18:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZeA-0005L9-4E; Fri, 15 Oct 2004 17:29:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYTG-0000Wk-Pc; Fri, 15 Oct 2004 16:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYFa-0007r7-KV for isms@megatron.ietf.org; Fri, 15 Oct 2004 16:00:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05338 for ; Fri, 15 Oct 2004 16:00:28 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIYR1-000073-3z for isms@ietf.org; Fri, 15 Oct 2004 16:12:19 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9FK0OGQ014169 for ; Fri, 15 Oct 2004 16:00:24 -0400 (EDT) Message-Id: <200410152000.i9FK0OGQ014169@ginger.cmf.nrl.navy.mil> To: isms@ietf.org X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 15 Oct 2004 16:00:24 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Isms] A hopefully useful SASL tutorial X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Dave Perkins had asked me privately for a good tutorial on SASL. I cruised around the web a bit, and I couldn't find one. So I decided to write this to hopefully explain a bit about SASL, so everyone is (hopefully) on the same page. I hope that people who know more about SASL than I do will understand that I've simplified a number of things here in the interests of space. SASL is unfortunately a bit difficult to grasp at first, since it's a sort of protocol "middleware"; it doesn't define a network protocol, but a framework that application protocols can use to perform authentication. First, some definitions. Within SASL are these items called "mechanisms". These are different types of authentication that SASL can perform. Each of these mechanisms have different capabilities and requires. Some examples of SASL mechanisms are: - CRAM-MD5 - A shared secret is known on each side, and the client sends back the MD5 hash of the shared secret and a server-supplied nonce. This is an update of the POP "APOP" mechanism. - LOGIN/PLAIN - Two different variants of the same thing: a plaintext password sent unencrypted (as far as SASL knows, at least). - DIGEST-MD5 - An improved version of CRAM-MD5 (read RFC2222 if you want more details). - GSSAPI - Kerberos 5 authentication Now, one thing that not everyone appreciates is that SASL contains within it the framework to do encryption and integrity protection. I believe the reason that not everyone understands this is partially because the SASL RFC calls this "security layers", for reasons which I have never fully understood. In SASL, however, the confidentiality and integrity are done by each mechanism, and not every mechanism supports confidentiality and integrity protection (e.g., CRAM-MD5 does not, but DIGEST-MD5 and GSSAPI do). Exactly what encryption is used is dependant on the particular mechanism. DIGEST-MD5 sends a list of cipher suites it supports as part of it's negotiation; for GSSAPI, the encryption used is dictated by the session key chosen by the underlying Kerberos protocol. So when you're discussing the security of SASL, you have to also include the particular mechanisms you're talking about. How SASL messages get exchanged is specific to each protocol, and is part of a protocol's "SASL profile". The SASL profile includes how a protocol can indicate which SASL mechanisms it supports, how to start authentication, and how authentication messages are transmitted across that protocol. Let's take an example: SMTP. To understand this completely, you'd have to read RFC 2222 (the SASL base spec), RFC 2554 (The SMTP AUTH RFC, which defines the SMTP SASL profile), and the documents for the mechanisms that you were interested in (some of which are still in draft form right now). The way that SMTP indicates which mechanisms it supports is by including an extra line in the EHLO response, e.g.: EHLO some.mail.client 250-some.mail.server Hello some.mail.client [1.2.3.4], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 209715200 250-DSN 250-ETRN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP The key item here is the "AUTH" line. This lists the mechanisms that the server supports. What happens next is that the client picks one (which is usually based on what it supports and the ones that the server prefers), issues an "AUTH mechanism-name", and then the client and server exchange base64-encoded SASL blobs until either the authentication completes, or one side has decided that the authentication has failed. Now note that many of these features (the AUTH command, the text list of mechanisms, the base64 encoding) are purely features of the SMTP SASL profile. An application protocol can choose whatever is appropriate to transmit the list of supported mechanisms and SASL messages (for example, LDAP does this very differently). In terms of implementation (which I feel is important to at least touch on a bit), the library I am most familiar with is the Cyrus-SASL library. With that library, the details of each mechanism are hidden from you; you call a generic set of functions to extract out a list of mechanisms, select a mechanism, generate and process the SASL mechanism messages, and perform encryption. The encryption functions, however, are basically "here's some data, encrypt/decrypt it for me". You don't really have an idea what the mechanism is doing underneath the hood (you can tell if encryption has been negotiated or not, though), and you don't get access to any of the keying material. If you're careful, you can truely write code that is mechanism-agnostic. You can also set criteria for which mechanisms you want to support. For example, if you want to select mechanisms that aren't vulnerable to network sniffing, you can do that and your SASL library won't offer the PLAIN mechanism. You can also require that your mechanisms support mutual authentication, encryption, etc etc ... a whole bunch of options. I hope this makes the SASL murkiness a bit clearer. If you have further questions, please feel free to ask them on the list, because likely you're not the only one I have confused. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Oct 16 15:09:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09035; Sat, 16 Oct 2004 15:09:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIu74-0003a5-Bn; Sat, 16 Oct 2004 15:21:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CItub-00034v-0F; Sat, 16 Oct 2004 15:08:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CItr5-0000n6-6V for isms@megatron.ietf.org; Sat, 16 Oct 2004 15:04:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08550 for ; Sat, 16 Oct 2004 15:04:34 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIu2f-0003WV-W4 for isms@ietf.org; Sat, 16 Oct 2004 15:16:38 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9GJ3hr8021763; Sat, 16 Oct 2004 12:03:44 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PYW7Q9>; Sat, 16 Oct 2004 12:03:38 -0700 Message-ID: From: "McDonald, Ira" To: "'Ken Hornstein'" , isms@ietf.org Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Sat, 16 Oct 2004 12:03:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi Ken, Right - it's the interlayer security dependencies that are at issue. SASL by itself is fine. Cheers, - Ira PS - Thanks for the excellent SASL tutorial - I'm just reading it. Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Ken Hornstein Sent: Friday, October 15, 2004 1:32 PM To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th >Per the thread with Ken, client authentication at a >'higher layer' (SASL) really can't be made to work, >without some unacceptable weakening of security. Please note that I was talking about the combination of SASL and an external encryption layer (like TLS). If you just did SNMP-SASL over TCP and used the encryption provided by SASL, I think that security would be perfectly reasonable (I'm not saying that there wouldn't be other problems with such a proposal ... I'm just saying that I can't see any security related issues). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Oct 16 15:25:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10331; Sat, 16 Oct 2004 15:25:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIuMW-0003nx-64; Sat, 16 Oct 2004 15:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIu9v-0004OQ-UD; Sat, 16 Oct 2004 15:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIu8r-0003eq-DS for isms@megatron.ietf.org; Sat, 16 Oct 2004 15:23:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10231 for ; Sat, 16 Oct 2004 15:22:59 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIuKU-0003lX-Pt for isms@ietf.org; Sat, 16 Oct 2004 15:35:03 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9GJMIxV022977; Sat, 16 Oct 2004 12:22:18 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PYW8C7>; Sat, 16 Oct 2004 12:22:19 -0700 Message-ID: From: "McDonald, Ira" To: "'Ken Hornstein'" , isms@ietf.org Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Sat, 16 Oct 2004 12:22:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Hi, I concede that a PKI-only solution is no help. So, what about: (1) TLS with Kerberos Authentication (RFC 2712) - used with the DTLS connectionless substrate and/or (2) TLS with Secure Remote Password - SRP is one-time password (diminishing numbers of repetitive hashes of the seed to yield the current value one password, which when used immediately expires) Refereences: [RFC2945] The SRP Authentication and Key Exchange System September 2000 [TLS-SRP] Using SRP for TLS Authentication , August 19, 2004 Both of these avoid the need for PKI deployment and both are fairly widely deployed today. As to the dedicated port issue, since we aren't allowed to modify or extend the SNMP protocol operations, we'd have to have some kludge (i.e., Set serial number and some string value to some MIB object) to pass STARTTLS in the SNMP application datastream. Do we think the SNMP purists will swallow such a kludge to avoid a dedicated port? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Ken Hornstein Sent: Friday, October 15, 2004 1:31 PM To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th >(4) SNMP over DTLS requires a separate well-known > port (like the much-maligned HTTPS), because > the client (SNMP Manager) must know that the > DTLS handshake always comes first (the use > of an Upgrade header like RFC 2817 in the > application traffic doesn't make any sense). Another minor nit ... I always hear protocol geeks gnash their teeth about running TLS-based protocols on a different port (that's why many protocols now have STARTTLS or something similar with them). It may not be possible to turn on DTLS in-line (I will confess that I don't fully understand it all yet) but I'm sure someone's going to complain about it. --Ken >PS - Ken just made a very good point about the lack >of hooks in SASL and TLS (OpenSSL) APIs for passing >the cryptographic hash back and forth - that should >convince people to force mutual authentication in >the DTLS layer. I have to echo Wes's comments here ... one requirement of the output of this working group is that the security system fit in with _existing_ infrastructures, not require the creation of new security infrastructures (this was a major complaint of USM). This is non-negotiable. A PKI-only solution is a non-starter, IMHO (not speaking as a WG chair here). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Oct 16 16:06:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12095; Sat, 16 Oct 2004 16:06:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIv0D-0004WE-Ef; Sat, 16 Oct 2004 16:18:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIunb-00012w-29; Sat, 16 Oct 2004 16:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIump-0000aG-VI for isms@megatron.ietf.org; Sat, 16 Oct 2004 16:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12053 for ; Sat, 16 Oct 2004 16:04:17 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIuyT-0004VZ-KQ for isms@ietf.org; Sat, 16 Oct 2004 16:16:22 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id C668E11D805; Sat, 16 Oct 2004 13:04:16 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: From: Wes Hardaker Organization: Sparta Date: Sat, 16 Oct 2004 13:04:16 -0700 In-Reply-To: (Ira McDonald's message of "Sat, 16 Oct 2004 12:22:15 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a >>>>> On Sat, 16 Oct 2004 12:22:15 -0700, "McDonald, Ira" said: Ira> (1) TLS with Kerberos Authentication (RFC 2712) Ira> - used with the DTLS connectionless substrate I'd hesitate to require kerberos since it isn't used everywhere (certainly less than other authentication DBs like radius, etc). However, I do think the result should include the ability to use kerberos in an ideal world. Ira> (2) TLS with Secure Remote Password Ira> - SRP is one-time password (diminishing numbers Ira> of repetitive hashes of the seed to yield the Ira> current value one password, which when used Ira> immediately expires) Again, not everyone wants one-time passwords. Flexibility is the key. I'd suggest writing a draft that documents how we'd use TLS and which authentication mechanisms we'd allow and thus allow both 1 and 2 above and document how the login information is passed to the higher SNMP layer. I think flexibility will be key in the results to ensure we don't have to go down this road again in 5 years when some new authentication mechanism becomes popular. Ira> As to the dedicated port issue, since we aren't allowed to modify Ira> or extend the SNMP protocol operations, we'd have to have some Ira> kludge (i.e., Set serial number and some string value to some MIB Ira> object) to pass STARTTLS in the SNMP application datastream. Do Ira> we think the SNMP purists will swallow such a kludge to avoid a Ira> dedicated port? I don't think you need to do that. You can write new security protocols that make use of new fields in the security parameters section of the SNMPv3 message without modifying the base. In these parameters you could pass TLS start information. (Both KSM and SBSM make use of security-model specific parameters that extend the base packet format with parameters specific to each of these security models... They didn't require modifying the protocol). However, I don't think Ken was saying you couldn't require a separate port. Just that we need to make that decision carefully, as some people don't like it. It may or may not be possible to reuse port 161 by carefully encapsulating the start-TLS requirements. However, unlike TCP where the data is contained and thus its easier to encapsulate future packets within a stream below the SNMP layer so-as-to-hide the fact it went over a secure transport, I suspect this will be more difficult with DTLS and the SNMP stack will have to be much more involved. Thus I'm not yet convinced this is the right way to go and I think a separate port would be less work for most stacks which would be a win in the end. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Oct 17 00:38:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05186; Sun, 17 Oct 2004 00:38:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ2zq-0003LD-UB; Sun, 17 Oct 2004 00:50:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2nR-00082N-Cl; Sun, 17 Oct 2004 00:37:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2iA-0006oz-C0 for isms@megatron.ietf.org; Sun, 17 Oct 2004 00:32:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04602 for ; Sun, 17 Oct 2004 00:31:58 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ2ts-0003DB-QO for isms@ietf.org; Sun, 17 Oct 2004 00:44:09 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 1739E11D807; Sat, 16 Oct 2004 21:32:00 -0700 (PDT) To: isms@ietf.org From: Wes Hardaker Organization: Sparta Date: Sat, 16 Oct 2004 21:32:00 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Isms] New SBSM -03 draft posted X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad But it'll have to go through the publication queue. If you want it faster, feel free to pick it up from http://sbsm.hardakers.net/ before it hits the ID directory. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 12:49:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00995; Mon, 18 Oct 2004 12:49:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJat0-0004Er-0c; Mon, 18 Oct 2004 13:01:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaS2-0004iQ-Jm; Mon, 18 Oct 2004 12:33:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJZyt-0000sN-6Z for isms@megatron.ietf.org; Mon, 18 Oct 2004 12:03:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27622 for ; Mon, 18 Oct 2004 12:03:23 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJaAn-0003Jo-Tl for isms@ietf.org; Mon, 18 Oct 2004 12:15:51 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA19367; Mon, 18 Oct 2004 09:02:39 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9IG2ds13618; Mon, 18 Oct 2004 09:02:39 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Oct 2004 09:02:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Mon, 18 Oct 2004 09:02:38 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD8AB@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Reminder: ISMS proposals due October 18th Thread-Index: AcSyl6EE/p1s4zFfSS+l3PvQelxjpgCk8Kcw From: "Fleischman, Eric" To: X-OriginalArrivalTime: 18 Oct 2004 16:02:38.0826 (UTC) FILETIME=[E418ACA0:01C4B52B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Yes, it is problematic that there are a number of valid key management = alternatives to leverage and that no one choice is likely to satisfy = everyone. That is why I prefer approaches that support all of the "heavy = hitters" (i.e., a single approach that permit bindings to kerberos, PKI, = etc.). That way everyone's itch can be scratched. From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] =20 >I am using SASL enabled protocols all the day and so=20 >I would think that authenticating SNMP users via SASL=20 >should fit at least some operational requirements.=20 >Sure, in a kerberos environment, leveraging kerberos >services makes sense. The problem I see is that not all >environments are the same nor that all SNMP interaction=20 > patterns are the same. So searching for the holy grail=20 >is kind of doomed to failure (and that >probably reduces my enthusiam here a bit). =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 12:53:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01308; Mon, 18 Oct 2004 12:53:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJax2-0004Jb-SP; Mon, 18 Oct 2004 13:05:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaUO-0005Bs-Om; Mon, 18 Oct 2004 12:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJa7G-0001tQ-Pd for isms@megatron.ietf.org; Mon, 18 Oct 2004 12:12:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28276 for ; Mon, 18 Oct 2004 12:12:03 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJaJD-0003Sv-2I for isms@ietf.org; Mon, 18 Oct 2004 12:24:31 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA19815; Mon, 18 Oct 2004 09:11:14 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9IGBEs25249; Mon, 18 Oct 2004 09:11:14 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Oct 2004 09:11:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Mon, 18 Oct 2004 09:11:12 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD8AC@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Reminder: ISMS proposals due October 18th Thread-Index: AcSztd2JjK04qzbhRZK+/dYe0tQ5+ABdvC5Q From: "Fleischman, Eric" To: "McDonald, Ira" , "Ken Hornstein" , X-OriginalArrivalTime: 18 Oct 2004 16:11:14.0248 (UTC) FILETIME=[174FD480:01C4B52D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Ira, No one system will meet everyone's need. While a PKI system would be the = best choice for the environments in which I work, it would be fairly = unusable in other environments. That is why I favor alternatives = supporting multiple key management systems because that way I can have = my PKI and you can have your whatever-it-is-that-you-use. --Eric -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Saturday, October 16, 2004 12:22 PM To: 'Ken Hornstein'; isms@ietf.org Subject: RE: [Isms] Reminder: ISMS proposals due October 18th=20 Hi, I concede that a PKI-only solution is no help. So, what about: (1) TLS with Kerberos Authentication (RFC 2712) - used with the DTLS connectionless substrate and/or (2) TLS with Secure Remote Password - SRP is one-time password (diminishing numbers of repetitive hashes of the seed to yield the current value one password, which when used immediately expires) Refereences: [RFC2945] The SRP Authentication and Key Exchange System September 2000 [TLS-SRP] Using SRP for TLS Authentication , August 19, 2004 Both of these avoid the need for PKI deployment and both are fairly widely deployed today. As to the dedicated port issue, since we aren't allowed=20 to modify or extend the SNMP protocol operations, we'd have to have some kludge (i.e., Set serial number and=20 some string value to some MIB object) to pass STARTTLS in the SNMP application datastream. Do we think the SNMP purists will swallow such a kludge to avoid a dedicated port? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Ken Hornstein Sent: Friday, October 15, 2004 1:31 PM To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th=20 >(4) SNMP over DTLS requires a separate well-known > port (like the much-maligned HTTPS), because > the client (SNMP Manager) must know that the > DTLS handshake always comes first (the use > of an Upgrade header like RFC 2817 in the > application traffic doesn't make any sense). Another minor nit ... I always hear protocol geeks gnash their teeth about running TLS-based protocols on a different port (that's why many protocols now have STARTTLS or something similar with them). It may not be possible to turn on DTLS in-line (I will confess that I don't fully understand it all yet) but I'm sure someone's going to complain about it. --Ken >PS - Ken just made a very good point about the lack >of hooks in SASL and TLS (OpenSSL) APIs for passing >the cryptographic hash back and forth - that should >convince people to force mutual authentication in >the DTLS layer. I have to echo Wes's comments here ... one requirement of the output of this working group is that the security system fit in with _existing_ infrastructures, not require the creation of new security infrastructures (this was a major complaint of USM). This is non-negotiable. A PKI-only solution is a non-starter, IMHO (not speaking as a WG chair here). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 12:54:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01490; Mon, 18 Oct 2004 12:54:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJayP-0004LQ-Tm; Mon, 18 Oct 2004 13:07:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaUc-0005Ij-9k; Mon, 18 Oct 2004 12:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJa9l-00028t-Iz for isms@megatron.ietf.org; Mon, 18 Oct 2004 12:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28426 for ; Mon, 18 Oct 2004 12:14:37 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJaLe-0003W0-7D for isms@ietf.org; Mon, 18 Oct 2004 12:27:02 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9IGE05W015863; Mon, 18 Oct 2004 09:14:00 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PYX0QP>; Mon, 18 Oct 2004 09:14:00 -0700 Message-ID: From: "McDonald, Ira" To: "'Fleischman, Eric'" , j.schoenwaelder@iu-bremen.de Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Date: Mon, 18 Oct 2004 09:13:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi, I agree that an ISMS that depends on only one key management alternative will be unsatisfactory. I also agree with Ken that SASL _all_by_itself_ could be used with SNMP. Because of the inner/outer security layer linkage needed for SASL over TLS, I fail to see the value of TLS (or conversely, of SASL). There are TLS standardized bindings to many authentication schemes, but even there, exporting that knowledge up into the SNMP application layer looks complicated. Unfortunately, TLS falls off the edge for ISMS, because we didn't have sufficient discussion and concensus on a TLS approach to get an I-D out today. But this perceived requirement to support multiple key management and authentication schemes should certainly be applied when reviewing other ISMS alternatives (e.g., an all RADIUS approach should not be accepted). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Fleischman, Eric [mailto:eric.fleischman@boeing.com] Sent: Monday, October 18, 2004 12:03 PM To: j.schoenwaelder@iu-bremen.de Cc: Wes Hardaker; McDonald, Ira; isms@ietf.org Subject: RE: [Isms] Reminder: ISMS proposals due October 18th Yes, it is problematic that there are a number of valid key management alternatives to leverage and that no one choice is likely to satisfy everyone. That is why I prefer approaches that support all of the "heavy hitters" (i.e., a single approach that permit bindings to kerberos, PKI, etc.). That way everyone's itch can be scratched. From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] >I am using SASL enabled protocols all the day and so >I would think that authenticating SNMP users via SASL >should fit at least some operational requirements. >Sure, in a kerberos environment, leveraging kerberos >services makes sense. The problem I see is that not all >environments are the same nor that all SNMP interaction > patterns are the same. So searching for the holy grail >is kind of doomed to failure (and that >probably reduces my enthusiam here a bit). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 13:27:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04154; Mon, 18 Oct 2004 13:27:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbTq-000532-VK; Mon, 18 Oct 2004 13:39:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJb0f-0000lo-S6; Mon, 18 Oct 2004 13:09:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaZa-000671-OO for isms@megatron.ietf.org; Mon, 18 Oct 2004 12:41:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00559 for ; Mon, 18 Oct 2004 12:41:19 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJalU-00045d-Cy for isms@ietf.org; Mon, 18 Oct 2004 12:53:48 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 8D4A51223BF; Mon, 18 Oct 2004 09:41:12 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: From: Wes Hardaker Organization: Sparta Date: Mon, 18 Oct 2004 09:41:12 -0700 In-Reply-To: (Ira McDonald's message of "Mon, 18 Oct 2004 09:13:59 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 >>>>> On Mon, 18 Oct 2004 09:13:59 -0700, "McDonald, Ira" said: Ira> But this perceived requirement to support multiple key management Ira> and authentication schemes should certainly be applied when Ira> reviewing other ISMS alternatives (e.g., an all RADIUS approach Ira> should not be accepted). I'm not sure "not be accepted" is the right wording. Personally, I think its not what would be ideal for the operators out there as it wouldn't meet everyones needs. However, I think the proper wording would be more like "must be weighted carefully". I don't think an end goal of "must support at least 10 mechanisms" is wise either. I think we need to strike a balance, make one mandatory to implement (probably) and hopefully use a fairly extensible solution so adding new authentication mechanisms in the future would be easy. For SBSM, eg, it takes about a page of text to describe how to add another authentication mechanism without modifying the rest of the document. I think this is a good thing, as it allows for future expansion if we ever needed it (but that doesn't mean I think we should support everything under the sun either; just the most needed). [Many other protocols have taken similar lines. EAP, etc, also allow for easy future expansion because they have recognized that environments differ greatly and that the future is far from certain] -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 14:06:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07621; Mon, 18 Oct 2004 14:06:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJc5w-0005zU-CX; Mon, 18 Oct 2004 14:18:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbaX-0005vq-W3; Mon, 18 Oct 2004 13:46:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbDe-0002gf-05 for isms@megatron.ietf.org; Mon, 18 Oct 2004 13:22:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03784 for ; Mon, 18 Oct 2004 13:22:42 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbPZ-0004xm-4k for isms@ietf.org; Mon, 18 Oct 2004 13:35:11 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9IHMa2D018141 for ; Mon, 18 Oct 2004 13:22:37 -0400 (EDT) Message-Id: <200410181722.i9IHMa2D018141@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Reminder: ISMS proposals due October 18th In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 18 Oct 2004 13:22:36 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 >I also agree with Ken that SASL _all_by_itself_ could be used >with SNMP. Because of the inner/outer security layer linkage >needed for SASL over TLS, I fail to see the value of TLS (or >conversely, of SASL). To be fair ... SASL does provide an architecture that supports authentication (the piece that TLS is generally deficient in) and it can do encryption (_if_ the SASL mechanism supports it), and there is a reasonable set of APIs that exist to get the authentication information to the application. So SASL alone would be fine, IMHO. Well, it would be a challenge to get some of the back-ends in there (e.g. RADIUS), but I don't think it's insurmountable. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 15:46:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17240; Mon, 18 Oct 2004 15:46:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJdeW-00089v-GQ; Mon, 18 Oct 2004 15:58:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJd3k-0006ie-N0; Mon, 18 Oct 2004 15:20:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJcjB-0003pQ-59 for isms@megatron.ietf.org; Mon, 18 Oct 2004 14:59:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12752 for ; Mon, 18 Oct 2004 14:59:25 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJcvB-0007CB-RD for isms@ietf.org; Mon, 18 Oct 2004 15:11:54 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2004 12:06:17 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9IIwoYJ002720; Mon, 18 Oct 2004 11:58:50 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (dhcp-171-69-71-73.cisco.com [171.69.71.73]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUV57892; Mon, 18 Oct 2004 11:57:20 -0700 (PDT) Message-Id: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 18 Oct 2004 11:58:51 -0700 To: isms@ietf.org From: Kaushik Narayan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Isms] ISMS Encryption Requirement X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Hi All, We had a question about ISMS being able to provide one of the features that we think is important for SNMPv3. It is ability in SNMPv3 to decide whether a packet needs to be encrypted on a per-packet basis, rather than on a per-"session" basis. It is essential that agents need to authenticate every packet but however, the same is *not* true for encryption. For example, the ifInOctets counter for the interface over which the SNMP request is sent is not secret -- anybody with access to the wire can count such packets. It is entirely a waste of the agent's resources to encrypt an SNMP packet which contains (only) that ifInOctets counter. The same is true for a significant number of other MIB objects. On the other hand, some packets contain the values of MIB objects which *are* secret and do need to be encrypted. In other words, the ability to decide whether a packet needs to be encrypted ought to be on a per-packet basis, not on a per-"session" basis. Of course: - some agents have lots of CPU-power and can afford to encrypt/decrypt every SNMP packet send/received, or - some net-administrators are naturally paranoid and will want to encrypt all SNMP packets, or - some management applications send/receive no more packets to/from an SNMP agent than they send/receive CLI commands over encrypted SSH sessions, and because that number is small enough, the CPU-power taken to encrypt/de-crypt is not significant burden. But ... for agents where none of the above bullets are true, then ISMS needs to offer the capability for an agent to be configured to accept and respond to authenticated but unencrypted packets for a number of MIB objects which are not secret and provide encryption for certain other sensitive MIB objects as part of the same "session". Otherwise, many of today's SNMP agents and/or management applications will break due to a lack of CPU-power. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 16:43:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21345; Mon, 18 Oct 2004 16:43:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeXS-00014j-Nk; Mon, 18 Oct 2004 16:55:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJe8X-00053x-58; Mon, 18 Oct 2004 16:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdrf-0001VC-K9 for isms@megatron.ietf.org; Mon, 18 Oct 2004 16:12:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19139 for ; Mon, 18 Oct 2004 16:12:12 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJe3c-0000Pu-OC for isms@ietf.org; Mon, 18 Oct 2004 16:24:42 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 67DF99E23; Mon, 18 Oct 2004 22:11:38 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08355-08; Mon, 18 Oct 2004 22:11:37 +0200 (CEST) Received: from james (G5aaa.g.pppool.de [80.185.90.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 3052A9C66; Mon, 18 Oct 2004 22:11:37 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CJdqy-0000Tj-8i; Mon, 18 Oct 2004 22:11:36 +0200 Date: Mon, 18 Oct 2004 22:11:36 +0200 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement Message-ID: <20041018201136.GA1819@james> Mail-Followup-To: Kaushik Narayan , isms@ietf.org References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 2.9 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Mon, Oct 18, 2004 at 11:58:51AM -0700, Kaushik Narayan wrote: > We had a question about ISMS being able to provide one of the features > that we think is important for SNMPv3. It is ability in SNMPv3 to decide > whether a packet needs to be encrypted on a per-packet basis, rather > than on a per-"session" basis. Let me disagree - at least to start a debate about this. ;-) > It is essential that agents need to authenticate every packet > but however, the same is *not* true for encryption. For example, the > ifInOctets counter for the interface over which the SNMP request is > sent is not secret -- anybody with access to the wire can count such > packets. It is entirely a waste of the agent's resources to encrypt > an SNMP packet which contains (only) that ifInOctets counter. The same > is true for a significant number of other MIB objects. On the other hand, > some packets contain the values of MIB objects which *are* secret and > do need to be encrypted. In other words, the ability to decide whether > a packet needs to be encrypted ought to be on a per-packet basis, not on > a per-"session" basis. Of course: > > - some agents have lots of CPU-power and can afford to encrypt/decrypt > every SNMP packet send/received, or > - some net-administrators are naturally paranoid and will want to encrypt > all SNMP packets, or > - some management applications send/receive no more packets to/from > an SNMP agent than they send/receive CLI commands over encrypted > SSH sessions, and because that number is small enough, the CPU-power > taken to encrypt/de-crypt is not significant burden. Who decides whether a certain packet needs encryption? If it is simply the type of application (say MRTG), then why is using an unencrypted session not working? If it is more than the type of the application, who actually makes the decision? The application writer? The operator? But in both cases, why is it not sufficient to have an encrypted and an unencrypted authenticated channel to choose from? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 17:00:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22862; Mon, 18 Oct 2004 17:00:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJenx-0001QR-5t; Mon, 18 Oct 2004 17:12:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeIo-0006zj-WC; Mon, 18 Oct 2004 16:40:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJe1X-0003PZ-Jo for isms@megatron.ietf.org; Mon, 18 Oct 2004 16:22:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19851 for ; Mon, 18 Oct 2004 16:22:24 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeDW-0000e0-1B for isms@ietf.org; Mon, 18 Oct 2004 16:34:54 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id EEAEB9E2C; Mon, 18 Oct 2004 22:21:54 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08885-08; Mon, 18 Oct 2004 22:21:54 +0200 (CEST) Received: from james (G5aaa.g.pppool.de [80.185.90.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id D6D819E2B; Mon, 18 Oct 2004 22:21:53 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CJe0v-0000UQ-4b; Mon, 18 Oct 2004 22:21:53 +0200 Date: Mon, 18 Oct 2004 22:21:53 +0200 From: Juergen Schoenwaelder To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th Message-ID: <20041018202153.GB1819@james> Mail-Followup-To: "McDonald, Ira" , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 2.9 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Mon, Oct 18, 2004 at 09:13:59AM -0700, McDonald, Ira wrote: > Unfortunately, TLS falls off the edge for ISMS, because we > didn't have sufficient discussion and concensus on a TLS > approach to get an I-D out today. Just for the record: I submitted an ID which is still in its infancy stage. It is up the chairs whether they want to consider or right away defeat it. What we were trying to do was to start work on how a security mechanism which is part of a transport (in terms of the SNMP architecture) could fit into the SNMP architecture. This is the SNMP architecture part of the work that needs to be done. The other part of the work is to identify how TLS and/or how SASL would be a viable secure transport. I tried to collect some of the wisdom of recent messages here on the list but there is lots of work to be donw in order to get something meaningful. Our motivation is more that the SNMP architecture work needs only be done once and then we can add secure transports as they come and go. The ID will be called once it is being posted. We plan to continue work on this before the IETF so any suggestions and contributions are welcome. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 17:22:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24267; Mon, 18 Oct 2004 17:22:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJf9j-0001pm-47; Mon, 18 Oct 2004 17:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJenH-0004iK-Vo; Mon, 18 Oct 2004 17:11:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeN0-0007uD-BK for isms@megatron.ietf.org; Mon, 18 Oct 2004 16:44:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21467 for ; Mon, 18 Oct 2004 16:44:34 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeYx-00016E-Rr for isms@ietf.org; Mon, 18 Oct 2004 16:57:05 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 786F51223BD; Mon, 18 Oct 2004 13:44:29 -0700 (PDT) To: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> From: Wes Hardaker Organization: Sparta Date: Mon, 18 Oct 2004 13:44:29 -0700 In-Reply-To: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> (Kaushik Narayan's message of "Mon, 18 Oct 2004 11:58:51 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 >>>>> On Mon, 18 Oct 2004 11:58:51 -0700, Kaushik Narayan said: Kaushik> We had a question about ISMS being able to provide one of the Kaushik> features that we think is important for SNMPv3. It is ability Kaushik> in SNMPv3 to decide whether a packet needs to be encrypted on Kaushik> a per-packet basis, rather than on a per-"session" basis. I think many of the solutions proposed fit this bill. SBSM certainly handles this and I'd have to go back and look to be certain, but I believe EUSM does too. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 17:55:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27776; Mon, 18 Oct 2004 17:55:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJffd-0002gk-1d; Mon, 18 Oct 2004 18:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJexI-0006eS-N8; Mon, 18 Oct 2004 17:22:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJenE-0004fN-KM for isms@megatron.ietf.org; Mon, 18 Oct 2004 17:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23533 for ; Mon, 18 Oct 2004 17:11:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJezB-0001bo-HZ for isms@ietf.org; Mon, 18 Oct 2004 17:24:12 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2004 14:18:32 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9ILB7OE002290; Mon, 18 Oct 2004 14:11:08 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (dhcp-171-69-71-73.cisco.com [171.69.71.73]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUV72824; Mon, 18 Oct 2004 14:09:34 -0700 (PDT) Message-Id: <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 18 Oct 2004 14:11:04 -0700 To: j.schoenwaelder@iu-bremen.de From: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <20041018201136.GA1819@james> References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <20041018201136.GA1819@james> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0131413909==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 --===============0131413909== Content-Type: multipart/alternative; boundary="=====================_1562881344==.ALT" --=====================_1562881344==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Juergen, Please find my response inline. At 01:11 PM 10/18/2004, Juergen Schoenwaelder wrote: >On Mon, Oct 18, 2004 at 11:58:51AM -0700, Kaushik Narayan wrote: > > > We had a question about ISMS being able to provide one of the features > > that we think is important for SNMPv3. It is ability in SNMPv3 to decide > > whether a packet needs to be encrypted on a per-packet basis, rather > > than on a per-"session" basis. > >Let me disagree - at least to start a debate about this. ;-) Per packet application of the securityLevel is inherent to the SNMPv3 architecture. From STD62 "Every message has an associated securityLevel. All Subsystems (Message Processing, Security, Access Control) and applications are REQUIRED to either supply a value of securityLevel or to abide by the supplied value of securityLevel while processing the message and its contents." Are you suggesting that this behavior need not be retained with ISMS. > > > It is essential that agents need to authenticate every packet > > but however, the same is *not* true for encryption. For example, the > > ifInOctets counter for the interface over which the SNMP request is > > sent is not secret -- anybody with access to the wire can count such > > packets. It is entirely a waste of the agent's resources to encrypt > > an SNMP packet which contains (only) that ifInOctets counter. The same > > is true for a significant number of other MIB objects. On the other hand, > > some packets contain the values of MIB objects which *are* secret and > > do need to be encrypted. In other words, the ability to decide whether > > a packet needs to be encrypted ought to be on a per-packet basis, not on > > a per-"session" basis. Of course: > > > > - some agents have lots of CPU-power and can afford to encrypt/decrypt > > every SNMP packet send/received, or > > - some net-administrators are naturally paranoid and will want to encrypt > > all SNMP packets, or > > - some management applications send/receive no more packets to/from > > an SNMP agent than they send/receive CLI commands over encrypted > > SSH sessions, and because that number is small enough, the CPU-power > > taken to encrypt/de-crypt is not significant burden. > >Who decides whether a certain packet needs encryption? If it is simply >the type of application (say MRTG), then why is using an unencrypted >session not working? If it is more than the type of the application, >who actually makes the decision? The application writer? The operator? >But in both cases, why is it not sufficient to have an encrypted and >an unencrypted authenticated channel to choose from? The per-packet decision is made by a combination of things, in most cases driven by the NM application based on the MIB objects, operator policy and agent capability. Correct me if I am wrong but per your suggestion, each SNMP "session" would have to negotiate two separate protection channels (encrypted and authenticated w/o encryption) and for every packet the SNMP engine will use the appropriate channel based on the desired securityLevel. It would be more optimal to negotiate authentication and privacy keys and let SNMP engine apply the per-packet protection as described in STD62. regards, kaushik! > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany --=====================_1562881344==.ALT Content-Type: text/html; charset="us-ascii" Hi Juergen,

Please find my response inline.


At 01:11 PM 10/18/2004, Juergen Schoenwaelder wrote:
On Mon, Oct 18, 2004 at 11:58:51AM -0700, Kaushik Narayan wrote:
 
> We had a question about ISMS being able to provide one of the features
> that we think is important for SNMPv3. It is ability in SNMPv3 to decide
> whether a packet needs to be encrypted on a per-packet basis, rather
> than on a per-"session" basis.

Let me disagree - at least to start a debate about this. ;-)


Per packet application of the securityLevel is inherent to the SNMPv3
architecture. From STD62

"Every message has an associated securityLevel.  All
Subsystems
(Message Processing, Security, Access Control) and applications are
REQUIRED to either supply a value of securityLevel or to abide by the
supplied value of securityLevel while processing the message and its
contents."
Are you suggesting that this behavior need not be retained with ISMS.
 
> It is essential that agents need to authenticate every packet
> but however, the same is *not* true for encryption.  For example, the
> ifInOctets counter for the interface over which the SNMP request is
> sent is not secret -- anybody with access to the wire can count such
> packets.  It is entirely a waste of the agent's resources to encrypt
> an SNMP packet which contains (only) that ifInOctets counter.  The same
> is true for a significant number of other MIB objects.  On the other hand,
> some packets contain the values of MIB objects which *are* secret and
> do need to be encrypted.  In other words, the ability to decide whether
> a packet needs to be encrypted ought to be on a per-packet basis, not on
> a per-"session" basis.  Of course:
>
> - some agents have lots of CPU-power and can afford to encrypt/decrypt
>   every SNMP packet send/received, or
> - some net-administrators are naturally paranoid and will want to encrypt
>   all SNMP packets, or
> - some management applications send/receive no more packets to/from
>   an SNMP agent than they send/receive CLI commands over encrypted
>   SSH sessions, and because that number is small enough, the CPU-power
>   taken to encrypt/de-crypt is not significant burden.

Who decides whether a certain packet needs encryption? If it is simply
the type of application (say MRTG), then why is using an unencrypted
session not working? If it is more than the type of the application,
who actually makes the decision? The application writer? The operator?
But in both cases, why is it not sufficient to have an encrypted and
an unencrypted authenticated channel to choose from?


The per-packet decision is made by a combination of things, in most
cases driven by the NM application based on the MIB objects, operator
policy and agent capability.

Correct me if I am wrong but per your suggestion, each SNMP "session"
would have to negotiate two separate protection channels (encrypted and
authenticated w/o encryption) and for every packet the SNMP engine will
use the appropriate channel based on the desired securityLevel. It would
be more optimal to negotiate authentication and privacy keys and let SNMP
engine apply the per-packet protection as described in STD62.


regards,
  kaushik!

 
/js

--
Juergen Schoenwaelder               International University Bremen
<http://www.eecs.iu-bremen.de/>     P.O. Box 750 561, 28725 Bremen, Germany
--=====================_1562881344==.ALT-- --===============0131413909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0131413909==-- From isms-bounces@ietf.org Mon Oct 18 17:57:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28019; Mon, 18 Oct 2004 17:57:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfhw-0002kf-UI; Mon, 18 Oct 2004 18:10:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJf7v-0008GK-UQ; Mon, 18 Oct 2004 17:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeva-0005y7-6q for isms@megatron.ietf.org; Mon, 18 Oct 2004 17:20:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24134 for ; Mon, 18 Oct 2004 17:20:19 -0400 (EDT) Message-Id: <200410182120.RAA24134@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJf7Z-0001mE-Hv for isms@ietf.org; Mon, 18 Oct 2004 17:32:49 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <20041018211947016000sfibe>; Mon, 18 Oct 2004 21:19:47 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" , Subject: RE: [Isms] ISMS Encryption Requirement Date: Mon, 18 Oct 2004 17:19:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS1SyFaLpBkFmDERSK2yoWZ3YqAnwAC6a5w In-Reply-To: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hi, I suspect that different solutions will support this to differing degrees. If a session is all-encrypted or no-encryption, it might be possible to open two sessions. Of course, both agent and manager may need to understand how to handle two sessions with different security properties. I suspect that most operators, most agent implementors, and most application implementors would choose the simpler path of encrypting everything in the session. For vendors who produce products with inadequate CPU, they will need to worry about whether their competitors will do a better job. Having been on both the agent side and the manager side, and having listened to operators who want simple solutions, I don't think ISMS should require all proposed solutions to make encryption per-packet. The goal of ISMS is to make it easier to configure the security of SNMPv3. Requiring complexity that most equipment and application developers might not support in their products, and most operators wouldn't use if it was supported in products seems to be counter-indicated. My $.02 dbh -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan Sent: Monday, October 18, 2004 2:59 PM To: isms@ietf.org Subject: [Isms] ISMS Encryption Requirement Hi All, We had a question about ISMS being able to provide one of the features that we think is important for SNMPv3. It is ability in SNMPv3 to decide whether a packet needs to be encrypted on a per-packet basis, rather than on a per-"session" basis. It is essential that agents need to authenticate every packet but however, the same is *not* true for encryption. For example, the ifInOctets counter for the interface over which the SNMP request is sent is not secret -- anybody with access to the wire can count such packets. It is entirely a waste of the agent's resources to encrypt an SNMP packet which contains (only) that ifInOctets counter. The same is true for a significant number of other MIB objects. On the other hand, some packets contain the values of MIB objects which *are* secret and do need to be encrypted. In other words, the ability to decide whether a packet needs to be encrypted ought to be on a per-packet basis, not on a per-"session" basis. Of course: - some agents have lots of CPU-power and can afford to encrypt/decrypt every SNMP packet send/received, or - some net-administrators are naturally paranoid and will want to encrypt all SNMP packets, or - some management applications send/receive no more packets to/from an SNMP agent than they send/receive CLI commands over encrypted SSH sessions, and because that number is small enough, the CPU-power taken to encrypt/de-crypt is not significant burden. But ... for agents where none of the above bullets are true, then ISMS needs to offer the capability for an agent to be configured to accept and respond to authenticated but unencrypted packets for a number of MIB objects which are not secret and provide encryption for certain other sensitive MIB objects as part of the same "session". Otherwise, many of today's SNMP agents and/or management applications will break due to a lack of CPU-power. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 18:18:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00140; Mon, 18 Oct 2004 18:18:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJg1u-000395-JA; Mon, 18 Oct 2004 18:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfW5-0004qu-Pk; Mon, 18 Oct 2004 17:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfBk-0000MR-6S for isms@megatron.ietf.org; Mon, 18 Oct 2004 17:37:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25770 for ; Mon, 18 Oct 2004 17:37:01 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfNj-00028i-Ec for isms@ietf.org; Mon, 18 Oct 2004 17:49:31 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7493096EB; Mon, 18 Oct 2004 23:36:31 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13053-04; Mon, 18 Oct 2004 23:36:30 +0200 (CEST) Received: from james (G5b1d.g.pppool.de [80.185.91.29]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 239E67CA6; Mon, 18 Oct 2004 23:36:30 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CJfB7-0000Yk-FZ; Mon, 18 Oct 2004 23:36:29 +0200 Date: Mon, 18 Oct 2004 23:36:29 +0200 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement Message-ID: <20041018213629.GB2108@james> Mail-Followup-To: Kaushik Narayan , isms@ietf.org References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <20041018201136.GA1819@james> <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe On Mon, Oct 18, 2004 at 02:11:04PM -0700, Kaushik Narayan wrote: > Per packet application of the securityLevel is inherent to the SNMPv3 > architecture. From STD62 > > "Every message has an associated securityLevel. All Subsystems > (Message Processing, Security, Access Control) and applications are > REQUIRED to either supply a value of securityLevel or to abide by the > supplied value of securityLevel while processing the message and its > contents." To me, this text only says that every message has an associated securityLevel. It does not say how that maps to sessions (since the notion of sessions does not exist in STD62). > The per-packet decision is made by a combination of things, in most > cases driven by the NM application based on the MIB objects, operator > policy and agent capability. I would be curios to see some piece of code or logic that does this sort of thing. How do you combine the three ingredients you have listed above? What does agent capability mean here?? > Correct me if I am wrong but per your suggestion, each SNMP "session" > would have to negotiate two separate protection channels (encrypted and > authenticated w/o encryption) and for every packet the SNMP engine will > use the appropriate channel based on the desired securityLevel. It would > be more optimal to negotiate authentication and privacy keys and let SNMP > engine apply the per-packet protection as described in STD62. More optimal with regard to what? Encryption of small packets by itself is not very efficient. Breaking communication into pieces, some of which are encrypted while other are not might in some situations be more expensive than using an encrypted channel for everything. The measurements reported in the SNMP over TLS paper showed that SNMP over TLS performed better than SNMP over TCP with USM, basically because you share session state and do not have to treat each packet as an isolated event. Of course, you can build scenarios where you reach other results. The point is that we should start to be more precise and define the metrics and the scenario we are talking about if we claim something to be optimal or better. This is especially important since SNMP sometimes shows rather poor performance for tasks other than regular polling of a handful of variables that fit into one PDU. For those interested, there is a paper forthcoming in the IEEE eTNSM fall issue where you can see results from reading the interface table or doing SNMP walks on real-world agents. The work was driven by the desire to understand the impact of web services on CPU and memory requirements. As a side effect, some measurements of real-world SNMP agents were done and the results of these measurements alone are fun to look at. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 18:42:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01947; Mon, 18 Oct 2004 18:42:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgOp-0003X1-2X; Mon, 18 Oct 2004 18:54:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfqi-0006EA-0t; Mon, 18 Oct 2004 18:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfY5-0005I1-Gx for isms@megatron.ietf.org; Mon, 18 Oct 2004 18:00:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28208 for ; Mon, 18 Oct 2004 18:00:06 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfk2-0002oP-6Z for isms@ietf.org; Mon, 18 Oct 2004 18:12:37 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 0BA6D1223BD; Mon, 18 Oct 2004 15:00:01 -0700 (PDT) To: "McDonald, Ira" Subject: Re: [Isms] Reminder: ISMS proposals due October 18th References: <20041018202153.GB1819@james> From: Wes Hardaker Organization: Sparta Date: Mon, 18 Oct 2004 15:00:00 -0700 In-Reply-To: <20041018202153.GB1819@james> (Juergen Schoenwaelder's message of "Mon, 18 Oct 2004 22:21:53 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> On Mon, 18 Oct 2004 22:21:53 +0200, Juergen Schoenwaelder said: Juergen> Just for the record: I submitted an ID which is still in its infancy Juergen> stage. Infancy drafts are acceptable, as previously discussed. If you want it to be considered, I suggest you say so really quickly since the deadline was technically this morning ET and we haven't heard about it until now. It sounds like this is sort of a message saying that, but you weren't very explicit. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 19:07:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04059; Mon, 18 Oct 2004 19:07:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgng-00049k-O1; Mon, 18 Oct 2004 19:20:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJgOn-0006Cr-Fm; Mon, 18 Oct 2004 18:54:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJg1l-0000nL-Kj for isms@megatron.ietf.org; Mon, 18 Oct 2004 18:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01161 for ; Mon, 18 Oct 2004 18:30:46 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgDk-0003KJ-Fv for isms@ietf.org; Mon, 18 Oct 2004 18:43:17 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Oct 2004 15:37:27 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9IMTuOE020853; Mon, 18 Oct 2004 15:30:01 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (dhcp-171-69-71-73.cisco.com [171.69.71.73]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUV81710; Mon, 18 Oct 2004 15:28:23 -0700 (PDT) Message-Id: <6.0.0.22.0.20041018144506.03e85900@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 18 Oct 2004 15:29:55 -0700 To: From: Kaushik Narayan Subject: RE: [Isms] ISMS Encryption Requirement In-Reply-To: <3hr0l2$53ri9@sj-inbound-c.cisco.com> References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <3hr0l2$53ri9@sj-inbound-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db It's not just about CPU power of the device but the percentage of CPU cycles that are spent on network management. There isn't much value in using encryption for a performance management system polling PEs for performance data on thousands of interfaces every ten minutes,it just adds significant overhead to processing of the packet. At 02:19 PM 10/18/2004, David B Harrington wrote: >Hi, > >I suspect that different solutions will support this to differing >degrees. If a session is all-encrypted or no-encryption, it might be >possible to open two sessions. Of course, both agent and manager may >need to understand how to handle two sessions with different security >properties. > >I suspect that most operators, most agent implementors, and most >application implementors would choose the simpler path of encrypting >everything in the session. For vendors who produce products with >inadequate CPU, they will need to worry about whether their >competitors will do a better job. > >Having been on both the agent side and the manager side, and having >listened to operators who want simple solutions, I don't think ISMS >should require all proposed solutions to make encryption per-packet. >The goal of ISMS is to make it easier to configure the security of >SNMPv3. Requiring complexity that most equipment and application >developers might not support in their products, and most operators >wouldn't use if it was supported in products seems to be >counter-indicated. > >My $.02 > >dbh > >-----Original Message----- >From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] >On Behalf Of Kaushik Narayan >Sent: Monday, October 18, 2004 2:59 PM >To: isms@ietf.org >Subject: [Isms] ISMS Encryption Requirement > >Hi All, > >We had a question about ISMS being able to provide one of the features >that we think is important for SNMPv3. It is ability in SNMPv3 to >decide whether a packet needs to be encrypted on a per-packet basis, >rather than on a per-"session" basis. > >It is essential that agents need to authenticate every packet but >however, the same is *not* true for encryption. For example, the >ifInOctets counter for the interface over which the SNMP request is >sent is not secret -- anybody with access to the wire can count such >packets. It is entirely a waste of the agent's resources to encrypt >an SNMP packet which contains (only) that ifInOctets counter. The >same is true for a significant number of other MIB objects. On the >other hand, some packets contain the values of MIB objects which *are* >secret and do need to be encrypted. In other words, the ability to >decide whether a packet needs to be encrypted ought to be on a >per-packet basis, not on a per-"session" basis. Of course: > >- some agents have lots of CPU-power and can afford to encrypt/decrypt > every SNMP packet send/received, or >- some net-administrators are naturally paranoid and will want to >encrypt > all SNMP packets, or >- some management applications send/receive no more packets to/from > an SNMP agent than they send/receive CLI commands over encrypted > SSH sessions, and because that number is small enough, the >CPU-power > taken to encrypt/de-crypt is not significant burden. > >But ... for agents where none of the above bullets are true, then ISMS >needs to offer the capability for an agent to be configured to accept >and respond to authenticated but unencrypted packets for a number of >MIB objects which are not secret and provide encryption for certain >other sensitive MIB objects as part of the same "session". Otherwise, >many of today's SNMP agents and/or management applications will break >due to a lack of CPU-power. > >regards, > kaushik! > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 19:12:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04524; Mon, 18 Oct 2004 19:12:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgsM-0004I4-6O; Mon, 18 Oct 2004 19:25:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJgVm-0007wg-KN; Mon, 18 Oct 2004 19:01:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJgBY-0002vW-Hy for isms@megatron.ietf.org; Mon, 18 Oct 2004 18:41:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01731 for ; Mon, 18 Oct 2004 18:40:52 -0400 (EDT) Message-Id: <200410182240.SAA01731@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgNV-0003UI-DU for isms@ietf.org; Mon, 18 Oct 2004 18:53:24 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004101822402001200g4hboe>; Mon, 18 Oct 2004 22:40:20 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" , Subject: RE: [Isms] ISMS Encryption Requirement Date: Mon, 18 Oct 2004 18:40:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS1XTsFVOuNbg04Tzi1XE4idOSFSwAAKj4Q In-Reply-To: <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 7bit Hi, Let me address this three ways. 1) As one of the architects of SNMPv3, I believe you're interpreting the text from RFC3411 section 3.4.3 incorrectly. Please read it more closely. Each designed subsytem must **either** supply a value of securityLevel, **or** abide by the supplied value of SecurityLevel. The architecture described in RFC3411 was designed to be compatible with the existing architecture of SNMPv1; i.e. SNMPv1 could be described using the RFC3411 architecture. SNMPv1 has no capability of specifying the securityLevel in a message, but it has a supplied value of securityLevel - noAuthNoPriv, as per BCP 74, RFC3584. You seem to be arguing that it should be a requirement that all subsystems must be designed to abide by a supplied value of SecurityLevel, and thus all proposals must be able to supply a securityLevel per packet. That is NOT an architectural requirement of RFC3411. 2) To make this a requirement of ISMS would require a change to the existing RFC3411 architecture requirements, or limit ISMS to a subset of legal RFC3411 designs. It would not necessarily be optimal to make this a requirement. A large part of the goal of ISMS is to leverage existing security solutions, to minimize the need to configure additional security solutions. It is not a goal to design another SNMP-specific security solution. If the existing technologies that are widely deployed could not be used because of the requirement you would like to require, then you would be defeating the purpose of ISMS. 3) It could be very beneficial to security and ease-of-use if the same technologies could be used to provide security for multiple NM interfaces within a system. Non-SNMP interfaces typically do not support the per-packet selection of encryption, to my knowledge. Common protocols in wide use for NM security include SSH for the CLI, and TLS or SSL for web-based interfaces, and I don't believe these support the feature. NetConf does not appear to be planning to support this feature either. The added complexity may not be justified in enough environments to make this "sometimes" benefit worth the cost. Therefore, to require that this feature be supported in all ISMS proposals would be to again isolate SNMP from the types of security used in most other NM interfaces. That is not desirable. David Harrington dbharrington@comcast.net co-chair SNMPv3 WG, concluded ________________________________ From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan Sent: Monday, October 18, 2004 5:11 PM To: j.schoenwaelder@iu-bremen.de Cc: isms@ietf.org Subject: Re: [Isms] ISMS Encryption Requirement Hi Juergen, Please find my response inline. At 01:11 PM 10/18/2004, Juergen Schoenwaelder wrote: On Mon, Oct 18, 2004 at 11:58:51AM -0700, Kaushik Narayan wrote: > We had a question about ISMS being able to provide one of the features > that we think is important for SNMPv3. It is ability in SNMPv3 to decide > whether a packet needs to be encrypted on a per-packet basis, rather > than on a per-"session" basis. Let me disagree - at least to start a debate about this. ;-) Per packet application of the securityLevel is inherent to the SNMPv3 architecture. From STD62 "Every message has an associated securityLevel. All Subsystems (Message Processing, Security, Access Control) and applications are REQUIRED to either supply a value of securityLevel or to abide by the supplied value of securityLevel while processing the message and its contents." Are you suggesting that this behavior need not be retained with ISMS. > It is essential that agents need to authenticate every packet > but however, the same is *not* true for encryption. For example, the > ifInOctets counter for the interface over which the SNMP request is > sent is not secret -- anybody with access to the wire can count such > packets. It is entirely a waste of the agent's resources to encrypt > an SNMP packet which contains (only) that ifInOctets counter. The same > is true for a significant number of other MIB objects. On the other hand, > some packets contain the values of MIB objects which *are* secret and > do need to be encrypted. In other words, the ability to decide whether > a packet needs to be encrypted ought to be on a per-packet basis, not on > a per-"session" basis. Of course: > > - some agents have lots of CPU-power and can afford to encrypt/decrypt > every SNMP packet send/received, or > - some net-administrators are naturally paranoid and will want to encrypt > all SNMP packets, or > - some management applications send/receive no more packets to/from > an SNMP agent than they send/receive CLI commands over encrypted > SSH sessions, and because that number is small enough, the CPU-power > taken to encrypt/de-crypt is not significant burden. Who decides whether a certain packet needs encryption? If it is simply the type of application (say MRTG), then why is using an unencrypted session not working? If it is more than the type of the application, who actually makes the decision? The application writer? The operator? But in both cases, why is it not sufficient to have an encrypted and an unencrypted authenticated channel to choose from? The per-packet decision is made by a combination of things, in most cases driven by the NM application based on the MIB objects, operator policy and agent capability. Correct me if I am wrong but per your suggestion, each SNMP "session" would have to negotiate two separate protection channels (encrypted and authenticated w/o encryption) and for every packet the SNMP engine will use the appropriate channel based on the desired securityLevel. It would be more optimal to negotiate authentication and privacy keys and let SNMP engine apply the per-packet protection as described in STD62. regards, kaushik! /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 19:15:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04900; Mon, 18 Oct 2004 19:15:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgvJ-0004Pu-RI; Mon, 18 Oct 2004 19:28:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJgYx-0000Pn-6E; Mon, 18 Oct 2004 19:05:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJgGU-00048u-Mg for isms@megatron.ietf.org; Mon, 18 Oct 2004 18:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02255 for ; Mon, 18 Oct 2004 18:45:59 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgST-0003aW-MS for isms@ietf.org; Mon, 18 Oct 2004 18:58:31 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1F4E72358; Tue, 19 Oct 2004 00:45:29 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 16539-02; Tue, 19 Oct 2004 00:45:28 +0200 (CEST) Received: from james (G5b1d.g.pppool.de [80.185.91.29]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 6BCF67C96; Tue, 19 Oct 2004 00:45:27 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CJgFp-0000XS-KW; Tue, 19 Oct 2004 00:45:25 +0200 Date: Tue, 19 Oct 2004 00:45:25 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Reminder: ISMS proposals due October 18th Message-ID: <20041018224525.GA2047@james> Mail-Followup-To: Wes Hardaker , "McDonald, Ira" , isms@ietf.org References: <20041018202153.GB1819@james> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Mon, Oct 18, 2004 at 03:00:00PM -0700, Wes Hardaker wrote: > Juergen> Just for the record: I submitted an ID which is still in its infancy > Juergen> stage. I have submitted an ID and I think this is what was required. It has not shown up so I was waiting to see that I actually managed to get all the formalisms we have to follow these days right. At the end, I think it is the job of the chairs to decide whether they accept the ID. So thanks for reminding me. /sj -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 19:20:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05327; Mon, 18 Oct 2004 19:20:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJh0H-0004Ys-4W; Mon, 18 Oct 2004 19:33:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJgb0-0001TK-18; Mon, 18 Oct 2004 19:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJgK8-0004tu-Dm for isms@megatron.ietf.org; Mon, 18 Oct 2004 18:49:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02432 for ; Mon, 18 Oct 2004 18:49:44 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgW8-0003fi-CU for isms@ietf.org; Mon, 18 Oct 2004 19:02:16 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 18 Oct 2004 15:59:07 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9IMn9k2006182; Mon, 18 Oct 2004 15:49:10 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (dhcp-171-69-71-73.cisco.com [171.69.71.73]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUV83732; Mon, 18 Oct 2004 15:47:37 -0700 (PDT) Message-Id: <6.0.0.22.0.20041018153003.06946230@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 18 Oct 2004 15:49:09 -0700 To: j.schoenwaelder@iu-bremen.de From: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <20041018213629.GB2108@james> References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <20041018201136.GA1819@james> <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <20041018213629.GB2108@james> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 At 02:36 PM 10/18/2004, Juergen Schoenwaelder wrote: >On Mon, Oct 18, 2004 at 02:11:04PM -0700, Kaushik Narayan wrote: > > > Per packet application of the securityLevel is inherent to the SNMPv3 > > architecture. From STD62 > > > > "Every message has an associated securityLevel. All Subsystems > > (Message Processing, Security, Access Control) and applications are > > REQUIRED to either supply a value of securityLevel or to abide by the > > supplied value of securityLevel while processing the message and its > > contents." > >To me, this text only says that every message has an associated >securityLevel. It does not say how that maps to sessions (since >the notion of sessions does not exist in STD62). > > > The per-packet decision is made by a combination of things, in most > > cases driven by the NM application based on the MIB objects, operator > > policy and agent capability. > >I would be curios to see some piece of code or logic that does this >sort of thing. How do you combine the three ingredients you have listed >above? What does agent capability mean here?? Predominantly the decision is driven by the SNMP objects. For e.g. the performance sub-system will work with objects that won't need encryption whereas we need encryption for most configuration objects. Typically operator policy such as "encryptAll" will over-ride this behavior. In some cases, especially for monitoring of modems and access points, it does not make sense to use encryption and the option to set explicit encryption policies is not available for operators. > > > Correct me if I am wrong but per your suggestion, each SNMP "session" > > would have to negotiate two separate protection channels (encrypted and > > authenticated w/o encryption) and for every packet the SNMP engine will > > use the appropriate channel based on the desired securityLevel. It would > > be more optimal to negotiate authentication and privacy keys and let SNMP > > engine apply the per-packet protection as described in STD62. > >More optimal with regard to what? > >Encryption of small packets by itself is not very efficient. Breaking >communication into pieces, some of which are encrypted while other are >not might in some situations be more expensive than using an encrypted >channel for everything. The measurements reported in the SNMP over TLS >paper showed that SNMP over TLS performed better than SNMP over TCP >with USM, basically because you share session state and do not have to >treat each packet as an isolated event. Of course, you can build >scenarios where you reach other results. I am not sure that using an encrypted TLS channel for everything will work for use cases in performance management wherein we collect massive amounts of non sensitive data at periodic intervals. >The point is that we should start to be more precise and define the >metrics and the scenario we are talking about if we claim something to >be optimal or better. This is especially important since SNMP sometimes >shows rather poor performance for tasks other than regular polling >of a handful of variables that fit into one PDU. For those interested, >there is a paper forthcoming in the IEEE eTNSM fall issue where you >can see results from reading the interface table or doing SNMP walks >on real-world agents. The work was driven by the desire to understand >the impact of web services on CPU and memory requirements. As a side >effect, some measurements of real-world SNMP agents were done and >the results of these measurements alone are fun to look at. > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 21:32:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15296; Mon, 18 Oct 2004 21:32:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJj3u-0007Rr-Qi; Mon, 18 Oct 2004 21:45:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJibX-0005Ki-Iw; Mon, 18 Oct 2004 21:15:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJiIs-0001zc-7B for isms@megatron.ietf.org; Mon, 18 Oct 2004 20:56:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12415 for ; Mon, 18 Oct 2004 20:56:32 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJiUm-0006XH-Sm for isms@ietf.org; Mon, 18 Oct 2004 21:09:04 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2004 03:10:44 +0200 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9J0tqSf013016; Tue, 19 Oct 2004 02:55:53 +0200 (MEST) Received: from kaushik-w2k02.cisco.com ([128.107.168.226]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUV94506; Mon, 18 Oct 2004 17:54:17 -0700 (PDT) Message-Id: <6.0.0.22.0.20041018154918.03e628c0@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 18 Oct 2004 17:55:50 -0700 To: From: Kaushik Narayan Subject: RE: [Isms] ISMS Encryption Requirement In-Reply-To: <3fhi7r$7nj50@sj-inbound-a.cisco.com> References: <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <3fhi7r$7nj50@sj-inbound-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Hi David, Sorry for my narrow interpretation of RFC3411. I was suggesting that the capability to use selective encryption for SNMPv3 is extremely useful in use cases around periodic data collection which is what SNMP is predominantly used for currently (in addition to fault management). NetConf and CLI access are predominantly used for configuration management that deal with data that is far more sensitive and far less voluminous and there is really no need to perform selective encryption. I am also not proposing that we stop evaluating existing security technologies for the use within ISMS. Infact most of the proposals on the table seem to be based on existing security technologies. Essentially, I think the ability to provide selective protection should be considered as a requirement to evaluate the proposals in addition to other requirements. regards, kaushik! At 03:40 PM 10/18/2004, David B Harrington wrote: >Hi, > >Let me address this three ways. > >1) As one of the architects of SNMPv3, I believe you're interpreting >the text from RFC3411 section 3.4.3 incorrectly. Please read it more >closely. > >Each designed subsytem must **either** supply a value of >securityLevel, **or** abide by the supplied value of SecurityLevel. >The architecture described in RFC3411 was designed to be compatible >with the existing architecture of SNMPv1; i.e. SNMPv1 could be >described using the RFC3411 architecture. >SNMPv1 has no capability of specifying the securityLevel in a message, >but it has a supplied value of securityLevel - noAuthNoPriv, as per >BCP 74, RFC3584. > >You seem to be arguing that it should be a requirement that all >subsystems must be designed to abide by a supplied value of >SecurityLevel, and thus all proposals must be able to supply a >securityLevel per packet. That is NOT an architectural requirement of >RFC3411. > >2) To make this a requirement of ISMS would require a change to the >existing RFC3411 architecture requirements, or limit ISMS to a subset >of legal RFC3411 designs. >It would not necessarily be optimal to make this a requirement. > >A large part of the goal of ISMS is to leverage existing security >solutions, to minimize the need to configure additional security >solutions. It is not a goal to design another SNMP-specific security >solution. >If the existing technologies that are widely deployed could not be >used because of the requirement you would like to require, then you >would be defeating the purpose of ISMS. > >3) It could be very beneficial to security and ease-of-use if the same >technologies could be used to provide security for multiple NM >interfaces within a system. Non-SNMP interfaces typically do not >support the per-packet selection of encryption, to my knowledge. >Common protocols in wide use for NM security include SSH for the CLI, >and TLS or SSL for web-based interfaces, and I don't believe these >support the feature. NetConf does not appear to be planning to support >this feature either. The added complexity may not be justified in >enough environments to make this "sometimes" benefit worth the cost. > >Therefore, to require that this feature be supported in all ISMS >proposals would be to again isolate SNMP from the types of security >used in most other NM interfaces. That is not desirable. > >David Harrington > >dbharrington@comcast.net > >co-chair SNMPv3 WG, concluded > > > >________________________________ > >From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] >On Behalf Of Kaushik Narayan >Sent: Monday, October 18, 2004 5:11 PM >To: j.schoenwaelder@iu-bremen.de >Cc: isms@ietf.org >Subject: Re: [Isms] ISMS Encryption Requirement > > >Hi Juergen, > >Please find my response inline. > > >At 01:11 PM 10/18/2004, Juergen Schoenwaelder wrote: > > > On Mon, Oct 18, 2004 at 11:58:51AM -0700, Kaushik Narayan >wrote: > > > We had a question about ISMS being able to provide one of >the features > > that we think is important for SNMPv3. It is ability in >SNMPv3 to decide > > whether a packet needs to be encrypted on a per-packet >basis, rather > > than on a per-"session" basis. > > Let me disagree - at least to start a debate about this. ;-) > > > >Per packet application of the securityLevel is inherent to the SNMPv3 >architecture. From STD62 > > >"Every message has an associated securityLevel. All >Subsystems >(Message Processing, Security, Access Control) and applications are >REQUIRED to either supply a value of securityLevel or to abide by the >supplied value of securityLevel while processing the message and its >contents." > > >Are you suggesting that this behavior need not be retained with ISMS. > > > > > It is essential that agents need to authenticate every >packet > > but however, the same is *not* true for encryption. For >example, the > > ifInOctets counter for the interface over which the SNMP >request is > > sent is not secret -- anybody with access to the wire can >count such > > packets. It is entirely a waste of the agent's resources to >encrypt > > an SNMP packet which contains (only) that ifInOctets >counter. The same > > is true for a significant number of other MIB objects. On >the other hand, > > some packets contain the values of MIB objects which *are* >secret and > > do need to be encrypted. In other words, the ability to >decide whether > > a packet needs to be encrypted ought to be on a per-packet >basis, not on > > a per-"session" basis. Of course: > > > > - some agents have lots of CPU-power and can afford to >encrypt/decrypt > > every SNMP packet send/received, or > > - some net-administrators are naturally paranoid and will >want to encrypt > > all SNMP packets, or > > - some management applications send/receive no more packets >to/from > > an SNMP agent than they send/receive CLI commands over >encrypted > > SSH sessions, and because that number is small enough, the >CPU-power > > taken to encrypt/de-crypt is not significant burden. > > Who decides whether a certain packet needs encryption? If it >is simply > the type of application (say MRTG), then why is using an >unencrypted > session not working? If it is more than the type of the >application, > who actually makes the decision? The application writer? The >operator? > But in both cases, why is it not sufficient to have an >encrypted and > an unencrypted authenticated channel to choose from? > > > >The per-packet decision is made by a combination of things, in most >cases driven by the NM application based on the MIB objects, operator >policy and agent capability. > >Correct me if I am wrong but per your suggestion, each SNMP "session" >would have to negotiate two separate protection channels (encrypted >and >authenticated w/o encryption) and for every packet the SNMP engine >will >use the appropriate channel based on the desired securityLevel. It >would >be more optimal to negotiate authentication and privacy keys and let >SNMP >engine apply the per-packet protection as described in STD62. > > >regards, > kaushik! > > > > > /js > > -- > Juergen Schoenwaelder International University >Bremen > P.O. Box 750 561, 28725 >Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 21:48:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16988; Mon, 18 Oct 2004 21:48:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJjIy-0007qE-FS; Mon, 18 Oct 2004 22:00:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJiuK-0000qQ-1c; Mon, 18 Oct 2004 21:35:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJiej-000640-6F for isms@megatron.ietf.org; Mon, 18 Oct 2004 21:19:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14208 for ; Mon, 18 Oct 2004 21:19:10 -0400 (EDT) Message-Id: <200410190119.VAA14208@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJiqh-00073a-7X for isms@ietf.org; Mon, 18 Oct 2004 21:31:42 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004101901183701200g4nr6e>; Tue, 19 Oct 2004 01:18:37 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" Subject: RE: [Isms] ISMS Encryption Requirement Date: Mon, 18 Oct 2004 21:18:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS1dmUXuq8uPDETQuOZzRiIlQ7LRgAAp5hQ In-Reply-To: <6.0.0.22.0.20041018154918.03e628c0@mira-sjc5-a.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: 7bit I think the ability to provide selective protection should be considered as a desirable feature to evaluate the proposals in addition to other requirements and desirable features. David Harrington dbharrington@comcast.net -----Original Message----- From: Kaushik Narayan [mailto:kaushik@cisco.com] Sent: Monday, October 18, 2004 8:56 PM To: ietfdbh@comcast.net Cc: j.schoenwaelder@iu-bremen.de; isms@ietf.org Subject: RE: [Isms] ISMS Encryption Requirement Hi David, Sorry for my narrow interpretation of RFC3411. I was suggesting that the capability to use selective encryption for SNMPv3 is extremely useful in use cases around periodic data collection which is what SNMP is predominantly used for currently (in addition to fault management). NetConf and CLI access are predominantly used for configuration management that deal with data that is far more sensitive and far less voluminous and there is really no need to perform selective encryption. I am also not proposing that we stop evaluating existing security technologies for the use within ISMS. Infact most of the proposals on the table seem to be based on existing security technologies. Essentially, I think the ability to provide selective protection should be considered as a requirement to evaluate the proposals in addition to other requirements. regards, kaushik! At 03:40 PM 10/18/2004, David B Harrington wrote: >Hi, > >Let me address this three ways. > >1) As one of the architects of SNMPv3, I believe you're interpreting >the text from RFC3411 section 3.4.3 incorrectly. Please read it more >closely. > >Each designed subsytem must **either** supply a value of securityLevel, >**or** abide by the supplied value of SecurityLevel. >The architecture described in RFC3411 was designed to be compatible >with the existing architecture of SNMPv1; i.e. SNMPv1 could be >described using the RFC3411 architecture. >SNMPv1 has no capability of specifying the securityLevel in a message, >but it has a supplied value of securityLevel - noAuthNoPriv, as per BCP >74, RFC3584. > >You seem to be arguing that it should be a requirement that all >subsystems must be designed to abide by a supplied value of >SecurityLevel, and thus all proposals must be able to supply a >securityLevel per packet. That is NOT an architectural requirement of >RFC3411. > >2) To make this a requirement of ISMS would require a change to the >existing RFC3411 architecture requirements, or limit ISMS to a subset >of legal RFC3411 designs. >It would not necessarily be optimal to make this a requirement. > >A large part of the goal of ISMS is to leverage existing security >solutions, to minimize the need to configure additional security >solutions. It is not a goal to design another SNMP-specific security >solution. >If the existing technologies that are widely deployed could not be used >because of the requirement you would like to require, then you would be >defeating the purpose of ISMS. > >3) It could be very beneficial to security and ease-of-use if the same >technologies could be used to provide security for multiple NM >interfaces within a system. Non-SNMP interfaces typically do not >support the per-packet selection of encryption, to my knowledge. >Common protocols in wide use for NM security include SSH for the CLI, >and TLS or SSL for web-based interfaces, and I don't believe these >support the feature. NetConf does not appear to be planning to support >this feature either. The added complexity may not be justified in >enough environments to make this "sometimes" benefit worth the cost. > >Therefore, to require that this feature be supported in all ISMS >proposals would be to again isolate SNMP from the types of security >used in most other NM interfaces. That is not desirable. > >David Harrington > >dbharrington@comcast.net > >co-chair SNMPv3 WG, concluded > > > >________________________________ > >From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] >On Behalf Of Kaushik Narayan >Sent: Monday, October 18, 2004 5:11 PM >To: j.schoenwaelder@iu-bremen.de >Cc: isms@ietf.org >Subject: Re: [Isms] ISMS Encryption Requirement > > >Hi Juergen, > >Please find my response inline. > > >At 01:11 PM 10/18/2004, Juergen Schoenwaelder wrote: > > > On Mon, Oct 18, 2004 at 11:58:51AM -0700, Kaushik Narayan >wrote: > > > We had a question about ISMS being able to provide one of >the features > > that we think is important for SNMPv3. It is ability in >SNMPv3 to decide > > whether a packet needs to be encrypted on a per-packet >basis, rather > > than on a per-"session" basis. > > Let me disagree - at least to start a debate about this. ;-) > > > >Per packet application of the securityLevel is inherent to the SNMPv3 >architecture. From STD62 > > >"Every message has an associated securityLevel. All Subsystems >(Message Processing, Security, Access Control) and applications are >REQUIRED to either supply a value of securityLevel or to abide by the >supplied value of securityLevel while processing the message and its >contents." > > >Are you suggesting that this behavior need not be retained with ISMS. > > > > > It is essential that agents need to authenticate every >packet > > but however, the same is *not* true for encryption. For >example, the > > ifInOctets counter for the interface over which the SNMP >request is > > sent is not secret -- anybody with access to the wire can >count such > > packets. It is entirely a waste of the agent's resources to >encrypt > > an SNMP packet which contains (only) that ifInOctets >counter. The same > > is true for a significant number of other MIB objects. On >the other hand, > > some packets contain the values of MIB objects which *are* >secret and > > do need to be encrypted. In other words, the ability to >decide whether > > a packet needs to be encrypted ought to be on a per-packet >basis, not on > > a per-"session" basis. Of course: > > > > - some agents have lots of CPU-power and can afford to >encrypt/decrypt > > every SNMP packet send/received, or > > - some net-administrators are naturally paranoid and will >want to encrypt > > all SNMP packets, or > > - some management applications send/receive no more packets >to/from > > an SNMP agent than they send/receive CLI commands over >encrypted > > SSH sessions, and because that number is small enough, the >CPU-power > > taken to encrypt/de-crypt is not significant burden. > > Who decides whether a certain packet needs encryption? If it >is simply > the type of application (say MRTG), then why is using an >unencrypted > session not working? If it is more than the type of the >application, > who actually makes the decision? The application writer? The >operator? > But in both cases, why is it not sufficient to have an >encrypted and > an unencrypted authenticated channel to choose from? > > > >The per-packet decision is made by a combination of things, in most >cases driven by the NM application based on the MIB objects, operator >policy and agent capability. > >Correct me if I am wrong but per your suggestion, each SNMP "session" >would have to negotiate two separate protection channels (encrypted and >authenticated w/o encryption) and for every packet the SNMP engine will >use the appropriate channel based on the desired securityLevel. It >would be more optimal to negotiate authentication and privacy keys and >let SNMP engine apply the per-packet protection as described in STD62. > > >regards, > kaushik! > > > > > /js > > -- > Juergen Schoenwaelder International University >Bremen > P.O. Box 750 561, 28725 >Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 21:53:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17441; Mon, 18 Oct 2004 21:53:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJjOR-000805-6M; Mon, 18 Oct 2004 22:06:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJiv6-000131-PY; Mon, 18 Oct 2004 21:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJij6-0006iS-Sy for isms@megatron.ietf.org; Mon, 18 Oct 2004 21:23:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14685 for ; Mon, 18 Oct 2004 21:23:42 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJiv5-0007DJ-C1 for isms@ietf.org; Mon, 18 Oct 2004 21:36:14 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CJiit-000426-Bs; Mon, 18 Oct 2004 21:23:35 -0400 Date: Mon, 18 Oct 2004 21:23:36 -0400 From: Robert Story To: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement Message-Id: <20041018212336.18c34c0a@dev.localdomain> In-Reply-To: <6.0.0.22.0.20041018153003.06946230@mira-sjc5-a.cisco.com> References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <20041018201136.GA1819@james> <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <20041018213629.GB2108@james> <6.0.0.22.0.20041018153003.06946230@mira-sjc5-a.cisco.com> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit On Mon, 18 Oct 2004 11:58:51 -0700 Kaushik wrote: KN> We had a question about ISMS being able to provide one of the features KN> that we think is important for SNMPv3. It is ability in SNMPv3 to decide KN> whether a packet needs to be encrypted on a per-packet basis, rather KN> than on a per-"session" basis. My impression of Kaushik's message was that he wants the decision to be made automatically (like setting up VACM views to define which objects need/don't need encryption). That doesn't seem workable, especially if done on the agent side, as sending a response packet with a different securityLevel than the the request packet would be just plain wrong. On Mon, 18 Oct 2004 15:49:09 -0700 Kaushik wrote: KN> At 02:36 PM 10/18/2004, Juergen Schoenwaelder wrote: KN> > > "Every message has an associated securityLevel. KN> > KN> >To me, this text only says that every message has an associated KN> >securityLevel. It does not say how that maps to sessions (since KN> >the notion of sessions does not exist in STD62). I think this is a key point. I think what the securityLevel of a session should be a soft of max-access. If you create a session with noAuthNoPriv, then you wouldn't be able to send encrypted packets. But if you start a session with AuthPriv, I don't see any reason why you shouldn't be able to send a pdu with a securityLevel of AuthNoPriv, thus requesting that there be no encryption for that packet. This, however, is a decision on the NM side, and would be at the application level, not the protocol level. If the ISMS RFC does let the session securityLevel function as a max-access level, then I think the view-based packet security level is a neat idea for the application vendor. Put in a feature request. Or, if you use and open source platform (*cough* net-snmp *cough*), submit a patch! :-) . -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Oct 18 23:51:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27103; Mon, 18 Oct 2004 23:51:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJlEa-0001zG-Kw; Tue, 19 Oct 2004 00:04:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJkdG-000310-D8; Mon, 18 Oct 2004 23:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJkKK-0000Cj-N3 for isms@megatron.ietf.org; Mon, 18 Oct 2004 23:06:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23457 for ; Mon, 18 Oct 2004 23:06:12 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJkWL-00013c-8d for isms@ietf.org; Mon, 18 Oct 2004 23:18:46 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id BC9DF1223BC; Mon, 18 Oct 2004 20:06:07 -0700 (PDT) To: ietfdbh@comcast.net Subject: Re: [Isms] ISMS Encryption Requirement References: <200410190119.VAA14208@ietf.org> From: Wes Hardaker Organization: Sparta Date: Mon, 18 Oct 2004 20:06:07 -0700 In-Reply-To: <200410190119.VAA14208@ietf.org> (David B. Harrington's message of "Mon, 18 Oct 2004 21:18:37 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 David> I think the ability to provide selective protection should be David> considered as a desirable feature to evaluate the proposals in David> addition to other requirements and desirable features. I agree. I shouldn't be a requirement, but as a desire I think it should be there as well. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 00:06:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27917; Tue, 19 Oct 2004 00:06:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJlSp-0002Ci-75; Tue, 19 Oct 2004 00:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJkmE-0004NS-CH; Mon, 18 Oct 2004 23:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJkQN-0001FM-My for isms@megatron.ietf.org; Mon, 18 Oct 2004 23:12:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23862 for ; Mon, 18 Oct 2004 23:12:28 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJkcQ-0001A9-1O for isms@ietf.org; Mon, 18 Oct 2004 23:25:02 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id C28111223BC; Mon, 18 Oct 2004 20:12:25 -0700 (PDT) To: Robert Story Subject: Re: [Isms] ISMS Encryption Requirement References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <20041018201136.GA1819@james> <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <20041018213629.GB2108@james> <6.0.0.22.0.20041018153003.06946230@mira-sjc5-a.cisco.com> <20041018212336.18c34c0a@dev.localdomain> From: Wes Hardaker Organization: Sparta Date: Mon, 18 Oct 2004 20:12:25 -0700 In-Reply-To: <20041018212336.18c34c0a@dev.localdomain> (Robert Story's message of "Mon, 18 Oct 2004 21:23:36 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 >>>>> On Mon, 18 Oct 2004 21:23:36 -0400, Robert Story said: Robert> My impression of Kaushik's message was that he wants the Robert> decision to be made automatically (like setting up VACM views Robert> to define which objects need/don't need encryption). That Robert> doesn't seem workable, especially if done on the agent side, Robert> as sending a response packet with a different securityLevel Robert> than the the request packet would be just plain wrong. I don't think thats what he meant at all. I'm quite sure he meant that if you start a SBSM or TLS or EUSM or ... session that you should be able to transmit packets under that session as either authNoPriv or authPriv. This is possible in SBSM and EUSM (I think) today, but will likely not be possible with TLS (though maybe with DTLS?). KN> >To me, this text only says that every message has an associated KN> >securityLevel. It does not say how that maps to sessions (since KN> >the notion of sessions does not exist in STD62). Robert> I think this is a key point. I think what the securityLevel of Robert> a session should be a soft of max-access. If you create a Robert> session with noAuthNoPriv, then you wouldn't be able to send Robert> encrypted packets. But if you start a session with AuthPriv, I Robert> don't see any reason why you shouldn't be able to send a pdu Robert> with a securityLevel of AuthNoPriv, thus requesting that there Robert> be no encryption for that packet. This, however, is a decision Robert> on the NM side, and would be at the application level, not the Robert> protocol level. I suspect that many potential protocols (SBSM included) don't really map to that statement. EG, in SBSM during setup the security level flags are ignored by the security and have to be till negotiation is finished. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 06:13:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07496; Tue, 19 Oct 2004 06:13:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJrC1-0000nb-EI; Tue, 19 Oct 2004 06:26:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqZC-00036j-OH; Tue, 19 Oct 2004 05:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqLQ-0000QF-Ml for isms@megatron.ietf.org; Tue, 19 Oct 2004 05:31:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04728 for ; Tue, 19 Oct 2004 05:31:45 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJqXU-0008R8-Te for isms@ietf.org; Tue, 19 Oct 2004 05:44:22 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 06FA09C7E; Tue, 19 Oct 2004 11:31:14 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12754-08; Tue, 19 Oct 2004 11:31:13 +0200 (CEST) Received: from james (james.public.iu-bremen.de [212.201.46.187]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 1DF2D9823; Tue, 19 Oct 2004 11:31:13 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CJqKn-0000rS-10; Tue, 19 Oct 2004 11:31:13 +0200 Date: Tue, 19 Oct 2004 11:31:13 +0200 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement Message-ID: <20041019093113.GA3295@james> Mail-Followup-To: Kaushik Narayan , ietfdbh@comcast.net, isms@ietf.org References: <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <3fhi7r$7nj50@sj-inbound-a.cisco.com> <6.0.0.22.0.20041018154918.03e628c0@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.22.0.20041018154918.03e628c0@mira-sjc5-a.cisco.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Mon, Oct 18, 2004 at 05:55:50PM -0700, Kaushik Narayan wrote: > I was suggesting that the capability to use selective encryption for SNMPv3 > is extremely useful in use cases around periodic data collection which > is what SNMP is predominantly used for currently (in addition to fault > management). NetConf and CLI access are predominantly used for configuration > management that deal with data that is far more sensitive and far less > voluminous and there is really no need to perform selective encryption. I heard operators saying that (a) MIB instrumentation often come too late and that (b) they often trust CLI numbers more than SNMP numbers. So there might be more scripted CLI access to collect data than you might expect. If you talk about voluminous data, do you mean that (i) you talk to lots of devices and each device gives you little pieces of data, but the total is voluminous, or do you mean that (ii) you retrieve large amounts of data from the average device, so the total is voluminous or (iii) are you saying that the retrieved data over some time tends to be voluminous. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 19:44:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03265; Tue, 19 Oct 2004 19:44:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK3qu-000831-3S; Tue, 19 Oct 2004 19:57:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJszN-0000QF-2p; Tue, 19 Oct 2004 08:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJshH-0005zH-TC for isms@megatron.ietf.org; Tue, 19 Oct 2004 08:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15267 for ; Tue, 19 Oct 2004 08:02:29 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJstN-0002pL-Oa for isms@ietf.org; Tue, 19 Oct 2004 08:15:07 -0400 Received: from [192.168.2.52] (YahooBB219059144059.bbtec.net [219.59.144.59]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 81DD41BAC4D; Tue, 19 Oct 2004 14:01:49 +0200 (CEST) Date: Tue, 19 Oct 2004 14:01:46 +0200 From: Juergen Quittek To: j.schoenwaelder@iu-bremen.de, Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement Message-ID: <2147483647.1098194506@[192.168.2.52]> In-Reply-To: <20041019093113.GA3295@james> References: <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <3fhi7r$7nj50@sj-inbound-a.cisco.com> <6.0.0.22.0.20041018154918.03e628c0@mira-sjc5-a.cisco.com> <20041019093113.GA3295@james> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit --On 19.10.2004 11:31 Uhr +0200 Juergen Schoenwaelder wrote: > On Mon, Oct 18, 2004 at 05:55:50PM -0700, Kaushik Narayan wrote: > >> I was suggesting that the capability to use selective encryption for SNMPv3 >> is extremely useful in use cases around periodic data collection which >> is what SNMP is predominantly used for currently (in addition to fault >> management). NetConf and CLI access are predominantly used for configuration >> management that deal with data that is far more sensitive and far less >> voluminous and there is really no need to perform selective encryption. > > I heard operators saying that (a) MIB instrumentation often come too > late and that (b) they often trust CLI numbers more than SNMP numbers. > So there might be more scripted CLI access to collect data than you > might expect. For periodical data collection, my observations is that several big operators prefer most and trust most log files over ftp, particularly if its a lot of data per managed node. Juergen > If you talk about voluminous data, do you mean that (i) you talk to > lots of devices and each device gives you little pieces of data, but > the total is voluminous, or do you mean that (ii) you retrieve large > amounts of data from the average device, so the total is voluminous > or (iii) are you saying that the retrieved data over some time tends > to be voluminous. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 22:05:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15650; Tue, 19 Oct 2004 22:05:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK63b-000383-SO; Tue, 19 Oct 2004 22:18:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK438-0000IS-V2; Tue, 19 Oct 2004 20:09:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJvEM-000524-Qs for isms@megatron.ietf.org; Tue, 19 Oct 2004 10:44:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02298 for ; Tue, 19 Oct 2004 10:44:45 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJvQR-0007Sb-E1 for isms@ietf.org; Tue, 19 Oct 2004 10:57:25 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9JEiefR002236 for ; Tue, 19 Oct 2004 10:44:40 -0400 (EDT) Message-Id: <200410191444.i9JEiefR002236@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 19 Oct 2004 10:44:40 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c >It is essential that agents need to authenticate every packet >but however, the same is *not* true for encryption. While I agree that it's not essential ... you should consider _very carefully_ the security implications of this. Let me give you a cautionary tale (the origin of it predates my involvement, but I was involved in the aftermath). Many many moons ago, various parties were hammering out the specification for Telnet Encryption (this eventually became RFC 2946). As part of this, there were a number of Telnet vendors/implementors involved in this process. A number of vendors wanted the ability to turn on and off encryption on the fly; the reasoning at the time was that they didn't want to incur the CPU overhead of encrypting and decrypting _everything_ (this was in the era of 68000-based Macintoshes), and that not everything in the Telnet stream was important. For example, some vendors planned on only encrypting passwords and the like. So, placed into the Telnet protocol was the ability to turn on and off encryption on the fly (a feature which is unique among stream-based encrypting protocols, AFAIK). In retrospect, this turned out to be a HUGE mistake. The reasons are multiple: - It turned out impossible in practice to determine when a password was being entered (since most telnet streams are not linemode and thus echo is handled on the server side). - Because this complicated the protocol, some vendors ended up implementing this feature incorrectly or incompletely (but because it wasn't being used in practice, see above, no one really understood this at the time). - It made it hard to enforce a consistant server-side policy (e.g, requiring the use of encryption), partly due to the nature of the protocol and partly because the implementations had to be so complicated to support this protocol feature. - It ended up creating a bunch of security vulnerabilities in the protocol which required a protocol revision to correct some of them (since you have to negotiate encryption before encryption starts, an attacker could remove the part of the stream that negotiates encryption). Not all of them are correctable, unfortunately (but thankfully the more important ones are). Other protocols learned the hard lessons of encrypted Telnet, and now nearly all encrypted-stream protocols (that I'm aware of) simply start encrypting as soon as possible, and have no capability to turn this encryption off. This simplifies the protocol and the implementation, and reduces the possibility of vulnerabilites. Now, not all of these things apply to SNMP, of course (for one, SNMP is a datagram-based protocol). But when you get into deciding that some data isn't worth encrypting and maybe you should only encrypt _part_ of it ... well, all I can say is that other protocols have decided that in the long run, it's better to encrypt everything. If the WG decides that only partial encryption is desired, then that's fine ... but I feel I would be remiss if I didn't point out that we should think _very hard_ about what exactly this means for security. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 22:39:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18657; Tue, 19 Oct 2004 22:39:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6Zr-00043x-Vw; Tue, 19 Oct 2004 22:51:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4do-00047h-1x; Tue, 19 Oct 2004 20:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJxVP-0005oM-1Y for isms@megatron.ietf.org; Tue, 19 Oct 2004 13:10:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17392 for ; Tue, 19 Oct 2004 13:10:30 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJxhX-0003fJ-HK for isms@ietf.org; Tue, 19 Oct 2004 13:23:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 19 Oct 2004 10:19:49 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9JH9gYJ021792; Tue, 19 Oct 2004 10:09:42 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (sjc-vpn1-585.cisco.com [10.21.98.73]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW39867; Tue, 19 Oct 2004 10:08:04 -0700 (PDT) Message-Id: <6.0.0.22.0.20041019093253.036ddb88@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 19 Oct 2004 10:09:45 -0700 To: Robert Story From: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <20041018212336.18c34c0a@dev.localdomain> References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <20041018201136.GA1819@james> <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <20041018213629.GB2108@james> <6.0.0.22.0.20041018153003.06946230@mira-sjc5-a.cisco.com> <20041018212336.18c34c0a@dev.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi Robert, Please find my reply inline. At 06:23 PM 10/18/2004, Robert Story wrote: >On Mon, 18 Oct 2004 11:58:51 -0700 Kaushik wrote: >KN> We had a question about ISMS being able to provide one of the features >KN> that we think is important for SNMPv3. It is ability in SNMPv3 to decide >KN> whether a packet needs to be encrypted on a per-packet basis, rather >KN> than on a per-"session" basis. > >My impression of Kaushik's message was that he wants the decision to be made >automatically (like setting up VACM views to define which objects need/don't >need encryption). That doesn't seem workable, especially if done on the agent >side, as sending a response packet with a different securityLevel than the the >request packet would be just plain wrong. I was suggesting that SNMPv3 currently allows a management application to support selective encryption within a session, i.e. certain requests can be sent with authPriv and certain others within authNoPriv. This is an important ability since there are significant implications on agent performance if we were to encrypt all data within a session. This ability to provide selective encryption is supported by SBSM and EUSM but difficult to achieve with the use of transport level protection like SNMPv3 over TLS. regards, kaushik! >On Mon, 18 Oct 2004 15:49:09 -0700 Kaushik wrote: >KN> At 02:36 PM 10/18/2004, Juergen Schoenwaelder wrote: >KN> > > "Every message has an associated securityLevel. >KN> > >KN> >To me, this text only says that every message has an associated >KN> >securityLevel. It does not say how that maps to sessions (since >KN> >the notion of sessions does not exist in STD62). > >I think this is a key point. I think what the securityLevel of a session >should >be a soft of max-access. If you create a session with noAuthNoPriv, then you >wouldn't be able to send encrypted packets. But if you start a session with >AuthPriv, I don't see any reason why you shouldn't be able to send a pdu >with a >securityLevel of AuthNoPriv, thus requesting that there be no encryption for >that packet. This, however, is a decision on the NM side, and would be at the >application level, not the protocol level. > >If the ISMS RFC does let the session securityLevel function as a max-access >level, then I think the view-based packet security level is a neat idea >for the >application vendor. Put in a feature request. Or, if you use >and open source platform (*cough* net-snmp *cough*), submit a patch! :-) >. > > >-- >Robert Story; NET-SNMP Junkie > > >You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 22:48:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19302; Tue, 19 Oct 2004 22:48:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6jC-0004Fq-FI; Tue, 19 Oct 2004 23:01:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4es-00065y-HN; Tue, 19 Oct 2004 20:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJyFf-0003Op-0X for isms@megatron.ietf.org; Tue, 19 Oct 2004 13:58:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23050 for ; Tue, 19 Oct 2004 13:58:20 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJyRo-00059B-Vr for isms@ietf.org; Tue, 19 Oct 2004 14:11:01 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 19 Oct 2004 10:58:08 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9JHve9d005846; Tue, 19 Oct 2004 10:57:47 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (sjc-vpn1-548.cisco.com [10.21.98.36]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW46221; Tue, 19 Oct 2004 10:55:58 -0700 (PDT) Message-Id: <6.0.0.22.0.20041019101038.036de130@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 19 Oct 2004 10:57:39 -0700 To: j.schoenwaelder@iu-bremen.de From: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <20041019093113.GA3295@james> References: <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <3fhi7r$7nj50@sj-inbound-a.cisco.com> <6.0.0.22.0.20041018154918.03e628c0@mira-sjc5-a.cisco.com> <20041019093113.GA3295@james> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi Juergen, Please find my reply in line. At 02:31 AM 10/19/2004, Juergen Schoenwaelder wrote: >On Mon, Oct 18, 2004 at 05:55:50PM -0700, Kaushik Narayan wrote: > > > I was suggesting that the capability to use selective encryption for SNMPv3 > > is extremely useful in use cases around periodic data collection which > > is what SNMP is predominantly used for currently (in addition to fault > > management). NetConf and CLI access are predominantly used for > configuration > > management that deal with data that is far more sensitive and far less > > voluminous and there is really no need to perform selective encryption. > >I heard operators saying that (a) MIB instrumentation often come too >late and that (b) they often trust CLI numbers more than SNMP numbers. >So there might be more scripted CLI access to collect data than you >might expect. > >If you talk about voluminous data, do you mean that (i) you talk to >lots of devices and each device gives you little pieces of data, but >the total is voluminous, or do you mean that (ii) you retrieve large >amounts of data from the average device, so the total is voluminous >or (iii) are you saying that the retrieved data over some time tends >to be voluminous. With performance collection the data is voluminous since you collect large amounts of data at periodic intervals, for e.g. collection of a objects in the IF MIB on PE routers with tens of thousands interfaces every 10 minutes. We have quite a few devices that support bulk files upload using FTP for such use cases but there are a few that still need to be polled periodically via SNMP. regards, kaushik! >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 22:52:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19517; Tue, 19 Oct 2004 22:52:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6n7-0004JV-Gf; Tue, 19 Oct 2004 23:05:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4fN-0006vH-8Y; Tue, 19 Oct 2004 20:49:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJyRc-0004Li-UV for isms@megatron.ietf.org; Tue, 19 Oct 2004 14:10:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24544 for ; Tue, 19 Oct 2004 14:10:42 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJydn-0005Ut-8F for isms@ietf.org; Tue, 19 Oct 2004 14:23:23 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CJyRU-0008Qb-8x; Tue, 19 Oct 2004 14:10:40 -0400 Date: Tue, 19 Oct 2004 14:10:40 -0400 From: Robert Story To: Wes Hardaker Subject: Re: [Isms] ISMS Encryption Requirement Message-Id: <20041019141040.0c52397f@dev.localdomain> In-Reply-To: References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <20041018201136.GA1819@james> <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <20041018213629.GB2108@james> <6.0.0.22.0.20041018153003.06946230@mira-sjc5-a.cisco.com> <20041018212336.18c34c0a@dev.localdomain> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit On Mon, 18 Oct 2004 20:12:25 -0700 Wes wrote: WH> >>>>> On Mon, 18 Oct 2004 21:23:36 -0400, Robert Story WH> > said: WH> WH> Robert> My impression of Kaushik's message was that he wants the WH> Robert> decision to be made automatically [...] WH> WH> I don't think thats what he meant at all. I guess I misunderstood "[...] the decision is driven by the SNMP objects". I interpreted that to mean a decision make as the packet were processed, not by the NM before sending the packet. Sorry for the confusion! (I still think it's an interesting idea on the NM side.) WH> Robert> I think what the securityLevel of a session should be a sort WH> Robert> of max-access. WH> WH> I suspect that many potential protocols (SBSM included) don't really WH> map to that statement. EG, in SBSM during setup the security level WH> flags are ignored by the security and have to be till negotiation is WH> finished. I was talking about sending packets once the session was established. And if sessions don't have a max-access, should they? e.g. If a authPriv packet is sent via SBSM, and no encryption keys were negotiated for the session, shouldn't that be rejected (as noAuth packets are)? Obviously if the solution relies on encryption at the transport level, then authNoPriv will continue to be encrypted and consume extra CPU resources. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 22:55:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19720; Tue, 19 Oct 2004 22:55:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6pu-0004Mc-Aj; Tue, 19 Oct 2004 23:08:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4fQ-000741-83; Tue, 19 Oct 2004 20:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJyTI-0004aD-Es for isms@megatron.ietf.org; Tue, 19 Oct 2004 14:12:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24692 for ; Tue, 19 Oct 2004 14:12:26 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJyfR-0005Wn-Ee for isms@ietf.org; Tue, 19 Oct 2004 14:25:07 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 010359AFA; Tue, 19 Oct 2004 20:11:51 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14006-07; Tue, 19 Oct 2004 20:11:50 +0200 (CEST) Received: from james (G5b53.g.pppool.de [80.185.91.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id DF4E09AF6; Tue, 19 Oct 2004 20:11:49 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CJySb-0000ZV-1J; Tue, 19 Oct 2004 20:11:49 +0200 Date: Tue, 19 Oct 2004 20:11:48 +0200 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement Message-ID: <20041019181148.GA2177@james> Mail-Followup-To: Kaushik Narayan , ietfdbh@comcast.net, isms@ietf.org References: <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <3fhi7r$7nj50@sj-inbound-a.cisco.com> <6.0.0.22.0.20041018154918.03e628c0@mira-sjc5-a.cisco.com> <20041019093113.GA3295@james> <6.0.0.22.0.20041019101038.036de130@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.22.0.20041019101038.036de130@mira-sjc5-a.cisco.com> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Tue, Oct 19, 2004 at 10:57:39AM -0700, Kaushik Narayan wrote: > With performance collection the data is voluminous since you collect large > amounts > of data at periodic intervals, for e.g. collection of a objects in the IF > MIB on PE routers > with tens of thousands interfaces every 10 minutes. We have quite a few > devices that > support bulk files upload using FTP for such use cases but there are a few > that still > need to be polled periodically via SNMP. So if FTP works for you (which actually establishes multiple connections), I would say session based SNMP should work as well. ;-) Note: I see your point. I am just trying to figure out what is really being done and if people talk about large sets of SNMP MIB variables (whatever means large here), I know from experience and actual measurements that SNMP is really a poor protocol to retrieve such data sets (according to my definition of large ;-). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Oct 19 23:45:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22324; Tue, 19 Oct 2004 23:45:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK7by-0005BE-HM; Tue, 19 Oct 2004 23:58:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4hM-0002LX-A1; Tue, 19 Oct 2004 20:51:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJzpC-0006I7-2f for isms@megatron.ietf.org; Tue, 19 Oct 2004 15:39:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03972 for ; Tue, 19 Oct 2004 15:39:06 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK01L-0007zD-To for isms@ietf.org; Tue, 19 Oct 2004 15:51:49 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 45CB21223BC; Tue, 19 Oct 2004 12:39:00 -0700 (PDT) To: Robert Story Subject: Re: [Isms] ISMS Encryption Requirement References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <20041018201136.GA1819@james> <6.0.0.22.0.20041018131821.03ec0200@mira-sjc5-a.cisco.com> <20041018213629.GB2108@james> <6.0.0.22.0.20041018153003.06946230@mira-sjc5-a.cisco.com> <20041018212336.18c34c0a@dev.localdomain> <20041019141040.0c52397f@dev.localdomain> From: Wes Hardaker Organization: Sparta Date: Tue, 19 Oct 2004 12:39:00 -0700 In-Reply-To: <20041019141040.0c52397f@dev.localdomain> (Robert Story's message of "Tue, 19 Oct 2004 14:10:40 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 >>>>> On Tue, 19 Oct 2004 14:10:40 -0400, Robert Story said: Robert> And if sessions don't have a max-access, should they? e.g. If Robert> a authPriv packet is sent via SBSM, and no encryption keys Robert> were negotiated for the session, shouldn't that be rejected Robert> (as noAuth packets are)? As currently defined, thats not possible actually. Now, there was discussion in the past about not requiring encryption but to date the SBSM draft says you must support at least one encryption alg. Robert> Obviously if the solution relies on encryption at the Robert> transport level, then authNoPriv will continue to be encrypted Robert> and consume extra CPU resources. In SBSM, you must negotiate encryption and keys but you don't have to use it once a session is up. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Oct 20 04:26:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09746 for ; Wed, 20 Oct 2004 04:26:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKC0S-0002Sf-Ei for isms-archive@ietf.org; Wed, 20 Oct 2004 04:39:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9LJ-0004tK-4s; Wed, 20 Oct 2004 01:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK7WD-0007mk-OG for isms@megatron.ietf.org; Tue, 19 Oct 2004 23:52:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22970 for ; Tue, 19 Oct 2004 23:52:02 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK7iS-0005Tb-AL for isms@ietf.org; Wed, 20 Oct 2004 00:04:49 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 088361223BC; Tue, 19 Oct 2004 20:51:53 -0700 (PDT) To: Ken Hornstein Subject: Re: [Isms] ISMS Encryption Requirement References: <200410191444.i9JEiefR002236@ginger.cmf.nrl.navy.mil> From: Wes Hardaker Organization: Sparta Date: Tue, 19 Oct 2004 20:51:53 -0700 In-Reply-To: <200410191444.i9JEiefR002236@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Tue, 19 Oct 2004 10:44:40 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 >>>>> On Tue, 19 Oct 2004 10:44:40 -0400, Ken Hornstein said: Ken> - It made it hard to enforce a consistant server-side policy Ken> (e.g, requiring the use of encryption), partly due to the nature Ken> of the protocol and partly because the implementations had to be Ken> so complicated to support this protocol feature. Ken, Thanks for the good summary on past problems. I'm certainly glad we have a decent security-guy as a chair! One comment though (read: not a rebuttal): SNMPv3 already has an access control mechanism in place today (VACM) that allows you use fine grained control over which objects can be accessed and which can not if encryption is not turned on. Because of the nature of well-structured OID trees, you actually have the ability to have fairly precise control over what is allowed and disallowed to go over plain-text versions. That being said, operator error or lack of understanding is sure to be a problem. I suspect that many people today have a minimum authNoPriv requirement on most of their MIB tree and don't rethink the policy every time they upload a new firmware and it is suddenly capable of releasing more sensitive data than the previous firmware release. Very few people do the "right" think and only turn on access to objects that they want. Instead, most people turn on access to everything and attempt to deny things they don't want released which is not forward-future thinking. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Oct 20 08:47:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28615; Wed, 20 Oct 2004 08:47:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG4H-00081z-Py; Wed, 20 Oct 2004 08:59:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF0l-0007sz-E2; Wed, 20 Oct 2004 07:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKE2F-0004M7-5O for isms@megatron.ietf.org; Wed, 20 Oct 2004 06:49:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20300 for ; Wed, 20 Oct 2004 06:49:30 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKEEX-0005YV-SC for isms@ietf.org; Wed, 20 Oct 2004 07:02:22 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6066E9E2C; Wed, 20 Oct 2004 11:56:55 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28068-05; Wed, 20 Oct 2004 11:56:54 +0200 (CEST) Received: from james (james.public.iu-bremen.de [212.201.46.187]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 998419E2A; Wed, 20 Oct 2004 11:56:54 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1CKDDD-0000i3-4j; Wed, 20 Oct 2004 11:56:55 +0200 Date: Wed, 20 Oct 2004 11:56:55 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] ISMS Encryption Requirement Message-ID: <20041020095655.GA2704@james> Mail-Followup-To: Wes Hardaker , Ken Hornstein , isms@ietf.org References: <200410191444.i9JEiefR002236@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Tue, Oct 19, 2004 at 08:51:53PM -0700, Wes Hardaker wrote: > That being said, operator error or lack of > understanding is sure to be a problem. In many cases, the operator simply has no chance because a) the SNMP application of choice does not document what it needs to function and b) the MIB modules, especially some proprietary ones, do not really explain in enough details what the various objects really do. So even if the operators would have the time to dive into the details (which they don't have generally), they would have no chance of success. Fine grained VACM access control is IMHO a myths. [And thanks to Ken for the nice telnet story - we should learn from it.] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Oct 20 23:01:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17736; Wed, 20 Oct 2004 23:01:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKTPm-00041j-34; Wed, 20 Oct 2004 23:14:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIUO-0000EK-Ay; Wed, 20 Oct 2004 11:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHt0-0003vT-4T for isms@megatron.ietf.org; Wed, 20 Oct 2004 10:56:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12136 for ; Wed, 20 Oct 2004 10:56:14 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKI5K-0002Qy-TD for isms@ietf.org; Wed, 20 Oct 2004 11:09:08 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 604CC1223BC; Wed, 20 Oct 2004 07:56:13 -0700 (PDT) To: Ken Hornstein Subject: Re: [Isms] ISMS Encryption Requirement References: <200410191444.i9JEiefR002236@ginger.cmf.nrl.navy.mil> <20041020095655.GA2704@james> From: Wes Hardaker Organization: Sparta Date: Wed, 20 Oct 2004 07:56:13 -0700 In-Reply-To: <20041020095655.GA2704@james> (Juergen Schoenwaelder's message of "Wed, 20 Oct 2004 11:56:55 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 >>>>> On Wed, 20 Oct 2004 11:56:55 +0200, Juergen Schoenwaelder said: Juergen> Fine grained VACM access control is IMHO a myths. It'd be fine if people did the proper thing from a security perspective: Turn on only what you need. exclude .1.3 include ifTable instead of the more typical include .1.3 -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 07:59:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10168; Thu, 21 Oct 2004 07:59:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKboF-0006if-GZ; Thu, 21 Oct 2004 08:12:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKanl-0001FJ-WB; Thu, 21 Oct 2004 07:08:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKLhh-0005On-Tt for isms@megatron.ietf.org; Wed, 20 Oct 2004 15:00:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11456 for ; Wed, 20 Oct 2004 15:00:56 -0400 (EDT) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKLu7-0001eP-TP for isms@ietf.org; Wed, 20 Oct 2004 15:13:51 -0400 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i9KJ0n3n026916 for ; Wed, 20 Oct 2004 15:00:49 -0400 (EDT) Message-Id: <200410201900.i9KJ0n3n026916@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 20 Oct 2004 15:00:49 -0400 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >One comment though (read: not a rebuttal): SNMPv3 already has an >access control mechanism in place today (VACM) that allows you use >fine grained control over which objects can be accessed and which can >not if encryption is not turned on. Sure, and that part is _very_ cool. But that's not actually what I'm worried about. Let's say that we want to (within one as-yet-undefined-future-SNMPv3- security-model "session") have some MIB elements be sent encrypted, and some sent unencrypted. Let's also say that we're doing a GetBulkRequest. We could be put in the case where not only is the change from encrypted to not encrypted happens between different PDUs in the same "session" (I'm using the word "session" loosely here, some security models may not have sessions), but the change would happen _within the same PDU_. Now, of course we could specify that is not allowed. But even saying _that_ means we have to complicate the GetBulkRequest code to know that it needs to process these MIB elements in a different way. Again, this is hypothetical. And I think that if you want to start a "session" where you don't have encryption and you are depending on VACM to not return parts of the MIB tree that have to be encrypted is fine. But switching back and forth can get complicated, and experience has taught us that complexity can be the enemy of security. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 08:36:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17169; Thu, 21 Oct 2004 08:36:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcO8-0008P7-Ql; Thu, 21 Oct 2004 08:49:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbAJ-0005rY-R9; Thu, 21 Oct 2004 07:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUEt-0004kh-KL for isms@megatron.ietf.org; Thu, 21 Oct 2004 00:07:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22279 for ; Thu, 21 Oct 2004 00:07:39 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKURL-0005Jq-ED for isms@ietf.org; Thu, 21 Oct 2004 00:20:40 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id F22491223BC; Wed, 20 Oct 2004 21:07:34 -0700 (PDT) To: isms@ietf.org From: Wes Hardaker Organization: Sparta Date: Wed, 20 Oct 2004 21:07:34 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Isms] formal list? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Could the chairs please provide a formal list of what they consider to be on the table with respect to possible solutions? I suspect many people, myself included, are not sure quite where we stand now that the submission deadline has passed. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 10:43:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08211; Thu, 21 Oct 2004 10:43:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeNE-0004rJ-Aw; Thu, 21 Oct 2004 10:57:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKe17-0008LZ-Oz; Thu, 21 Oct 2004 10:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdu8-0003ud-Hz for isms@megatron.ietf.org; Thu, 21 Oct 2004 10:27:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05308 for ; Thu, 21 Oct 2004 10:26:58 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe6l-0004Kh-RM for isms@ietf.org; Thu, 21 Oct 2004 10:40:04 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CKdu3-0002cW-VR; Thu, 21 Oct 2004 10:26:56 -0400 Date: Thu, 21 Oct 2004 10:26:58 -0400 From: Robert Story To: Ken Hornstein Subject: Re: [Isms] ISMS Encryption Requirement Message-Id: <20041021102658.0fc4416f@dev.localdomain> In-Reply-To: <200410201900.i9KJ0n3n026916@ginger.cmf.nrl.navy.mil> References: <200410201900.i9KJ0n3n026916@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit On Wed, 20 Oct 2004 15:00:49 -0400 Ken wrote: KH> Let's say that we want to (within one as-yet-undefined-future-SNMPv3- KH> security-model "session") have some MIB elements be sent encrypted, and KH> some sent unencrypted. Let's also say that we're doing a KH> GetBulkRequest. KH> KH> We could be put in the case where not only is the change from encrypted KH> to not encrypted happens between different PDUs in the same "session" This is how I interpreted Kaushik's first message. KH> (I'm using the word "session" loosely here, some security models may KH> not have sessions), but the change would happen _within the same PDU_. KH> Now, of course we could specify that is not allowed. And this was the next logical step in that line of thought. Although I don't think anyone was suggesting that only certain parts of the PDU should be encrypted. What I was going to suggest, before it was determined that Kaushik didn't mean what I thought he meant, was that instead of not allowing different levels within the same PDU, that each object's security level be used to determine the minimal security level needed for the whole PDU. So if all the varbinds only require authNoPriv, then PDU need not be encrypted. But if even one requires authPriv, then the entire PDU must be encrypted. But this still leaves open the possibility of a response PDU with a different security level than the request PDU, which was my initial objection. KH> But even saying _that_ means we have to complicate the GetBulkRequest code KH> to know that it needs to process these MIB elements in a different way. Not just GetBulk, but GetNext as well. Like I said, for get/set requests, the manager should be able to determine the appropriate level before sending a request. (though a manager and agent might disagree on what that level should be. but that's getting into policy.) -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 12:38:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20728; Thu, 21 Oct 2004 12:38:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgA2-0007fL-Bm; Thu, 21 Oct 2004 12:51:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfku-00006A-4N; Thu, 21 Oct 2004 12:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfU6-0006NC-By for isms@megatron.ietf.org; Thu, 21 Oct 2004 12:08:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17291 for ; Thu, 21 Oct 2004 12:08:11 -0400 (EDT) Message-Id: <200410211608.MAA17291@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfgk-0006vd-GM for isms@ietf.org; Thu, 21 Oct 2004 12:21:18 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004102116073801200fujrce>; Thu, 21 Oct 2004 16:07:38 +0000 From: "David B Harrington" To: "'Robert Story'" , "'Ken Hornstein'" Subject: RE: [Isms] ISMS Encryption Requirement Date: Thu, 21 Oct 2004 12:07:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS3fGay/clppsEjTY+4FPplTzpBoAABjp/Q In-Reply-To: <20041021102658.0fc4416f@dev.localdomain> X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Hi, SNMPv3 does not support per-varbind securityLevels, only message-based securityLevels. David Harrington dbharrington@comcast.net co-chair SNMPv3 WG, concluded -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story Sent: Thursday, October 21, 2004 10:27 AM To: Ken Hornstein Cc: isms@ietf.org Subject: Re: [Isms] ISMS Encryption Requirement On Wed, 20 Oct 2004 15:00:49 -0400 Ken wrote: KH> Let's say that we want to (within one KH> as-yet-undefined-future-SNMPv3- security-model "session") have some KH> MIB elements be sent encrypted, and some sent unencrypted. Let's KH> also say that we're doing a GetBulkRequest. KH> KH> We could be put in the case where not only is the change from KH> encrypted to not encrypted happens between different PDUs in the same "session" This is how I interpreted Kaushik's first message. KH> (I'm using the word "session" loosely here, some security models may KH> not have sessions), but the change would happen _within the same PDU_. KH> Now, of course we could specify that is not allowed. And this was the next logical step in that line of thought. Although I don't think anyone was suggesting that only certain parts of the PDU should be encrypted. What I was going to suggest, before it was determined that Kaushik didn't mean what I thought he meant, was that instead of not allowing different levels within the same PDU, that each object's security level be used to determine the minimal security level needed for the whole PDU. So if all the varbinds only require authNoPriv, then PDU need not be encrypted. But if even one requires authPriv, then the entire PDU must be encrypted. But this still leaves open the possibility of a response PDU with a different security level than the request PDU, which was my initial objection. KH> But even saying _that_ means we have to complicate the KH> GetBulkRequest code to know that it needs to process these MIB elements in a different way. Not just GetBulk, but GetNext as well. Like I said, for get/set requests, the manager should be able to determine the appropriate level before sending a request. (though a manager and agent might disagree on what that level should be. but that's getting into policy.) -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 12:52:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22369; Thu, 21 Oct 2004 12:52:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgNr-00086C-M0; Thu, 21 Oct 2004 13:05:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKg3s-0008W9-Qw; Thu, 21 Oct 2004 12:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfoX-0001eu-Pp for isms@megatron.ietf.org; Thu, 21 Oct 2004 12:29:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19885 for ; Thu, 21 Oct 2004 12:29:16 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKg19-0007Th-Qf for isms@ietf.org; Thu, 21 Oct 2004 12:42:24 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9LGSPpm027962; Thu, 21 Oct 2004 09:28:25 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PY5BDC>; Thu, 21 Oct 2004 09:28:26 -0700 Message-ID: From: "McDonald, Ira" To: "'Robert Story'" , Ken Hornstein Subject: RE: [Isms] ISMS Encryption Requirement Date: Thu, 21 Oct 2004 09:28:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi folks, > But this still leaves open the possibility of a response PDU with a different > security level than the request PDU, which was my initial objection. > KH> But even saying _that_ means we have to complicate the GetBulkRequest code > KH> to know that it needs to process these MIB elements in a different way. > Not just GetBulk, but GetNext as well. Like I said, for get/set requests, the > manager should be able to determine the appropriate level before sending a > request. (though a manager and agent might disagree on what that level should > be. but that's getting into policy.) Changing security _within_ a PDU is very unwise. And having the responder _degrade_ the security level specified in a request is simply broken. Policy should never force broken protocol behaviour. And all of this discussion is for a corner case requirement. There is nothing to prevent a client (SNMP Manager) from starting two sessions to cope with different security levels. The complexity of supporting different security levels in the same session is an unreasonable burden. I dislike this corner case requirement because it rules out the use of all existing session mode security protocols (which negotiate security parameters _once_ at beginning of session) and takes us off into unusual new protocols, which is no improvement at all over USM/VACM. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 12:59:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23252; Thu, 21 Oct 2004 12:59:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgUi-0008Lg-Lr; Thu, 21 Oct 2004 13:12:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKg82-0002Bs-R0; Thu, 21 Oct 2004 12:49:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKg38-0007no-Pq for isms@megatron.ietf.org; Thu, 21 Oct 2004 12:44:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21537 for ; Thu, 21 Oct 2004 12:44:23 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgFk-0007s0-6k for isms@ietf.org; Thu, 21 Oct 2004 12:57:31 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id A58001223BC; Thu, 21 Oct 2004 09:44:19 -0700 (PDT) To: Robert Story Subject: Re: [Isms] ISMS Encryption Requirement References: <200410201900.i9KJ0n3n026916@ginger.cmf.nrl.navy.mil> <20041021102658.0fc4416f@dev.localdomain> From: Wes Hardaker Organization: Sparta Date: Thu, 21 Oct 2004 09:44:19 -0700 In-Reply-To: <20041021102658.0fc4416f@dev.localdomain> (Robert Story's message of "Thu, 21 Oct 2004 10:26:58 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb >>>>> On Thu, 21 Oct 2004 10:26:58 -0400, Robert Story said: Robert> Although I don't think anyone was suggesting that only certain Robert> parts of the PDU should be encrypted. No, and in fact it would violate part of the charter: to not modify the SNMPv3 architecture (which states that the scopedPDU is what gets encrypted or not; not pieces of it). Robert> What I was going to suggest, before it was determined that Robert> Kaushik didn't mean what I thought he meant, was that instead Robert> of not allowing different levels within the same PDU, that Robert> each object's security level be used to determine the minimal Robert> security level needed for the whole PDU. So if all the Robert> varbinds only require authNoPriv, then PDU need not be Robert> encrypted. But if even one requires authPriv, then the entire Robert> PDU must be encrypted. That's also against the v3 architecture, as the security level flags are defined fairly explicitly such that if you send a authNoPriv message then you should not expect a authPriv response (or vice-versa). It's not USM specific, its more global to the architecture than that (grep for securityLevel in 341?). Robert> But this still leaves open the possibility of a response PDU Robert> with a different security level than the request PDU, which Robert> was my initial objection. Yep. Not even in the possibility range, according to the charter (and, of course, my humble opinion). -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 13:16:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24570; Thu, 21 Oct 2004 13:16:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgl9-0000Ed-Uj; Thu, 21 Oct 2004 13:29:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgKS-0001F8-BK; Thu, 21 Oct 2004 13:02:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgD2-0005F9-NL for isms@megatron.ietf.org; Thu, 21 Oct 2004 12:54:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22510 for ; Thu, 21 Oct 2004 12:54:37 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgPh-00088P-89 for isms@ietf.org; Thu, 21 Oct 2004 13:07:45 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CKgCy-0003BI-Af; Thu, 21 Oct 2004 12:54:36 -0400 Date: Thu, 21 Oct 2004 12:54:37 -0400 From: Robert Story To: "McDonald, Ira" Subject: Re: [Isms] ISMS Encryption Requirement Message-Id: <20041021125437.4dce204e@dev.localdomain> In-Reply-To: References: X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit On Thu, 21 Oct 2004 09:28:19 -0700 McDonald, wrote: MI> Changing security _within_ a PDU is very unwise. I think we are all in agreement here. And nobody proposed that we should (I though that's what the original message implied, but I was wrong). MI> And all of this discussion is for a corner case requirement. There is MI> nothing to prevent a client (SNMP Manager) from starting two sessions to MI> cope with different security levels. The complexity of supporting MI> different security levels in the same session is an unreasonable burden. I disagree here. Agents are often resource-constrained. Adding sessions increases the need for resources, we shouldn't require two sessions when one can suffice. MI> I dislike this corner case requirement because it rules out the use of all MI> existing session mode security protocols (which negotiate security MI> parameters _once_ at beginning of session) I don't think that is the case. As I suggested earlier, the session could have a 'maximum' security level, which would not necessarily require that all messages sent via that session are of the same level. If a session is created as 'authPriv', then keys for encryption would still be negotiated once at the beginning of the session. But if a message is presented to the session with a security level of authNoPriv, then that message could simply be authenticated and not encrypted. Wouldn't that also have some security benefit, in that it reduces the encrypted data available to an attacker gathering packets to try and discover the encryption keys? The session could also have a minimum security level, so that a session created with a min/max of authPriv would reject an attempt to send an authNoPriv message. I think 2 bytes per session structure and a compare or two is much less of a resource burden on an agent than two separate sessions. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 13:26:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25723; Thu, 21 Oct 2004 13:26:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKguz-0000Vq-2I; Thu, 21 Oct 2004 13:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgbW-0000h6-Ak; Thu, 21 Oct 2004 13:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgVv-0004eh-SO for isms@megatron.ietf.org; Thu, 21 Oct 2004 13:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24264 for ; Thu, 21 Oct 2004 13:14:09 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgib-0000B2-5C for isms@ietf.org; Thu, 21 Oct 2004 13:27:17 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i9LHEAWj011572 for ; Thu, 21 Oct 2004 10:14:10 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i9LHE9Vs011558 for ; Thu, 21 Oct 2004 10:14:09 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 21 Oct 2004 10:14:09 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <20041021102658.0fc4416f@dev.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 HI, First, when one does a GET or a SET, the instance of management info that is being accessed is known by the manager, and, thus, the privLevel in the message can be set based on the preceived sensitivity by the manager of the data. (Of course, if the VACM tables require a level "higher" than specified by the manager, then access is not allowed.) However, on GETNEXT and GETBULK, the actual instance of management info is not always deterministically known by the manager when the request is sent. What instance is returned (if any) is based on both what instances exist, and the configuration of the VACM tables. That is, if instances exist, but are "not in the view" for the privLevel specified in the request, then the instances are "skipped over". Thus, the description below about choosing a privLevel for the response based on the highest level of any accessed instance is a change in the behavior as specified by VACM. Of course a new access control model could be proposed that would have the behavior as described below. For the ISMS work, this is out of scope of the charter. Secondly, back to the high level question of whether or not it is desirable and/or a requirement for a manager to be able to specifify the privLevel in each message, here are my thoughts... a) Using IPSEC, SSH, or SSL/TLS to provide security services "below" the SNMP message creates a fundamental problem to the current model of SNMP. SNMP VACM uses the "securityName" and the "securityLevel" to determine if access is allowed. The securityLevel is contained in _every_ SNMPv3 message. How the securityName is provided is security model dependent, and for USM it is in every SNMPv3 message, where for SBSM, it specified during session setup, and associated with the session identifier (which is specified in each SNMPv3/SBSM message). But with IPSEC, SSH, and SSL/TLS securityName and securityLevel is determined "below" the application level, and any proposal for a security model using them needs to specify how this info is made available to the SNMPv3 message processing, and how it is used. That is, if a (IPSEC, SSH, or SSL/TLS) session is set up with encryption, is the priv bit always (or never) set in the msgFlags field, and is the PDU never (or always) encrypted. b) Current definitions of SNMPv3 message processing and VACM allow requestor to set the security level only on a per-message and not per-varbind level. On Thu, 21 Oct 2004, Robert Story wrote: > On Wed, 20 Oct 2004 15:00:49 -0400 Ken wrote: > KH> Let's say that we want to (within one as-yet-undefined-future-SNMPv3- > KH> security-model "session") have some MIB elements be sent encrypted, and > KH> some sent unencrypted. Let's also say that we're doing a > KH> GetBulkRequest. > KH> > KH> We could be put in the case where not only is the change from encrypted > KH> to not encrypted happens between different PDUs in the same "session" > > This is how I interpreted Kaushik's first message. > > KH> (I'm using the word "session" loosely here, some security models may > KH> not have sessions), but the change would happen _within the same PDU_. > KH> Now, of course we could specify that is not allowed. > > And this was the next logical step in that line of thought. Although I don't > think anyone was suggesting that only certain parts of the PDU should be > encrypted. > > What I was going to suggest, before it was determined that Kaushik didn't mean > what I thought he meant, was that instead of not allowing different levels > within the same PDU, that each object's security level be used to determine the > minimal security level needed for the whole PDU. So if all the varbinds only > require authNoPriv, then PDU need not be encrypted. But if even one requires > authPriv, then the entire PDU must be encrypted. > > But this still leaves open the possibility of a response PDU with a different > security level than the request PDU, which was my initial objection. > > KH> But even saying _that_ means we have to complicate the GetBulkRequest code > KH> to know that it needs to process these MIB elements in a different way. > > Not just GetBulk, but GetNext as well. Like I said, for get/set requests, the > manager should be able to determine the appropriate level before sending a > request. (though a manager and agent might disagree on what that level should > be. but that's getting into policy.) > > -- > Robert Story; NET-SNMP Junkie Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 13:50:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28775; Thu, 21 Oct 2004 13:50:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhHm-0001Mv-LV; Thu, 21 Oct 2004 14:03:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgzi-0005bo-6a; Thu, 21 Oct 2004 13:44:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgit-00049Q-93 for isms@megatron.ietf.org; Thu, 21 Oct 2004 13:27:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25859 for ; Thu, 21 Oct 2004 13:27:33 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgvZ-0000XX-Cg for isms@ietf.org; Thu, 21 Oct 2004 13:40:41 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CKgiq-0003Jr-5e; Thu, 21 Oct 2004 13:27:32 -0400 Date: Thu, 21 Oct 2004 13:27:34 -0400 From: Robert Story To: Wes Hardaker Subject: Re: [Isms] ISMS Encryption Requirement Message-Id: <20041021132734.628959c8@dev.localdomain> In-Reply-To: References: <200410201900.i9KJ0n3n026916@ginger.cmf.nrl.navy.mil> <20041021102658.0fc4416f@dev.localdomain> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On Thu, 21 Oct 2004 09:44:19 -0700 Wes wrote: WH> Robert> Although I don't think anyone was suggesting that only certain WH> Robert> parts of the PDU should be encrypted. WH> WH> No, and in fact it would violate part of the charter: to not modify WH> the SNMPv3 architecture (which states that the scopedPDU is what gets WH> encrypted or not; not pieces of it). We are all wasting our time here, arguing about something that nobody has proposed that we do. But my curiosity got the better of me. Based on my ignorant poking about in the specs, I think it could probably be finagled if someone really wanted to (and I'm not that someone). In particular: RFC 3411, A.1.1: For privacy, the Security Model defines what portion of the message is encrypted. RFC 3412, 6.4 b: b) privFlag If the privFlag is set, then the securityModel used by the SNMP engine which sent the message MUST also protect the scopedPDU in an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the scopedPDU. If the privFlag is zero, then the securityModel in use does not need to protect the data from disclosure. ^^^^^^^^^^^^^ So a security model is not *prohibited* from protecting a packet without the privFlag set. In theory, couldn't a security model be defined such that an authNoPriv packet could encrypt portions of the pdu? -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 13:58:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29342; Thu, 21 Oct 2004 13:58:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhPp-0001YU-EQ; Thu, 21 Oct 2004 14:11:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgzr-0005rR-I0; Thu, 21 Oct 2004 13:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgks-0005Nv-7k for isms@megatron.ietf.org; Thu, 21 Oct 2004 13:29:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26007 for ; Thu, 21 Oct 2004 13:29:34 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgxW-0000ZH-VG for isms@ietf.org; Thu, 21 Oct 2004 13:42:43 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2004 10:39:27 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9LHT06u024470; Thu, 21 Oct 2004 10:29:02 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (dhcp-171-69-71-73.cisco.com [171.69.71.73]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUY35431; Thu, 21 Oct 2004 10:26:55 -0700 (PDT) Message-Id: <6.0.0.22.0.20041021095757.03d4c050@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 21 Oct 2004 10:07:58 -0700 To: Ken Hornstein From: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <200410191444.i9JEiefR002236@ginger.cmf.nrl.navy.mil> References: <6.0.0.22.0.20041018114325.03eef3c8@mira-sjc5-a.cisco.com> <200410191444.i9JEiefR002236@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hi Ken, I understand that it would be much simpler for us to encrypt all data and given the improvement in ciphers and hardware based crypto, we could probably get to a point where the cost of encryption is not significantly higher than the cost of digest calculation (for authentication). My concern is that we have a lot of applications of SNMP where all we do is collect large amounts of data that is typically not very sensitive and forcing encryption of all that data will put a severe strain on both the agents and the manager applications. The SNMPv3 protocol already provides per-packet securityLevel handling both part of USM and VACM, I was suggesting that the new security model for SNMPv3 continue to provide that capability. regards, kaushik! At 07:44 AM 10/19/2004, Ken Hornstein wrote: > >It is essential that agents need to authenticate every packet > >but however, the same is *not* true for encryption. > >While I agree that it's not essential ... you should consider _very >carefully_ the security implications of this. Let me give you a >cautionary tale (the origin of it predates my involvement, but I >was involved in the aftermath). > >Many many moons ago, various parties were hammering out the specification >for Telnet Encryption (this eventually became RFC 2946). As part of >this, there were a number of Telnet vendors/implementors involved in >this process. > >A number of vendors wanted the ability to turn on and off encryption on >the fly; the reasoning at the time was that they didn't want to incur >the CPU overhead of encrypting and decrypting _everything_ (this was in >the era of 68000-based Macintoshes), and that not everything in the >Telnet stream was important. For example, some vendors planned on only >encrypting passwords and the like. So, placed into the Telnet protocol >was the ability to turn on and off encryption on the fly (a feature >which is unique among stream-based encrypting protocols, AFAIK). > >In retrospect, this turned out to be a HUGE mistake. The reasons are >multiple: > >- It turned out impossible in practice to determine when a password was > being entered (since most telnet streams are not linemode and thus > echo is handled on the server side). > >- Because this complicated the protocol, some vendors ended up implementing > this feature incorrectly or incompletely (but because it wasn't being > used in practice, see above, no one really understood this at the time). > >- It made it hard to enforce a consistant server-side policy (e.g, requiring > the use of encryption), partly due to the nature of the protocol and > partly because the implementations had to be so complicated to support > this protocol feature. > >- It ended up creating a bunch of security vulnerabilities in the protocol > which required a protocol revision to correct some of them (since > you have to negotiate encryption before encryption starts, an attacker > could remove the part of the stream that negotiates encryption). Not > all of them are correctable, unfortunately (but thankfully the more > important ones are). > >Other protocols learned the hard lessons of encrypted Telnet, and now >nearly all encrypted-stream protocols (that I'm aware of) simply start >encrypting as soon as possible, and have no capability to turn this >encryption off. This simplifies the protocol and the implementation, >and reduces the possibility of vulnerabilites. > >Now, not all of these things apply to SNMP, of course (for one, SNMP is >a datagram-based protocol). But when you get into deciding that some >data isn't worth encrypting and maybe you should only encrypt _part_ of >it ... well, all I can say is that other protocols have decided that in >the long run, it's better to encrypt everything. If the WG decides >that only partial encryption is desired, then that's fine ... but I >feel I would be remiss if I didn't point out that we should think _very >hard_ about what exactly this means for security. > >--Ken > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 14:05:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00284; Thu, 21 Oct 2004 14:05:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhWF-0001mU-FZ; Thu, 21 Oct 2004 14:18:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh07-000661-96; Thu, 21 Oct 2004 13:45:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgrK-0007rp-3j for isms@megatron.ietf.org; Thu, 21 Oct 2004 13:36:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26533 for ; Thu, 21 Oct 2004 13:36:14 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKh3x-0000jE-J8 for isms@ietf.org; Thu, 21 Oct 2004 13:49:23 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 81F601223BC; Thu, 21 Oct 2004 10:36:13 -0700 (PDT) To: "David T. Perkins" Subject: Re: [Isms] ISMS Encryption Requirement References: From: Wes Hardaker Organization: Sparta Date: Thu, 21 Oct 2004 10:36:13 -0700 In-Reply-To: (David T. Perkins's message of "Thu, 21 Oct 2004 10:14:09 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 >>>>> On Thu, 21 Oct 2004 10:14:09 -0700 (PDT), "David T. Perkins" said: David> a) Using IPSEC, SSH, or SSL/TLS to provide security services David> "below" the SNMP message creates a fundamental problem to the David> current model of SNMP. SNMP VACM uses the "securityName" David> and the "securityLevel" to determine if access is allowed. David> The securityLevel is contained in _every_ SNMPv3 message. David> How the securityName is provided is security model dependent, David> and for USM it is in every SNMPv3 message, where for SBSM, David> it specified during session setup, and associated with David> the session identifier (which is specified in each SNMPv3/SBSM David> message). But with IPSEC, SSH, and SSL/TLS securityName David> and securityLevel is determined "below" the application David> level, and any proposal for a security model using them David> needs to specify how this info is made available to the SNMPv3 David> message processing, and how it is used. That is, if a David> (IPSEC, SSH, or SSL/TLS) session is set up with encryption, David> is the priv bit always (or never) set in the msgFlags field, David> and is the PDU never (or always) encrypted. Regarding user names: thats not a problem. As long as the problem of passing that name upward from the transport to the security model can be solved then the sec model can return it to the MP and above. Regarding the secLevel, however, thats a more interesting problem. The question is: is the seclevel looked at before the security model gets to it. Would it be legal for the security model to ignore the incoming flags and change them before passing them back up? If not, its still possible and the security model would need to (MUST) check the incoming security level flags to make sure they matched the TLS/whatever session setup and if not drop the message. Still doable, either way. [And Robert just indicated another point which is interesting in that you might legally be able to have a authNoPriv message that is actually encrypted via the transport (but not the other way around of course).] -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 14:05:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00340; Thu, 21 Oct 2004 14:05:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhWh-0001nU-8c; Thu, 21 Oct 2004 14:19:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh09-000673-Kd; Thu, 21 Oct 2004 13:45:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgrs-0008N3-TA for isms@megatron.ietf.org; Thu, 21 Oct 2004 13:36:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26584 for ; Thu, 21 Oct 2004 13:36:50 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKh4W-0000jM-Q5 for isms@ietf.org; Thu, 21 Oct 2004 13:49:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2004 10:46:41 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9LHaGk2013866; Thu, 21 Oct 2004 10:36:17 -0700 (PDT) Received: from kaushik-w2k02.cisco.com (dhcp-171-69-71-73.cisco.com [171.69.71.73]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AUY36344; Thu, 21 Oct 2004 10:34:10 -0700 (PDT) Message-Id: <6.0.0.22.0.20041021102952.07294988@mira-sjc5-a.cisco.com> X-Sender: kaushik@mira-sjc5-a.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 21 Oct 2004 10:36:14 -0700 To: Robert Story From: Kaushik Narayan Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <20041021102658.0fc4416f@dev.localdomain> References: <200410201900.i9KJ0n3n026916@ginger.cmf.nrl.navy.mil> <20041021102658.0fc4416f@dev.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab I was suggesting that new security model for SNMPv3 retain the per-PDU securityLevel. At 07:26 AM 10/21/2004, Robert Story wrote: >On Wed, 20 Oct 2004 15:00:49 -0400 Ken wrote: >KH> Let's say that we want to (within one as-yet-undefined-future-SNMPv3- >KH> security-model "session") have some MIB elements be sent encrypted, and >KH> some sent unencrypted. Let's also say that we're doing a >KH> GetBulkRequest. >KH> >KH> We could be put in the case where not only is the change from encrypted >KH> to not encrypted happens between different PDUs in the same "session" > >This is how I interpreted Kaushik's first message. > >KH> (I'm using the word "session" loosely here, some security models may >KH> not have sessions), but the change would happen _within the same PDU_. >KH> Now, of course we could specify that is not allowed. > >And this was the next logical step in that line of thought. Although I don't >think anyone was suggesting that only certain parts of the PDU should be >encrypted. > >What I was going to suggest, before it was determined that Kaushik didn't mean >what I thought he meant, was that instead of not allowing different levels >within the same PDU, that each object's security level be used to >determine the >minimal security level needed for the whole PDU. So if all the varbinds only >require authNoPriv, then PDU need not be encrypted. But if even one requires >authPriv, then the entire PDU must be encrypted. > >But this still leaves open the possibility of a response PDU with a different >security level than the request PDU, which was my initial objection. > >KH> But even saying _that_ means we have to complicate the GetBulkRequest code >KH> to know that it needs to process these MIB elements in a different way. > >Not just GetBulk, but GetNext as well. Like I said, for get/set requests, the >manager should be able to determine the appropriate level before sending a >request. (though a manager and agent might disagree on what that level should >be. but that's getting into policy.) > >-- >Robert Story; NET-SNMP Junkie > > >You are lost in a twisty maze of little standards, all different. > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 14:31:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03028; Thu, 21 Oct 2004 14:31:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhvK-0002ZU-1m; Thu, 21 Oct 2004 14:44:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhNR-000242-D8; Thu, 21 Oct 2004 14:09:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhJ8-0008Sb-Rq for isms@megatron.ietf.org; Thu, 21 Oct 2004 14:05:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00209 for ; Thu, 21 Oct 2004 14:05:00 -0400 (EDT) Message-Id: <200410211805.OAA00209@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhVn-0001kz-Ae for isms@ietf.org; Thu, 21 Oct 2004 14:18:07 -0400 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004102118043001200frknge>; Thu, 21 Oct 2004 18:04:30 +0000 From: "David B Harrington" To: "'Robert Story'" , "'McDonald, Ira'" Subject: RE: [Isms] ISMS Encryption Requirement Date: Thu, 21 Oct 2004 14:04:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS3kcBx4IjM8VMlQ26ZlvogBLE0GgABcbVQ In-Reply-To: <20041021125437.4dce204e@dev.localdomain> X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Hi Robert, Why are we having this discussion? Is this in scope? Or is this just an interesting tangent of out-of-scope feature creep? If it is in scope, can you tell me how it is in scope? Which of the proposals has the capabilty of supporting this feature using existing security infrastructure and without violating the architectural constraints of SNMPv3? Dbh -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story Sent: Thursday, October 21, 2004 12:55 PM To: McDonald, Ira Cc: isms@ietf.org Subject: Re: [Isms] ISMS Encryption Requirement On Thu, 21 Oct 2004 09:28:19 -0700 McDonald, wrote: MI> Changing security _within_ a PDU is very unwise. I think we are all in agreement here. And nobody proposed that we should (I though that's what the original message implied, but I was wrong). MI> And all of this discussion is for a corner case requirement. There MI> is nothing to prevent a client (SNMP Manager) from starting two MI> sessions to cope with different security levels. The complexity of MI> supporting different security levels in the same session is an unreasonable burden. I disagree here. Agents are often resource-constrained. Adding sessions increases the need for resources, we shouldn't require two sessions when one can suffice. MI> I dislike this corner case requirement because it rules out the use MI> of all existing session mode security protocols (which negotiate MI> security parameters _once_ at beginning of session) I don't think that is the case. As I suggested earlier, the session could have a 'maximum' security level, which would not necessarily require that all messages sent via that session are of the same level. If a session is created as 'authPriv', then keys for encryption would still be negotiated once at the beginning of the session. But if a message is presented to the session with a security level of authNoPriv, then that message could simply be authenticated and not encrypted. Wouldn't that also have some security benefit, in that it reduces the encrypted data available to an attacker gathering packets to try and discover the encryption keys? The session could also have a minimum security level, so that a session created with a min/max of authPriv would reject an attempt to send an authNoPriv message. I think 2 bytes per session structure and a compare or two is much less of a resource burden on an agent than two separate sessions. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 14:32:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03137; Thu, 21 Oct 2004 14:32:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhw4-0002bS-Gj; Thu, 21 Oct 2004 14:45:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhNT-00025I-Ps; Thu, 21 Oct 2004 14:09:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhJW-0008U4-Rk for isms@megatron.ietf.org; Thu, 21 Oct 2004 14:05:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00271 for ; Thu, 21 Oct 2004 14:05:24 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhWB-0001mF-Ex for isms@ietf.org; Thu, 21 Oct 2004 14:18:31 -0400 Received: from h-69-3-28-107.snvacaid.dynamic.covad.net ([69.3.28.107] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CKhJU-0003tZ-00 for isms@ietf.org; Thu, 21 Oct 2004 11:05:24 -0700 Message-ID: <00a701c4b798$a4dd6020$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200410201900.i9KJ0n3n026916@ginger.cmf.nrl.navy.mil><20041021102658.0fc4416f@dev.localdomain> <20041021132734.628959c8@dev.localdomain> Subject: Re: [Isms] ISMS Encryption Requirement Date: Thu, 21 Oct 2004 11:06:09 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi - > From: "Robert Story" > To: "Wes Hardaker" > Cc: > Sent: Thursday, October 21, 2004 10:27 AM > Subject: Re: [Isms] ISMS Encryption Requirement .... > Based on my ignorant poking about in the specs, I think it could probably be > finagled if someone really wanted to (and I'm not that someone). In particular: ... > So a security model is not *prohibited* from protecting a packet without the > privFlag set. In theory, couldn't a security model be defined such that an > authNoPriv packet could encrypt portions of the pdu? ... Twisted. That certainly wasn't what we had in mind when we came up with those words, but your reading does seem to hold up in the context of what is actually in the architecture document. How something could decide which bits to encrypt would be left as a difficult exercise for the reader, since the ASIs don't provide any help there, and the operation of get-next and get-bulk complicate response generation. Let's hope the saying remains true: when people say "in theory" they mean "not really." :-) Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 14:48:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04832; Thu, 21 Oct 2004 14:48:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiBg-00035w-IS; Thu, 21 Oct 2004 15:01:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhkW-00043M-AV; Thu, 21 Oct 2004 14:33:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhUy-0005di-KC for isms@megatron.ietf.org; Thu, 21 Oct 2004 14:17:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01535 for ; Thu, 21 Oct 2004 14:17:14 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhhc-00027W-0h for isms@ietf.org; Thu, 21 Oct 2004 14:30:21 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i9LIH7hT006252; Thu, 21 Oct 2004 11:17:07 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i9LIH69r006236; Thu, 21 Oct 2004 11:17:07 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 21 Oct 2004 11:17:06 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Robert Story Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <20041021132734.628959c8@dev.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 HI, Robert - please be careful with SNMP terminology. The term "SNMP security model" does not include access control. And yes, we may be wasting time talking about capabilities that may be possible, but are not used. I totally agree with JuergenS that in practice, it has been shown that it is difficult (if not impossible) to determine which objects (and especially which instances) a management application accesses so that VACM access rules can configured accordingly. So, per-varbind doesn't seem to make a lot a sense. On Thu, 21 Oct 2004, Robert Story wrote: > On Thu, 21 Oct 2004 09:44:19 -0700 Wes wrote: > WH> Robert> Although I don't think anyone was suggesting that only certain > WH> Robert> parts of the PDU should be encrypted. > WH> > WH> No, and in fact it would violate part of the charter: to not modify > WH> the SNMPv3 architecture (which states that the scopedPDU is what gets > WH> encrypted or not; not pieces of it). > > We are all wasting our time here, arguing about something that nobody has > proposed that we do. But my curiosity got the better of me. > > Based on my ignorant poking about in the specs, I think it could probably be > finagled if someone really wanted to (and I'm not that someone). In particular: > > RFC 3411, A.1.1: > > For privacy, the Security Model defines what portion of the message > is encrypted. > > RFC 3412, 6.4 b: > > b) privFlag > > If the privFlag is set, then the securityModel used by the SNMP > engine which sent the message MUST also protect the scopedPDU in > an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the > scopedPDU. If the privFlag is zero, then the securityModel in use > does not need to protect the data from disclosure. > ^^^^^^^^^^^^^ > > So a security model is not *prohibited* from protecting a packet without the > privFlag set. In theory, couldn't a security model be defined such that an > authNoPriv packet could encrypt portions of the pdu? > > -- > Robert Story; NET-SNMP Junkie > > > You are lost in a twisty maze of little standards, all different. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 14:50:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05058; Thu, 21 Oct 2004 14:50:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiE6-0003Ak-SD; Thu, 21 Oct 2004 15:03:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhkY-00044h-Tl; Thu, 21 Oct 2004 14:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhVK-00060F-Gi for isms@megatron.ietf.org; Thu, 21 Oct 2004 14:17:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01595 for ; Thu, 21 Oct 2004 14:17:36 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhhy-00029Z-T4 for isms@ietf.org; Thu, 21 Oct 2004 14:30:44 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CKhVD-0003XY-W2; Thu, 21 Oct 2004 14:17:32 -0400 Date: Thu, 21 Oct 2004 14:17:34 -0400 From: Robert Story To: Subject: Re: [Isms] ISMS Encryption Requirement Message-Id: <20041021141734.6574c826@dev.localdomain> In-Reply-To: References: <20041021125437.4dce204e@dev.localdomain> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Thu, 21 Oct 2004 14:04:30 -0400 David wrote: DBH> Why are we having this discussion? Is this in scope? Or is this just DBH> an interesting tangent of out-of-scope feature creep? No, it is not in scope. It is a tangent spawned by my misinterpretation of the original message that started this thread. I've repeatedly stated that, and Kaushuik has repeatedly stated that his intent was only to be able to specify authNoPriv and authPriv on a per-packet basis. I think his concern is that a session that is set up as authPriv would encrypt noAuthPriv messages, and he'd like to avoid that overhead. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 14:57:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05883; Thu, 21 Oct 2004 14:57:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiKV-0003O8-6a; Thu, 21 Oct 2004 15:10:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhmL-0005FN-Ab; Thu, 21 Oct 2004 14:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhg9-0001hH-1k for isms@megatron.ietf.org; Thu, 21 Oct 2004 14:28:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02776 for ; Thu, 21 Oct 2004 14:28:47 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhsn-0002UQ-9e for isms@ietf.org; Thu, 21 Oct 2004 14:41:54 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CKhg2-0003aP-CH; Thu, 21 Oct 2004 14:28:42 -0400 Date: Thu, 21 Oct 2004 14:28:45 -0400 From: Robert Story To: "David T. Perkins" Subject: Re: [Isms] ISMS Encryption Requirement Message-Id: <20041021142845.44195c73@dev.localdomain> In-Reply-To: References: <20041021132734.628959c8@dev.localdomain> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Thu, 21 Oct 2004 11:17:06 -0700 (PDT) David wrote: DTP> And yes, we may be wasting time talking about capabilities DTP> that may be possible, but are not used. I'm just exploring an interesting idea. Obviously people are starting to get annoyed by the off-topic posts, so I'm just going to be quiet now. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 15:14:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08278; Thu, 21 Oct 2004 15:14:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKibS-0003rA-PU; Thu, 21 Oct 2004 15:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiA2-00021A-Kp; Thu, 21 Oct 2004 14:59:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhn1-0005hd-EG for isms@megatron.ietf.org; Thu, 21 Oct 2004 14:35:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03929 for ; Thu, 21 Oct 2004 14:35:53 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhzf-0002oo-VP for isms@ietf.org; Thu, 21 Oct 2004 14:49:01 -0400 Received: from localhost ([127.0.0.1] helo=dev.localdomain) by hosting.revelstone.com with smtp (Exim 4.43) id 1CKhmw-0003cn-4l for isms@ietf.org; Thu, 21 Oct 2004 14:35:50 -0400 Date: Thu, 21 Oct 2004 14:35:53 -0400 From: Robert Story To: isms@ietf.org Message-Id: <20041021143553.2ea3db2c@dev.localdomain> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Isms] sbsm and noAuthNoPriv X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit While perusing the v3 specs, I ran across this section of RFC 3411: A.1.2. Security Processing Received messages MUST be validated by a Model of the Security Subsystem. Validation includes authentication and privacy processing if needed, but it is explicitly allowed to send messages which do not require authentication or privacy. I know that SBSM explicitly rejects noAuthNoPriv. It would seem to be a conflict with the rfc, even if there isn't a MUST in there. Admittedly, if you are using noAuthNoPriv, there is no benefit to even using a session. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 15:15:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08477; Thu, 21 Oct 2004 15:15:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKicN-0003sg-Mh; Thu, 21 Oct 2004 15:28:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiBG-0004Ks-TQ; Thu, 21 Oct 2004 15:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhp1-0006KI-U7 for isms@megatron.ietf.org; Thu, 21 Oct 2004 14:38:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04185 for ; Thu, 21 Oct 2004 14:37:58 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKi1h-0002sm-7o for isms@ietf.org; Thu, 21 Oct 2004 14:51:05 -0400 Received: from h-69-3-28-107.snvacaid.dynamic.covad.net ([69.3.28.107] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CKhoz-0007jZ-00 for isms@ietf.org; Thu, 21 Oct 2004 11:37:58 -0700 Message-ID: <00d001c4b79d$318eb100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200410201900.i9KJ0n3n026916@ginger.cmf.nrl.navy.mil> Subject: Re: [Isms] ISMS Encryption Requirement Date: Thu, 21 Oct 2004 11:38:43 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi - > From: "Ken Hornstein" > To: > Sent: Wednesday, October 20, 2004 12:00 PM > Subject: Re: [Isms] ISMS Encryption Requirement ... > We could be put in the case where not only is the change from encrypted > to not encrypted happens between different PDUs in the same "session" > (I'm using the word "session" loosely here, some security models may > not have sessions), but the change would happen _within the same PDU_. > Now, of course we could specify that is not allowed. But even saying > _that_ means we have to complicate the GetBulkRequest code to know that > it needs to process these MIB elements in a different way. Though I don't think it's a good idea to do this, the added complexity for GetNext / GetBulk processing isn't *that* great if the agent/subagent infrastructure is doing a naive iteration while evaluating the isAccessAllowed() decision for each thing that might be returned in a response until it finds something that would get through. If isAccessAllowed(authNoPriv) fails, try isAccessAllowed(authPriv). It would no more than double the processing time to get to a varbind, though could result in material being sent that wasn't wanted. ("If I had wanted to get the passwords, I'd have used AuthPriv.") If the agent/subagent is using more sophisticated techniques, in which the VACM views are used to skip over excluded subtrees without iteration, things get a little tangled, with the increase in processing cost depending on whether the views have the same granularity, but the code complexity wouldn't be that great. However, this still doesn't mean I like the idea at all. > Again, this is hypothetical. And I think that if you want to start a > "session" where you don't have encryption and you are depending on VACM > to not return parts of the MIB tree that have to be encrypted is fine. That's how things work today, and how getNext / getBulk processing is defined in RFC 3413. I'd rather not reopen that work! :-) > But switching back and forth can get complicated, and experience has > taught us that complexity can be the enemy of security. Whole-heartedly agreed, while recognizing that being able to process security level on a pdu-by-pdu basis is already built into SNMPv3. If a proposal defines a notion of session, we'll need to understand whether it defines the minimum, maximum, or simply *the* security level for the PDUs belonging to that session. It's also thinkable that setting up a session just ensures that the keys and identities are known, and that everything proceeds from there just as it does now. In any case, I think we'd be better served at this point by drilling into the specifics of each proposal to make sure we understand what the various designers have in mind. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 15:39:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11416; Thu, 21 Oct 2004 15:39:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiyv-0004QI-Sm; Thu, 21 Oct 2004 15:52:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKib3-0003Dg-Cm; Thu, 21 Oct 2004 15:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiUg-0005jG-Fx for isms@megatron.ietf.org; Thu, 21 Oct 2004 15:21:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09370 for ; Thu, 21 Oct 2004 15:21:00 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKihJ-00041B-D5 for isms@ietf.org; Thu, 21 Oct 2004 15:34:08 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i9LJKrIb032731; Thu, 21 Oct 2004 12:20:53 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i9LJKqbL032726; Thu, 21 Oct 2004 12:20:53 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 21 Oct 2004 12:20:52 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Robert Story Subject: Re: [Isms] ISMS Encryption Requirement In-Reply-To: <20041021141734.6574c826@dev.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c HI, Yes, the issue is with using SSL/TLS where the "transport" possibly provides endpoint authentication (the value for securityName), message integrity and encryption is provided below in the stack than SNMPv3 messages. And thus, 1) how is this lower layer info passed up? 2) how are the integrity and encryption bits in SNMPv3 messages interpreted (do they have to match the security services provided by the lower layer, or are they ignored (and the values from the lower layer used). 3) the request (and notification) originator loses the ability to specify per message auth and encryption services, since they are "fixed" by the SSL/TLS connection. Regards, /david t. perkins On Thu, 21 Oct 2004, Robert Story wrote: > On Thu, 21 Oct 2004 14:04:30 -0400 David wrote: > DBH> Why are we having this discussion? Is this in scope? Or is this just > DBH> an interesting tangent of out-of-scope feature creep? > > No, it is not in scope. It is a tangent spawned by my misinterpretation of the > original message that started this thread. I've repeatedly stated that, and > Kaushuik has repeatedly stated that his intent was only to be able to specify > authNoPriv and authPriv on a per-packet basis. I think his concern is that a > session that is set up as authPriv would encrypt noAuthPriv messages, and he'd > like to avoid that overhead. > > -- > Robert Story; NET-SNMP Junkie > > > You are lost in a twisty maze of little standards, all different. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 16:13:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15964; Thu, 21 Oct 2004 16:13:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjW9-0005by-K6; Thu, 21 Oct 2004 16:26:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiuF-00028P-Kd; Thu, 21 Oct 2004 15:47:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKihO-00076r-NI for isms@megatron.ietf.org; Thu, 21 Oct 2004 15:34:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10896 for ; Thu, 21 Oct 2004 15:34:07 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiu4-0004JG-1f for isms@ietf.org; Thu, 21 Oct 2004 15:47:16 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i9LJY4NU005888; Thu, 21 Oct 2004 12:34:04 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i9LJY3uf005880; Thu, 21 Oct 2004 12:34:04 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 21 Oct 2004 12:34:03 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Robert Story Subject: Re: [Isms] sbsm and noAuthNoPriv In-Reply-To: <20041021143553.2ea3db2c@dev.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb HI, Back when we were defining SNMPv3, I really wanted to have a security model, pick the name, like "void". You would use it for noauth/nopriv. It would also be used in a report when you didn't support the security model specified in a request. People thought it would complicate things (since it would require possibly additional VACM entries). A noauth/nopriv in all security models essentially maps to the "void" security model. (And yes, we can debate my claim.) On Thu, 21 Oct 2004, Robert Story wrote: > While perusing the v3 specs, I ran across this section of RFC 3411: > > A.1.2. Security Processing > > Received messages MUST be validated by a Model of the Security > Subsystem. Validation includes authentication and privacy processing > if needed, but it is explicitly allowed to send messages which do not > require authentication or privacy. > > > I know that SBSM explicitly rejects noAuthNoPriv. It would seem to be a > conflict with the rfc, even if there isn't a MUST in there. > > Admittedly, if you are using noAuthNoPriv, there is no benefit to even using a > session. > > -- > Robert Story; NET-SNMP Junkie Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Oct 21 21:15:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20369; Thu, 21 Oct 2004 21:14:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoDy-0008Te-Ct; Thu, 21 Oct 2004 21:28:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlNb-0006KS-Qt; Thu, 21 Oct 2004 18:25:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjwS-00067Z-Ja for isms@megatron.ietf.org; Thu, 21 Oct 2004 16:53:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24453 for ; Thu, 21 Oct 2004 16:53:45 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKk98-0008KJ-7I for isms@ietf.org; Thu, 21 Oct 2004 17:06:55 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 49B0C1223BC; Thu, 21 Oct 2004 13:53:40 -0700 (PDT) To: Robert Story Subject: Re: [Isms] sbsm and noAuthNoPriv References: <20041021143553.2ea3db2c@dev.localdomain> From: Wes Hardaker Organization: Sparta Date: Thu, 21 Oct 2004 13:53:40 -0700 In-Reply-To: <20041021143553.2ea3db2c@dev.localdomain> (Robert Story's message of "Thu, 21 Oct 2004 14:35:53 -0400") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >>>>> On Thu, 21 Oct 2004 14:35:53 -0400, Robert Story said: Robert> Received messages MUST be validated by a Model of the Security Robert> Subsystem. Validation includes authentication and privacy processing Robert> if needed, but it is explicitly allowed to send messages which do not Robert> require authentication or privacy. Robert> I know that SBSM explicitly rejects noAuthNoPriv. It would seem to be a Robert> conflict with the rfc, even if there isn't a MUST in there. Ok. Easy enough. Just like encryption can be turned off in the flags but turned on in the packet, I'll just do the same with authentication ;-) All messages are authenticated even when you don't ask for it! Ha! -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 22 05:47:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16228; Fri, 22 Oct 2004 05:47:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwE9-0002Bh-UD; Fri, 22 Oct 2004 06:00:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKw0I-0001vy-8f; Fri, 22 Oct 2004 05:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvw9-00005K-G2 for isms@megatron.ietf.org; Fri, 22 Oct 2004 05:42:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15861 for ; Fri, 22 Oct 2004 05:42:14 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKw8s-00023N-8w for isms@ietf.org; Fri, 22 Oct 2004 05:55:29 -0400 Received: from [192.168.2.3] (YahooBB219059144059.bbtec.net [219.59.144.59]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 47F431BAC4D; Fri, 22 Oct 2004 11:41:39 +0200 (CEST) Date: Fri, 22 Oct 2004 11:41:41 +0200 From: Juergen Quittek To: Wes Hardaker , isms@ietf.org Subject: Re: [Isms] formal list? Message-ID: <2147483647.1098445300@[192.168.2.3]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Wes, Yes, you are ocmpletely right, the situation should be clarified. The submission deadline for proposals ended on Monday 18th. So far, Ken and I are aware of three proposals that have been submitted. Name: TLSM - Transport Layer Security Model I-D: draft-schoenw-snmp-tlsm-00.txt Contact: Juergen Schoenwaelder Name: SBSM - Session-Based Security Model I-D: draft-hardaker-snmp-session-sm-03.txt Contact: Wes Hardaker Name: EUSM - External User Security Model I-D: draft-kaushik-snmp-external-usm-00.txt Contact: Kaushik Narayan Does anybody think there is another proposal that was submitted in time and that should be considered for evaluation? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 20.10.2004 21:07 Uhr -0700 Wes Hardaker wrote: > > Could the chairs please provide a formal list of what they consider to > be on the table with respect to possible solutions? I suspect many > people, myself included, are not sure quite where we stand now that the > submission deadline has passed. > > -- > Wes Hardaker > Sparta > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 22 14:50:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28855; Fri, 22 Oct 2004 14:50:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4hi-0004Fa-0g; Fri, 22 Oct 2004 15:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4QG-0002zN-PG; Fri, 22 Oct 2004 14:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4GD-0000Dr-OL for isms@megatron.ietf.org; Fri, 22 Oct 2004 14:35:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27636 for ; Fri, 22 Oct 2004 14:35:30 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4T2-0003xD-2i for isms@ietf.org; Fri, 22 Oct 2004 14:48:49 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA01999; Fri, 22 Oct 2004 13:34:51 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id i9MIYps17993; Fri, 22 Oct 2004 11:34:51 -0700 (PDT) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 11:34:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS Encryption Requirement Date: Fri, 22 Oct 2004 11:34:42 -0700 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDD901@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] ISMS Encryption Requirement Thread-Index: AcS3paX0dVsILYumRByN30R8xFOdJwAv6opQ From: "Fleischman, Eric" To: "David T. Perkins" , "Robert Story" X-OriginalArrivalTime: 22 Oct 2004 18:34:43.0114 (UTC) FILETIME=[CC3F88A0:01C4B865] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable These authentication limitations are my principal concern about leveraging SSL/TLS for SNMP security. However, isn't there also a problem in that SSL/TLS usually requires TCP transports while SNMP's performance within congested or capacity limited environments (e.g., wireless networks) is significantly better using UDP transports? -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com]=20 Sent: Thursday, October 21, 2004 12:21 PM To: Robert Story Cc: isms@ietf.org Subject: Re: [Isms] ISMS Encryption Requirement HI, Yes, the issue is with using SSL/TLS where the "transport" possibly provides endpoint authentication (the value for securityName), message integrity and encryption is provided below in the stack than SNMPv3 messages. And thus, 1) how is this lower layer info passed up? 2) how are the integrity and encryption bits in=20 SNMPv3 messages interpreted (do they have to match the security services provided by the lower layer, or are they ignored (and the values from the lower layer used). 3) the request (and notification) originator loses the ability to specify per message auth and encryption services, since they are "fixed" by the SSL/TLS connection. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 22 15:16:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01200; Fri, 22 Oct 2004 15:16:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL56s-0004hJ-JH; Fri, 22 Oct 2004 15:29:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4tB-0005jC-Tn; Fri, 22 Oct 2004 15:15:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4p6-000243-DA for isms@megatron.ietf.org; Fri, 22 Oct 2004 15:11:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00569 for ; Fri, 22 Oct 2004 15:11:32 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL51w-0004as-2a for isms@ietf.org; Fri, 22 Oct 2004 15:24:52 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 91AD21223BC; Fri, 22 Oct 2004 12:11:21 -0700 (PDT) To: "Fleischman, Eric" Subject: Re: [Isms] ISMS Encryption Requirement References: <5B58696DB20B9140AD20E0685C573A6404FDD901@xch-nw-09.nw.nos.boeing.com> From: Wes Hardaker Organization: Sparta Date: Fri, 22 Oct 2004 12:11:21 -0700 In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDD901@xch-nw-09.nw.nos.boeing.com> (Eric Fleischman's message of "Fri, 22 Oct 2004 11:34:42 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> On Fri, 22 Oct 2004 11:34:42 -0700, "Fleischman, Eric" said: Eric> These authentication limitations are my principal concern about Eric> leveraging SSL/TLS for SNMP security. However, isn't there also Eric> a problem in that SSL/TLS usually requires TCP transports while Eric> SNMP's performance within congested or capacity limited Eric> environments (e.g., wireless networks) is significantly better Eric> using UDP transports? The solutions are considering the use of DTLS as well, which is a modified TLS that works over UDP. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Oct 22 15:41:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03311; Fri, 22 Oct 2004 15:41:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5VB-000589-0V; Fri, 22 Oct 2004 15:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5AW-0002oq-UI; Fri, 22 Oct 2004 15:33:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL57X-0000Ma-H8 for isms@megatron.ietf.org; Fri, 22 Oct 2004 15:30:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02642 for ; Fri, 22 Oct 2004 15:30:31 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5KF-0004ua-Cb for isms@ietf.org; Fri, 22 Oct 2004 15:43:51 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id i9MJSMVM008215; Fri, 22 Oct 2004 12:28:32 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <46PY58VY>; Fri, 22 Oct 2004 12:28:23 -0700 Message-ID: From: "McDonald, Ira" To: "'Fleischman, Eric'" , "David T. Perkins" , Robert Story Subject: RE: [Isms] ISMS Encryption Requirement Date: Fri, 22 Oct 2004 12:28:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hi Eric, Nope, not a problem. Eric Rescorla has been working on DTLS (Datagram TLS) in (July 2004). My assumption all along was that DTLS is the enabling factor that allows reasonable cost of TLS for SNMP security. DTLS is connectionless, but has sessions, and cipher suites that do NOT have inter-PDU dependencies for decrypting or hash (message integrity check) validation. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Fleischman, Eric Sent: Friday, October 22, 2004 2:35 PM To: David T. Perkins; Robert Story Cc: isms@ietf.org Subject: RE: [Isms] ISMS Encryption Requirement These authentication limitations are my principal concern about leveraging SSL/TLS for SNMP security. However, isn't there also a problem in that SSL/TLS usually requires TCP transports while SNMP's performance within congested or capacity limited environments (e.g., wireless networks) is significantly better using UDP transports? -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, October 21, 2004 12:21 PM To: Robert Story Cc: isms@ietf.org Subject: Re: [Isms] ISMS Encryption Requirement HI, Yes, the issue is with using SSL/TLS where the "transport" possibly provides endpoint authentication (the value for securityName), message integrity and encryption is provided below in the stack than SNMPv3 messages. And thus, 1) how is this lower layer info passed up? 2) how are the integrity and encryption bits in SNMPv3 messages interpreted (do they have to match the security services provided by the lower layer, or are they ignored (and the values from the lower layer used). 3) the request (and notification) originator loses the ability to specify per message auth and encryption services, since they are "fixed" by the SSL/TLS connection. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Oct 30 02:21:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01946; Sat, 30 Oct 2004 02:21:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNmqW-0003bG-JF; Sat, 30 Oct 2004 02:36:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNmW2-0005eq-Bw; Sat, 30 Oct 2004 02:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNmRQ-0002y7-9R for isms@megatron.ietf.org; Sat, 30 Oct 2004 02:10:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27531 for ; Sat, 30 Oct 2004 02:10:18 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNmfp-0003RM-Tk for isms@ietf.org; Sat, 30 Oct 2004 02:25:15 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 4C10511D8FC; Fri, 29 Oct 2004 23:10:10 -0700 (PDT) To: isms@ietf.org From: Wes Hardaker Organization: Sparta Date: Fri, 29 Oct 2004 23:10:09 -0700 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Isms] meeting agenda? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Do we have a agenda thought out yet? There isn't one on the agenda page yet. The obvious topics are probably protocol overviews (I'm not sure they're worth the time or not since we've been briefed a bunch at both BOFs), requirements discussions, requirements evaluation and selection process, and, of course, everyone's favorite: the brawl. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms