From isms-bounces@lists.ietf.org Wed Jan 04 09:47:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9vO-0006Yq-Cn; Wed, 04 Jan 2006 09:47:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9vN-0006Yl-Ew for isms@megatron.ietf.org; Wed, 04 Jan 2006 09:47:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09178 for ; Wed, 4 Jan 2006 09:46:21 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuA0r-0002eZ-FA for isms@ietf.org; Wed, 04 Jan 2006 09:53:18 -0500 Received: from [192.168.11.244] (theo.dagstuhl.de [192.76.146.31]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 9A8C51BAC4D for ; Wed, 4 Jan 2006 15:47:24 +0100 (CET) Date: Wed, 04 Jan 2006 15:47:12 +0100 From: Juergen Quittek To: isms@ietf.org Message-ID: <2B3B97372C841E475ADD8358@753F3B888A9969457862729D> X-Mailer: Mulberry/3.1.6 (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.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] ISMS interim meeting om Feb 13-14 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, The IETF ISMS Working Group will hold an interim meeting on February 13-14, 2006. The meeting will be hosted by the Massachusetts Institute of Technology at 304 Vassar Street in Cambridge, MA USA. The primary purpose of this meeting will be solving open issues that concern Internet drafts draft-ietf-isms-secshell-00.txt and draft-ietf-isms-secshell-00.txt We started an intensive face-to-face discussion of these issues at the IETF meeting in Vancouver. But for solving them well, far more meeting time is needed than we can get at a regular IETF meeting. Anyone who plans to join the meeting, please send a message to Juergen Schoenwaelder (j.schoenwaelder@iu-bremen.de) and me. We need this feedback in order to reserve sufficient meeting space. Many thanks to or AD Sam Harman who will be our host for the meeting! You will find basic information about the meeting below. A web site with more details and the meeting agenda will be available soon. So far, the following WG members confirmed their participation: David Harrington Sam Hartman Jeff Hutzelman Juergen Quittek Joe Salowey Juergen Schoenwaelder Bert Wijnen (Eliot Lear and David Nelson indicated their interest.) Meeting Information: - Date: February 13-14 - Location: MIT, 304 Vassar Street in Cambridge, MA USA - Directions to MIT: . - The closest hotel is the Cambridge Hyatt which is right across the street (about a 30 second walk from the building) . _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 04 11:12:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBFn-00049e-Qu; Wed, 04 Jan 2006 11:12:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuBFm-00049G-CM for isms@megatron.ietf.org; Wed, 04 Jan 2006 11:12:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21761 for ; Wed, 4 Jan 2006 11:11:32 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuBLD-0006Pz-4X for isms@ietf.org; Wed, 04 Jan 2006 11:18:28 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id EE0B94D2C2; Wed, 4 Jan 2006 17:12:18 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 18601-02; Wed, 4 Jan 2006 17:12:17 +0100 (CET) Received: from boskop.local (unknown [10.222.1.3]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6C2874D293; Wed, 4 Jan 2006 17:12:17 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id E80845AA2A4; Wed, 4 Jan 2006 17:12:14 +0100 (CET) Date: Wed, 4 Jan 2006 17:12:14 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Subject: Re: [Isms] ISMS interim meeting om Feb 13-14 Message-ID: <20060104161214.GA4686@boskop.local> Mail-Followup-To: Juergen Quittek , isms@ietf.org References: <2B3B97372C841E475ADD8358@753F3B888A9969457862729D> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B3B97372C841E475ADD8358@753F3B888A9969457862729D> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de 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 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Jan 04, 2006 at 03:47:12PM +0100, Juergen Quittek wrote: > You will find basic information about the meeting below. A web site > with more details and the meeting agenda will be available soon. A first draft version of the ISMS interim web page is now online: http://www.eecs.iu-bremen.de/wiki/index.php/01._ISMS_Interim We will provide a more detailed agenda soon. In fact, I am working on a general ISMS wiki page which soon should also host a revised list of issues. Anyway, if you have questions or find bugs or know good alternatives where people can stay, please drop us a note. /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@lists.ietf.org Fri Jan 06 19:14:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1jR-0001K6-9T; Fri, 06 Jan 2006 19:14:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev1jP-0001HC-Id for isms@megatron.ietf.org; Fri, 06 Jan 2006 19:14:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27703 for ; Fri, 6 Jan 2006 19:13:35 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev1pK-0008Kg-Vb for isms@ietf.org; Fri, 06 Jan 2006 19:21:03 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 088984D1A2 for ; Sat, 7 Jan 2006 01:14:25 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03430-10; Sat, 7 Jan 2006 01:14:23 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9B65B4D0FD; Sat, 7 Jan 2006 01:14:23 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 4F1665ABB1E; Sat, 7 Jan 2006 01:14:22 +0100 (CET) Date: Sat, 7 Jan 2006 01:14:22 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060107001422.GA9635@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Isms] ssh specifications published 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, the SSH specifications have been published as RFCs 4250-4246. This gives us stable references to work from. Happy reading. ;-) /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@lists.ietf.org Wed Jan 25 22:00:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1xMk-0000xX-7P; Wed, 25 Jan 2006 22:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1xMi-0000xL-OL for isms@megatron.ietf.org; Wed, 25 Jan 2006 22:00:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01256 for ; Wed, 25 Jan 2006 21:58:32 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1xWa-0000ke-1q for isms@ietf.org; Wed, 25 Jan 2006 22:10:17 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A81A1E0053; Wed, 25 Jan 2006 21:59:50 -0500 (EST) To: isms@ietf.org From: Sam Hartman Date: Wed, 25 Jan 2006 21:59:50 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Isms] Attendance at interim meeting 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I'm going to ask the chairs for a headcount at the end of the week in order to determine which room we need. So, you should let the chairs know you are attending if you have not already done so. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 27 05:17:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Qff-0004uB-ID; Fri, 27 Jan 2006 05:17:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Qfe-0004tz-1Z for isms@megatron.ietf.org; Fri, 27 Jan 2006 05:17:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23739 for ; Fri, 27 Jan 2006 05:16:01 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Qpk-0000Tc-Ar for isms@ietf.org; Fri, 27 Jan 2006 05:28:03 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 455044D3AB for ; Fri, 27 Jan 2006 11:17:12 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30451-02; Fri, 27 Jan 2006 11:17:10 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) by hermes.iu-bremen.de (Postfix) with ESMTP id D7DB04D2C2; Fri, 27 Jan 2006 11:17:09 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 4C25F5E0DA5; Fri, 27 Jan 2006 11:17:09 +0100 (CET) Date: Fri, 27 Jan 2006 11:17:08 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060127101708.GA17064@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline Fcc: =SENT User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Subject: [Isms] upcoming interim meeting and high level issue list 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I like to remind you to tell us ASAP whether you are going to attend the interim meeting. If you are a maybe candidate, please let us know when we can expect a final decision. The currently list of people who signed up and the list of maybe candidates is on the meeting web page: While we have a rather detailed list of technical issues, I have produced a more high-level issue list in order to drive the meeting. I am attaching this more high-level issue list. You can also find the most up-to-date version on the ISM web page: http://www.eecs.iu-bremen.de/wiki/index.php/ISMS_Working_Group I also like to see some discussion on these issues here on the mailing list (bash the issues, outline possible solutions, outline reasons why certain solutions should not be considered, ...). This list has been remarkably silent and I like to know whether this means simply lack of animation during the christmas/new year period or simply lack of interest. If you feel you should comment on a specific issue, please but the issue number into the subject line and please send multiple messages if you want to comment on multiple issues. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-issues.txt" Issues Below is a list of high-level issues that need to be resolved before work can continue on several low-level issues. Session Management Session establishment seems rather obvious if we consider command generators. It is less obvious if we consider notification originators. Some of these questions have a discussion in [24]RFC 3430. It needs to be determined whether the transport layer security model should follow [25]RFC 3430 or take a different approach. * SQ1: Are notifications originators responsible to establish sessions for notification delivery? * SQ2: Can notification originators (re-)use already established sessions for notification delivery? * SQ3: Is it required that a session already exists before a notification can be sent? Session teardown also allows for multiple solutions: * SQ4: Are sessions torn down when a logical operation is complete? * SQ5: If sessions are kept alive for future use, how do we deal with situations where sessions either need to be torn down due to resource constrains or where sessions seem to bind resouces but are not really used? Sessions establish state information and must be managed in various parts of the SNMP entity. * SQ6: How is session state information managed and in particular cleaned up when sessions go away (both via clean session shutdown or due to failures)? * SQ7: How do we deal with MIB variables that are bound to the existence of a session (e.g. notification target configurations pointing to a session established by a "manager" to receive notifications)? SSH Authentication SSH authentication is typically asymmetric. The SSH server is usually authenticated by its host identity (hostname) and its host key while the client is authenticated by its user identity (user name) and its associated credentials (password, keys). While the mapping seems to be straight-forward for command generators initiating SSH sessions to a command responder, things are less clear for sessions carrying notifications (node that this clearly depends on how we deal with notification sessions in general). * AQ1: Does notification delivery via SSH require user authentication of the notification originator and host authentication of the notification receiver? * AQ2: Does notification delivery via SSH require host authentication of the notification originator and user authentication of the notification receiver? * AQ3: Should both authentication styles outlined above be supported and runtime configurable? * AQ4: Is it possible/useful to have a "turn" mechanism in SSH which allows a process to initiate the SSH protocol but later turn the automatically assigned client role into a server role? Radius Integration One of the goals is to integrate into AAA services such as RADIUS to achieve centralized management of access to network devices for management purposes. Ideally, a solution would work not only for ISMS but consitently also for CLI access and potential other types of administrative access to devices (e.g. netconf). * RQ1: How does AAA hook into the overall model? Is AAA integration transparent from the viewpoint of the SNMP architecture or are explicit hooks required to make things work? * RQ2: What is the exact information that needs to be exchanged between an SNMP entity supporting ISMS and an AAA server? * RQ3: What happens to long lasting sessions? Is there a mechanism to re-check AAA information? How is an SNMP engine supposed to react if the re-check of AAA information is negative? --vkogqOf2sHV7VnPd Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --vkogqOf2sHV7VnPd-- From isms-bounces@lists.ietf.org Mon Jan 30 20:16:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3k30-0001BH-RU; Mon, 30 Jan 2006 20:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3k2z-0001B1-UD for isms@megatron.ietf.org; Mon, 30 Jan 2006 20:11:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29132 for ; Mon, 30 Jan 2006 20:09:30 -0500 (EST) Received: from [66.114.247.24] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3kDs-0006ga-0Z for isms@ietf.org; Mon, 30 Jan 2006 20:22:20 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 10DCCE006A; Mon, 30 Jan 2006 20:10:57 -0500 (EST) To: isms@ietf.org Subject: Re: [Isms] upcoming interim meeting and high level issue list References: <20060127101708.GA17064@boskop.local> From: Sam Hartman Date: Mon, 30 Jan 2006 20:10:57 -0500 In-Reply-To: <20060127101708.GA17064@boskop.local> (Juergen Schoenwaelder's message of "Fri, 27 Jan 2006 11:17:08 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I'm going to go put in the meeting room request tomorrow. So you definitely need to make sure you are on the attendance list at this point. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jan 30 23:58:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3nbA-0006XN-QV; Mon, 30 Jan 2006 23:58:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3nb7-0006Vy-1d for isms@megatron.ietf.org; Mon, 30 Jan 2006 23:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13244 for ; Mon, 30 Jan 2006 23:56:57 -0500 (EST) 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.43) id 1F3nlz-0004nY-TK for isms@ietf.org; Tue, 31 Jan 2006 00:09:48 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id E8EBE11D72F; Mon, 30 Jan 2006 20:58:23 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Mon, 30 Jan 2006 20:58:23 -0800 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: Subject: [Isms] notifications and SSH authentication 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org At the last IETF meeting I mentioned in the meeting that I had heard rumors of SSH experts stating that using a host-key for authentication of an initiating session was considered a bad thing and would be frowned upon. Turns out, fortunately, that I was wrong. Though not "desired", it is acceptable. reminder: politically correct SNMP speak means: CG = command generator CR = command responder NG = notification generator NR = notification responder SSH speak: LoF = Leap of Faith [this is much longer than I wanted to end up putting to text but shorting it would mean resorting to even more hand waving than I did end up doing. Not only that but I use different bullet types for every list to both annoy you and allow for easy referrals at the same time. I didn't go into the smaller details about what triggers a connection, when it is shut down, etc... only about the authentication mechanisms. Oh, and I didn't proof read it because it's late as it is.] -- previously discussed and likely known CG->CR: --------------------- Thus from a normal management session I think we have the SNMP CR being able to respond to an incoming SSH request from a client CG using the standard host key authentication on the CR side, and the standard ssh client side authentication (of any of it's forms) on the CG side. Both sides would need, of course, to check the authentication of the either side. Functionally this breaks down to (I haven't verified the exact SSH packet ordering, but roughly this is still accurate I think; I have also skipped how public key knowledge is previously set up or how LoF could be used instead for those willing to jump): 1) client CG connects via SSH (likely with a SNMP subsystem) to the CR SSH port. 2) the CR responds with it's host-key and proof of ownership. Note: there are other forms of SSH responder authentication but these aren't widely deployed to date 3) the CG verifies that the CR is the one it expected to talk to and checks the authentication of the CR's host key 4) the CG sends it's credentials using one of the SSH authentication mechanisms I) the user-name II) the authentication type: i) a client key and proof of ownership ii) a passphrase form of checking (exact method not described here) iii) ... 5) The CR verifies the authenticity of the credentials and verifies that the SSH user-name has a VACM map to a group that lets it do SNMP things. This binding may not be 1-1 like USM, but that's subject to later date. 6) The CG sends commands 7) the CR responds to them using the SNMP mapped SSH user name and checks the VACM settings to authorize each transaction. How the VACM is populated has always been subject to future debate. It's irrelevant from the authentication point of view, which is all I'm discussing today. Again, this is probably what is in people's heads today. I'm just being complete... -- New and not discussed in detail before: NG->NR ------------------- One of the issues with ISMS has been "what happens when a SNMP agent acting in a NG mode needs to send a notification off but no existing session is available". The only choice is very clear: it has to create one. The question then becomes, how does it authenticate to the NR? Well, the only likely choices available today are: NG1) Through having password based user credentials on the device such that it could connect via SSH to a NG and authenticate itself using a username/password types scenario. NG2) By having the NG use the host-public-key of the SSH server to connect to a NG since this public key is already installed in every SSH server out there and is truly what seems to most people to be the "natural" choice for how to reverse the connection. I had said in the meeting that I thought I had heard people say this was not going to be acceptable. However, after talking with people extremely familiar with SSH it turned out I was wrong about the current thinking of this issue. In fact the SSH RFCs have been recently published and even discuss this scenario in RFC 4252 (SSH Authentication Protocol) section 9: Some sites wish to allow authentication based on the host that the user is coming from and the user name on the remote host. While this form of authentication is not suitable for high-security sites, it can be very convenient in many environments. This form of authentication is OPTIONAL. When used, special care SHOULD be taken to prevent a regular user from obtaining the private host key. The client requests this form of authentication by sending the following message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of authentication, except that the identity of the client host is checked more rigorously. This method works by having the client send a signature created with the private key of the client host, which the server checks with that host's public key. Once the client host's identity is established, authorization (but no further authentication) is performed based on the user names on the server and the client, and the client host name. ... [technical protocol details] The server MUST verify that the host key actually belongs to the client host named in the message, that the given user on that host is allowed to log in, and that the 'signature' value is a valid signature on the appropriate value by the given host key. The server MAY ignore the client 'user name', if it wants to authenticate only the client host. ... There are two important parts about the above text with respect to using a host-key for starting an SSH session to send a SNMP notification over: SSH1) The NG would send the SSH host-key as a credential, and the host name of the NG, *and* would still send a user name SSH2) A server MAY ignore the user name and only consider the host name from the sent message. This leads me to think we have 3 choices for fulling the goal of NG2 above. ISMS1) we recommend the use of the host key and only the host name to authenticate traps at the NR. ISMS2) we recommend the use of the host key and the user name to authenticate the traps arriving at the NR. ISMS3) we don't recommend the use of the host key for authenticating incoming traps (sessions really) at the NR. ISMS3 doesn't of course meat the goal of NG2. The question then becomes which of the other two options to pick from. I think ideally we should allow for both alternatives to be used in the field, but maybe suggest one in practice over the other. IMHO, I prefer ISMS1 because note that the security credentials required by ISMS2 are actually the same and you have to trust the NG that it's correctly selecting the user name sending the notification. Security wise, using the user name doesn't buy you anything. Administratively I can see cases where it might be more helpful. Here's a concrete example of what I think we should end up doing: A) NG connects to NR using SSH over subsystem SNMPNotification at a new port number to be assigned by IANA. B) NR responds with it's host based credential. C) NG would have to verify this as being the right place to send notifications to. Note that there is no infrastructure in place today either in SNMP terms or otherwise that will allow existing NGs to make this decision. However, there are a number of ways to combat this via either radius like things that people are already talking about or a MIB configuration (which could allow configuration of it over ISMS/SSH). The up shot is still the same: the knowledge of the NRs host public key doesn't exist today on the NG. There isn't a way around this though regardless of the solution space. D) NG would send it's information and credentials to the NR. This would likely be (but doesn't have to be) the same public key being sent by the CR in step 2 way up above. Something along the breakdown of (defined by the SSH authentication mechanism not ISMS): Key: [data] Proof: [data] Host: me.example.com User: USER The choice here being what to set for USER. My view is that we should allow USER to be either: D1) USER = "" to indicate only host-based authentication is going to be submitted. D2) USER = "wes" to indicate that wes@me.example.com is the person trying to send the notification. We could only allow for one of these choices, but I think allowing for both options is the best way forward. [keep reading] E) the NR would receive the credentials, verify that the key and the proof work together and that the key matches the expected key for the me.example.com host. (This also doesn't have an existing database counterpart, but is much easier to construct on the fly from a given operators .ssh/known_hosts file if need be or through LoF techniques for those so willing). It would have to then make a choice: E1) if USER="" deal with the notification as if sent by the host. In SNMPv3-speak, this would be akin to only ever receiving notifications from a given NG being protected under a single USM securityName or the alternative view of only from the engineID without the usm-securityName half at all. I doubt many operators (if any) have notifications sent out over different USM users to the same destination, but I could always be wrong about that. E2) if USER="wes" we have 2 sub-choices: E2A) ignore the USER and continue as if E1 happened E2B) accept the notifications functionally as wes@me.example.com, similar to how operators can send notifications as usmSecurityName@engineID today. ---------- MIB notes ---------------------------------------------------- I'll leave it to the reader to decide whether the notification/target mibs need to be modified to support D1 and/or D2 above. I don't think so since the snmpTargetParamsTable today specifies a security model and name which functionally would be SNMPv3/SSH and USER from step D1 and D2 above. The secLevel may have to have special meaning though ("at least" or...). ---------- Conclusion --------------------------------------------------- The important take away point here (aside from me being wrong previously) is that we can use the host-key to initiate a connection to a NR. I think something like the above is likely the only real usable solution for notifications under ISMS. ---------- Implementation notes ----------------------------------------- If *I* were implementing this in a paranoid system, I'd be seriously tempted to not allow the snmp service to access the private/public keys of the local host. Instead I'd have a special socket from the snmp system that could trigger the snmp service to open a connection using it's own private/public key. However, that being said most systems today have the snmp service running at a really high level of access (root-level) by necessity since it has to be able to configure and access the important parts of the device. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 31 04:15:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rZV-0004yQ-0I; Tue, 31 Jan 2006 04:13:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3rZR-0004xB-Ua for isms@megatron.ietf.org; Tue, 31 Jan 2006 04:13:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27660 for ; Tue, 31 Jan 2006 04:11:21 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3rkE-0003Gw-PF for isms@ietf.org; Tue, 31 Jan 2006 04:24:16 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 31 Jan 2006 01:12:46 -0800 X-IronPort-AV: i="4.01,237,1136188800"; d="scan'208"; a="252555589:sNHT30242656" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0V9Ckc1009514; Tue, 31 Jan 2006 01:12:46 -0800 (PST) Received: from [212.254.247.4] (ams-clip-vpn-dhcp343.cisco.com [10.61.65.87]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0V9Gn1O010096; Tue, 31 Jan 2006 01:16:49 -0800 Message-ID: <43DF2A0C.5010202@cisco.com> Date: Tue, 31 Jan 2006 10:12:44 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Wes Hardaker Subject: Re: [Isms] notifications and SSH authentication References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1772; t=1138699010; x=1139131210; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Isms]=20notifications=20and=20SSH=20authentication |To:Wes=20Hardaker=20; X=v=3Dmtcc.com=3B=20h=3DwBDKj5CQiWxFOPkV275PCCM/Zuw=3D; b=YqHUpzKDYnJtqydYHihUqQfWv9GwJ8Gg6nCATZHef323dl1BVfnVHDUUeJYxKQUquJaLG+Z+ WTUiKcNIjBYs5GlbHft1cdLRJjNblV2M5CTRx08zvmnJQKgeJAVSqeoyHfnfVwAS6WnfWrligVl vJFfqR/8SHLyr5hwKbfC6gB0=; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Wes, Small mostly unrelated nit. I'm still digesting the rest of your message. Wes Hardaker wrote: > [Typical CG -> CR] > > 1) client CG connects via SSH (likely with a SNMP subsystem) to the CR > SSH port. > 2) the CR responds with it's host-key and proof of ownership. > Note: there are other forms of SSH responder authentication but > these aren't widely deployed to date > 3) the CG verifies that the CR is the one it expected to talk to and > checks the authentication of the CR's host key > 4) the CG sends it's credentials using one of the SSH authentication > mechanisms > I) the user-name > II) the authentication type: > i) a client key and proof of ownership > ii) a passphrase form of checking (exact method not described here) > iii) ... > 5) The CR verifies the authenticity of the credentials and verifies > that the SSH user-name has a VACM map to a group that lets it do > SNMP things. This binding may not be 1-1 like USM, but that's > subject to later date. > This depends on how the doc is written. If you don't use a separate port then there are really three steps here: 5a. CR verifies the authenticity of the credentials 5b. CG requests "snmp-isms" service. 5c. CR verifies that SSH user-name is authorized for "snmp-isms" service first via whatever SSH subsystem checks there 5d. If 5c checks are passed, then a VACM check is done. N.B. initial radius transactions take place during 5a. If a separate port is used, an assumption can be made by the ssh server that the use is ISMS, but even here it's important to note that some code changes would be necessary in order to make the assumption. You're not using SSH out of the box. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 31 11:10:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3y5Q-0007cP-EE; Tue, 31 Jan 2006 11:10:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3y5P-0007bh-8E for isms@megatron.ietf.org; Tue, 31 Jan 2006 11:10:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00438 for ; Tue, 31 Jan 2006 11:08:49 -0500 (EST) 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.43) id 1F3yGJ-0000bt-52 for isms@ietf.org; Tue, 31 Jan 2006 11:21:48 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 4E6BD11D72F; Tue, 31 Jan 2006 08:10:18 -0800 (PST) From: Wes Hardaker To: Eliot Lear Subject: Re: [Isms] notifications and SSH authentication Organization: Sparta References: <43DF2A0C.5010202@cisco.com> Date: Tue, 31 Jan 2006 08:10:18 -0800 In-Reply-To: <43DF2A0C.5010202@cisco.com> (Eliot Lear's message of "Tue, 31 Jan 2006 10:12:44 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Tue, 31 Jan 2006 10:12:44 +0100, Eliot Lear said: Eliot> This depends on how the doc is written. If you don't use a separate Eliot> port then there are really three steps here: I think the last I heard was that the WG consensus was that we were going to recommend the use of a different port (by default) but wouldn't do anything to prohibit it from using the same port. You're right that we should be requesting the snmp-ssh service or some service name we haven't yet discussed. Regardless of the port, I actually think a particular service name should always be requested regardless of whether it's expected to be a dedicated port or not. It makes implementation on both sides easier and is less prone to conflict of any kind. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 31 13:09:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zwP-0008Kr-Mb; Tue, 31 Jan 2006 13:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3zwO-0008EN-6m for isms@megatron.ietf.org; Tue, 31 Jan 2006 13:09:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14211 for ; Tue, 31 Jan 2006 13:07:39 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F407H-0006K3-SK for isms@ietf.org; Tue, 31 Jan 2006 13:20:38 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc11) with SMTP id <2006013118090201100kuosqe>; Tue, 31 Jan 2006 18:09:03 +0000 From: "David B Harrington" To: Date: Tue, 31 Jan 2006 13:08:57 -0500 Message-ID: <01d501c62691$68356140$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYhMUa0YyYGhndHQVul41k3leB6CQFVv5rQ In-Reply-To: <20060124215807.GA1018@boskop.local> X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: 'Juergen Quittek' , isms@ietf.org Subject: [Isms] RE: interim meeting preparation X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Sorry for the slow response; I was in China and email was challenging at times. Your list of issues looks good to drive the agenda. Recognize that I had moved the discussion from high-level discussion to low-level details for a reason. It is fairly easy to answer your high-level questions: SQ1: yes SQ2: yes SQ3: no These answers could also be answered differently: SQ1: no (the notifications should be discarded if no session exists) SQ2: no (they should establish their own sessions with reverse direction) SQ3: yes It really doesn't matter much which way they are answered; it's six one way, half-a-dozen the other way - it doesn't matter much which the answer is until you get into the details. Regardless of which way your questions are answered, it is not clear WHEN and HOW it CAN be done. And without knowing WHEN and HOW it should be done, we cannot advance the documents. A previous question asked at a high level: Does SSH need to pass the authenticated username to the SNMP engine? Yes The high-level question was easy to answer; we've known since long before ISMS was chartered that any lower security layer would need to pass the username so we could map it to securityName. But it took months of asking the SSH experts to determine where that information comes from to get a concrete answer that I could use in the elements of procedure. The SSH experts disagreed on whether it was reasonable to extract the user name field of the SSH_MSG_USERAUTH_REQUEST. They finally agreed it could be done, but it would have to be done in an implementation-dependent manner, partly because it may not be possible to get access to the SSH_MSG_USERAUTH_REQUEST with some SSH implementations. There is also the question of whether the securityName should reflect the authenticated user name, because securityName is used by SNMP, not for authentication purposes, but for authorization purposes, and if the AAA subsystem used by the SSH subsystem returns an *authorization* username to the SSH layer that is different than the username used for authentication, should the username provided to SNMP by SSH be the authenticated username or the authorized username? The detailed answer (HOW?) was only decidied at the last IETF meeting, and I hope that the detailed answer is final and not subject to further debate. So be careful about going for only the high-level answers, without getting the low-level details of WHEN and HOW to do it. We need to answer the HOW, to determine what information needs to be available to do it, and we need to answer the WHEN to determine whether the necessary information is available at the desired point in the elements of procedure. Without those details, we cannot write the elements of procedure, or the elements of procedure will need to be filled with a bunch of "magic happens here" procedures. The questions could be phrased differently: SQ1: Are notifications originators responsible to establish sessions for notification delivery, and if so, how and when do they do so? SQ2: Can notification originators (re-)use already established sessions for notification delivery, and if so, how and when do they determine that a session does or does not exist, and how and when do they choose a session with the appropriate security characteristics (both SSH and SNMP)? SQ3: Is it required that a session already exists before a notification can be sent, and if so, when and how does the NG (or message processor) determine whether a session exists or not, and what happens if there is no session? SQ4: Are sessions torn down when a logical operation is complete, and if so, HOW and WHEN does the engine know that a logical operation is complete (for example, when a message is discarded during processing and no Report is generated)? And so on... David Harrington dbharrington@comcast.net > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, January 24, 2006 4:58 PM > To: Dave Harrington > Cc: Juergen Quittek > Subject: interim meeting preparation > > Dave, > > it is time that we prepare the interim and also entertain some > discussion on the WG mailing list to better understand the design > space. While looking at the open issues list again, I felt that > they are too detailed and tend to hide the much more fundamental > questions that we IMHO need to answer first. > > I tried to formulate a set of questions to which I would like to get > answers during the interim (see attachment). Please check whether the > questions make sense and feel free to add more questions as you see > them (but lets avoid to go down to too much details). > > I like to post a revised issue list to the WG mailing list by the end > of the week latest to get some people thinking about ISMS again. > > /js > > PS: The source of the issue list is on the ISMS wiki page at > > > -- > 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@lists.ietf.org Tue Jan 31 15:11:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41q9-00016G-9B; Tue, 31 Jan 2006 15:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F41po-0000fb-SW for isms@megatron.ietf.org; Tue, 31 Jan 2006 15:10:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23425 for ; Tue, 31 Jan 2006 15:09:03 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F41wk-0002jt-MN for isms@ietf.org; Tue, 31 Jan 2006 15:17:52 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id F32D64D778; Tue, 31 Jan 2006 21:06:02 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 21037-09; Tue, 31 Jan 2006 21:06:01 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1ED874C991; Tue, 31 Jan 2006 21:06:01 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 629185E20AA; Tue, 31 Jan 2006 21:06:00 +0100 (CET) Date: Tue, 31 Jan 2006 21:06:00 +0100 From: Juergen Schoenwaelder To: David B Harrington Message-ID: <20060131200600.GB19381@boskop.local> Mail-Followup-To: David B Harrington , 'Juergen Quittek' , isms@ietf.org References: <20060124215807.GA1018@boskop.local> <01d501c62691$68356140$0400a8c0@DJYXPY41> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01d501c62691$68356140$0400a8c0@DJYXPY41> Fcc: =SENT User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Juergen Quittek' , isms@ietf.org Subject: [Isms] Re: interim meeting preparation 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Jan 31, 2006 at 01:08:57PM -0500, David B Harrington wrote: [...] > So be careful about going for only the high-level answers, without > getting the low-level details of WHEN and HOW to do it. We need to > answer the HOW, to determine what information needs to be available to > do it, and we need to answer the WHEN to determine whether the > necessary information is available at the desired point in the > elements of procedure. Without those details, we cannot write the > elements of procedure, or the elements of procedure will need to be > filled with a bunch of "magic happens here" procedures. My intention was indeed to look into the details (how and when) in order to find answers to the questions or to see whether answers are viable. (I would not travel to Boston to just count a few yes/nos.) > The questions could be phrased differently: > SQ1: Are notifications originators responsible to establish sessions > for notification delivery, and if so, how and when do they do so? > SQ2: Can notification originators (re-)use already established > sessions for notification delivery, and if so, how and when do they > determine that a session does or does not exist, and how and when do > they choose a session with the appropriate security characteristics > (both SSH and SNMP)? > SQ3: Is it required that a session already exists before a > notification can be sent, and if so, when and how does the NG (or > message processor) determine whether a session exists or not, and what > happens if there is no session? > SQ4: Are sessions torn down when a logical operation is complete, and > if so, HOW and WHEN does the engine know that a logical operation is > complete (for example, when a message is discarded during processing > and no Report is generated)? > > And so on... I have put the revised questions on the wiki page. Feel free to send me more input. I think we now make progress towards a decent set of questions we have to work through. Lets continue. If someone has concrete input to the how and whens, please by all means send your input to this list prior to the interim meeting. /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@lists.ietf.org Tue Jan 31 15:59:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42bK-0007TY-T1; Tue, 31 Jan 2006 15:59:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42bJ-0007TH-9Y for isms@megatron.ietf.org; Tue, 31 Jan 2006 15:59:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27142 for ; Tue, 31 Jan 2006 15:57:59 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F42mB-0004mH-S2 for isms@ietf.org; Tue, 31 Jan 2006 16:11:01 -0500 Received: from djyxpy41 (c-24-62-247-149.hsd1.nh.comcast.net[24.62.247.149]) by comcast.net (sccrmhc12) with SMTP id <2006013120592201200elunhe>; Tue, 31 Jan 2006 20:59:22 +0000 From: "David B Harrington" To: Date: Tue, 31 Jan 2006 15:59:17 -0500 Message-ID: <01dc01c626a9$33745bb0$0400a8c0@DJYXPY41> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYmqTMHB1jKPFTpRkad1yWBArWjaQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Hyatt rates X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I don't know if anybody attending qualifies, but if you're 62 or older, the senior citizen rate is much lower than the normal rate at the Hyatt. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 31 17:00:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F43YQ-0004Z8-1I; Tue, 31 Jan 2006 17:00:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F43YO-0004Ul-KK for isms@megatron.ietf.org; Tue, 31 Jan 2006 17:00:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04435 for ; Tue, 31 Jan 2006 16:59:03 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F43jI-0007kO-Rm for isms@ietf.org; Tue, 31 Jan 2006 17:12:06 -0500 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 97C151BAC4D; Tue, 31 Jan 2006 23:00:29 +0100 (CET) Date: Tue, 31 Jan 2006 23:00:37 +0100 From: Juergen Quittek To: Sam Hartman , isms@ietf.org Subject: Re: [Isms] upcoming interim meeting and high level issue list Message-ID: <8DF4F1403602B24A0F9697C7@[192.168.1.128]> In-Reply-To: References: <20060127101708.GA17064@boskop.local> X-Mailer: Mulberry/3.1.6 (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.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam, Thank you for keeping both reservations until today. With 9 confirmed and 3 unconfirmed participants it looks like the small room for 10-15 people is sufficient and you can give up the reservation for the room for 50 people. Thanks, Juergen Q. --On 1/30/06 8:10 PM -0500 Sam Hartman wrote: > > I'm going to go put in the meeting room request tomorrow. So you > definitely need to make sure you are on the attendance list at this > point. > > > _______________________________________________ > 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