From isms-bounces@ietf.org Mon Jun 2 10:40:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5F43A6C8B; Mon, 2 Jun 2008 10:40:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6CA3A69DA for ; Mon, 2 Jun 2008 10:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hor+kIiZhDAR for ; Mon, 2 Jun 2008 10:40:15 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 8C6B93A6D20 for ; Mon, 2 Jun 2008 10:34:33 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA10.westchester.pa.mail.comcast.net with comcast id Yzda1Z00k0cZkys5A0Uj00; Mon, 02 Jun 2008 17:34:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id Z5aZ1Z00T4HwxpC3W00000; Mon, 02 Jun 2008 17:34:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=abe5jlwL1A8A:10 a=KOiMaYgTFfs3SSyOaT4A:9 a=RYaAAaDqTmz_yTJOp6wA:7 a=lyoDfgH1Eny3J9ymYpHSa_rXC2IA:4 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Phil Shafer'" References: <003101c8c109$cca067f0$0600a8c0@china.huawei.com> <200806021509.m52F9kW4061621@idle.juniper.net> Date: Mon, 2 Jun 2008 13:34:33 -0400 Message-ID: <032601c8c4d6$ec0e6170$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjEwwdJhaZnq02XRKuJWvQpudu1aAADrWJQ In-Reply-To: <200806021509.m52F9kW4061621@idle.juniper.net> Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Monday, June 02, 2008 11:10 AM > To: David Harrington > Cc: ops-dir@ietf.org; 'OPS Area' > Subject: Re: [OPS-DIR] SNMP notification configuration > > "David Harrington" writes: > >For SNMP notifications, the SNMP agent will need to act as an SSH > >client, and the SNMP notification receivers will need to act > as an SSH > >server. Will operators find this objectionable? > > This would require a password/passphrase for an account on the > management station to be included in the device configuration, > right? Many operators will find this objectionable, though one can > make the ssh equivalent on an "anonymous ftp user" will a little > effort. Reachability via firewall (and nat) is also an issue. Yes, we know that NATs can be problematic. Hopefully someday the IETF will figure out how to make NATs less of a problem. > > >Question #2: > >Would operators prefer to modify their existing user and key > >management solutions, such as implementation-dependent CLI > scripts, to > >configure SSH clients on devices where they may not be found now, or > >would operators prefer to have the ISMS WG develop a standard MIB > >module to configure and manage the SSH credentials needed to > have SNMP > >agents act as SSH clients? > > There are few real-world deployment scenarios for MIBs for config > (unless forced) and the big motivation for using ssh is that the > infrastructure is already deployed. So my take is that no one needs > or will use a writable MIB for ssh credentials. Remeber that operators will need to configure the SNMP agents to send notifications, and we have standard MIBs to do that configuration. Lacking the ability to also configure the SSH client credebtials via SNMP means thay must use multiple management interfaces to config SNMP notifications (or not use the SNMPv3 standard MIBs for notifications). > > Another question: Given that NETCONF includes ssh-as-transport and > now has a notification mechanism, would snmp-over-netconf work > better than snmp-over-ssh? It doubt snmp-over-netconf would meet most operators' needs for SNMP notifications. SNMP supports asynchronous notifications. The agent initiates the session when an event occurs. This may occur at any time, and the manager (or notification-receiver) is expected to be listening (more or less) all the time. This is like having your phone ring when somebody calls you. One benefit of this approach is trap-directed-polling, The agent can notify the manager that an event has occured, and the manager can then poll for additional information to determine the nature and importance of the event. I think this is like using an answering machine to screen calls - it tells you who is calling, and maybe what they called about, but you would pick up or call back to get all the details when you're ready to handle the details. Netconf uses a subscribe approach. The client (manager) initiates the session over which the server (agent) will deliver notifications. The notifications can only be delivered if a manager has subscribed and the manager asks for a replay of the notifications it missed while not subscribed, or kept the session open to listen for new notifications. I think of this as polling-directed-traps. I think this is like calling your voicemail to see who called while you weren't home, or calling all your friends to open a long-term phone connection to each in case they want to talk to you later. SNMP notifications have traditionally been close-to-real-time and scalable. I think netconf notifications are great for interactive configuration work. I don't think the netconf subscribe approach is scalable to managing large networks. dbh > > Thanks, > Phil > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 3 08:34:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D533A6A2C; Tue, 3 Jun 2008 08:34:39 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC223A6849; Tue, 3 Jun 2008 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuY+4KoHAMb2; Tue, 3 Jun 2008 07:37:57 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id E6D7528C18B; Tue, 3 Jun 2008 07:36:38 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Tue, 03 Jun 2008 07:36:40 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 07:36:34 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m53EaXx87212; Tue, 3 Jun 2008 07:36:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m53EYMRa076056; Tue, 3 Jun 2008 14:34:23 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806031434.m53EYMRa076056@idle.juniper.net> To: "David Harrington" In-reply-to: <032601c8c4d6$ec0e6170$0600a8c0@china.huawei.com> Date: Tue, 03 Jun 2008 10:34:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2008 14:36:34.0585 (UTC) FILETIME=[38E50890:01C8C587] X-Mailman-Approved-At: Tue, 03 Jun 2008 08:34:39 -0700 Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org "David Harrington" writes: >SNMP notifications have traditionally been close-to-real-time and >scalable. I think netconf notifications are great for interactive >configuration work. I don't think the netconf subscribe approach is >scalable to managing large networks. The difference is much smaller, I think. SNMP sends async notifications based on content descriptions set in (typically) configuration. NETCONF sends async notifications based on content descriptions given in client subscriptions. Once set, both styles send notifications when event happen. The action of the snmp agent and the netconf agent are completly similar. The major difference is that NETCONF requires the manager establish a connection beforehand, where SNMP sends notifications without regard to the manager. The real cost is that a manager needs to have connections up and running to each managed device. The cost for the agent is a connection (one per manager) which is negligible. Thanks, Phil _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 3 08:59:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B333A69C6; Tue, 3 Jun 2008 08:59:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8C63A681E for ; Tue, 3 Jun 2008 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pVAIpV7ZBda for ; Tue, 3 Jun 2008 08:59:32 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 54D393A69D0 for ; Tue, 3 Jun 2008 08:59:32 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ZTUN1Z00C0lTkoCA403E00; Tue, 03 Jun 2008 15:59:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id ZTzY1Z0074HwxpC8Q00000; Tue, 03 Jun 2008 15:59:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=abe5jlwL1A8A:10 a=NTGhQEpmd0-iKNMwtdYA:9 a=KTui6D9nyqoTTnWOTQoA:7 a=LZlpZPHJDeb0JrC5TklWvQi_DUwA:4 a=NQ6Gw_dTYHUA:10 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Phil Shafer'" References: <032601c8c4d6$ec0e6170$0600a8c0@china.huawei.com> <200806031434.m53EYMRa076056@idle.juniper.net> Date: Tue, 3 Jun 2008 11:59:31 -0400 Message-ID: <00ce01c8c592$d114fd90$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200806031434.m53EYMRa076056@idle.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjFhz3pm55KLCeTTtGF6o0EYlFQOQABU29Q Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, comments inline, and a request for additional feedback from operators. > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, June 03, 2008 10:34 AM > To: David Harrington > Cc: ops-dir@ietf.org; 'OPS Area'; isms@ietf.org > Subject: Re: [OPS-DIR] SNMP notification configuration > > "David Harrington" writes: > >SNMP notifications have traditionally been close-to-real-time and > >scalable. I think netconf notifications are great for interactive > >configuration work. I don't think the netconf subscribe approach is > >scalable to managing large networks. > > The difference is much smaller, I think. SNMP sends async > notifications > based on content descriptions set in (typically) configuration. > NETCONF sends async notifications based on content descriptions > given in client subscriptions. Once set, both styles send > notifications > when event happen. The action of the snmp agent and the netconf > agent are completly similar. > > The major difference is that NETCONF requires the manager establish > a connection beforehand, where SNMP sends notifications without > regard to the manager. SNMP can send notifications when an event happens, without having to wait for a manager to initiate a connection first. This distinction can be important, especially during startup. As SNMP moves from a UDP transport to an SSH transport, an entity-to-entity connection will need to be initiated before the notification can be sent, so the fact that a connection must be instantiated first might become less important. The distinction of WHO must initiates the connection first might become more important because of NATs. > The real cost is that a manager needs to > have connections up and running to each managed device. The cost > for the agent is a connection (one per manager) which is negligible. These costs probably are similar between netconf/SSH and SNMP/SSH. So, in ISMS terms, would operators find it acceptable if SNMP adopted a "manager must subscribe to get notifications (with replay capability)" similar to the netconf notification protocol approach, when using SNMP over a secure transport layer like SSH or TLS? Using a manager-must-subscribe mechanism would eliminate the need for having the agent establish the SSH connection. The ISMS WG could consider using the same notification protocol design as netconf. This could be done by 1) using a MIB extension to the TARGET-MIB, EVENT-MIB, et. al., requiring a manager to use SNMP SETs to create subscriptions similar to that of the netconf notification protocol. Notifications would be buffered, possibly using the NOTIFICATION-LOG-MIB, just as with netconf notifications. or 2) not sending SNMP notifications over secure transports, but rather requiring support for the netconf notification protocol in all SNMP agents and managers that support SNMP/secure-transport, so managers would need to use netconf to get the notifications. SNMP would presumably continue to support its existing notification model, requiring no subscription (but still requring pre-configuration), when used over UDP. or 3) we could define a new SNMP operation to create a subscription comparable to the netconf notification protocol. The second and third approaches seem to be totally out of scope of the ISMS WG charter, but if they would be better solutions, we could presumably re-charter. (Once we get some operator feedback, we can take this discussion off the OPS lists and return to detailed engineering discussions in the ISMS WG. ;-) David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 3 09:40:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DB128C18F; Tue, 3 Jun 2008 09:40:12 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B37A3A69A5 for ; Tue, 3 Jun 2008 09:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L97qiN9DsEjk for ; Tue, 3 Jun 2008 09:40:06 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 6D3563A682B for ; Tue, 3 Jun 2008 09:40:06 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id ZU6w1Z01r0lTkoCA601W00; Tue, 03 Jun 2008 16:40:09 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id ZUg71Z0024HwxpC8Q00000; Tue, 03 Jun 2008 16:40:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=abe5jlwL1A8A:10 a=TsNevSaXmjjEHZoBEhAA:9 a=XJnkrROM32FM8VgAipNrHv9xAeAA:4 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=9XSpoOj3B7kA:10 From: "David Harrington" To: "'Phil Shafer'" References: <00ce01c8c592$d114fd90$0600a8c0@china.huawei.com> <200806031619.m53GJduY077171@idle.juniper.net> Date: Tue, 3 Jun 2008 12:40:06 -0400 Message-ID: <00dc01c8c598$7c0c7070$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200806031619.m53GJduY077171@idle.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjFlfFZuOgTOGu5T4CzydgHTTx+dQAAX5Ug Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org As an SNMP "old dog", I have been indoctrinated with many assumptions that were true in the 80s, but might be less true now. Startup keeps getting smaller as a percentage of overall uptime; notifications may not be as desirable during startup as they once were; UDP may not be any more reliable than TCP for getting through broken networks, and so on. The ISMS WG is trying to make sure we don't change the basic assumptions of how SNMP works, but we occasionally need to question whether certain old assumptions are still valid. dbh > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, June 03, 2008 12:20 PM > To: David Harrington > Cc: ops-dir@ietf.org; 'OPS Area'; isms@ietf.org > Subject: Re: [OPS-DIR] SNMP notification configuration > > "David Harrington" writes: > >SNMP can send notifications when an event happens, without having to > >wait for a manager to initiate a connection first. This distinction > >can be important, especially during startup. > > Sure, but in practice, startup is a painful time to send > notifications, > since the delays of interface bringup and learning routes may mean > your manager is unreachable. Waiting for a connection turns out > to be more useful than firing off packets into nowhere. > > Thanks, > Phil > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 3 11:42:45 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A993A6A8E; Tue, 3 Jun 2008 11:42:45 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031943A6A55; Tue, 3 Jun 2008 11:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8pZp6yiTy-e; Tue, 3 Jun 2008 11:42:44 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 69EDD3A6AB8; Tue, 3 Jun 2008 11:40:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dGtbmIagx1bguZlhPiQAYwkoRA/+ZirFOvKTgrOfswtrW4E1UDNUloj8y/UAfVp1; h=Received:Message-ID:From:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.89.73] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K3bQg-0002L3-Rl; Tue, 03 Jun 2008 14:40:19 -0400 Message-ID: <00a301c8c5a9$5a91ab20$6801a8c0@oemcomputer> From: "Randy Presuhn" References: <032601c8c4d6$ec0e6170$0600a8c0@china.huawei.com><200806031434.m53EYMRa076056@idle.juniper.net> <00ce01c8c592$d114fd90$0600a8c0@china.huawei.com> Date: Tue, 3 Jun 2008 11:40:52 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3dd97ece9fbbe0d32e9061a4d6823f15b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.73 Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "David Harrington" > To: "'Phil Shafer'" > Cc: ; ; "'OPS Area'" > Sent: Tuesday, June 03, 2008 8:59 AM > Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration ... > The ISMS WG could consider using the same notification protocol design > as netconf. This could be done by > 1) using a MIB extension to the TARGET-MIB, EVENT-MIB, et. al., > requiring a manager to use SNMP SETs to create subscriptions similar > to that of the netconf notification protocol. Notifications would be > buffered, possibly using the NOTIFICATION-LOG-MIB, just as with > netconf notifications. or I'm no operator, but... For this solution, *no* extensions are needed. The log mib is already designed for this scenario. Yes, the manager would need to query the MIB to gather the notification payloads. However, I think this may be a feature rather than a bug. If we're going to start talking about replaying those notifications, we'd then need to limit that replay to transports with appropriate congestion avoidance built in. I think it's simpler to just use the existing MIBs to do what they were designed to do. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jun 4 02:01:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2393A6A9D; Wed, 4 Jun 2008 02:01:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343B33A69A5 for ; Wed, 4 Jun 2008 02:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY5JkxndQ3MP for ; Wed, 4 Jun 2008 02:01:44 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 52CA33A6923 for ; Wed, 4 Jun 2008 02:01:44 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5491hW4018091; Wed, 4 Jun 2008 12:01:45 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jun 2008 11:59:28 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jun 2008 11:59:15 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 11:59:14 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72D0D4BE@vaebe104.NOE.Nokia.com> In-Reply-To: <20080527062527.GC16024@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ssh notifications and draft-ietf-isms-secshell-10 Thread-Index: Aci/wn03mD491Uk2THSH7tDHFBtirwGXlpcQ References: <20080527062527.GC16024@elstar.local> From: To: , X-OriginalArrivalTime: 04 Jun 2008 08:59:15.0382 (UTC) FILETIME=[43CD7D60:01C8C621] X-Nokia-AV: Clean Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder wrote > So please, help us by taking a look at the document and sending out > proposals what you think need to be changed or let us know that you > took a look at the documents and they appear to be fine already. Taking a look at draft-ietf-isms-secshell-10 only: Section 4.2 needs to consider both SSH client and server cases (probably separately); currently, the discussion about extracting an identity from the SSH layer seems to properly describe only SSH server behavior. Maybe something along these lines: SSH server: On SSH server, tmSecurityName is a human-readable name in SnmpAdminString format that is mapped from the user identity that has been authenticated by the SSH Authentication Protocol. How the SSH identity is mapped to a tmSecurityName should be administratively configurable in the LCD. Typically, the LCD would provide a mapping from the SSH user name (the user name field of the SSH_MSG_USERAUTH_REQUEST message) to tmSecurityName, and information about how the user is to be authenticated (e.g., way to verify the password for "password" authentication, or user's public key for "publickey" authentication). AAA services can also be used to provide this information. SSH client: On SSH client, tmSecurityName is a human-readable name in snmpAdminString format that is mapped to (1) how the server is authenticated, and (2) how the client authenticates itself to the server. This mapping is provided by the LCD. Typically, the LCD would contain at least (1) the server's host public key, and (2) the SSH user name to be sent by the client, the authentication method to use (e.g., "publickey" or "password"), and a credential appropriate for the authentication method (e.g., a private key or a password). Section 4.3: if we assume that TARGET-MIB will contain the notification receiver's IP address + the IANA-assigned port number, and we do the "do we already have a session" check using both of them (and not just the IP address), then we have the same restriction as RFC 3430: notifications can't be sent over a transport session opened by the other end. Section 4.3 probably needs a small update to reflect this (and this restriction should be explicitly said somewhere earlier in the document) Section 5.1: the text about tmsSecurityName also assumes that "incoming messages" implies "incoming SSH connection". This is clearly not the case for e.g. command responses. suggested replacement: "tmsSecurityName = see Section 4.2." Section 5.3 is basically OK, but could benefit from some clarifications. Updated steps 1..3: 1) The provided transport domain, transport address, securityName and securityLevel are used to lookup an associated entry in the Local Configuration Datastore (LCD). 2) Using destTransportDomain and destTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, authenticate the server (using information in the LCD entry), and exchange keys for message integrity and encryption. The parameters of the transport connection are provided in an implementation-dependent manner. 3)The client will then invoke an SSH authentications service to authenticate the user, such as that described in the SSH authentication protocol [RFC4252]. The user name and credentials used to authenticate are determined by the LCD entry. If the authentication is unsuccessful [...] The section (or some other section) should also explain the behavior of the other end (SSH server side). Here's a rough attempt: 1) The server will listen for incoming connections; by default, the IANA-assinged TCP port is used. 2) When a connection is received, the server will establish an SSH transport connection using the SSH transport protocol. The host public/private keypair is provided in an implementation dependent manner. 3) The server will then authenticate the client. How the client is authenticated is implementation dependent. It may involve communication with an AAA server. The LCD is used to determine the SNMP securityName for this user. 4) The client wil then request a channel of type "session" and invokve the SNMP subsystem. 5) Create a session entry in the Local Configuration Datastore, containing the transportDomain, transportAddress, securityName, securityLevel, and SSH-specific parameters, and create a tmStateReference to reference the entry. Section 6.3, "This MIB module models a sample Local Configuration Datastore." doesn't seem to be true anymore? Section 7: the counters in the sshtmSession group seem to apply only to SSH client side, not server? This should be said explicitly. Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jun 4 07:39:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DADF3A6D22; Wed, 4 Jun 2008 07:39:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E2E3A6B5E; Tue, 3 Jun 2008 09:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKyghRnRFQnc; Tue, 3 Jun 2008 09:24:25 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 4A83228C1DD; Tue, 3 Jun 2008 09:21:53 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 03 Jun 2008 09:21:55 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 09:21:51 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m53GLox20620; Tue, 3 Jun 2008 09:21:50 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m53GJduY077171; Tue, 3 Jun 2008 16:19:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806031619.m53GJduY077171@idle.juniper.net> To: "David Harrington" In-reply-to: <00ce01c8c592$d114fd90$0600a8c0@china.huawei.com> Date: Tue, 03 Jun 2008 12:19:38 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2008 16:21:51.0001 (UTC) FILETIME=[EDC5A090:01C8C595] X-Mailman-Approved-At: Wed, 04 Jun 2008 07:39:02 -0700 Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org "David Harrington" writes: >SNMP can send notifications when an event happens, without having to >wait for a manager to initiate a connection first. This distinction >can be important, especially during startup. Sure, but in practice, startup is a painful time to send notifications, since the delays of interface bringup and learning routes may mean your manager is unreachable. Waiting for a connection turns out to be more useful than firing off packets into nowhere. Thanks, Phil _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jun 4 07:39:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989513A6D26; Wed, 4 Jun 2008 07:39:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E213A6805; Tue, 3 Jun 2008 10:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIy27rxR+QE6; Tue, 3 Jun 2008 10:37:27 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id B32AA3A6B4C; Tue, 3 Jun 2008 10:37:21 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Tue, 03 Jun 2008 10:37:09 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 10:37:06 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m53Hb5x47046; Tue, 3 Jun 2008 10:37:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m53HYsSL078063; Tue, 3 Jun 2008 17:34:54 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806031734.m53HYsSL078063@idle.juniper.net> To: "David Harrington" In-reply-to: <00dc01c8c598$7c0c7070$0600a8c0@china.huawei.com> Date: Tue, 03 Jun 2008 13:34:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2008 17:37:06.0570 (UTC) FILETIME=[7142C6A0:01C8C5A0] X-Mailman-Approved-At: Wed, 04 Jun 2008 07:39:02 -0700 Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org "David Harrington" writes: >The ISMS WG is trying to make sure we don't change the basic >assumptions of how SNMP works, but we occasionally need to question >whether certain old assumptions are still valid. Sure, and I'm not out to make trouble, just wondering about cost/benefit tradeoffs. Thanks, Phil _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jun 4 09:15:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4AA28C201; Wed, 4 Jun 2008 09:15:12 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AEA28C201 for ; Wed, 4 Jun 2008 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2whsk1JEyMC for ; Wed, 4 Jun 2008 09:15:05 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id BB3BD28C18F for ; Wed, 4 Jun 2008 09:13:50 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id ZmD71Z00A0lTkoCA90Zm00; Wed, 04 Jun 2008 16:13:55 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id ZsDs1Z00B4HwxpC8Q00000; Wed, 04 Jun 2008 16:13:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=uWnPa_7rsvpvNRY_WHgA:9 a=_lg1XTGFAWUkXNH6YfgA:7 a=ho4VSrykz3E04Mp2dYphm481U94A:4 a=lZB815dzVvQA:10 a=1pxjJC3EenQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , , References: <20080527062527.GC16024@elstar.local> <1696498986EFEC4D9153717DA325CB72D0D4BE@vaebe104.NOE.Nokia.com> Date: Wed, 4 Jun 2008 12:13:52 -0400 Message-ID: <019501c8c65d$fc32b960$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1696498986EFEC4D9153717DA325CB72D0D4BE@vaebe104.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci/wn03mD491Uk2THSH7tDHFBtirwGXlpcQAA0nqoA= Subject: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I will start to work on these suggestions (and those from other emails). I will respond to the specific text suggestions in a separate email. I need something from the WG and chair before I make the proposed changes. I believe the WG reached consensus to permit reuse of an existing session, even if it was initially established in the opposite direction, as well as permitting agent initiation of a session. The proposed text contains statements like "notifications can't be sent over a transport session opened by the other end." The port we will be sending to will already be listening, because it already listens for responses. And the transport model doesn't know what type of operation is contained in a message; it simply accepts an outgoing wholeMessage from the MPM, or it simply accepts the wholeMsg from SSH and passes it to the MPM, which detrmines which type of operation is involved. So the SSH layer should not care which operation type is contained in the message. Unless of course, we think that SNMP command generator/responder applications run over a different SSH service or a different SSH subsystem than SNMP notification origination and notification receiver applications. The RFC3411 architecture was designed such that an entity is an entity, and which applications they support internally is an implementation decision. The transport model shouldn't care, and should be able to use the same SSH service/subsystem for all SNMP applications. -- While we have been discussing how to specify the agent as SSH client, we asked the OPS-AREA and OPS-DIR operators for feedback on how they want to do configuration/key distribution for SSH client credentials. My impression of the feedback is that a MIB is not called to hold the keys, but others should review the discussion as well. Part of the discussion there (parts of which I copied here) suggests that a subscribe-style notification like that used in netconf might also meet operators' needs for SNMP/SSH. If that is the case, then we could avoid having the SNMP agent act as an SSH client. We might have to provide some type of non-SSH request-for-SSH-session capability (callhome), such as a USM or noAuthNoPriv notification to the manager. I think we could design a solution where the "agent" can always be the SSH server, never the client. This would be more consistent with current SSH deployment, possibly simplify our processing (except the callhome and possibly informs), and enable us to always use both server and client authentication. I think we should discuss this before making changes that force this one way or the other. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Wednesday, June 04, 2008 4:59 AM > To: j.schoenwaelder@jacobs-university.de; isms@ietf.org > Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 > > Juergen Schoenwaelder wrote > > So please, help us by taking a look at the document and sending out > > proposals what you think need to be changed or let us know that you > > took a look at the documents and they appear to be fine already. > > Taking a look at draft-ietf-isms-secshell-10 only: > > Section 4.2 needs to consider both SSH client and server cases > (probably separately); currently, the discussion about extracting an > identity from the SSH layer seems to properly describe only SSH server > behavior. Maybe something along these lines: > > SSH server: > > On SSH server, tmSecurityName is a human-readable name in > SnmpAdminString format that is mapped from the user identity that > has been authenticated by the SSH Authentication Protocol. > > How the SSH identity is mapped to a tmSecurityName should be > administratively configurable in the LCD. > > Typically, the LCD would provide a mapping from the SSH user name > (the user name field of the SSH_MSG_USERAUTH_REQUEST message) to > tmSecurityName, and information about how the user is to be > authenticated (e.g., way to verify the password for "password" > authentication, or user's public key for "publickey" > authentication). AAA services can also be used to provide > this information. > > SSH client: > > On SSH client, tmSecurityName is a human-readable name in > snmpAdminString format that is mapped to (1) how the server is > authenticated, and (2) how the client authenticates itself to the > server. > > This mapping is provided by the LCD. Typically, the LCD would > contain at least (1) the server's host public key, and (2) the SSH > user name to be sent by the client, the authentication method to > use (e.g., "publickey" or "password"), and a credential appropriate > for the authentication method (e.g., a private key or a password). > > Section 4.3: if we assume that TARGET-MIB will contain the > notification receiver's IP address + the IANA-assigned port number, > and we do the "do we already have a session" check using both of them > (and not just the IP address), then we have the same restriction as > RFC 3430: notifications can't be sent over a transport session opened > by the other end. Section 4.3 probably needs a small update to reflect > this (and this restriction should be explicitly said somewhere earlier > in the document) > > Section 5.1: the text about tmsSecurityName also assumes that > "incoming messages" implies "incoming SSH connection". This > is clearly not the case for e.g. command responses. > suggested replacement: "tmsSecurityName = see Section 4.2." > > Section 5.3 is basically OK, but could benefit from some > clarifications. > > Updated steps 1..3: > > 1) The provided transport domain, transport address, securityName > and securityLevel are used to lookup an associated entry in the > Local Configuration Datastore (LCD). > > 2) Using destTransportDomain and destTransportAddress, the client > will establish an SSH transport connection using the SSH transport > protocol, authenticate the server (using information in the LCD > entry), and exchange keys for message integrity and encryption. > The parameters of the transport connection are provided in an > implementation-dependent manner. > > 3)The client will then invoke an SSH authentications service to > authenticate the user, such as that described in the SSH > authentication protocol [RFC4252]. The user name and credentials > used to authenticate are determined by the LCD entry. > > If the authentication is unsuccessful [...] > > The section (or some other section) should also explain the behavior > of the other end (SSH server side). Here's a rough attempt: > > 1) The server will listen for incoming connections; by default, > the IANA-assinged TCP port is used. > > 2) When a connection is received, the server will establish > an SSH transport connection using the SSH transport protocol. > The host public/private keypair is provided in an implementation > dependent manner. > > 3) The server will then authenticate the client. How the client is > authenticated is implementation dependent. It may involve > communication with an AAA server. The LCD is used to determine the > SNMP securityName for this user. > > 4) The client wil then request a channel of type "session" and > invokve the SNMP subsystem. > > 5) Create a session entry in the Local Configuration Datastore, > containing the transportDomain, transportAddress, securityName, > securityLevel, and SSH-specific parameters, and create a > tmStateReference to reference the entry. > > Section 6.3, "This MIB module models a sample Local Configuration > Datastore." doesn't seem to be true anymore? > > Section 7: the counters in the sshtmSession group seem to apply > only to SSH client side, not server? This should be said > explicitly. > > Best regards, > Pasi > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 5 06:44:10 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438643A6856; Thu, 5 Jun 2008 06:44:10 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7623A68E6 for ; Thu, 5 Jun 2008 06:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Cv9qio6uDIY for ; Thu, 5 Jun 2008 06:44:08 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 517B93A6856 for ; Thu, 5 Jun 2008 06:44:07 -0700 (PDT) X-Trace: 125724688/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.122.151 X-SBRS: None X-RemoteIP: 62.188.122.151 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAAaKR0g+vHqX/2dsb2JhbACLb6QTAw X-IronPort-AV: E=Sophos;i="4.27,595,1204502400"; d="scan'208";a="125724688" X-IP-Direction: IN Received: from 1cust151.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.151]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2008 14:44:08 +0100 Message-ID: <010601c8c709$2ab817c0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <037201c8b070$85442300$0600a8c0@china.huawei.com><20080526085932.GA13279@elstar.local> <02a201c8bf97$3abf4680$0600a8c0@china.huawei.com> Date: Thu, 5 Jun 2008 14:31:21 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: [Isms] securityName mapping was Re: draft updates X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David This is related to but I think distinct from issues 2 and 3. When we discussed securityName last year, I understood that - the Security Model always determines the securityName and not the Transport Model. - there are (consequently) two mappings involved, between identifier used by the secure transport and proposed securityName from the Transport Model, and between the proposed securityName from the Transport Model and the securityName selected by Security Model. Of course both mappings can be the identity mapping. Is this intended to be what SSHTM describes? Where does tmSecurityName fit into the three identifiers? I ask because the usage seems not quite consistent. If we agree on what should be happening, then I will trawl the I-D again for wording which I think inconsistent, but want to establish the principle first. The simplest case is is a CR receiving a request, so let's focus on that first. Tom Petch ----- Original Message ----- From: "David Harrington" To: Cc: Sent: Tuesday, May 27, 2008 3:16 AM Subject: [Isms] draft updates > Hi, > > I intend to publish an updated draft before the document cut-off for > Dublin. If I can, I will publish it earlier than that. > > I just changed divisions in my company. I am heading off to China for > a month starting June 10. The next two weeks I will be pretty busy > preparing for China. I expect to have some, possibly limited, time in > China to work on the ISMS drafts and other drafts I am editing, plus > any chair work I need to do. > > I started looking at the drafts to see what should be updated relative > to the ongoing discussion. Unfortunately, I am not finding a lot to > update. The drafts represent what I believe has been, and remains WG > consensus - that the format of the LCD is implementation-dependent, > and processing related to the LCD and SSH remains > implementation-dependent. Most of what we are talking about is some > abstractions and possible details of implementation-dependent stuff. I > think it has been valuable for understanding how the problem can be > addressed by people developing implementation-dependent designs. > > I do think it would be really unfortunate to not have some of the > current discussion summarized in the document, possible in an > "implementor recommendations" section. But the discussion has > meandered quite a bit, and has had a lot of RFC3411-incorrect > explanations, so I'm not quite sure what to write at this time. > Cleaned-up proposed text is welcome. > > It might be helpful to include an SSHTM-MIB as a sample LCD, but we've > started this and removed it and started this again and removed it. We > have not reached consensus what needs to be in the LCD. Even in the > current discussion, we have not reached any consensus on what the > "pointer into SSH config" must be able to represent. > > While the current discussion seems to be reaching consensus that > storing client credentials is acceptable for establishing a connection > for notifications, what those credentials look like are strictly > implementation-dependent. The standardized part of notification config > (target and params-mib config) is already described in the TSM > document, and the secshell document says that the SSH and LCD details > are implementation-dependent. > > As far as the documents are concerned, I don't understand the edits. > We need to drive the discussion to be more specific about how the text > in the documents should be changed. > > I am not sure whether reusing an existing connection makes sense any > more. It has been WG consensus, but supporting both client credentials > and reuse adds unnecessary complexity. especially given some of > Pasis's comments. I am also not sure how all this works for informs > between two manager applications or between two agents, or if that > makes any difference. > > I think the WG needs to go through the documents closely, with RFC3411 > modularity in mind, to determine what new text is needed, what text > needs to be changed, and whether the proposed approaches work in all > instances. > > dbh > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, May 26, 2008 5:00 AM > > To: David Harrington > > Subject: Re: FYI: my priorities > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 5 06:44:11 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE7B28C17A; Thu, 5 Jun 2008 06:44:11 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3090F3A6856 for ; Thu, 5 Jun 2008 06:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwkIb9PMAY+q for ; Thu, 5 Jun 2008 06:44:09 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id E9ED728C109 for ; Thu, 5 Jun 2008 06:44:08 -0700 (PDT) X-Trace: 125724743/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.122.151 X-SBRS: None X-RemoteIP: 62.188.122.151 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAAaKR0g+vHqX/2dsb2JhbACLb6QTAw X-IronPort-AV: E=Sophos;i="4.27,595,1204502400"; d="scan'208";a="125724743" X-IP-Direction: IN Received: from 1cust151.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.151]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2008 14:44:11 +0100 Message-ID: <010701c8c709$2c84e880$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <037201c8b070$85442300$0600a8c0@china.huawei.com><20080526085932.GA13279@elstar.local> <02a201c8bf97$3abf4680$0600a8c0@china.huawei.com> Date: Thu, 5 Jun 2008 14:35:40 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: [Isms] securityName genesis was Re: draft updates X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David, My third source of confusion, which I do not think falls within the existing issues. Is the securityName always derived, by one or two mappings, from the SSH client user name, and never from a name used by the SSH Server? I ask, because the current I-D clearly conveys to me the former, and the discussions we have been having - well, you, Wes and Juergen have been having while I have been digesting - seem to open the possibility that some server identifier could be the basis. Again, clarify the principle and I will go through the text again. Tom Petch ----- Original Message ----- From: "David Harrington" To: Cc: Sent: Tuesday, May 27, 2008 3:16 AM Subject: [Isms] draft updates > Hi, > > I intend to publish an updated draft before the document cut-off for > Dublin. If I can, I will publish it earlier than that. > > I just changed divisions in my company. I am heading off to China for > a month starting June 10. The next two weeks I will be pretty busy > preparing for China. I expect to have some, possibly limited, time in > China to work on the ISMS drafts and other drafts I am editing, plus > any chair work I need to do. > > I started looking at the drafts to see what should be updated relative > to the ongoing discussion. Unfortunately, I am not finding a lot to > update. The drafts represent what I believe has been, and remains WG > consensus - that the format of the LCD is implementation-dependent, > and processing related to the LCD and SSH remains > implementation-dependent. Most of what we are talking about is some > abstractions and possible details of implementation-dependent stuff. I > think it has been valuable for understanding how the problem can be > addressed by people developing implementation-dependent designs. > > I do think it would be really unfortunate to not have some of the > current discussion summarized in the document, possible in an > "implementor recommendations" section. But the discussion has > meandered quite a bit, and has had a lot of RFC3411-incorrect > explanations, so I'm not quite sure what to write at this time. > Cleaned-up proposed text is welcome. > > It might be helpful to include an SSHTM-MIB as a sample LCD, but we've > started this and removed it and started this again and removed it. We > have not reached consensus what needs to be in the LCD. Even in the > current discussion, we have not reached any consensus on what the > "pointer into SSH config" must be able to represent. > > While the current discussion seems to be reaching consensus that > storing client credentials is acceptable for establishing a connection > for notifications, what those credentials look like are strictly > implementation-dependent. The standardized part of notification config > (target and params-mib config) is already described in the TSM > document, and the secshell document says that the SSH and LCD details > are implementation-dependent. > > As far as the documents are concerned, I don't understand the edits. > We need to drive the discussion to be more specific about how the text > in the documents should be changed. > > I am not sure whether reusing an existing connection makes sense any > more. It has been WG consensus, but supporting both client credentials > and reuse adds unnecessary complexity. especially given some of > Pasis's comments. I am also not sure how all this works for informs > between two manager applications or between two agents, or if that > makes any difference. > > I think the WG needs to go through the documents closely, with RFC3411 > modularity in mind, to determine what new text is needed, what text > needs to be changed, and whether the proposed approaches work in all > instances. > > dbh > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, May 26, 2008 5:00 AM > > To: David Harrington > > Subject: Re: FYI: my priorities > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 5 06:44:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F79528C1BE; Thu, 5 Jun 2008 06:44:12 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E87728C17A for ; Thu, 5 Jun 2008 06:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcGWtf16BiND for ; Thu, 5 Jun 2008 06:44:10 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 8DBF13A68C9 for ; Thu, 5 Jun 2008 06:44:09 -0700 (PDT) X-Trace: 125724767/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.122.151 X-SBRS: None X-RemoteIP: 62.188.122.151 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAAaKR0g+vHqX/2dsb2JhbACLb6QTAw X-IronPort-AV: E=Sophos;i="4.27,595,1204502400"; d="scan'208";a="125724767" X-IP-Direction: IN Received: from 1cust151.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.151]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2008 14:44:13 +0100 Message-ID: <010801c8c709$2da0b8c0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <037201c8b070$85442300$0600a8c0@china.huawei.com><20080526085932.GA13279@elstar.local> <02a201c8bf97$3abf4680$0600a8c0@china.huawei.com> Date: Thu, 5 Jun 2008 14:37:01 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: [Isms] tmStateReference wasRe: draft updates X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David, Re-reading SSHTM, I am uncertain about tmStateReference. Is it in any way dependent on a specific message, or is it solely about the session? And does it identify an instantion of a specific session? What drives the question is session reuse, when a Response must use the same session and, between Request and Response in a CR, the session has been taken down and a fresh one has been set up with identical target index, as defined in eg SSHTM s5.2. It would seem to me that the tmStateReference MUST contain a unique session identifier otherwise it is impossible to tell if it is the same session, but that is not what SSHTM says. And, less clearly, SSHTM seems to use tmStateReference as if it referred to any session with a given target index rather than a single instantiation. Can you clarify how you see session reuse working when eg 1) CG sends reqA, reqB, CR receives both, sends respA 2) session fails, is re-established, CG sends reqC 3) CR generates respB, respC; former must not be sent, latter can be. It would seem that tmStateReference for respB must be distinct from tmStateReference for respC. Of course, we could rely on the pseudo-random generation of TCP source ports for the tmTransportAddress to distinguish them but that would seem to me to be insecure. Tom Petch ----- Original Message ----- From: "David Harrington" To: Cc: Sent: Tuesday, May 27, 2008 3:16 AM Subject: [Isms] draft updates > Hi, > > I intend to publish an updated draft before the document cut-off for > Dublin. If I can, I will publish it earlier than that. > > I just changed divisions in my company. I am heading off to China for > a month starting June 10. The next two weeks I will be pretty busy > preparing for China. I expect to have some, possibly limited, time in > China to work on the ISMS drafts and other drafts I am editing, plus > any chair work I need to do. > > I started looking at the drafts to see what should be updated relative > to the ongoing discussion. Unfortunately, I am not finding a lot to > update. The drafts represent what I believe has been, and remains WG > consensus - that the format of the LCD is implementation-dependent, > and processing related to the LCD and SSH remains > implementation-dependent. Most of what we are talking about is some > abstractions and possible details of implementation-dependent stuff. I > think it has been valuable for understanding how the problem can be > addressed by people developing implementation-dependent designs. > > I do think it would be really unfortunate to not have some of the > current discussion summarized in the document, possible in an > "implementor recommendations" section. But the discussion has > meandered quite a bit, and has had a lot of RFC3411-incorrect > explanations, so I'm not quite sure what to write at this time. > Cleaned-up proposed text is welcome. > > It might be helpful to include an SSHTM-MIB as a sample LCD, but we've > started this and removed it and started this again and removed it. We > have not reached consensus what needs to be in the LCD. Even in the > current discussion, we have not reached any consensus on what the > "pointer into SSH config" must be able to represent. > > While the current discussion seems to be reaching consensus that > storing client credentials is acceptable for establishing a connection > for notifications, what those credentials look like are strictly > implementation-dependent. The standardized part of notification config > (target and params-mib config) is already described in the TSM > document, and the secshell document says that the SSH and LCD details > are implementation-dependent. > > As far as the documents are concerned, I don't understand the edits. > We need to drive the discussion to be more specific about how the text > in the documents should be changed. > > I am not sure whether reusing an existing connection makes sense any > more. It has been WG consensus, but supporting both client credentials > and reuse adds unnecessary complexity. especially given some of > Pasis's comments. I am also not sure how all this works for informs > between two manager applications or between two agents, or if that > makes any difference. > > I think the WG needs to go through the documents closely, with RFC3411 > modularity in mind, to determine what new text is needed, what text > needs to be changed, and whether the proposed approaches work in all > instances. > > dbh > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, May 26, 2008 5:00 AM > > To: David Harrington > > Subject: Re: FYI: my priorities > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 5 07:34:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A003A6D28; Thu, 5 Jun 2008 07:34:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543FB3A6D26 for ; Thu, 5 Jun 2008 07:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87Snz+WW0-od for ; Thu, 5 Jun 2008 07:34:13 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 906223A6D3D for ; Thu, 5 Jun 2008 07:33:57 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id aCUi1Z0070QkzPwA60FR00; Thu, 05 Jun 2008 14:34:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id aEZp1Z00B4HwxpC8N00000; Thu, 05 Jun 2008 14:33:51 +0000 X-Authority-Analysis: v=1.0 c=1 a=ptziyY9Tk7UA:10 a=EGi5_cgm2ewA:10 a=iQamxCgH9Jv1nGPG3GMA:9 a=e3wt3RBMyau3uE3gZhUA:7 a=f6C6JcnxhOEW_KS-DzYt6CFdS0oA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , References: <037201c8b070$85442300$0600a8c0@china.huawei.com><20080526085932.GA13279@elstar.local> <02a201c8bf97$3abf4680$0600a8c0@china.huawei.com> <010601c8c709$2ab817c0$0601a8c0@allison> Date: Thu, 5 Jun 2008 10:33:49 -0400 Message-ID: <02a701c8c719$2cb57b20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <010601c8c709$2ab817c0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjHEkArkEXe7RWcR9qMGiD7bxKSNgABVd8g Cc: isms@ietf.org Subject: Re: [Isms] securityName mapping was Re: draft updates X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Tom, comments inline. > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Thursday, June 05, 2008 8:31 AM > To: David Harrington; j.schoenwaelder@jacobs-university.de > Cc: isms@ietf.org > Subject: securityName mapping was Re: [Isms] draft updates > > David > > This is related to but I think distinct from issues 2 and 3. > > When we discussed securityName last year, I understood that > - the Security Model always determines the securityName and > not the Transport > Model. That is correct. > - there are (consequently) two mappings involved, Yes. > between > identifier used by the > secure transport and proposed securityName from the Transport > Model, the "proposed securityName from the Transport Model" is the tmSecurityname in the tmStateReference > and between > the proposed securityName from the Transport Model and the > securityName selected > by Security Model. Yes. (and for different securitymodels, there may be mappings from other things to securityName; for USM, the proposed securityName comes from the securityParameters from the SNMPv3 message (IIRC); for "community" security models, the proposed security name comes from the community string.) > Of course both mappings can be the > identity mapping. > > Is this intended to be what SSHTM describes? SSH TM should describe the SSH-to-tmSecurityName mapping. TSM should describe the tmSecurityName-to-securityName mapping. There is some ambiguity because we have not defined an LCD standard, and have not provided a non-standard example LCD; the value of tmSecurityName is also likely to be stored in the LCD, as part of the index into the LCD, so the mappings to/from tmSecurityName might also be done using the LCD. > > Where does tmSecurityName fit into the three identifiers? > > I ask because the usage seems not quite consistent. If we > agree on what should > be happening, then I will trawl the I-D again for wording > which I think > inconsistent, but want to establish the principle first. I think the amount of confusion we have had in our discussions stems a great deal from not having a sample LCD, and I think we should define a sample LCD format (as a MIB module) so people can really see the data and how it passed between models. > > The simplest case is is a CR receiving a request, so let's > focus on that first. > > Tom Petch > > > ----- Original Message ----- > From: "David Harrington" > To: > Cc: > Sent: Tuesday, May 27, 2008 3:16 AM > Subject: [Isms] draft updates > > > > Hi, > > > > I intend to publish an updated draft before the document cut-off for > > Dublin. If I can, I will publish it earlier than that. > > > > I just changed divisions in my company. I am heading off to > China for > > a month starting June 10. The next two weeks I will be pretty busy > > preparing for China. I expect to have some, possibly > limited, time in > > China to work on the ISMS drafts and other drafts I am editing, plus > > any chair work I need to do. > > > > I started looking at the drafts to see what should be > updated relative > > to the ongoing discussion. Unfortunately, I am not finding a lot to > > update. The drafts represent what I believe has been, and remains WG > > consensus - that the format of the LCD is implementation-dependent, > > and processing related to the LCD and SSH remains > > implementation-dependent. Most of what we are talking about is some > > abstractions and possible details of > implementation-dependent stuff. I > > think it has been valuable for understanding how the problem can be > > addressed by people developing implementation-dependent designs. > > > > I do think it would be really unfortunate to not have some of the > > current discussion summarized in the document, possible in an > > "implementor recommendations" section. But the discussion has > > meandered quite a bit, and has had a lot of RFC3411-incorrect > > explanations, so I'm not quite sure what to write at this time. > > Cleaned-up proposed text is welcome. > > > > It might be helpful to include an SSHTM-MIB as a sample > LCD, but we've > > started this and removed it and started this again and > removed it. We > > have not reached consensus what needs to be in the LCD. Even in the > > current discussion, we have not reached any consensus on what the > > "pointer into SSH config" must be able to represent. > > > > While the current discussion seems to be reaching consensus that > > storing client credentials is acceptable for establishing a > connection > > for notifications, what those credentials look like are strictly > > implementation-dependent. The standardized part of > notification config > > (target and params-mib config) is already described in the TSM > > document, and the secshell document says that the SSH and > LCD details > > are implementation-dependent. > > > > As far as the documents are concerned, I don't understand the edits. > > We need to drive the discussion to be more specific about > how the text > > in the documents should be changed. > > > > I am not sure whether reusing an existing connection makes sense any > > more. It has been WG consensus, but supporting both client > credentials > > and reuse adds unnecessary complexity. especially given some of > > Pasis's comments. I am also not sure how all this works for informs > > between two manager applications or between two agents, or if that > > makes any difference. > > > > I think the WG needs to go through the documents closely, > with RFC3411 > > modularity in mind, to determine what new text is needed, what text > > needs to be changed, and whether the proposed approaches work in all > > instances. > > > > dbh > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, May 26, 2008 5:00 AM > > > To: David Harrington > > > Subject: Re: FYI: my priorities > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 5 12:07:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676FD28C17A; Thu, 5 Jun 2008 12:07:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439463A6CC9; Thu, 5 Jun 2008 12:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULzhM+BDaisc; Thu, 5 Jun 2008 12:07:02 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id EEBF428C23E; Thu, 5 Jun 2008 12:05:35 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m55J5SUj012442; Thu, 5 Jun 2008 22:05:28 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m55J5SLq012438; Thu, 5 Jun 2008 22:05:28 +0300 Date: Thu, 5 Jun 2008 22:05:28 +0300 (EEST) From: Pekka Savola To: Phil Shafer In-Reply-To: <200806031619.m53GJduY077171@idle.juniper.net> Message-ID: References: <200806031619.m53GJduY077171@idle.juniper.net> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.93/6816/Fri Apr 18 03:41:09 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, 3 Jun 2008, Phil Shafer wrote: > "David Harrington" writes: >> SNMP can send notifications when an event happens, without having to >> wait for a manager to initiate a connection first. This distinction >> can be important, especially during startup. > > Sure, but in practice, startup is a painful time to send notifications, > since the delays of interface bringup and learning routes may mean > your manager is unreachable. Waiting for a connection turns out > to be more useful than firing off packets into nowhere. FWIW my take on this is: We (our network) are happy enough with SNMP traps over UDP from the security (confidentiality etc.) perspective. I realize that some other operators, especially if their borders are not easily definable or have equipment all over the globe without virtual management interfaces (through tunnels etc.) may have a different perspective. The main problem with SNMP traps, syslog, etc. is that when a system reboots or a line goes down, they get lost. If the amount of loss is infrequent (every event does not cause loss), you can live with it as long as you can verify the correct operations using other, reliable means. On the other hand, if every event caused significant loss of information, the manual procedures would become more burdensome and you would need to use a different management model (e.g. almost exclusively polling based) to get the job done. This is to say that traps/notifications over TCP is not to _us_ very interesting if it doesn't also do something else -- i.e. make practically certain that all traps/notifications will in fact be delivered. If we examine how unreliable syslog can be made to work we may learn something for other protocols. Mostly unreliable syslog is fine. Some implementations AFAIK buffer syslog data and don't send it if there is no route to the destination. That helps a bit but not much if you're using default routes your network. But because syslog is also stored locally, you can either 1) go check the local syslog manually if in doubt, or 2) configure scripts to pull in devices' local syslog automatically after certain kinds of events to ensure that the syslog data you have should be complete. That makes me think that (unless this is already being done) an SNMP agent should also store traps/notifications locally at least for the duration of O(days), and that a management system could poll them after the fact to synchronize notification "state". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 5 13:12:21 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2FD3A68ED; Thu, 5 Jun 2008 13:12:21 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0143A67CE for ; Thu, 5 Jun 2008 13:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxUDGv3K3EVy for ; Thu, 5 Jun 2008 13:12:10 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1CE563A69CD for ; Thu, 5 Jun 2008 13:12:10 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m55KBdgP013925; Thu, 5 Jun 2008 15:11:47 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 23:11:45 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 23:11:45 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 23:11:44 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72D5486F@vaebe104.NOE.Nokia.com> In-Reply-To: <019501c8c65d$fc32b960$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue#11 Reuse Thread-Index: Aci/wn03mD491Uk2THSH7tDHFBtirwGXlpcQAA0nqoAAO9UnkA== References: <20080527062527.GC16024@elstar.local> <1696498986EFEC4D9153717DA325CB72D0D4BE@vaebe104.NOE.Nokia.com> <019501c8c65d$fc32b960$0600a8c0@china.huawei.com> From: To: , , X-OriginalArrivalTime: 05 Jun 2008 20:11:45.0427 (UTC) FILETIME=[60B77E30:01C8C748] X-Nokia-AV: Clean Subject: Re: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington wrote: > I believe the WG reached consensus to permit reuse of an existing > session, even if it was initially established in the opposite > direction, as well as permitting agent initiation of a session. I have nothing against this, if we come up with text specifying how it works. But as I wrote earlier, if transportAddress contains both the IP address and TCP port number, and we require both of them to match when determining whether a session already exists, it seems reusing a session won't usually happen. If the port numbers are required to match, for "reuse in opposite direction" to occur, the administrator configuring the notification target has to know the source TCP port that will be used (or was used) for the "inbound" connection (initiated by the notification receiver). This actually would be the case when the notification receiver opens a connection, configures the TARGET-MIB (in effect "subscribing" to some notifications), and keeps the connection open. (So perhaps it's not an unrealistic case.) But it doesn't seem to really work for the case where notification target configuration is static -- unless we specify a different way to compare the transportAddresses (e.g. ignore the port number, compare just the IP address part), or map the notification targets to existing connections. > The proposed text contains statements like "notifications can't be > sent over a transport session opened by the other end." The port we > will be sending to will already be listening, because it already > listens for responses. And the transport model doesn't know what > type of operation is contained in a message; it simply accepts an > outgoing wholeMessage from the MPM, or it simply accepts the > wholeMsg from SSH and passes it to the MPM, which detrmines which > type of operation is involved. So the SSH layer should not care > which operation type is contained in the message. I agree that the SSH layer should not care. BTW, the TCP transport mapping (RFC 3430) has this constraint -- but I guess it doesn't really inspect the operation type either..? > Unless of course, we think that SNMP command generator/responder > applications run over a different SSH service or a different SSH > subsystem than SNMP notification origination and notification receiver > applications. The RFC3411 architecture was designed such that an > entity is an entity, and which applications they support internally is > an implementation decision. The transport model shouldn't care, and > should be able to use the same SSH service/subsystem for all SNMP > applications. I agree, I don't think we need to assume separate SSH subsystems. > -- > > While we have been discussing how to specify the agent as SSH client, > we asked the OPS-AREA and OPS-DIR operators for feedback on how they > want to do configuration/key distribution for SSH client credentials. > My impression of the feedback is that a MIB is not called to hold the > keys, but others should review the discussion as well. > > Part of the discussion there (parts of which I copied here) suggests > that a subscribe-style notification like that used in netconf might > also meet operators' needs for SNMP/SSH. If that is the case, then we > could avoid having the SNMP agent act as an SSH client. We might have > to provide some type of non-SSH request-for-SSH-session capability > (callhome), such as a USM or noAuthNoPriv notification to the manager. > I think we could design a solution where the "agent" can always be the > SSH server, never the client. This would be more consistent with > current SSH deployment, possibly simplify our processing (except the > callhome and possibly informs), and enable us to always use both > server and client authentication. > > I think we should discuss this before making changes that force this > one way or the other. I agree this would be simpler (if it's otherwise an acceptable solution). It would need a way how the to-be-sent notifications are mapped to the existing connections that were initiated by the notification receiver. Would requiring that the notification receiver updates the transportAddress in TARGET-MIB when he connects (in effect, "subscribing" to notifications when a session starts) be acceptable? Another way would be to ignore the TCP port number when determining whether a session exists (just check securityName, transportDomain, IP address, and securityLevel) -- although that would complicate running multiple SNMP managers on the same host (and I haven't thought about NATs yet). Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 6 09:01:53 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E723A6A12; Fri, 6 Jun 2008 09:01:53 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E7E3A6A12 for ; Fri, 6 Jun 2008 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L2aAW+GRpzq for ; Fri, 6 Jun 2008 09:01:51 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 0E8E93A6840 for ; Fri, 6 Jun 2008 09:01:50 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA02.westchester.pa.mail.comcast.net with comcast id afwu1Z0090Fqzac5200v00; Fri, 06 Jun 2008 16:01:59 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id ag1y1Z0064HwxpC3U00000; Fri, 06 Jun 2008 16:01:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=abe5jlwL1A8A:10 a=LyrTWiuPIYU3A7sl8t0A:9 a=C24A5tC-Mls_OV849ZpbT0Ge9iEA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Pekka Savola'" , "'Phil Shafer'" References: <200806031619.m53GJduY077171@idle.juniper.net> Date: Fri, 6 Jun 2008 12:01:54 -0400 Message-ID: <036301c8c7ee$a4be7bf0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjHPySKoLfeACBXSLaPAiCDCMMWSwApDcAg Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, RFC3014 "Notification Log MIB" provides a pollable log of SNMP traps, and statistics that could be checked to see if the manager and agent are in sync. The Notification Log MIB also allows for aggregators, so all trap-generation devices do not need to keep historical logs; the Notification Log MIB can be implemented in a node that has greater storage capacity. If ISMS adopts a subscription-style approach, we could recommend or require the Notification Log MIB be used as the buffering and replay mechanism using a polling approach. dbh > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, June 05, 2008 3:05 PM > To: Phil Shafer > Cc: David Harrington; ops-dir@ietf.org; isms@ietf.org; 'OPS Area' > Subject: Re: [OPS-DIR] SNMP notification configuration > > On Tue, 3 Jun 2008, Phil Shafer wrote: > > "David Harrington" writes: > >> SNMP can send notifications when an event happens, without > having to > >> wait for a manager to initiate a connection first. This distinction > >> can be important, especially during startup. > > > > Sure, but in practice, startup is a painful time to send > notifications, > > since the delays of interface bringup and learning routes may mean > > your manager is unreachable. Waiting for a connection turns out > > to be more useful than firing off packets into nowhere. > > FWIW my take on this is: > > We (our network) are happy enough with SNMP traps over UDP from the > security (confidentiality etc.) perspective. I realize that some > other operators, especially if their borders are not easily definable > or have equipment all over the globe without virtual management > interfaces (through tunnels etc.) may have a different perspective. > > The main problem with SNMP traps, syslog, etc. is that when a system > reboots or a line goes down, they get lost. If the amount of loss is > infrequent (every event does not cause loss), you can live with it as > long as you can verify the correct operations using other, reliable > means. On the other hand, if every event caused significant loss of > information, the manual procedures would become more burdensome and > you would need to use a different management model (e.g. almost > exclusively polling based) to get the job done. > > This is to say that traps/notifications over TCP is not to _us_ very > interesting if it doesn't also do something else -- i.e. make > practically certain that all traps/notifications will in fact be > delivered. > > If we examine how unreliable syslog can be made to work we may learn > something for other protocols. > > Mostly unreliable syslog is fine. Some implementations AFAIK buffer > syslog data and don't send it if there is no route to the > destination. > That helps a bit but not much if you're using default routes your > network. But because syslog is also stored locally, you can > either 1) > go check the local syslog manually if in doubt, or 2) configure > scripts to pull in devices' local syslog automatically after certain > kinds of events to ensure that the syslog data you have should be > complete. > > That makes me think that (unless this is already being done) an SNMP > agent should also store traps/notifications locally at least for the > duration of O(days), and that a management system could poll them > after the fact to synchronize notification "state". > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 6 09:02:08 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5A43A6D8E; Fri, 6 Jun 2008 09:02:08 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020A328C103 for ; Fri, 6 Jun 2008 09:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkjviUIOMpK2 for ; Fri, 6 Jun 2008 09:02:07 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id D360D3A6D83 for ; Fri, 6 Jun 2008 09:02:06 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA06.westchester.pa.mail.comcast.net with comcast id afyx1Z00L0cZkys5600d00; Fri, 06 Jun 2008 16:02:16 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id ag2C1Z0014HwxpC3W00000; Fri, 06 Jun 2008 16:02:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=vEeLAe6aKXYA:10 a=xSGO0-sLpgVAnpTTVrEA:9 a=sn-nzGZnGWEWzfpY1TMgHHPwgtAA:4 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: Date: Fri, 6 Jun 2008 12:02:08 -0400 Message-ID: <036401c8c7ee$aca6b710$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjHPySKoLfeACBXSLaPAiCDCMMWSwAr4KVA Subject: [Isms] FW: [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, June 05, 2008 3:05 PM To: Phil Shafer Cc: David Harrington; ops-dir@ietf.org; isms@ietf.org; 'OPS Area' Subject: Re: [OPS-DIR] SNMP notification configuration On Tue, 3 Jun 2008, Phil Shafer wrote: > "David Harrington" writes: >> SNMP can send notifications when an event happens, without having to >> wait for a manager to initiate a connection first. This distinction >> can be important, especially during startup. > > Sure, but in practice, startup is a painful time to send notifications, > since the delays of interface bringup and learning routes may mean > your manager is unreachable. Waiting for a connection turns out > to be more useful than firing off packets into nowhere. FWIW my take on this is: We (our network) are happy enough with SNMP traps over UDP from the security (confidentiality etc.) perspective. I realize that some other operators, especially if their borders are not easily definable or have equipment all over the globe without virtual management interfaces (through tunnels etc.) may have a different perspective. The main problem with SNMP traps, syslog, etc. is that when a system reboots or a line goes down, they get lost. If the amount of loss is infrequent (every event does not cause loss), you can live with it as long as you can verify the correct operations using other, reliable means. On the other hand, if every event caused significant loss of information, the manual procedures would become more burdensome and you would need to use a different management model (e.g. almost exclusively polling based) to get the job done. This is to say that traps/notifications over TCP is not to _us_ very interesting if it doesn't also do something else -- i.e. make practically certain that all traps/notifications will in fact be delivered. If we examine how unreliable syslog can be made to work we may learn something for other protocols. Mostly unreliable syslog is fine. Some implementations AFAIK buffer syslog data and don't send it if there is no route to the destination. That helps a bit but not much if you're using default routes your network. But because syslog is also stored locally, you can either 1) go check the local syslog manually if in doubt, or 2) configure scripts to pull in devices' local syslog automatically after certain kinds of events to ensure that the syslog data you have should be complete. That makes me think that (unless this is already being done) an SNMP agent should also store traps/notifications locally at least for the duration of O(days), and that a management system could poll them after the fact to synchronize notification "state". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jun 9 04:08:44 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196DC3A6C3F; Mon, 9 Jun 2008 04:08:44 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5FB628C0EC for ; Mon, 9 Jun 2008 04:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9YXUPm9LNSF for ; Mon, 9 Jun 2008 04:08:41 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id EA3103A6C3C for ; Mon, 9 Jun 2008 04:08:40 -0700 (PDT) X-Trace: 127762664/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.50.129 X-SBRS: None X-RemoteIP: 213.116.50.129 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAO+rTEjVdDKB/2dsb2JhbACLc6JwAw X-IronPort-AV: E=Sophos;i="4.27,612,1204502400"; d="scan'208";a="127762664" X-IP-Direction: IN Received: from 1cust129.tnt101.lnd4.gbr.da.uu.net (HELO allison) ([213.116.50.129]) by smtp.pipex.tiscali.co.uk with SMTP; 09 Jun 2008 12:08:54 +0100 Message-ID: <029601c8ca18$21ea7ae0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <037201c8b070$85442300$0600a8c0@china.huawei.com><20080526085932.GA13279@elstar.local> <02a201c8bf97$3abf4680$0600a8c0@china.huawei.com> <010601c8c709$2ab817c0$0601a8c0@allison> <02a701c8c719$2cb57b20$0600a8c0@china.huawei.com> Date: Mon, 9 Jun 2008 12:02:53 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] securityName mapping was Re: draft updates X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Towards the end; some suggested amendments and a further issue. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; Cc: Sent: Thursday, June 05, 2008 4:33 PM Subject: RE: securityName mapping was Re: [Isms] draft updates > Hi Tom, > > comments inline. > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Thursday, June 05, 2008 8:31 AM > > To: David Harrington; j.schoenwaelder@jacobs-university.de > > Cc: isms@ietf.org > > Subject: securityName mapping was Re: [Isms] draft updates > > > > David > > > > This is related to but I think distinct from issues 2 and 3. > > > > When we discussed securityName last year, I understood that > > - the Security Model always determines the securityName and > > not the Transport > > Model. > > That is correct. > > > - there are (consequently) two mappings involved, > > Yes. > > > between > > identifier used by the > > secure transport and proposed securityName from the Transport > > Model, > > the "proposed securityName from the Transport Model" is the > tmSecurityname in the tmStateReference > > > and between > > the proposed securityName from the Transport Model and the > > securityName selected > > by Security Model. > > Yes. (and for different securitymodels, there may be mappings from > other things to securityName; for USM, the proposed securityName comes > from the securityParameters from the SNMPv3 message (IIRC); for > "community" security models, the proposed security name comes from the > community string.) > > > Of course both mappings can be the > > identity mapping. > > > > Is this intended to be what SSHTM describes? > > SSH TM should describe the SSH-to-tmSecurityName mapping. > TSM should describe the tmSecurityName-to-securityName mapping. > Good, we are on the same wavelength. Consequently, 4.2 I would like an explicit statement here, about the roles of TM and SM, for those whose memory of the tmsm I-D may be slipping:-). Perhaps, "When a connection is received, the SSH Transport Model places a proposed 'securityName' in the tmSecurityName field. The final decision on what securityName to use for a message is taken by the Security Model, based on all the information it has available to it" 3.1.1 3) " SSH provides for both verification of the identity of the SSH server and verification of the identity of the SSH client - the principal on whose behalf a received SNMP message claims to have been generated." I have puzzled over this but think that it is ok. The identifier may change, from transport to SSHTM to Security Model via mappings, but the underlying identity remains the same so I think it correct to equate SSH identifier with principal, as you do. This crops up elsewhere, eg 3.1.2. 3.2. Security Parameter Passing "For incoming messages, SSH-specific security parameters are translated by the transport model into security parameters independent of the transport and security models." This doesn't seem right. SSHTM starts the process, but it is the Security Model that has the last say on the securityName. I think that it is only SSH independent, not security model independent. And The Big(?) Issue. 3.1.6 "SSH sessions are uniquely identified within the SSH Transport Model by the combination of transportAddressType, transportAddress, securityName, and securityLevel associated with each session." I am going round on circles on this. At the application level, in a target MIB, sessions must be identifed by securityName since tmSecurityName is unknown. But here in the SSHTM, I think that this is tmSecurityName and not securityName. If I assume it is securityName and not tmSecurityName, then when a connection is received, SSHTM knows the tmSecurityName but cannot know the securityName until the SecurityModel has performed its processing. The cache would also need to contain the securityName in order to perform the match for an outbound message, perhaps inserted by the Security Model when it determines it. And this gets more worrying since different messages over the same SSH connection could be different SNMP versions and the Security Model then determines a different securityName for different messages over the same connection (which the SNMP v2c SM cannot insert into the cache since it does not know about the cache). And, since the mapping from tmSecurityName to SSH identifier is under the remit of the SSH TM, I think that the SSH TM needs to hang on to the tmSecurityName in unaltered form for it to be able to communicate with SSH for outbound messages, ie the Transport Security Model cannot simply overwrite tmSecurityName with the securityName it determines. In 5.1, the references are to tmSecuirtyName, which I agree with, but in 5.2, this issue arises again; I think that it needs to be tmSecurityName and not securityName. It is complicated, allowing these mappings between SSH identifier, proposed securityName and securityName. My thinking is that the SSHTM cannot reliably know the securityName for an incoming session (nb not message) so references to securityName in this I-D should only arise to help readers understand that the Security Model performs a second mapping to it. Tom Petch > There is some ambiguity because we have not defined an LCD standard, > and have not provided a non-standard example LCD; the value of > tmSecurityName is also likely to be stored in the LCD, as part of the > index into the LCD, so the mappings to/from tmSecurityName might also > be done using the LCD. > > > > > Where does tmSecurityName fit into the three identifiers? > > > > I ask because the usage seems not quite consistent. If we > > agree on what should > > be happening, then I will trawl the I-D again for wording > > which I think > > inconsistent, but want to establish the principle first. > > I think the amount of confusion we have had in our discussions stems a > great deal from not having a sample LCD, and I think we should define > a sample LCD format (as a MIB module) so people can really see the > data and how it passed between models. > > > > > The simplest case is is a CR receiving a request, so let's > > focus on that first. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "David Harrington" > > To: _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 10 16:54:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102E93A68FD; Tue, 10 Jun 2008 16:54:40 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EF03A6884 for ; Tue, 10 Jun 2008 16:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm+ru+F6cd+7 for ; Tue, 10 Jun 2008 16:54:37 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 4B27F3A68FD for ; Tue, 10 Jun 2008 16:54:37 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m5ANsacu022872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 19:54:37 -0400 (EDT) Date: Tue, 10 Jun 2008 19:54:36 -0400 From: Jeffrey Hutzelman To: j.schoenwaelder@jacobs-university.de, Wes Hardaker Message-ID: <1F3BC2E24E6D0B034D5B550D@sirius.fac.cs.cmu.edu> In-Reply-To: <20080528085419.GA18649@elstar.local> References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> <20080528085419.GA18649@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, May 28, 2008 10:54:19 AM +0200 Juergen Schoenwaelder wrote: > As chair, I believe writing an SSH MIB module is not part of our > current charter. Nor do I. One of the reasons this is important is that participation in a working group is largely affefcted by who is interested in its chartered work. Since our chartered work does not include an SSH MIB module, it seems reasonable to assume that there are people who would be interested in participating in such work, if it happened, who are not currently involved in this working group. I would expect those to include members of the SSH community, including some of the many implementors of that protocol. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 10 17:31:51 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AB03A68B3; Tue, 10 Jun 2008 17:31:51 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB9A3A68A8 for ; Tue, 10 Jun 2008 17:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8X2glg3T164 for ; Tue, 10 Jun 2008 17:31:48 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 4EE953A68B3 for ; Tue, 10 Jun 2008 17:31:45 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m5B0VtlY023841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 20:31:55 -0400 (EDT) Date: Tue, 10 Jun 2008 20:31:55 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Wes Hardaker'" Message-ID: <4869322909BA2A1DB31507D7@sirius.fac.cs.cmu.edu> In-Reply-To: <01c801c8c26f$5675fab0$0600a8c0@china.huawei.com> References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> <20080528085419.GA18649@elstar.local> <041001c8c0df$4c2767b0$0600a8c0@china.huawei.com> <000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com> <002f01c8c106$6cf836f0$0600a8c0@china.huawei.com><483FE009.3040808@cisco.com> <01b001c8c25c$45509d70$0600a8c0@china.huawei.com> <01c801c8c26f$5675fab0$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Issue#2 - standardized mapping X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, May 30, 2008 12:08:01 PM -0400 David Harrington wrote: > I suggest that we add a mapping table to the SSHTM-MIB that includes > 1) an INDEX based on values of tmTransportDomain, tmTransportAddress, > tmSecurityName, and tmSecurityLevel from the tmStateReference, and > 2) an SSHIndex column that is an OCTET STRING, whose format and value > is implementation-dependent, but the DESCRIPTION would be that it is a > value that can be used in an implementation-dependent manner to refer > to an SSH set of credentials associated with a particular SSH entity. I would support adding such a table. > If we want to require SSHindex to be human-readable to make it easier > for operators, we can use an SnmpAdminString. I suspect that in reality, the underlying values will usually be either human-readable strings or small integers. This, storing this as an SnmpAdminString rather than as an OCTET STRING may be useful, especially if it will encourage user agents to display its value as a string. > If the same SSH identity might be authenticated using different > algorithms, then I would not be averse to adding columns that can > specify the authProtocol values, similar to usmUserTable. If the same SSH identity might be authentiated using different algorithms, then either you need multiple entries in the SSH LCD, or a single entry containing all the information necessary to support multiple algorithms. I don't think there's any reason to treat this situation specially at the SSHTM layer, any more than we would treat specially support for multiple ciphers or hash algorithms (the LCD may tell the SSH client which algorithms are acceptable, but this information is not passed as an additional parameter separate from the SSH LCD index). -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 10 17:46:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4566F3A69D3; Tue, 10 Jun 2008 17:46:28 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC03F3A68AB for ; Tue, 10 Jun 2008 17:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E+mAo5ypTpt for ; Tue, 10 Jun 2008 17:45:43 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 0C3123A68B3 for ; Tue, 10 Jun 2008 17:45:42 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m5B0jn8o024115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 20:45:49 -0400 (EDT) Date: Tue, 10 Jun 2008 20:45:49 -0400 From: Jeffrey Hutzelman To: Eliot Lear , David Harrington Message-ID: <2821D8438E54C82479FB5653@sirius.fac.cs.cmu.edu> In-Reply-To: <484011B9.5030805@cisco.com> References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> <20080528085419.GA18649@elstar.local> <041001c8c0df$4c2767b0$0600a8c0@china.huawei.com> <000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com> <002f01c8c106$6cf836f0$0600a8c0@china.huawei.com><483FE009.3040808@cisco.com> <01b101c8c25e$c411e2c0$0600a8c0@china.huawei.com> <484011B9.5030805@cisco.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Issue #9 - securing host keys X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, May 30, 2008 04:39:53 PM +0200 Eliot Lear wrote: > I do not think securing host keys necessarily needs to be accomplished > in this group, and I'm not even sure one should go to great effort to > discuss them in security considerations, except as it directly relates > to SNMP Agree. > On the other hand, the issue I had with host keys is that they do not > lend themselves easily today to autoconfiguration out of the box when > you have tens of thousands of devices. That is something X.509 might > prove to be more useful, and hence my interest in that area. Until very recently, I saw little point in doing further work on X.509 for SSH. There does not seem to be much interest in the SSH user community; most people seem to be perfectly happy with leap-of-faith, probably partly because it is convenient and partly because the ratio of information touting that convenient to information about the drawbacks is too high. There also has not been much interest in actually getting the work done; progress has been slow-to-stalled for several years. However, as I've reviewed and prepared replies to an earlier thread, I've come to the conclusion that there are probably a large number of organizations whose existing authentication infrastructure is based partly or entirely on X.509 certificates, and for that constituency, ISMS does not really meet its goal if SSH does not support use of X.509 certificates. As a result, I really would like to see someone pick up the SSH X.509 work, finish it, and get it published. IMHO that is not in scope for ISMS, but it is something that could be done by a hypothetical 'sshext' WG (along with preparation of SSH MIB's), or as an individual submission. Note that I don't think we've failed our charter here. Using SSH has allowed us to produce a system that will allow many or most operators to use their existing infrastructure for _user_(*) authentication (i.e. RADIUS), which we would not have gotten with TLS, and still provides a better story for _server_ authentication than does USM, since it is possible to use leap-of-faith or to collect a list of devices' SSH keys and distribute them to management stations, or to make use of existing Kerberos infrastructure (in both directions). -- Jeff (*) Please excuse the non-SNMP-oriented terminology; its use here allows me to make my point more clearly _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 10 18:03:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493AF3A68AB; Tue, 10 Jun 2008 18:03:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26153A6880 for ; Tue, 10 Jun 2008 18:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYfvrZf6ad7z for ; Tue, 10 Jun 2008 18:03:15 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id B8E843A67FA for ; Tue, 10 Jun 2008 18:03:15 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m5B13Xw7024544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 21:03:33 -0400 (EDT) Date: Tue, 10 Jun 2008 21:03:33 -0400 From: Jeffrey Hutzelman To: Pasi.Eronen@nokia.com, ietfdbh@comcast.net, j.schoenwaelder@jacobs-university.de, isms@ietf.org Message-ID: <3238781633A647C08AFD323D@sirius.fac.cs.cmu.edu> In-Reply-To: <1696498986EFEC4D9153717DA325CB72D5486F@vaebe104.NOE.Nokia.com> References: <20080527062527.GC16024@elstar.local> <1696498986EFEC4D9153717DA325CB72D0D4BE@vaebe104.NOE.Nokia.com> <019501c8c65d$fc32b960$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72D5486F@vaebe104.NOE.Nokia.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, June 05, 2008 11:11:44 PM +0300 Pasi.Eronen@nokia.com wrote: > If the port numbers are required to match, for "reuse in opposite > direction" to occur, the administrator configuring the notification > target has to know the source TCP port that will be used (or was used) > for the "inbound" connection (initiated by the notification receiver). > > This actually would be the case when the notification receiver opens > a connection, configures the TARGET-MIB (in effect "subscribing" to > some notifications), and keeps the connection open. (So perhaps > it's not an unrealistic case.) Yes, but if you're going to do that, chances are that you are not actually listening for incoming connections on that transport address (in fact, many systems make it difficult or impossible to both listen for incoming TCP connections on a port and originate outgoing TCP connections from that port). So you'd want that "subscription" to continue to exist only as long as the session is open. I think at one time we agreed in principle that there was nothing wrong with reusing an existing incoming session which happened to match, but I don't think there was a strong feeling that this was an important feature. Of course, I may be wrong, and I particular like the notion of a management station which opens an SSH session and "subscribes" to notifications to be sent back along the same session as long as it is open. Among other things, this would provide particular benefits for the scenario in which the management station is behind a NAT. >> Part of the discussion there (parts of which I copied here) suggests >> that a subscribe-style notification like that used in netconf might >> also meet operators' needs for SNMP/SSH. If that is the case, then we >> could avoid having the SNMP agent act as an SSH client. We might have >> to provide some type of non-SSH request-for-SSH-session capability >> (callhome), such as a USM or noAuthNoPriv notification to the manager. >> I think we could design a solution where the "agent" can always be the >> SSH server, never the client. This would be more consistent with >> current SSH deployment, possibly simplify our processing (except the >> callhome and possibly informs), and enable us to always use both >> server and client authentication. >> >> I think we should discuss this before making changes that force this >> one way or the other. > > I agree this would be simpler (if it's otherwise an acceptable > solution). > > It would need a way how the to-be-sent notifications are mapped to > the existing connections that were initiated by the notification > receiver. I don't make heavy use of SNMP as an operator, but I have enough experience with operatign and monitoring systems and services to have some idea what the common usage patterns probably are. I see two kinds of likely patterns: (1) A "dynamic" recipient, such as a management workstation that connects to a particular device and configures the device to send notifications to it as long as the user is interested in seeing them. (2) A "static" recipient, such as a collector to which all or many devices are configured to send notifications for the purpose of logging, monitoring, or statistics-gathering. The first kind benefits from a "subscription" model in which notifications are sent over the already-existing connection. In this case, it would be possible to simply set the transportAddress appropriately when setting up the "subscription", and allow it to match the existing session for as long as it exists. The main problem I see with this is that in practice, the interface between SNMP management software and the SSH client implementation is unlikely to allow the former to discover the local transport address of the outgoing SSH connection. I think I've said this before, but I'd love to see a special kind of transport address that can express "my existing session", which is really what this kind of client wants. Presumably this would be represented within an SNMP engine by a transportAddress containing the session's tmStateReference, at least conceptually, but I fear there is an abstraction violation here. It would be great if someone could figure out how to do this right. The second kind really can't reuse an existing session, because that would require the collector to maintain open SSH connections to every possible notification originator, which could potentially be tens or even hundreds of thousands of connections. Further, while all the NO's likely know who the collector is, the reverse may not be true. I believe that this kind of operation requires that notification originators be able to originate SSH connections. > Another way would be to ignore the TCP port number when determining > whether a session exists (just check securityName, transportDomain, IP > address, and securityLevel) -- although that would complicate running > multiple SNMP managers on the same host (and I haven't thought about > NATs yet). I don't think this is a good idea, for exactly the reasons you quote. It assumes not only that multiple connections from the same host are equivalent (which they probably are not), but that multiple connections from the same IP address are in fact from the same host, which unfortunately is often not the case either. I'd avoid this approach; it's asking for trouble. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 13 08:10:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31A43A695D; Fri, 13 Jun 2008 08:10:33 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D0B3A695D for ; Fri, 13 Jun 2008 08:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X73o5GF88Ehg for ; Fri, 13 Jun 2008 08:10:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 937663A6953 for ; Fri, 13 Jun 2008 08:10:30 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4014EC0020; Fri, 13 Jun 2008 17:11:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KgT-VvPFGXc3; Fri, 13 Jun 2008 17:10:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B254AC0011; Fri, 13 Jun 2008 17:10:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A4B835CF415; Fri, 13 Jun 2008 17:10:54 +0200 (CEST) Date: Fri, 13 Jun 2008 17:10:54 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20080613151054.GA5298@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , Pasi.Eronen@nokia.com, ietfdbh@comcast.net, isms@ietf.org References: <20080527062527.GC16024@elstar.local> <1696498986EFEC4D9153717DA325CB72D0D4BE@vaebe104.NOE.Nokia.com> <019501c8c65d$fc32b960$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72D5486F@vaebe104.NOE.Nokia.com> <3238781633A647C08AFD323D@sirius.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3238781633A647C08AFD323D@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Jun 10, 2008 at 09:03:33PM -0400, Jeffrey Hutzelman wrote: > I don't make heavy use of SNMP as an operator, but I have enough > experience with operatign and monitoring systems and services to have > some idea what the common usage patterns probably are. I see two kinds > of likely patterns: > > (1) A "dynamic" recipient, such as a management workstation that connects > to a particular device and configures the device to send notifications to > it as long as the user is interested in seeing them. > > (2) A "static" recipient, such as a collector to which all or many > devices are configured to send notifications for the purpose of logging, > monitoring, or statistics-gathering. > > The first kind benefits from a "subscription" model in which > notifications are sent over the already-existing connection. In this > case, it would be possible to simply set the transportAddress > appropriately when setting up the "subscription", and allow it to match > the existing session for as long as it exists. The main problem I see > with this is that in practice, the interface between SNMP management > software and the SSH client implementation is unlikely to allow the > former to discover the local transport address of the outgoing SSH > connection. There is some truth in this and clearly in the case of NATs, what you discover might not be what the other side sees/needs. > I think I've said this before, but I'd love to see a special > kind of transport address that can express "my existing session", which > is really what this kind of client wants. Presumably this would be > represented within an SNMP engine by a transportAddress containing the > session's tmStateReference, at least conceptually, but I fear there is an > abstraction violation here. It would be great if someone could figure > out how to do this right. Associated to this is a need for garbage collection. If the session goes away, we likely want the notification target subscription(s) pointing to the session also to go away. > The second kind really can't reuse an existing session, because that > would require the collector to maintain open SSH connections to every > possible notification originator, which could potentially be tens or even > hundreds of thousands of connections. Further, while all the NO's likely > know who the collector is, the reverse may not be true. I believe that > this kind of operation requires that notification originators be able to > originate SSH connections. I agree. And given the tradition of SNMP always using pattern (2), I believe we must support (2) while pattern (1) sounds like a nice to have new feature if someone figures out how to make subscription and garbage collection of subscriptions work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 13 08:21:14 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA11F3A6829; Fri, 13 Jun 2008 08:21:14 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94F23A6829 for ; Fri, 13 Jun 2008 08:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjk4PbB46i8l for ; Fri, 13 Jun 2008 08:21:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B66743A6825 for ; Fri, 13 Jun 2008 08:21:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204498800"; d="scan'208";a="11636116" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Jun 2008 17:21:32 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5DFLWMv000695; Fri, 13 Jun 2008 17:21:32 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5DFLWCi028057; Fri, 13 Jun 2008 15:21:32 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:21:32 +0200 Received: from adsl-247-3-fixip.tiscali.ch ([10.61.64.91]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 17:21:31 +0200 Message-ID: <4852907B.8090404@cisco.com> Date: Fri, 13 Jun 2008 17:21:31 +0200 From: Eliot Lear User-Agent: Thunderbird 3.0a2pre (Macintosh/2008060803) MIME-Version: 1.0 To: Jeffrey Hutzelman References: <20080527062527.GC16024@elstar.local> <1696498986EFEC4D9153717DA325CB72D0D4BE@vaebe104.NOE.Nokia.com> <019501c8c65d$fc32b960$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72D5486F@vaebe104.NOE.Nokia.com> <3238781633A647C08AFD323D@sirius.fac.cs.cmu.edu> In-Reply-To: <3238781633A647C08AFD323D@sirius.fac.cs.cmu.edu> X-OriginalArrivalTime: 13 Jun 2008 15:21:32.0124 (UTC) FILETIME=[28E251C0:01C8CD69] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1020; t=1213370492; x=1214234492; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Isms]=20Issue#11=20Reuse |Sender:=20; bh=F8VYd1+Q/WC2hAvvPXVKCMaJNNuTid9rZz/4TdXCsgA=; b=Q7YSZn6GAAvWxaVS874fu5fwlxwCaV2bjrj/cqAobs636SwfaLoyEukWgS b8PymKeiQAY9ilN1ZLKJlEZplsMPoLEdUTNpySJ/RWiJ8aRCAnSndBd65uYw LnhNoh6iCs; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: isms@ietf.org Subject: Re: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman wrote: > I think at one time we agreed in principle that there was nothing wrong > with reusing an existing incoming session which happened to match, but I > don't think there was a strong feeling that this was an important feature. > Of course, I may be wrong, and I particular like the notion of a management > station which opens an SSH session and "subscribes" to notifications to be > sent back along the same session as long as it is open. Among other > things, this would provide particular benefits for the scenario in which > the management station is behind a NAT. > I think you've just stated very well the reason why I feel strongly about this point. Based on Pasi's comments I wonder whether the abstraction in the table is correct, and whether we would do better to refer to the ssh service name ("isms" or "snmp" or some such) instead of TCP port numbers. Having another example OTHER than SSH I think would help, as Dave has indicated previously. Eliot _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 13 08:56:45 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D173A69DF; Fri, 13 Jun 2008 08:56:45 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36AB73A69DF for ; Fri, 13 Jun 2008 08:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNWSpb68QRdE for ; Fri, 13 Jun 2008 08:56:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A6C343A69D0 for ; Fri, 13 Jun 2008 08:56:41 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 724BFC001C for ; Fri, 13 Jun 2008 17:57:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JWgnFkmVTXYH; Fri, 13 Jun 2008 17:57:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EE74C0018; Fri, 13 Jun 2008 17:57:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 21D0B5CF686; Fri, 13 Jun 2008 17:57:07 +0200 (CEST) Date: Fri, 13 Jun 2008 17:57:07 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080613155706.GD5298@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] isms session at the upcoming ietf meeting in dublin X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, the initial schedule for the upcoming IETF meeting is online: https://datatracker.ietf.org/meeting/72/agenda.html As of today, a one hour ISMS meeting has been scheduled for Thursday afternoon (1510-1610). As usual, note that the meeting agenda is not fixed and can still change. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 13 09:09:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B453A6982; Fri, 13 Jun 2008 09:09:24 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F4A3A6982 for ; Fri, 13 Jun 2008 09:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-ykO06Gj+KX for ; Fri, 13 Jun 2008 09:09:22 -0700 (PDT) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by core3.amsl.com (Postfix) with SMTP id 0E7BC3A67F5 for ; Fri, 13 Jun 2008 09:09:21 -0700 (PDT) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa12382; 13 Jun 2008 12:09 EDT Date: Fri, 13 Jun 2008 12:09:01 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Eliot Lear In-Reply-To: <4852907B.8090404@cisco.com> Message-ID: MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, 13 Jun 2008, Eliot Lear wrote: > Jeffrey Hutzelman wrote: > > I think at one time we agreed in principle that there was nothing wrong > > with reusing an existing incoming session which happened to match, but I > > don't think there was a strong feeling that this was an important feature. > > Of course, I may be wrong, and I particular like the notion of a management > > station which opens an SSH session and "subscribes" to notifications to be > > sent back along the same session as long as it is open. Among other > > things, this would provide particular benefits for the scenario in which > > the management station is behind a NAT. > > > > I think you've just stated very well the reason why I feel strongly > about this point. Based on Pasi's comments I wonder whether the > abstraction in the table is correct, and whether we would do better to > refer to the ssh service name ("isms" or "snmp" or some such) instead of > TCP port numbers. The ssh _service_ name is always going to be "userauth", followed by "connect". I think you're referring to a subsystem name. It might be reasonable to include an ssh subsystem name, and I won't object beyond this one comment: Subsystem names are intended to be treated as protocol constants, like names of other kinds of extensions, rather than as values generated automatically or selected by an administrator. The DNS-based extensibility is there, so one could certainly imagine a deployment where the operator has made up names under his own domain, but this should not be the expected model. Even if we add a subsystem number, I don't think we can eliminate the port, because I think it is very likely that there will be situations where "normal" SSH and SNMP will need to run on separate ports. On most platforms, this is the case any time the SSH connections are handled by different processes, which would be the case if the SNMP software came with a different SSH implementation than that used on the rest of the system, or even if they are the same but need to be configured differently. For example, one might want to run SNMP behind an SSH server that lets in anyone who can authenticate, deferring all authorization policy to VACM; this would be a separate server from one which only lets in people who have accounts on a machine. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 13 11:12:44 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246C33A68FA; Fri, 13 Jun 2008 11:12:44 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C8F3A68FA for ; Fri, 13 Jun 2008 11:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDte76BjJbXx for ; Fri, 13 Jun 2008 11:12:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 143A23A6826 for ; Fri, 13 Jun 2008 11:12:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,640,1204498800"; d="scan'208";a="11645873" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Jun 2008 20:13:11 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5DIDBPF029102; Fri, 13 Jun 2008 20:13:11 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5DIDBad013005; Fri, 13 Jun 2008 18:13:11 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 20:13:11 +0200 Received: from adsl-247-3-fixip.tiscali.ch ([10.61.64.91]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 20:13:10 +0200 Message-ID: <4852B8B6.6000009@cisco.com> Date: Fri, 13 Jun 2008 20:13:10 +0200 From: Eliot Lear User-Agent: Thunderbird 3.0a2pre (Macintosh/2008060803) MIME-Version: 1.0 To: Jeffrey Hutzelman References: In-Reply-To: X-OriginalArrivalTime: 13 Jun 2008 18:13:10.0702 (UTC) FILETIME=[23509CE0:01C8CD81] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1838; t=1213380791; x=1214244791; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Isms]=20Issue#11=20Reuse |Sender:=20; bh=dNkO388oGNCRQEf1Fg1wipsGuMNylkeTvDsghLV1+KY=; b=echxytJ4o2ItN+Qz68IL+zLxXDmDggSLwrSohbpHXG2CAl3xUofWAWuKal xGg+PgEsFGi+2Vg00aNdO1uSOH1ttjJtWStmaUkHggAN/ixLs1g3qJcEuURN jFgREl+Jcl; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: isms@ietf.org Subject: Re: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman wrote: > > The ssh _service_ name is always going to be "userauth", followed by > "connect". I think you're referring to a subsystem name. You're right. My error. > It might be > reasonable to include an ssh subsystem name, and I won't object beyond > this one comment: > > Subsystem names are intended to be treated as protocol constants, like > names of other kinds of extensions, rather than as values generated > automatically or selected by an administrator. The DNS-based > extensibility is there, so one could certainly imagine a deployment where > the operator has made up names under his own domain, but this should not > be the expected model. > > > Even if we add a subsystem number, I don't think we can eliminate the > port, because I think it is very likely that there will be situations > where "normal" SSH and SNMP will need to run on separate ports. Yes, but remember what we're looking for- a registered instance of an SSH connection. So as long as we're not indexing off of ports, I would imagine having the port there does no harm, but I'm also not sure what good it does. > On most > platforms, this is the case any time the SSH connections are handled by > different processes, which would be the case if the SNMP software came > with a different SSH implementation than that used on the rest of the > system, or even if they are the same but need to be configured > differently. For example, one might want to run SNMP behind an SSH server > that lets in anyone who can authenticate, deferring all authorization > policy to VACM; this would be a separate server from one which only lets > in people who have accounts on a machine. > Right. But just for clarity's sake, why does a TCP port number need to be in any table? Eliot _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 13 11:41:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23CF3A6804; Fri, 13 Jun 2008 11:41:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77063A682E for ; Fri, 13 Jun 2008 11:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrbmEgfkbGMw for ; Fri, 13 Jun 2008 11:41:13 -0700 (PDT) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by core3.amsl.com (Postfix) with SMTP id CBDAF3A63D3 for ; Fri, 13 Jun 2008 11:41:12 -0700 (PDT) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa12601; 13 Jun 2008 14:41 EDT Date: Fri, 13 Jun 2008 14:41:20 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Eliot Lear In-Reply-To: <4852B8B6.6000009@cisco.com> Message-ID: MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, 13 Jun 2008, Eliot Lear wrote: > Yes, but remember what we're looking for- a registered instance of an > SSH connection. So as long as we're not indexing off of ports, I would > imagine having the port there does no harm, but I'm also not sure what > good it does. Oh, I'm sorry; you're talking about _incoming_ connections. Sure, you don't need to know the remote port in that case. But you need it in the "transport address" because you need it to establish outgoing connections, not only for notifications (and I think I explained why I think we still need that), but also for commands. > Right. But just for clarity's sake, why does a TCP port number need to > be in any table? Does what I said above answer this, or at least clear up a miscommunication? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 13 13:25:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A4B3A691B; Fri, 13 Jun 2008 13:25:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FC93A691B for ; Fri, 13 Jun 2008 13:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDmXJwfUOkye for ; Fri, 13 Jun 2008 13:25:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B3F0F3A690F for ; Fri, 13 Jun 2008 13:25:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,641,1204498800"; d="scan'208";a="11650866" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Jun 2008 22:25:43 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5DKPhXs022039; Fri, 13 Jun 2008 22:25:43 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5DKPhm3012635; Fri, 13 Jun 2008 20:25:43 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 22:25:42 +0200 Received: from adsl-247-3-fixip.tiscali.ch ([10.61.64.91]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 22:25:42 +0200 Message-ID: <4852D7C5.9020601@cisco.com> Date: Fri, 13 Jun 2008 22:25:41 +0200 From: Eliot Lear User-Agent: Thunderbird 3.0a2pre (Macintosh/2008060803) MIME-Version: 1.0 To: Jeffrey Hutzelman References: In-Reply-To: X-OriginalArrivalTime: 13 Jun 2008 20:25:42.0658 (UTC) FILETIME=[A70CCE20:01C8CD93] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=922; t=1213388743; x=1214252743; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Isms]=20Issue#11=20Reuse |Sender:=20; bh=IQ4Z/QyS4H7zsSLfiPUwc/pO2viFjudA5nGbccVYYz4=; b=ubqkWlRr1XWo5vmCS+qFq4TbAk5u8ytF9GYQaq1Ejnl/LWI5VanLyrAhYr Q0P0hbxv9J6cq0HCa3+dkf0c/wddZm+ull9bOevCKsEOSgtPY46Uwcr13yho cZBs/TXY2x; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: isms@ietf.org Subject: Re: [Isms] Issue#11 Reuse X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman wrote: > Oh, I'm sorry; you're talking about _incoming_ connections. Sure, you > don't need to know the remote port in that case. But you need it in the > "transport address" because you need it to establish outgoing connections, > not only for notifications (and I think I explained why I think we still > need that), but also for commands. > For outgoing connections as well, only perhaps the situation is indeed more complex if this table is the source of SSH parameters used to connect. If so, perhaps what's really going on here is that we need two separate tables- one for configuration and one with operational bindings between the two?? > >> Right. But just for clarity's sake, why does a TCP port number need to >> be in any table? >> > > Does what I said above answer this, or at least clear up a > miscommunication? > I think so... Eliot _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Jun 14 07:00:04 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6790A3A69C3; Sat, 14 Jun 2008 07:00:04 -0700 (PDT) X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BEB203A68E6; Sat, 14 Jun 2008 07:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080614140001.BEB203A68E6@core3.amsl.com> Date: Sat, 14 Jun 2008 07:00:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-usage-03.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Author(s) : K. Narayan, D. Nelson Filename : draft-ietf-isms-radius-usage-03.txt Pages : 15 Date : 2008-06-14 This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service by Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-usage-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-14065633.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Mon Jun 16 14:38:42 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCB93A67B7; Mon, 16 Jun 2008 14:38:42 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5893A67B7 for ; Mon, 16 Jun 2008 14:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52lRDx78B4S5 for ; Mon, 16 Jun 2008 14:38:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ED4513A67B1 for ; Mon, 16 Jun 2008 14:38:39 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE25AC0045 for ; Mon, 16 Jun 2008 23:39:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id D8kyk3JoExRs; Mon, 16 Jun 2008 23:39:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2B51C0038; Mon, 16 Jun 2008 23:39:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B91E5D37DD; Mon, 16 Jun 2008 23:39:14 +0200 (CEST) Date: Mon, 16 Jun 2008 23:39:14 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080616213914.GA5216@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] [dnelson@elbrysnetworks.com: RADEXT WG Last Call on "RADIUS Authorization for NAS Management"] X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, this RADEXT last call is relevant for ISMS since our RADIUS usage document depends on the document being last called. So please read and provide feedback to the RADEXT WG. /js ----- Forwarded message from "David B. Nelson" ----- From: "David B. Nelson" To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on "RADIUS Authorization for NAS Management" Date: Mon, 16 Jun 2008 16:32:59 -0400 Thread-Index: AcjP7oMtbwAqQuoxRMaIGZvyuOFXPgAASCaw Forwarding on behalf of Bernard... (transient e-mail issues) From: bernard_aboba@hotmail.com To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on "RADIUS Authorization for NAS Management" Date: Mon, 16 Jun 2008 13:03:40 -0700 This is an announcement of RADEXT WG Last Call on "RADIUS Authorization for NAS Management" prior to sending it on to the IESG for consideration as a Proposed Standard. ? The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati on-03.txt ? WG Last Call will last until June 30, 2008.?? Please review the document and post your comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT/).?? ? If you have read the document and approve of its publication, but have no comments, please also post this to the list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ----- End forwarded message ----- _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 17 10:27:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE563A6B50; Tue, 17 Jun 2008 10:27:28 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359143A6B50 for ; Tue, 17 Jun 2008 10:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ektm1ZSv7Ng for ; Tue, 17 Jun 2008 10:27:26 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id B91163A6B4C for ; Tue, 17 Jun 2008 10:27:23 -0700 (PDT) Received: (qmail 17995 invoked from network); 17 Jun 2008 13:28:03 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 17 Jun 2008 13:28:03 -0400 From: "David B. Nelson" To: References: <20080616213914.GA5216@elstar.local> Date: Tue, 17 Jun 2008 13:27:58 -0400 Organization: Elbrys Networks, Inc. Message-ID: <0093B05CE2514ACAAA0E57F6028880AD@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080616213914.GA5216@elstar.local> Thread-Index: AcjP+XLOdRG0a2LdRCek0Zpq4AVufwApCouA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Subject: Re: [Isms] RADEXT WG Last Call on"RADIUS Authorization for NAS Management" X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder writes... > this RADEXT last call is relevant for ISMS since our RADIUS usage > document depends on the document being last called. Yes, that's right. > So please read and provide feedback to the RADEXT WG. Please do! In terms of the relationship among the SNMP Transport Security work, and the two RADIUS-related drafts -- the RADIUS Usage draft in ISMS and the RADIUS Management A8thorization draft in RADEXT -- there are a couple of key points for ISMS WG members to consider. The RADIUS attributes for management authorization can specify a framed management protocol, e.g. SNMP. The current draft version no longer makes any distinction among which version of SNMP: v1, v2c of v3. There are similarly attributes to specify the minimum level of protection of the management transport, the equivalent of: authNoPriv and authPriv. There is not currently a way to specify a particular SNMP Transport Model, e.g. SSH vs. TLS. These decisions are the result of various review comments expressing the desire to keep the AAA provisioning at a suitably abstract level, and to avoid the temptation to use AAA as a means of provisioning parameters of SNMP or of the secure transport, e.g. SSH. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 19 03:40:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77AB3A6A86; Thu, 19 Jun 2008 03:40:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BFD83A698F for ; Thu, 19 Jun 2008 03:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.197 X-Spam-Level: X-Spam-Status: No, score=0.197 tagged_above=-999 required=5 tests=[AWL=-2.796, BAYES_20=-0.74, FM_ASCII_ART_SPACINGc=0.833, J_CHICKENPOX_57=0.6, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foHi06Xrz8uG for ; Thu, 19 Jun 2008 03:40:42 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 846243A6A70 for ; Thu, 19 Jun 2008 03:40:42 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id fm3Q1Z00J0EPchoA902u00; Thu, 19 Jun 2008 10:41:32 +0000 Received: from Harrington73653 ([222.128.247.59]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id fmhG1Z0011HdlbS8MmhMRc; Thu, 19 Jun 2008 10:41:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=edqPKRM8RMY9KFAAgEgA:9 a=D3-xYUTCidRrMXCvEmZ_QQ3evd4A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 a=48vgC7mUAAAA:8 a=I0CVDw5ZAAAA:8 a=Hb0PGcgVEdm4uyefDFIA:9 a=6EtTEyLRzHuNUbw4vZsA:7 a=0UXIzqYtUNraurePbspxVUKjevUA:4 a=8nNKBKeDaW0A:10 a=FvgKqOQ44qUA:10 a=oBKaSYGbyHAA:10 a=AVCpO1ehElwA:10 a=kLdjEiV55KYA:10 a=lZB815dzVvQA:10 a=c5zHXd76wwQA:10 From: "David Harrington" To: Date: Thu, 19 Jun 2008 18:41:15 +0800 Message-ID: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D3_01C8D23C.151668C0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdg== Subject: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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 This is a multi-part message in MIME format. ------=_NextPart_000_00D3_01C8D23C.151668C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I have added the MIB tables we discussed. I have not yet adjusted any of the non-MIB documentation. Please see whether these MIB tables look appropriate. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_00D3_01C8D23C.151668C0 Content-Type: text/plain; name="draft-ietf-isms-transport-security-model-pre08.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-transport-security-model-pre08.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track June 19, 2008=0A= Expires: December 21, 2008=0A= =0A= =0A= Transport Security Model for SNMP=0A= draft-ietf-isms-transport-security-model-08=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on December 21, 2008.=0A= =0A= Abstract=0A= =0A= This memo describes a Transport Security Model for the Simple Network=0A= Management Protocol.=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Transport Security Model for SNMP.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 1]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 2. How the Transport Security Model Fits in the Architecture . . 5=0A= 2.1. Security Capabilities of this Model . . . . . . . . . . . 6=0A= 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7=0A= 2.2. No Sessions . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 2.4. Security Parameter Passing . . . . . . . . . . . . . . . . 8=0A= 2.5. Notifications and Proxy . . . . . . . . . . . . . . . . . 9=0A= 3. Cached Information and References . . . . . . . . . . . . . . 9=0A= 3.1. tmStateReference . . . . . . . . . . . . . . . . . . . . . 10=0A= 3.2. securityStateReference . . . . . . . . . . . . . . . . . . 10=0A= 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10=0A= 4.1. Security Processing for an Outgoing Message . . . . . . . 11=0A= 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 12=0A= 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 13=0A= 5.1. Security Processing for an Incoming Message . . . . . . . 13=0A= 5.2. Elements of Procedure for Incoming Messages . . . . . . . 13=0A= 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 14=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 14=0A= 6.2. The tsmStats Subtree . . . . . . . . . . . . . . . . . . . 14=0A= 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 14=0A= 6.3.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . 15=0A= 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB . . . . . . . . 15=0A= 6.3.3. MIB Modules Required for IMPORTS . . . . . . . . . . . 15=0A= 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 15=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24=0A= 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 24=0A= 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . . 27=0A= Appendix A. Notification Tables Configuration . . . . . . . . . . 27=0A= A.1. Transport Security Model Processing for Notifications . . 29=0A= Appendix B. Processing Differences between USM and Secure=0A= Transport . . . . . . . . . . . . . . . . . . . . . . 29=0A= B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 30=0A= B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 30=0A= Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 31=0A= Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 31=0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 2]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Transport Security Model for the Simple Network=0A= Management Protocol, for use with secure Transport Models in the=0A= Transport Subsystem [I-D.ietf-isms-tmsm].=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Transport Security Model for SNMP.=0A= =0A= It is important to understand the SNMP architecture and the=0A= terminology of the architecture to understand where the Transport=0A= Security Model described in this memo fits into the architecture and=0A= interacts with other subsystems and models within the architecture.=0A= It is expected that reader will have also read and understood RFC3411=0A= [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418=0A= [RFC3418].=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications that use=0A= different variations of the same terminology. This is consistent=0A= with the IESG decision to not require the SNMPv3 terminology be=0A= modified to match the usage of other non-SNMP specifications when=0A= SNMPv3 was advanced to Full Standard.=0A= =0A= Authentication in this document typically refers to the English=0A= meaning of "serving to prove the authenticity of" the message, not=0A= data source authentication or peer identity authentication.=0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 3]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= because in the RFC 3411 architecture, all SNMP entities have the=0A= capability of acting as either manager or agent or both depending on=0A= the SNMP applications included in the engine. Where distinction is=0A= required, the application names of Command Generator, Command=0A= Responder, Notification Originator, Notification Receiver, and Proxy=0A= Forwarder are used. See "SNMP Applications" [RFC3413] for further=0A= information.=0A= =0A= While security protocols frequently refer to a user, the terminology=0A= used in RFC3411 [RFC3411] and in this memo is "principal". A=0A= principal is the "who" on whose behalf services are provided or=0A= processing takes place. A principal can be, among other things, an=0A= individual acting in a particular role; a set of individuals, with=0A= each acting in a particular role; an application or a set of=0A= applications, or a combination of these within an administrative=0A= domain.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411], and the architecture=0A= extension specified in "Transport Subsystem for the Simple Network=0A= Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of=0A= external "lower layer transport" protocols to provide message=0A= security, tied into the SNMP architecture through the Transport=0A= Subsystem. The Transport Security Model is designed to work with=0A= such lower-layer secure Transport Models.=0A= =0A= In keeping with the RFC 3411 design decisions to use self-contained=0A= documents, this memo includes the elements of procedure plus=0A= associated MIB objects which are needed for processing the Transport=0A= Security Model for SNMP. These MIB objects SHOULD not be referenced=0A= in other documents. This allows the Transport Security Model to be=0A= designed and documented as independent and self-contained, having no=0A= direct impact on other modules, and allowing this module to be=0A= upgraded and supplemented as the need arises, and to move along the=0A= standards track on different time-lines from other modules.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 4]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= 1.4. Motivation=0A= =0A= This memo describes a Security Model to make use of Transport Models=0A= that use lower layer secure transports and existing and commonly=0A= deployed security infrastructures. This Security Model is designed=0A= to meet the security and operational needs of network administrators,=0A= maximize usability in operational environments to achieve high=0A= deployment success and at the same time minimize implementation and=0A= deployment costs to minimize the time until deployment is possible.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Security Model is also influenced by the=0A= following constraints:=0A= =0A= 1. In times of network stress, the security protocol and its=0A= underlying security mechanisms SHOULD NOT depend solely upon the=0A= ready availability of other network services (e.g., Network Time=0A= Protocol (NTP) or Authentication, Authorization, and Accounting=0A= (AAA) protocols).=0A= =0A= 2. When the network is not under stress, the Security Model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= =0A= 3. It may not be possible for the Security Model to determine when=0A= the network is under stress.=0A= =0A= 4. A Security Model should require no changes to the SNMP=0A= architecture.=0A= =0A= 5. A Security Model should require no changes to the underlying=0A= security protocol.=0A= =0A= 2. How the Transport Security Model Fits in the Architecture=0A= =0A= The Transport Security Model is designed to fit into the RFC3411=0A= architecture as a Security Model in the Security Subsystem, and to=0A= utilize the services of a secure Transport Model.=0A= =0A= A cache, referenced by tmStateReference, is used to pass information=0A= between the Transport Security Model and a Transport Model, and vice=0A= versa. If the Transport Security Model is used with an insecure=0A= Transport Model, then the cache will not exist or be populated with=0A= security parameters, which will cause the Transport Security Model to=0A= return an error (see section 5.2) If another Security Model (eg=0A= Community-based Security Model) is used with a secure Transport=0A= Model, then the cache may be populated but the other Security Model=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 5]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= may be unaware of the cache and ignore its contents (eg deriving the=0A= securityName from the Community name in the message instead of=0A= deriving it from the tmSecurityName in the tmStateReference cache).=0A= =0A= When a secure Transport Model creates a tmStateReference cache for an=0A= incoming message, it will include a tmTransport, tmAddress,=0A= tmSecurityName and a tmTransportSecurityLevel, and it MAY include=0A= transport-specific information. When the Transport Security Model=0A= sends a message, it will create a cache containing the specified=0A= transportDomain, transportAddress, securityName, and securityLevel=0A= parameters. The Transport Security Model will pass the=0A= tmStateReference to enable the transport model to extract=0A= corresponding transport-specific information from the=0A= tmStateReference cache, in an implementation-dependent manner.=0A= =0A= When the Transport Security Model determines that a cache does not=0A= yet exist corresponding to the specified transportDomain,=0A= transportAddress, secuirtyName, and securityLevel parameters, it=0A= creates one that contains a tmSecurityName and=0A= tmRequestedSecurityLevel and passes the tmStateReference cache to the=0A= specified Transport Model.=0A= =0A= The Transport Security Model will determine the security-model-=0A= independent securityName and securityLevel, and will verify for=0A= incoming messages that tmTransportSecurityLevel is at least as strong=0A= as the requested securityLevel.=0A= =0A= To maintain the RFC3411 modularity, the Transport Model does not know=0A= which securityModel will be used for an incoming message; the Message=0A= Processing Model will determine the securityModel to be used, in a=0A= Message Processing Model dependent manner.=0A= =0A= 2.1. Security Capabilities of this Model=0A= =0A= 2.1.1. Threats=0A= =0A= The Transport Security Model, when used with suitable secure=0A= Transport Models, provides protection against the threats identified=0A= by the RFC 3411 architecture [RFC3411].=0A= =0A= Which threats are addressed depends on the Transport Model. The=0A= Transport Security Model does not address any threats itself, but=0A= delegates that responsibility to a secure Transport Model.=0A= =0A= The Transport Security Model is called a Security Model to be=0A= compatible with the RFC3411 architecture. However, this Security=0A= Model does not provide security mechanisms such as authentication and=0A= encryption itself, so it SHOULD always be used with a Transport Model=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 6]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= that provides appropriate security.=0A= =0A= 2.1.2. Security Levels=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= =0A= - without authentication and without privacy (noAuthNoPriv)=0A= =0A= - with authentication but without privacy (authNoPriv)=0A= =0A= - with authentication and with privacy (authPriv)=0A= =0A= The model-independent securityLevel parameter is used to request=0A= specific levels of security for outgoing messages, and to assert that=0A= specific levels of security were applied during the transport and=0A= processing of incoming messages.=0A= =0A= The transport layer algorithms used to provide security SHOULD NOT be=0A= exposed to the Transport Security Model, as the Transport Security=0A= Model has no mechanisms by which it can test whether an assertion=0A= made by a Transport Model is accurate.=0A= =0A= The Transport Security Model trusts that the underlying secure=0A= transport connection has been properly configured to support security=0A= characteristics at least as strong as reported in=0A= tmTransportSecurityLevel.=0A= =0A= 2.2. No Sessions=0A= =0A= The Transport Security Model will associate state regarding each=0A= message and each known remote engine with a combination of=0A= transportDomain, transportAddress, securityName, securityModel, and=0A= securityLevel.=0A= =0A= The Transport Security Model does not recognize sessions of any kind,=0A= although they may be supported by a transport model.=0A= =0A= 2.3. Coexistence=0A= =0A= There are two primary factors which determine whether Security Models=0A= can coexist. First, there must be a mechanism to select different=0A= Security Models at run-time. Second, the processing of one Security=0A= Model should not impact the processing of another Security Model.=0A= =0A= In the RFC3411 architecture, a Message Processing Model determines=0A= which Security Model should be called. As of this writing, IANA has=0A= registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/=0A= SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1,=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 7]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= SNMPv2c, and the User-based Security Model).=0A= =0A= The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP=0A= 74) [RFC3584] always selects the SNMPv1(1) Security Model for an=0A= SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c=0A= message. Since there is no field in the message format that permits=0A= specifying a Security Model, RFC3584 message processing does not=0A= permit the selection of Security Models other than SNMPv1 or SNMPv2.=0A= Therefore, SNMPv1 or SNMPv2c messages that go through the SNMPv1 or=0A= SNMPv2 Message Processing Models **as defined in RFC3584** cannot use=0A= the Transport Security Model. (This does not mean an SNMPv1 or=0A= SNMPv2 message cannot use a secure transport model, only that the=0A= RFC3584 Message Processing Model will not invoke this security=0A= model.)=0A= =0A= The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact=0A= for which there is no existing IETF specification.=0A= =0A= The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts=0A= the securityModel from the msgSecurityModel field of an incoming=0A= SNMPv3Message. When the extracted value of msgSecurityModel is=0A= transportSecurityModel(YY), security processing is directed to the=0A= Transport Security Model. For an outgoing message to be secured=0A= using the Transport Security Model, msgSecurityModel should be set to=0A= transportSecurityModel(YY).=0A= =0A= [-- NOTE to RFC editor: replace YY with actual IANA-assigned number,=0A= and remove this note. ]=0A= =0A= The Transport Security Model uses its own MIB module for processing=0A= to maintain independence from other Security Models. This allows the=0A= Transport Security Model to coexist with other Security Models, such=0A= as the User-based Security Model.=0A= =0A= Note that the Transport Security Model may work with multiple=0A= Transport Models, but the isAccessAllowed() application service=0A= interfaces (ASI) only accepts a value for the Security Model, not for=0A= Transport Models. As a result, it is not possible to have different=0A= access control rules for different Transport Models that use the=0A= Transport Security Model.=0A= =0A= 2.4. Security Parameter Passing=0A= =0A= For outgoing messages, Transport Security Model uses parameters=0A= provided by the SNMP application to determine if a corresponding=0A= tmStateReference cache exists, or to create a suitable=0A= tmStateReference cache. The wholeMsg and the tmStateReference are=0A= passed to the appropriate Transport Model through a series of ASIs,=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 8]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= as described in "Transport Subsystem for the Simple Network=0A= Management Protocol" [I-D.ietf-isms-tmsm].=0A= =0A= For incoming messages, the Transport Model accepts messages from the=0A= lower layer transport, and records the transport-related information=0A= and security-related information, including a tmSecurityName that=0A= represents the transport-authenticated identity, and a=0A= tmTransportSecurityLevel that represents the security features=0A= provided during transport, in a cache referenced by tmStateReference.=0A= The wholeMsg and the tmStateReference are passed to the appropriate=0A= Security Model through a series of ASIs, as described in "Transport=0A= Subsystem for the Simple Network Management Protocol"=0A= [I-D.ietf-isms-tmsm].=0A= =0A= 2.5. Notifications and Proxy=0A= =0A= The SNMP-TARGET-MIB module [RFC3413] contains objects for defining=0A= management targets, including transportDomain, transportAddress,=0A= securityName, securityModel, and securityLevel parameters, for=0A= applications such as notifications and proxy. Transport type and=0A= address are configured in the snmpTargetAddrTable, and the=0A= securityModel, securityName, and securityLevel parameters are=0A= configured in the snmpTargetParamsTable.=0A= =0A= For the Transport Security Model, these will be translated as needed=0A= into tmSecurityName and tmRequestedSecurityLevel.=0A= =0A= The default approach is for an administrator to statically configure=0A= this information to identify the targets authorized to receive=0A= notifications or perform proxy.=0A= =0A= 3. Cached Information and References=0A= =0A= The RFC3411 architecture uses caches to store dynamic model-specific=0A= information, and uses references in the ASIs to indicate in a model-=0A= independent manner which cached information must flow between=0A= subsystems.=0A= =0A= There are two levels of state that may need to be maintained: the=0A= security state in a request-response pair, and potentially long-term=0A= state relating to transport and security. This document describes=0A= caches, and differentiates the tmStateReference from the=0A= securityStateReference, but how this is represented internally is an=0A= implementation decision.=0A= =0A= As a general rule, if state information is available when a message=0A= being processed gets discarded, the state related to that message=0A= should also be discarded, and if state information is available when=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 9]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= a relationship between engines is severed, such as the closing of a=0A= transport connection, the state information for that relationship=0A= might also be discarded.=0A= =0A= 3.1. tmStateReference=0A= =0A= For each transport model, information about the transport security=0A= may be stored in a cache to pass model- and mechanism-specific=0A= parameters.=0A= =0A= For security reasons, the Transport Security Model REQUIRES that the=0A= security parameters used for a response are the same as those used=0A= for the corresponding request, and passes a tmSameSecurity parameter=0A= in the tmStateReference cache for outgoing messages to indicate that=0A= the same security MUST be used for the outgoing response as was used=0A= for the corresponding incoming request. It is transport-model-=0A= dependent and implementation-dependent how this is ensured at the=0A= transport layer.=0A= =0A= Since the contents of a cache are meaningful only within an=0A= implementation, and not on-the-wire, the format of the cache is=0A= implementation-specific.=0A= =0A= 3.2. securityStateReference=0A= =0A= The securityStateReference parameter is defined in RFC3411. Its=0A= primary purpose is to provide a mapping between a request and the=0A= corresponding response. A sample model-specific cache can be found=0A= in RFC3414 [RFC3414].=0A= =0A= Transport models do not have access to the securityStateReference.=0A= For the Transport Security Model, it is important to ensure that the=0A= security parameters used for a request match those used for the=0A= corresponding response. The Transport Security Model will=0A= conceptually add the tmStateReference to the securityStateReference=0A= cache, so the transport model can map transport-specific security=0A= parameters for a request to its corresponding response. How the=0A= tmStateReference is added to the securityStateReference is=0A= implementation-specific.=0A= =0A= 4. Processing an Outgoing Message=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected.=0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 10]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= 4.1. Security Processing for an Outgoing Message=0A= =0A= This section describes the procedure followed by the Transport=0A= Security Model.=0A= =0A= The parameters needed for generating a message are supplied to the=0A= Security Model by the Message Processing Model via the=0A= generateRequestMsg() or the generateResponseMsg() ASI. The Transport=0A= Subsystem architectural extension has added the transportDomain,=0A= transportAddress, and tmStateReference parameters to the original=0A= RFC3411 ASIs.=0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateRequestMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- (NEW) specified by application=0A= IN transportAddress -- (NEW) specified by application=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) transport info=0A= )=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 11]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateResponseMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- (NEW) specified by application=0A= IN transportAddress -- (NEW) specified by application=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= IN securityStateReference -- reference to security state=0A= -- information from original=0A= -- request=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) transport info=0A= )=0A= =0A= 4.2. Elements of Procedure for Outgoing Messages=0A= =0A= 1) If there is a securityStateReference, then this is a response=0A= message. Extract transportDomain, transportAddress, securityName,=0A= securityLevel, securityModel, and tmStateReference from the=0A= securityStateReference cache. Set the tmRequestedSecurityLevel to=0A= the value of the extracted securityLevel. The cachedSecurityData for=0A= this message can now be discarded. Set the tmSameSecurity parameter=0A= in the tmStateReference cache to true.=0A= =0A= 2) If there is no securityStateReference, create a tmStateReference=0A= cache with tmSecurityName set to the value of securityName,=0A= tmRequestedSecurityLevel set to the value of securityLevel, and=0A= tmSameSecurity set to false.=0A= =0A= 3) Fill in the securityParameters with a zero-length OCTET STRING=0A= ('0400').=0A= =0A= 4) Combine the message parts into a wholeMsg and calculate=0A= wholeMsgLength.=0A= =0A= 5) The wholeMsg, wholeMsgLength, securityParameters and=0A= tmStateReference are returned to the calling Message Processing Model=0A= with the statusInformation set to success.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 12]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= 5. Processing an Incoming SNMP Message=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected.=0A= =0A= 5.1. Security Processing for an Incoming Message=0A= =0A= This section describes the procedure followed by the Transport=0A= Security Model whenever it receives an incoming message from a=0A= Message Processing Model. The ASI from a Message Processing Model to=0A= the Security Subsystem for a received message is:=0A= =0A= statusInformation =3D -- errorIndication or success=0A= -- error counter OID/value if error=0A= processIncomingMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN maxMessageSize -- from the received message=0A= IN securityParameters -- from the received message=0A= IN securityModel -- from the received message=0A= IN securityLevel -- from the received message=0A= IN wholeMsg -- as received on the wire=0A= IN wholeMsgLength -- length as received on the wire=0A= IN tmStateReference -- (NEW) from the Transport Model=0A= OUT securityEngineID -- authoritative SNMP entity=0A= OUT securityName -- identification of the principal=0A= OUT scopedPDU, -- message (plaintext) payload=0A= OUT maxSizeResponseScopedPDU -- maximum size sender can handle=0A= OUT securityStateReference -- reference to security state=0A= ) -- information, needed for response=0A= =0A= 5.2. Elements of Procedure for Incoming Messages=0A= =0A= 1) Set the securityEngineID to the local snmpEngineID.=0A= =0A= 2) If tmStateReference does not refer to a cache containing values=0A= for tmSecurityName and tmTransportSecurityLevel, then the=0A= snmpTsmInvalidCaches counter is incremented, an error indication is=0A= returned to the calling module, and Security Model processing stops=0A= for this message.=0A= =0A= 3) Set securityName to the value of tmSecurityName from the cache=0A= referenced by tmStateReference.=0A= =0A= 4) Compare the value of tmTransportSecurityLevel in the=0A= tmStateReference cache to the value of the securityLevel parameter=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 13]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= passed in the processIncomingMsg ASI. If securityLevel specifies=0A= privacy (Priv), and tmTransportSecurityLevel specifies no privacy=0A= (noPriv), or securityLevel specifies authentication (auth) and=0A= tmTransportSecurityLevel specifies no authentication (noAuth) was=0A= provided by the Transport Model, then the=0A= snmpTsmInadequateSecurityLevels counter is incremented, and an error=0A= indication (unsupportedSecurityLevel) together with the OID and value=0A= of the incremented counter is returned to the calling module.=0A= Transport Security Model processing stops for this message.=0A= =0A= 5)The security data is cached as cachedSecurityData, so that a=0A= possible response to this message will use the same security=0A= parameters. Then securityStateReference is set for subsequent=0A= reference to this cached data. For Transport Security Model, the=0A= securityStateReference includes a reference to the tmStateReference=0A= cache.=0A= =0A= 6) The scopedPDU component is extracted from the wholeMsg.=0A= =0A= 7) The maxSizeResponseScopedPDU is calculated. This is the maximum=0A= size allowed for a scopedPDU for a possible Response message.=0A= =0A= 8) The statusInformation is set to success and a return is made to=0A= the calling module passing back the OUT parameters as specified in=0A= the processIncomingMsg ASI.=0A= =0A= 6. MIB Module Overview=0A= =0A= This MIB module provides management of the Transport Security Model.=0A= It defines some needed textual conventions, and some statistics.=0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= 6.2. The tsmStats Subtree=0A= =0A= This subtree contains counters specific to the Transport Security=0A= Model, that provide information for identifying fault conditions.=0A= =0A= 6.3. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing the Transport Security Model In particular,=0A= it is assumed that an entity implementing the Transport Security=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 14]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= Model will implement the SNMPv2-MIB [RFC3418] and the SNMP-FRAMEWORK-=0A= MIB [RFC3411].=0A= =0A= 6.3.1. Relationship to the SNMPv2-MIB=0A= =0A= The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being=0A= mandatory for all systems, and the objects apply to the entity as a=0A= whole. The 'system' group provides identification of the management=0A= entity and certain other system-wide data. The snmpInASNParseErrs=0A= counter is incremented during the elements of procedure. The SNMP-=0A= TRANSPORT-SM-MIB does not duplicate those objects.=0A= =0A= 6.3.2. Relationship to the SNMP-FRAMEWORK-MIB=0A= =0A= The SNMP-FRAMEWORK-MIB provides definitions for the concepts of=0A= SnmpEngineID, enumeration of Message Processing Models, Security=0A= Models and Security Levels, and object definitions for snmpEngineID=0A= These are important for implementing the Transport Security Model,=0A= but are not needed to implement the SNMP-TRANSPORT-SM-MIB.=0A= =0A= 6.3.3. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578] and [RFC2580].=0A= =0A= 7. MIB module definition=0A= =0A= =0A= SNMP-TSM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= mib-2, Counter32=0A= FROM SNMPv2-SMI=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= TEXTUAL-CONVENTION, TestAndIncr,=0A= RowStatus, StorageType=0A= FROM SNMPv2-TC=0A= SnmpAdminString, SnmpSecurityLevel=0A= FROM SNMP-FRAMEWORK-MIB=0A= TransportDomain, TransportAddress=0A= FROM TRANSPORT-ADDRESS-MIB=0A= ;=0A= =0A= snmpTsmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200710140000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 15]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Editor:=0A= David Harrington=0A= Huawei Technologies USA=0A= 1700 Alma Dr.=0A= Plano TX 75075=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= "=0A= DESCRIPTION "The Transport Security Model MIB=0A= =0A= In keeping with the RFC 3411 design decisions=0A= to use self-contained documents, the RFC which=0A= contains the definition of this MIB module also=0A= includes the elements of procedure which are=0A= needed for processing the Transport Security=0A= Model for SNMP. These MIB objects=0A= SHOULD NOT be modified via other documents.=0A= This allows the Transport Security Model=0A= for SNMP to be designed and documented as=0A= independent and self- contained, having no=0A= direct impact on other modules, and this=0A= allows this module to be upgraded and=0A= supplemented as the need arises, and to=0A= move along the standards track on different=0A= time-lines from other modules.=0A= =0A= Copyright (C) The IETF Trust (2007). This=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 16]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200710140000Z"=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the SNMP-TRANSPORT-SM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= snmpTsmNotifications OBJECT IDENTIFIER ::=3D { snmpTsmMIB 0 }=0A= snmpTsmMIBObjects OBJECT IDENTIFIER ::=3D { snmpTsmMIB 1 }=0A= snmpTsmConformance OBJECT IDENTIFIER ::=3D { snmpTsmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= -- Statistics for the Transport Security Model=0A= =0A= =0A= snmpTsmStats OBJECT IDENTIFIER ::=3D { snmpTsmMIBObjects 1 }=0A= =0A= snmpTsmInvalidCaches OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of messages dropped because the=0A= tmStateReference referred to an invalid cache.=0A= "=0A= ::=3D { snmpTsmStats 1 }=0A= =0A= snmpTsmInadequateSecurityLevels OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of incoming messages dropped because=0A= the actual securityLevel provided was less than=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 17]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= the requested securityLevel.=0A= "=0A= ::=3D { snmpTsmStats 2 }=0A= =0A= -- The snmpTsmLCD Group ************************************************=0A= =0A= snmpTsmLCD OBJECT IDENTIFIER ::=3D { snmpTsmMIBObjects 2 }=0A= =0A= snmpTsmLCDSpinLock OBJECT-TYPE=0A= SYNTAX TestAndIncr=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION "An advisory lock used to allow several cooperating=0A= Command Generator Applications to coordinate their=0A= use of facilities to alter the snmpTsmLCDTable.=0A= "=0A= ::=3D { snmpTsmLCD 1 }=0A= =0A= -- The table of transforms for the Transport Security Model=0A= =0A= snmpTsmLCDTransformTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF SnmpTsmLCDTransformEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The table of transform policies.=0A= =0A= This table is automatically populated by the snmp=0A= engine, creating a conceptual row for each transport=0A= model supported by the engine.=0A= "=0A= ::=3D { snmpTsmLCD 2 }=0A= =0A= snmpTsmLCDTransformEntry OBJECT-TYPE=0A= SYNTAX SnmpTsmLCDTransformEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Each entry specifies a transform policy for=0A= automatically converting between snmpTsmLCDNames=0A= and snmpTsmLCDSecurityNames. These policies are=0A= meant to be administratively assigned. In the absence=0A= of an assigned policy, the default transform will be=0A= used.=0A= =0A= The Transport Security Model uses the TransportDomain=0A= index to identify a transport model. The Policy object=0A= specifies which policy should be applied to the=0A= transforms related to the corresponding transport=0A= model.=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 18]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= "=0A= INDEX { snmpTsmLCDTransformTransportDomain=0A= }=0A= ::=3D { snmpTsmLCDTransformTable 1 }=0A= =0A= SnmpTsmLCDTransformEntry ::=3D SEQUENCE=0A= {=0A= snmpTsmLCDTransformTransportDomain TransportDomain,=0A= snmpTsmLCDTransformPolicy INTEGER=0A= }=0A= =0A= snmpTsmLCDTransformTransportDomain OBJECT-TYPE=0A= SYNTAX TransportDomain=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "This object indicates the transport type of the address=0A= which the Transport Security Model uses to select a=0A= transport model. Thus, this domain is used to indicate=0A= the policy to be used with different transport models."=0A= ::=3D { snmpTsmLCDTransformEntry 1 }=0A= =0A= snmpTsmLCDTransformPolicy OBJECT-TYPE=0A= SYNTAX INTEGER { default(1),=0A= private(2),=0A= disable(3)=0A= }=0A= =0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "The policy that should be used to perform transforms=0A= between the transport model specific identity and the=0A= transport model independent securityName.=0A= =0A= default (1) - for incoming messages, the value passed in=0A= the tmSecurityName field of tmStateReference is assigned=0A= to both snmpTsmLCDSecurityName and snmpTsmLCDName.=0A= For outgoing messages, the value passed in securityName=0A= is assigned to both snmpTsmLCDSecurityName and=0A= snmpTsmLCDName.=0A= =0A= private (2) - use an implementation-specific mapping=0A= algorithm for the transform. If the algorithm does not yield=0A= a mapping, no entry should be created for the identity in=0A= the snmpTsmLCDTable. It is implementation-dependent=0A= whether a private algorithm is supported.=0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 19]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= disable (3) - do not allow a specific transport model to be=0A= used.=0A= "=0A= DEFVAL { default }=0A= ::=3D { snmpTsmLCDTransformEntry 2 }=0A= =0A= =0A= -- The table of users for the Transport Security Model=0A= -- This table can support users of multiple transport models=0A= =0A= snmpTsmLCDTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF SnmpTsmLCDEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The table of users configured in the SNMP engine's=0A= Local Configuration Datastore (LCD).=0A= =0A= Rows in this table can be instantiated when an=0A= authenticated identity is passed to the Transport=0A= Security Model by a transport model, and they can be=0A= instantiated by a command generator.=0A= =0A= To instantiate a new row in this table, the=0A= snmpTsmLCDSpinLock should be used to prevent conflicts.=0A= =0A= 1) GET(snmpTsmLCDSpinLock.0) and save in sValue.=0A= =0A= 2) SET(snmpTsmLCDSpinLock.0=3DsValue,=0A= snmpTsmLCDTransportDomain=3D(desired value),=0A= snmpTsmLCDTransportAddress=3D(desired value),=0A= snmpTsmLCDSecurityName=3D(desired value),=0A= snmpTsmLCDSecurityLevel=3D(desired value),=0A= snmpTsmLCDName=3D(desired value),=0A= snmpTsmLCDStorageType=3D(desired value),=0A= snmpTsmLCDStatus=3DcreateAndGo)=0A= "=0A= ::=3D { snmpTsmLCD 3 }=0A= =0A= snmpTsmLCDEntry OBJECT-TYPE=0A= SYNTAX SnmpTsmLCDEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A user configured in the Local=0A= Configuration Datastore (LCD) for the Transport=0A= Security Model.=0A= =0A= To maintain modularity of design, and to avoid=0A= side-effects, only the Transport Security Model=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 20]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= (or a SET operation) should modify this table.=0A= In particular, transport models should not=0A= directly manipulate values in this table.=0A= "=0A= INDEX { snmpTsmLCDTransportDomain,=0A= snmpTsmLCDTransportAddress,=0A= snmpTsmLCDSecurityName,=0A= snmpTsmLCDSecurityLevel=0A= }=0A= ::=3D { snmpTsmLCDTable 1 }=0A= =0A= SnmpTsmLCDEntry ::=3D SEQUENCE=0A= {=0A= =0A= snmpTsmLCDTransportDomain TransportDomain,=0A= snmpTsmLCDTransportAddress TransportAddress,=0A= snmpTsmLCDSecurityName SnmpAdminString,=0A= snmpTsmLCDSecurityLevel SnmpSecurityLevel,=0A= snmpTsmLCDName SnmpAdminString,=0A= snmpTsmLCDStorageType StorageType,=0A= snmpTsmLCDRowStatus RowStatus=0A= }=0A= =0A= snmpTsmLCDTransportDomain OBJECT-TYPE=0A= SYNTAX TransportDomain=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "This object indicates the transport type of the address=0A= contained in the snmpTsmLCDTransportAddress object."=0A= ::=3D { snmpTsmLCDEntry 1 }=0A= =0A= snmpTsmLCDTransportAddress OBJECT-TYPE=0A= SYNTAX TransportAddress=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "This object contains a transport address. The format of=0A= this address depends on the value of the=0A= snmpTsmLCDTransportDomain object."=0A= ::=3D { snmpTsmLCDEntry 2 }=0A= =0A= snmpTsmLCDSecurityName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A human readable string representing the user in=0A= Security Model independent format.=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 21]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= The default transformation of the Transport Security=0A= Model dependent security ID to the securityName and=0A= vice versa is the identity function so that the=0A= securityName is the same as the LCDName.=0A= [TODO]=0A= "=0A= ::=3D { snmpTsmLCDEntry 3 }=0A= =0A= snmpTsmLCDSecurityLevel OBJECT-TYPE=0A= SYNTAX SnmpSecurityLevel=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A value representing whether the transport=0A= protocol provides authentication and privacy services=0A= for the specified UserName=0A= "=0A= ::=3D { snmpTsmLCDEntry 4 }=0A= =0A= snmpTsmLCDName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "A human readable string used by the=0A= corresponding transport model to determine which=0A= credentials are used during authentication of=0A= the prinicipal.=0A= =0A= This is the Transport Model dependent security ID=0A= used by the transport protocol.=0A= "=0A= ::=3D { snmpTsmLCDEntry 5 }=0A= =0A= snmpTsmLCDStorageType OBJECT-TYPE=0A= SYNTAX StorageType=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "The storage type for this conceptual row.=0A= =0A= Conceptual rows having the value readOnly, permanent,=0A= or nonVolatile must persist across reinitializations of=0A= the management subsystem.=0A= =0A= Conceptual rows having the value 'volatile' must not=0A= persist across reinitializations of the management=0A= subsystem.=0A= =0A= It is an implementation issue to decide if a SET for=0A= a readOnly or permanent row is accepted at all. In=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 22]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= some contexts this may make sense, in others it may=0A= not. If a SET for a readOnly or permanent row is not=0A= accepted at all, then a 'wrongValue' error must be=0A= returned.=0A= "=0A= DEFVAL { volatile }=0A= ::=3D { snmpTsmLCDEntry 6 }=0A= =0A= snmpTsmLCDRowStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "The status of this conceptual row.=0A= =0A= Until instances of all corresponding columns are=0A= appropriately configured, the value of the=0A= corresponding instance of snmpTsmLCDStatus=0A= is 'notReady'.=0A= =0A= The snmpTsmLCDName value should only be=0A= changed when the value of this object=0A= is 'active'.=0A= "=0A= ::=3D { snmpTsmLCDEntry 7 }=0A= =0A= -- -------------------------------------------------------------=0A= -- snmpTsmMIB - Conformance Information=0A= -- -------------------------------------------------------------=0A= =0A= snmpTsmCompliances OBJECT IDENTIFIER ::=3D { snmpTsmConformance 1 }=0A= =0A= snmpTsmGroups OBJECT IDENTIFIER ::=3D { snmpTsmConformance 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Compliance statements=0A= -- -------------------------------------------------------------=0A= =0A= snmpTsmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for SNMP engines that support=0A= the SNMP-TRANSPORT-SM-MIB"=0A= MODULE=0A= MANDATORY-GROUPS { snmpTsmGroup }=0A= ::=3D { snmpTsmCompliances 1 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Units of conformance=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 23]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= -- -------------------------------------------------------------=0A= snmpTsmGroup OBJECT-GROUP=0A= OBJECTS {=0A= snmpTsmInvalidCaches,=0A= snmpTsmInadequateSecurityLevels,=0A= snmpTsmLCDTransformPolicy,=0A= snmpTsmLCDSpinLock,=0A= snmpTsmLCDName,=0A= snmpTsmLCDStorageType,=0A= snmpTsmLCDRowStatus=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements=0A= the SNMP Transport Security Model.=0A= "=0A= =0A= ::=3D { snmpTsmGroups 2 }=0A= =0A= =0A= END=0A= =0A= =0A= 8. Security Considerations=0A= =0A= This document describes a Security Model that permits SNMP to utilize=0A= security services provided through an SNMP Transport Model. The=0A= Transport Security Model relies on Transport Models for mutual=0A= authentication, binding of keys, confidentiality and integrity. The=0A= security threats and how those threats are mitigated should be=0A= covered in detail in the specification of the Transport Model and the=0A= underlying secure transport.=0A= =0A= Transport Security Model relies on a Transport Model to provide an=0A= authenticated principal for mapping to securityName, and an assertion=0A= of tmTransportSecurityLevel.=0A= =0A= The Transport Security Model is called a Security Model to be=0A= compatible with the RFC3411 architecture. However, this Security=0A= Model provides no security itself. It SHOULD always be used with a=0A= Transport Model that provides security, but this is a run-time=0A= decision of the operator or management application, or a=0A= configuration decision of an operator.=0A= =0A= 8.1. MIB module security=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 24]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o snmpTsmInvalidCaches and snmpTsmInadequateSecurityLevels may make=0A= it easier for an attacker to detect vulnerabilities.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPsec),=0A= even then, there is no control as to who on the secure network is=0A= allowed to access and GET/SET (read/change/create/delete) the objects=0A= in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and Transport Security Model cryptographic=0A= mechanisms (for authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 9. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= =0A= 1. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= 2. a value, preferably 4, to identify the Transport Security Model,=0A= in the Security Models registry at=0A= http://www.iana.org/assignments/snmp-number-spaces. This should=0A= result in the following table of values:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 25]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= Value Description References=0A= ----- ----------- ----------=0A= 0 reserved for 'any' [RFC3411]=0A= 1 reserved for SNMPv1 [RFC3411]=0A= 2 reserved for SNMPv2c [RFC3411]=0A= 3 User-Based Security Model (USM) [RFC3411]=0A= YY Transport Security Model (TSM) [RFCXXXX]=0A= =0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= -- NOTE to RFC editor: replace YY with actual IANA-assigned number,=0A= throughout this document and remove this note.=0A= =0A= 10. References=0A= =0A= 10.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to=0A= Indicate Requirement Levels", BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Structure of Management=0A= Information Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Textual Conventions for=0A= SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins, D., and J.=0A= Schoenwaelder, "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=0A= Architecture for Describing Simple Network=0A= Management Protocol (SNMP) Management=0A= Frameworks", STD 62, RFC 3411, December 2002.=0A= =0A= [RFC3412] Case, J., Harrington, D., Presuhn, R., and B.=0A= Wijnen, "Message Processing and Dispatching for=0A= the Simple Network Management Protocol (SNMP)",=0A= STD 62, RFC 3412, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple=0A= Network Management Protocol (SNMP)=0A= Applications", STD 62, RFC 3413, December 2002.=0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 26]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= [RFC3418] Presuhn, R., "Management Information Base (MIB)=0A= for the Simple Network Management Protocol=0A= (SNMP)", STD 62, RFC 3418, December 2002.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport=0A= Subsystem for the Simple Network Management=0A= Protocol (SNMP)", draft-ietf-isms-tmsm-12 (work=0A= in progress), February 2008.=0A= =0A= 10.2. Informative References=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D., and B.=0A= Stewart, "Introduction and Applicability=0A= Statements for Internet-Standard Management=0A= Framework", RFC 3410, December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B. Wijnen, "User-based=0A= Security Model (USM) for version 3 of the=0A= Simple Network Management Protocol (SNMPv3)",=0A= STD 62, RFC 3414, December 2002.=0A= =0A= [RFC3584] Frye, R., Levi, D., Routhier, S., and B.=0A= Wijnen, "Coexistence between Version 1, Version=0A= 2, and Version 3 of the Internet-standard=0A= Network Management Framework", BCP 74,=0A= RFC 3584, August 2003.=0A= =0A= Appendix A. Notification Tables Configuration=0A= =0A= The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to=0A= configure notification originators with the destinations to which=0A= notifications should be sent.=0A= =0A= Most of the configuration is security-model-independent and=0A= transport-model-independent.=0A= =0A= The values we will use in the examples for the five model-independent=0A= security and transport parameters are:=0A= =0A= transportDomain =3D snmpSSHDomain=0A= =0A= transportAddress =3D 192.0.2.1:162=0A= =0A= securityModel =3D Transport Security Model=0A= =0A= securityName =3D sampleUser=0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 27]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= securityLevel =3D authPriv=0A= =0A= The following example will configure the Notification Originator to=0A= send informs to a Notification Receiver at host 192.0.2.1 port 162=0A= using the securityName "sampleUser". The columns marked with a "*"=0A= are the items that are Security Model or Transport Model specific.=0A= =0A= The configuration for the "sampleUser" settings in the SNMP-VIEW-=0A= BASED-ACM-MIB objects are not shown here for brevity. First we=0A= configure which type of notification should be sent for this taglist=0A= (toCRTag). In this example, we choose to send an Inform.=0A= snmpNotifyTable row:=0A= snmpNotifyName CRNotif=0A= snmpNotifyTag toCRTag=0A= snmpNotifyType inform=0A= snmpNotifyStorageType nonVolatile=0A= snmpNotifyColumnStatus createAndGo=0A= =0A= Then we configure a transport address to which notifications=0A= associated with this taglist should be sent, and we specify which=0A= snmpTargetParamsEntry should be used (toCR) when sending to this=0A= transport address.=0A= snmpTargetAddrTable row:=0A= snmpTargetAddrName toCRAddr=0A= * snmpTargetAddrTDomain snmpSSHDomain=0A= snmpTargetAddrTAddress 192.0.2.1:162=0A= snmpTargetAddrTimeout 1500=0A= snmpTargetAddrRetryCount 3=0A= snmpTargetAddrTagList toCRTag=0A= snmpTargetAddrParams toCR (must match below)=0A= snmpTargetAddrStorageType nonVolatile=0A= snmpTargetAddrColumnStatus createAndGo=0A= =0A= =0A= Then we configure which principal at the host should receive the=0A= notifications associated with this taglist. Here we choose=0A= "sampleUser", who uses the Transport Security Model.=0A= snmpTargetParamsTable row:=0A= snmpTargetParamsName toCR=0A= snmpTargetParamsMPModel SNMPv3=0A= * snmpTargetParamsSecurityModel TransportSecurityModel=0A= snmpTargetParamsSecurityName "sampleUser"=0A= snmpTargetParamsSecurityLevel authPriv=0A= snmpTargetParamsStorageType nonVolatile=0A= snmpTargetParamsRowStatus createAndGo=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 28]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= A.1. Transport Security Model Processing for Notifications=0A= =0A= The Transport Security Model is called using the generateRequestMsg()=0A= ASI, with the following parameters (* are from the above tables):=0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateRequestMsg(=0A= IN messageProcessingModel -- *snmpTargetParamsMPModel=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- *snmpTargetAddrTDomain=0A= IN transportAddress -- *snmpTargetAddrTAddress=0A= IN securityModel -- *snmpTargetParamsSecurityModel=0A= IN securityEngineID -- immaterial; TSM will ignore.=0A= IN securityName -- snmpTargetParamsSecurityName=0A= IN securityLevel -- *snmpTargetParamsSecurityLevel=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- reference to transport info=0A= )=0A= =0A= The Transport Security Model will determine the Transport Model based=0A= on the snmpTargetAddrTDomain. The selected Transport Model will=0A= select the appropriate transport connection using the=0A= snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and=0A= snmpTargetParamsSecurityLevel.=0A= =0A= Appendix B. Processing Differences between USM and Secure Transport=0A= =0A= USM and secure transports differ in the processing order and=0A= responsibilities within the RFC3411 architecture. While the steps=0A= are the same, they occur in a different order, and may be done by=0A= different subsystems. The following lists illustrate the difference=0A= in the flow and the responsibility for different processing steps for=0A= incoming messages when using USM and when using a secure transport.=0A= (Note that these lists are simplified for illustrative purposes, and=0A= do not represent all details of processing. Transport Models must=0A= provide the detailed elements of procedure.)=0A= =0A= With USM and other Security Models, security processing starts when=0A= the Message Processing Model decodes portions of the ASN.1 message to=0A= extract an opaque block of security parameters and header parameters=0A= that identify which Security Model should process the message to=0A= perform authentication, decryption, timeliness checking, integrity=0A= checking, and translation of parameters to model-independent=0A= parameters. A secure transport performs those security functions on=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 29]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= the message, before the ASN.1 is decoded.=0A= =0A= Step 6 cannot occur until after decryption occurs. Step 6 and beyond=0A= are the same for USM and a secure transport.=0A= =0A= B.1. USM and the RFC3411 Architecture=0A= =0A= 1) decode the ASN.1 header (Message Processing Model)=0A= =0A= 2) determine the SNMP Security Model and parameters (Message=0A= Processing Model)=0A= =0A= 3) verify securityLevel. [Security Model]=0A= =0A= 4) translate parameters to model-independent parameters (Security=0A= Model)=0A= =0A= 5) authenticate the principal, check message integrity and=0A= timeliness, and decrypt the message. [Security Model]=0A= =0A= 6) determine the pduType in the decrypted portions (Message=0A= Processing Model), and=0A= =0A= 7) pass on the decrypted portions with model-independent parameters.=0A= =0A= B.2. Transport Subsystem and the RFC3411 Architecture=0A= =0A= 1) authenticate the principal, check integrity and timeliness of the=0A= message, and decrypt the message. [Transport Model]=0A= =0A= 2) translate parameters to model-independent parameters (Transport=0A= Model)=0A= =0A= 3) decode the ASN.1 header (Message Processing Model)=0A= =0A= 4) determine the SNMP Security Model and parameters (Message=0A= Processing Model)=0A= =0A= 5) verify securityLevel [Security Model]=0A= =0A= 6) determine the pduType in the decrypted portions (Message=0A= Processing Model), and=0A= =0A= 7) pass on the decrypted portions with model-independent security=0A= parameters=0A= =0A= If a message is secured using a secure transport layer, then the=0A= Transport Model should provide the translation from the authenticated=0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 30]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= identity (e.g., an SSH user name) to a model-independent securityName=0A= in step 2.=0A= =0A= Appendix C. Open Issues=0A= =0A= none.=0A= =0A= Appendix D. Change Log=0A= =0A= From -05- to -06-=0A= =0A= Fixed a bunch of editorial nits=0A= =0A= Fixed the note about terminology consistent with SNMPv3.=0A= =0A= Updated MIB assignment to by rfc4181 compatible=0A= =0A= Replaced tmSameSession with tmSameSecurity to eliminate session-=0A= matching from the security model.=0A= =0A= Eliminated all reference to the LCD from the Transport Security=0A= Model; the LCD is now TM-specific.=0A= =0A= Added tmTransportSecurityLevel and tmRequestedSecurityLevel to=0A= clarify incoming versus outgoing=0A= =0A= From -04- to -05-=0A= =0A= Removed check for empty securityParameters for incoming messages=0A= =0A= Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= From -03- to -04-=0A= =0A= Editorial changes requested by Tom Petch, to clarify behavior with=0A= SNMPv1/v2c=0A= =0A= Added early discussion of how TSM fits into the architecture to=0A= clarify behavior when RFC3584 security models are co-resident.=0A= =0A= Editorial changes requested by Bert Wijnen, to eliminate version-=0A= specific discussions.=0A= =0A= Removed sections on version-specific message formats.=0A= =0A= Removed discussion of SNMPv3 in Motivation section.=0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 31]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= Added discussion of request/response session matching.=0A= =0A= From -02- to -03-=0A= =0A= Editorial changes suggested by Juergen Schoenwaelder=0A= =0A= Capitalized Transport Models, Security Models, and Message=0A= Processing Models, to be consistent with RFC341x conventions.=0A= =0A= Eliminated some text that duplicated RFC3412, especially in=0A= Elements of Procedure.=0A= =0A= Changed the encoding of msgSecurityParameters=0A= =0A= Marked the (NEW) fields added to existing ASIs=0A= =0A= Modified text intro discussing relationships to other MIB modules.=0A= =0A= From -01- to -02-=0A= =0A= Changed transportSecurityModel(4) to transportSecurityModel(YY),=0A= waiting for assignment=0A= =0A= cleaned up elements of procedure [todo]s=0A= =0A= use the same errorIndication as USM for unsupportedSecurityLevel=0A= =0A= fixed syntax of tsmInadequateSecurity counter=0A= =0A= changed the "can and will use" the same security parameters to=0A= "can use", to allow responses that have different security=0A= parameters than the request.=0A= =0A= removed "Relationship to the SNMP-FRAMEWORK-MIB"=0A= =0A= cleaned up "MIB Modules Required for IMPORTS"=0A= =0A= =0A= =0A= From -00- to -01-=0A= =0A= made the Transport Model not know anything about the Security=0A= Model.=0A= =0A= modified the elements of procedure sections, given the=0A= implications of this change.=0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 32]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= simplified elements of procedure, removing most info specified in=0A= architecture/subsystem definitions.=0A= =0A= rethought the coexistence section=0A= =0A= noted the implications of the Transport Security Model on=0A= isAccessAllowed()=0A= =0A= modified all text related to the LCD.=0A= =0A= removed most of the MIB (now the TSM has no configuration=0A= parameters).=0A= =0A= added counters needed to support elements of procedure=0A= =0A= renamed MIB module, and registered under snmpModules=0A= =0A= updated IANA and Security Considerations=0A= =0A= updated references.=0A= =0A= modified the notification configurations.=0A= =0A= From SSHSM-04- to Transport-security-model-00=0A= =0A= added tsmUserTable=0A= =0A= updated Appendix - Notification Tables Configuration=0A= =0A= remove open/closed issue appendices=0A= =0A= changed tmSessionReference to tmStateReference=0A= =0A= =0A= =0A= Author's Address=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 33]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP June 2008=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2008).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington Expires December 21, 2008 [Page 34]=0A= =0C=0A= =0A= ------=_NextPart_000_00D3_01C8D23C.151668C0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_00D3_01C8D23C.151668C0-- From isms-bounces@ietf.org Thu Jun 19 04:42:52 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FB93A6990; Thu, 19 Jun 2008 04:42:52 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A293A698F for ; Thu, 19 Jun 2008 04:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=1.398, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZc5UgD+D9GW for ; Thu, 19 Jun 2008 04:42:48 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 8D9F43A67F8 for ; Thu, 19 Jun 2008 04:42:48 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id fmzA1Z0010cQ2SLA302R00; Thu, 19 Jun 2008 11:43:39 +0000 Received: from Harrington73653 ([222.128.247.59]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id fnjP1Z0051HdlbS8WnjV2U; Thu, 19 Jun 2008 11:43:37 +0000 X-Authority-Analysis: v=1.0 c=1 a=9E8Jegf20ugUPk8lo8MA:9 a=2PjD-IMp_survoVzSAsA:7 a=n6hNOLWx851RZ10goB3m3k2oSM8A:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'David Harrington'" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> Date: Thu, 19 Jun 2008 19:43:22 +0800 Message-ID: <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgABMAHQ Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I should probably provide a little guidance on this MIB. Due to modularity rules, only the TSM will actually manipulate this MIB. It might also be the only module to read the MIB. (Implementations of course can optimize as they wish). TSM will convert from ASI parameters to LCD, and from LCD to ASI parameters. In C++ terms, this is a "private" datastore, accessible through "public" interfaces. I started calling this the snmpTsmUserTable, but that could be misleading, so I changed it the snmpTsmLCDTable. Let me know which you prefer, or if you have another name you prefer. For outgoing messages, the application ASIs will provide securityName, Level, domain, and address. These may, of course, come from the RFC3413 MIB modules. The TSM MIB may be preconfigured with desired mappings, so the TSM will look to see if there is an entry for the provided securityName, Level, domain, and address. If not, the TSM will create an entry, and by default, the provided securityName will be used as both the LCDSecurityName and the LCDName. (I debated whether to name the label default or identity. Then, the TSM will make a request of the transport model, converting the LCD info into the ASI parameters (passing a tmStateReference, containing info in the fields). The transport model will work with the info from the tmStateReference, not the LCDTable. The SSHTM will also have a local config datastore, but we are not defining that since it is SSH configuration. How SSHTM uses the tmStateReference equivalent of LCDName is implementation-dependent. For incoming messages, SSHTM will fill out the fields in the tmStateReference that is passed to TSM. TSM will check for an existing entry in the snmpTsmLCDTable. If none exists, it will create one using the provided info, by default using the SSHTM-recommended securityName. For both incoming and outgoing, the TSM will check the policy before creating an entry. Presumably, an error will be returned to the calling module and the processing will be aborted, if the policy says do not create the entry. The error-handling will become clear when I do the EOP. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David Harrington > Sent: Thursday, June 19, 2008 6:41 PM > To: isms@ietf.org > Subject: [Isms] pre-08 for TSM document > > Hi, > > I have added the MIB tables we discussed. > I have not yet adjusted any of the non-MIB documentation. > Please see whether these MIB tables look appropriate. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 19 11:07:13 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93823A684B; Thu, 19 Jun 2008 11:07:13 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A2F3A6817 for ; Thu, 19 Jun 2008 11:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZZkf1VMPDNh for ; Thu, 19 Jun 2008 11:07:11 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 720E23A67A5 for ; Thu, 19 Jun 2008 11:07:09 -0700 (PDT) Received: (qmail 14036 invoked from network); 19 Jun 2008 14:07:56 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 19 Jun 2008 14:07:56 -0400 From: "David B. Nelson" To: References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> Date: Thu, 19 Jun 2008 14:07:55 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org "These MIB objects SHOULD NOT be modified via other documents." DBN: You mean "by subsystems or models described in other documents"? snmpTsmInadequateSecurityLevels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the actual securityLevel provided was less than the requested securityLevel." DBN: Does this assume that individual messages are dropped? It seems to me that the securityLevel inadequacy is going to be on a per transport connection basis, not on a per message basis. All messages coming through the same transport connection will have the same securityLevel, no? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 19 11:18:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39E23A684B; Thu, 19 Jun 2008 11:18:25 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A822E3A684B for ; Thu, 19 Jun 2008 11:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSfpGoyn-i5r for ; Thu, 19 Jun 2008 11:18:20 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 1E32C3A6817 for ; Thu, 19 Jun 2008 11:18:20 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m5JIJAJA011713 for ; Thu, 19 Jun 2008 14:19:11 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m5JIJAx8011697; Thu, 19 Jun 2008 14:19:10 -0400 Received: from IMCSRV3.MITRE.ORG ([129.83.20.198]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 14:19:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 14:19:09 -0400 Message-ID: <6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Isms] pre-08 for TSM document Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAAENBpA= References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> From: "Purvis, Ray" To: "David B. Nelson" X-OriginalArrivalTime: 19 Jun 2008 18:19:10.0691 (UTC) FILETIME=[F85D1330:01C8D238] Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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="===============1036292333==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multipart message in MIME format. --===============1036292333== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002C_01C8D20F.0EF41A00" This is a multipart message in MIME format. ------=_NextPart_000_002C_01C8D20F.0EF41A00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If a TM is developed under TSM that uses DTLS, or any other connectionless protocol based method, then it would be a per message basis, wouldn't it? v/r Ray Purvis -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of David B. Nelson Sent: Thursday, June 19, 2008 1:08 PM To: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document "These MIB objects SHOULD NOT be modified via other documents." DBN: You mean "by subsystems or models described in other documents"? snmpTsmInadequateSecurityLevels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the actual securityLevel provided was less than the requested securityLevel." DBN: Does this assume that individual messages are dropped? It seems to me that the securityLevel inadequacy is going to be on a per transport connection basis, not on a per message basis. All messages coming through the same transport connection will have the same securityLevel, no? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_002C_01C8D20F.0EF41A00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKuzCCA2Qw ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQL ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3Qg Q0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJlLm9y ZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3Jh dGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiEJv5v MtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNXnOLj XtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsAl5Wn xwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUHRCtC blrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjWnwE8 A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0OBBYE FMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwkfJXu XNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJdv51a HTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liBl8jx pN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsCAhGh dnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spULZfB nQYdEpyz5tgh7Y2qMIIDZzCCAk+gAwIBAgICFqswDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJF IENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODAyMTMxNTM1MjJaFw0wOTA4MDYxNTM1MjJa MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZImiZPyLGQBARMH cnB1cnZpczEaMBgGA1UEAxMRUHVydmlzIFJheW1vbmQgSy4wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAMLsR5jBXwsj9oNA5OPbuTND/QTAJlridlWBGFeE33+FbKLTwm36BWwlRA+Vtzu4z1wh mXat+JWyT5gGl6/K5mH3XZdlvowgkNpAOIhuzdeym6J1djv4r6VhwqBC0hoDumuKdLCalYbhCqtL kVE4pZehT8jpV/7+tn9xacyAGPFFAgMBAAGjgbcwgbQwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW BBSFbMT3jYifJ8L8HaW7UztasSWlezAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21p dHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERcnB1cnZpc0BtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQAD ggEBACNPzWemHNWSeK5noshsdg8PH+1PjDRbUyNskeTIuN6LFdEd08Fw8rPqjbbWjVmVLqZ3j4Tq UIn27ojMbjvfoWUWSo2cxv+kIaDGshtb+NEcd9t9xk948qu9OvV+vruTtEvRbdREiDV5cbW7WCJA 3rUmELvKvEtR0/SUkeQjXsoj84HyiUVPsVCxRTajLO3hQvXz0Z2GSXs8Ek2Q3N4gA8Ov88dAaUfp wjBj5+KZlbd8oWf+7mdS7+gI6p/BghoXXMDrsDv558ak+H9a0WDoILvixJG1jKESbyHgm5olj5fK lCVWlPbtuLX/oG5LPhtr7OsbgBPFVSp1EmE8aPV6VW8wggPkMIICzKADAgECAgEFMA0GCSqGSIb3 DQEBBQUAMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y aXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIy WhcNMTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFP MXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2 ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhIC fgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzzt C+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBq mQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQW BBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBI BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNh MV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClq ix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatG moibqP/8WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo8 2ZiyU680ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M 6WHcxWXtp3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxM nGdh7NqgMYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRp ZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x AgIWqzAJBgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wODA2MTkxODE5MDlaMCMGCSqGSIb3DQEJBDEWBBSkIjYQNei8PvcMaMi67PVDEuhFHTBn BgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3 EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y aXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAharMHQGCyqGSIb3 DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIWqzANBgkq hkiG9w0BAQEFAASBgB5TFcWy7OQXNWo4nbjxh2kmSBO0ImFFzguBzY5VN2mBSlU1DHKOwk+LqZ66 0VpauXqo7eheO2NefjV/HC21i96n46CTJ97i4QzYEGciXQhWSZqncL5r/bu+GT78PysmUID2YL79 NIAjZ9MwgwmX89tEHBr1PneKjwGawXALOOyQAAAAAAAA ------=_NextPart_000_002C_01C8D20F.0EF41A00-- --===============1036292333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --===============1036292333==-- From isms-bounces@ietf.org Thu Jun 19 11:33:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDBD28C12B; Thu, 19 Jun 2008 11:33:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD533A6984 for ; Thu, 19 Jun 2008 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhSuNNXdQMQr for ; Thu, 19 Jun 2008 11:33:46 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 29F3E3A697D for ; Thu, 19 Jun 2008 11:33:45 -0700 (PDT) Received: (qmail 14710 invoked from network); 19 Jun 2008 14:34:37 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 19 Jun 2008 14:34:37 -0400 From: "David B. Nelson" To: References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG> Date: Thu, 19 Jun 2008 14:34:36 -0400 Organization: Elbrys Networks, Inc. Message-ID: <3969B00F552D4DE48AAAAD7D32D94E81@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAAENBpAAAHwRgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG> Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > If a TM is developed under TSM that uses DTLS, or any other connectionless > protocol based method, then it would be a per message basis, wouldn't it? No, not really. Whenever there is encryption or a cryptographic checksum involved, even a datagram based transport needs to keep track of which message belongs to which connection, otherwise the wrong keys are applied. The transport knows which packet belongs to which connection. I suppose the question is whether the TSM knows that? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 19 17:49:51 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306A73A6839; Thu, 19 Jun 2008 17:49:51 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EAF3A67FE for ; Thu, 19 Jun 2008 17:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIHZ8VPW3EOa for ; Thu, 19 Jun 2008 17:49:48 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 665C73A6895 for ; Thu, 19 Jun 2008 17:49:18 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id fzZM1Z0040vp7WLA20Cc00; Fri, 20 Jun 2008 00:49:17 +0000 Received: from Harrington73653 ([222.128.247.59]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id g0lN1Z00J1HdlbS8R0lVN8; Fri, 20 Jun 2008 00:45:37 +0000 X-Authority-Analysis: v=1.0 c=1 a=gwGctozfSGYy14ty8JKq6A==:17 a=48vgC7mUAAAA:8 a=18FMIU2twWxoUH6AqQ8A:9 a=XYCDwhRI9pG5WUn0GZgA:7 a=1mL_jYwd6nTjwjl7pnaunho25OYA:4 a=lZB815dzVvQA:10 a=XF7b4UCPwd8A:10 X-Authority-Analysis: v=1.0 c=1 a=gwGctozfSGYy14ty8JKq6A==:17 a=48vgC7mUAAAA:8 a=18FMIU2twWxoUH6AqQ8A:9 a=XYCDwhRI9pG5WUn0GZgA:7 a=1mL_jYwd6nTjwjl7pnaunho25OYA:4 a=lZB815dzVvQA:10 a=XF7b4UCPwd8A:10 From: "David Harrington" To: "'David B. Nelson'" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com><6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG> <3969B00F552D4DE48AAAAD7D32D94E81@xpsuperdvd2> Date: Fri, 20 Jun 2008 08:45:22 +0800 Message-ID: <013d01c8d26e$f463b5f0$3bf780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3969B00F552D4DE48AAAAD7D32D94E81@xpsuperdvd2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAAENBpAAAHwRgAAM29/w Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org The TSM does not know about transport-specific sessions. It knows only about the "thing" that can be identified using transportdomain, address, security name and level. It also knows about some opaque identifier (snmpTsmLCDName) that is presumabkly meaningful to the transport layer. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > Sent: Friday, June 20, 2008 2:35 AM > To: isms@ietf.org > Subject: Re: [Isms] pre-08 for TSM document > > > If a TM is developed under TSM that uses DTLS, or any other > connectionless > > protocol based method, then it would be a per message > basis, wouldn't it? > > No, not really. Whenever there is encryption or a > cryptographic checksum > involved, even a datagram based transport needs to keep track of which > message belongs to which connection, otherwise the wrong keys > are applied. > The transport knows which packet belongs to which connection. > I suppose the > question is whether the TSM knows that? > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 20 06:31:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224313A6A7C; Fri, 20 Jun 2008 06:31:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC22928C151 for ; Fri, 20 Jun 2008 06:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsXLjG62SQrV for ; Fri, 20 Jun 2008 06:31:45 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id D2B5428C14F for ; Fri, 20 Jun 2008 06:31:44 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA03.westchester.pa.mail.comcast.net with comcast id gAoJ1Z00H17dt5G530Cc00; Fri, 20 Jun 2008 13:31:46 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA13.westchester.pa.mail.comcast.net with comcast id gDXk1Z00924Kx1C3ZDXkvU; Fri, 20 Jun 2008 13:31:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=Wrj3ujcX-ytQxMPhBXEA:9 a=06f-W5MaHi_hjGY1KM0A:7 a=sA05ATjAOwdl8px1kKBAmk_cKW4A:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com><6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG><3969B00F552D4DE48AAAAD7D32D94E81@xpsuperdvd2> <013d01c8d26e$f463b5f0$3bf780de@china.huawei.com> Date: Fri, 20 Jun 2008 09:31:50 -0400 Message-ID: <01bd01c8d2d9$ff9f5f30$011716ac@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <013d01c8d26e$f463b5f0$3bf780de@china.huawei.com> Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAAENBpAAAHwRgAAM29/wABrYnGA= Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > The TSM does not know about transport-specific sessions. > > It knows only about the "thing" that can be identified using > transportdomain, address, security name and level. It also knows about > some opaque identifier (snmpTsmLCDName) that is presumabkly meaningful > to the transport layer. snmpTsmInadequateSecurityLevels OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the actual securityLevel provided was less than the requested securityLevel." So then, this object is incremented by the TSM when the securityLevel passed via the ASI isn't what is expected? If the securityLevel is part of the "index" of the "thing" how can that work? That is to say, how can it have an unexpected value and at the same time be used to distinguish (index) one connection vs. another? Maybe I'm just dense... _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 20 08:43:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2973A69BC; Fri, 20 Jun 2008 08:43:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1123A68B5 for ; Fri, 20 Jun 2008 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9gm0z+qNhCD for ; Fri, 20 Jun 2008 08:43:47 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 2EEC53A6866 for ; Fri, 20 Jun 2008 08:43:47 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id gDTk1Z0040S2fkCA20EP00; Fri, 20 Jun 2008 15:43:48 +0000 Received: from Harrington73653 ([222.128.247.35]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id gFjY1Z00W0mZdV28VFje7U; Fri, 20 Jun 2008 15:43:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=kWYUB8DnzQhcgMpHJ18A:9 a=lrfKy4bw2BFUnTwGK0AA:7 a=HjOXNgvgc4uNZ0-iI9vffRIyexAA:4 a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=m-cwX0H6ZdQA:10 From: "David Harrington" To: "'David B. Nelson'" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com><6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG><3969B00F552D4DE48AAAAD7D32D94E81@xpsuperdvd2> <013d01c8d26e$f463b5f0$3bf780de@china.huawei.com> <01bd01c8d2d9$ff9f5f30$011716ac@NEWTON603> Date: Fri, 20 Jun 2008 23:43:34 +0800 Message-ID: <005901c8d2ec$6dedb970$23f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <01bd01c8d2d9$ff9f5f30$011716ac@NEWTON603> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAAENBpAAAHwRgAAM29/wABrYnGAAAjWcIA== Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org comments inline > -----Original Message----- > From: David B. Nelson [mailto:d.b.nelson@comcast.net] > Sent: Friday, June 20, 2008 9:32 PM > To: isms@ietf.org > Cc: 'David Harrington' > Subject: RE: [Isms] pre-08 for TSM document > > > The TSM does not know about transport-specific sessions. > > > > It knows only about the "thing" that can be identified using > > transportdomain, address, security name and level. It also > knows about > > some opaque identifier (snmpTsmLCDName) that is presumabkly > meaningful > > to the transport layer. > > snmpTsmInadequateSecurityLevels OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The number of incoming messages dropped because > the actual securityLevel provided was less than > the requested securityLevel." > > So then, this object is incremented by the TSM when the > securityLevel passed > via the ASI isn't what is expected? No. This error can only occur for an incoming message. securityLevel in the ASI comes from the message header of an incoming message. tmTransportSecurityLevel is the level asserted by the transport model, based on whatever information it has about the services provided by the lower layer. Compare the value of tmTransportSecurityLevel in the tmStateReference cache to the value of the securityLevel parameter passed in the processIncomingMsg ASI. If securityLevel specifies privacy (Priv), and tmTransportSecurityLevel specifies no privacy (noPriv), or securityLevel specifies authentication (auth) and tmTransportSecurityLevel specifies no authentication (noAuth) was provided by the Transport Model, then the snmpTsmInadequateSecurityLevels counter is incremented, and an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module. Transport Security Model processing stops for this message. > If the securityLevel is > part of the > "index" of the "thing" how can that work? That is to say, > how can it have > an unexpected value and at the same time be used to > distinguish (index) one > connection vs. another? Maybe I'm just dense... > The existing revision never says when the LCD is created for an incoming message; the revision-in-progress will. It happens after it checks for a valid level. If the level is invalid, it won't be used to index into the LCD for that message. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 20 12:26:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52383A69DA; Fri, 20 Jun 2008 12:26:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398EF3A69DA for ; Fri, 20 Jun 2008 12:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zygDjRz+PPo for ; Fri, 20 Jun 2008 12:26:56 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 568DF3A699E for ; Fri, 20 Jun 2008 12:26:54 -0700 (PDT) Received: (qmail 13104 invoked from network); 20 Jun 2008 14:26:51 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 20 Jun 2008 14:26:51 -0400 From: "David B. Nelson" To: References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com><6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG><3969B00F552D4DE48AAAAD7D32D94E81@xpsuperdvd2><013d01c8d26e$f463b5f0$3bf780de@china.huawei.com><01bd01c8d2d9$ff9f5f30$011716ac@NEWTON603> <005901c8d2ec$6dedb970$23f780de@china.huawei.com> Date: Fri, 20 Jun 2008 14:26:47 -0400 Organization: Elbrys Networks, Inc. Message-ID: <5664A4E324E3429693C397052A28BBFA@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAAENBpAAAHwRgAAM29/wABrYnGAAAjWcIAAIJ2aw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <005901c8d2ec$6dedb970$23f780de@china.huawei.com> Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > Compare the value of tmTransportSecurityLevel in the > tmStateReference cache to the value of the securityLevel > parameter passed in the processIncomingMsg ASI. Under what circumstances could these be different? Does it require a nonconforming implementation to trigger this, or simply a misconfiguration? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 20 19:00:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71ED73A680A; Fri, 20 Jun 2008 19:00:12 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740753A680B for ; Fri, 20 Jun 2008 19:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IziKugkZekxs for ; Fri, 20 Jun 2008 19:00:09 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 2B1A13A680A for ; Fri, 20 Jun 2008 19:00:09 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id gEUb1Z0040vp7WLA10jL00; Sat, 21 Jun 2008 02:00:11 +0000 Received: from Harrington73653 ([222.128.247.35]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id gRzu1Z00C0mZdV28RS01qA; Sat, 21 Jun 2008 02:00:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=4dJejKqrN3UrsMWFhTMA:9 a=2IpwPGVOz3pXmeWjn8NVbybXh2gA:4 a=-utQw5L2n1AA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'David B. Nelson'" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com><6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG><3969B00F552D4DE48AAAAD7D32D94E81@xpsuperdvd2><013d01c8d26e$f463b5f0$3bf780de@china.huawei.com><01bd01c8d2d9$ff9f5f30$011716ac@NEWTON603> <005901c8d2ec$6dedb970$23f780de@china.huawei.com> <5664A4E324E3429693C397052A28BBFA@xpsuperdvd2> Date: Sat, 21 Jun 2008 09:59:54 +0800 Message-ID: <00b001c8d342$88909c60$23f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <5664A4E324E3429693C397052A28BBFA@xpsuperdvd2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAAENBpAAAHwRgAAM29/wABrYnGAAAjWcIAAIJ2awAA8cxVA= Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, With SSH, they are unlikely to differ in a manner that matters. SSH provides no standardized feedback for applications that use it. Because SSHTM has no visibility to the underlying transport security, we tell operators they MUST configure for authpriv; if they do not, that is a configuration error. SSHTM always asserts authpriv was used. As long as what is asserted is greater than or equal to what is requested (and you cannot request higher than authpriv), the InadequateLevel error is not triggered. With a transport that actually tells the transport model what properties were applied, we could distinguish between "dbh@address:authpriv" from "dbh@address:noauthnopriv". Applications can request different levels, and TSM could check whether the level provided is at least as strong as requested. If an SSHTM implementation uses an SSH toolkit (or builds their own) whose API provides feedback about what auth and priv protocols were actually used, SSHTM could detect when auth or priv were not provided, and that implementation could do better than the hardcoded authpriv assertion of the standard at determining whether the actual level is at least as strong as that requested. dbh > -----Original Message----- > From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] > Sent: Saturday, June 21, 2008 2:27 AM > To: isms@ietf.org > Cc: 'David Harrington' > Subject: RE: [Isms] pre-08 for TSM document > > > Compare the value of tmTransportSecurityLevel in the > > tmStateReference cache to the value of the securityLevel > > parameter passed in the processIncomingMsg ASI. > > Under what circumstances could these be different? Does it require a > nonconforming implementation to trigger this, or simply a > misconfiguration? > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jun 24 02:10:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87993A6829; Tue, 24 Jun 2008 02:10:36 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889943A6829 for ; Tue, 24 Jun 2008 02:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwFwrltsAf54 for ; Tue, 24 Jun 2008 02:10:32 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 154AC3A6861 for ; Tue, 24 Jun 2008 02:10:31 -0700 (PDT) X-Trace: 102039786/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.138.146 X-SBRS: None X-RemoteIP: 62.188.138.146 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAARXYEg+vIqS/2dsb2JhbACDXYgxpmUD X-IronPort-AV: E=Sophos;i="4.27,695,1204502400"; d="scan'208";a="102039786" X-IP-Direction: IN Received: from 1cust146.tnt9.lnd4.gbr.da.uu.net (HELO allison) ([62.188.138.146]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Jun 2008 10:10:20 +0100 Message-ID: <007f01c8d5d1$01b0bc20$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> Date: Tue, 24 Jun 2008 09:58:24 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Looks good. I think that my concerns with SSHTM remain unaltered by this. Focussing on this I-D, you say that the TM will not alter the LCD table, but I think that it will struggle to read it, at least on inbound messages, as it cannot be sure what the securityName is and so cannot index into the table. It could walk the table looking for a matching snmpTsmLCDName ... well perhaps not. I assume that snmpTsmLCDName is tmSecurityName; could the names be more similar or is there a subtle point that I am missing in them being so different? I am concerned at the length of snmpTsmLCDName, at 32 maximum. I am aware of no such constraint for an SSH user name. And as you probably realise, the Security Considerations will need an update viz "8.1. MIB module security There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create." Tom Petch ----- Original Message ----- From: "David Harrington" To: "'David Harrington'" ; Sent: Thursday, June 19, 2008 1:43 PM Subject: Re: [Isms] pre-08 for TSM document > Hi, > > I should probably provide a little guidance on this MIB. > Due to modularity rules, only the TSM will actually manipulate this > MIB. > It might also be the only module to read the MIB. > (Implementations of course can optimize as they wish). > > TSM will convert from ASI parameters to LCD, and from LCD to ASI > parameters. In C++ terms, this is a "private" datastore, accessible > through "public" interfaces. I started calling this the > snmpTsmUserTable, but that could be misleading, so I changed it the > snmpTsmLCDTable. Let me know which you prefer, or if you have another > name you prefer. > > For outgoing messages, the application ASIs will provide securityName, > Level, domain, and address. These may, of course, come from the > RFC3413 MIB modules. > > The TSM MIB may be preconfigured with desired mappings, so the TSM > will look to see if there is an entry for the provided securityName, > Level, domain, and address. If not, the TSM will create an entry, and > by default, the provided securityName will be used as both the > LCDSecurityName and the LCDName. (I debated whether to name the label > default or identity. > > Then, the TSM will make a request of the transport model, converting > the LCD info into the ASI parameters (passing a tmStateReference, > containing info in the fields). The transport model will work with the > info from the tmStateReference, not the LCDTable. The SSHTM will also > have a local config datastore, but we are not defining that since it > is SSH configuration. How SSHTM uses the tmStateReference equivalent > of LCDName is implementation-dependent. > > For incoming messages, SSHTM will fill out the fields in the > tmStateReference that is passed to TSM. TSM will check for an existing > entry in the snmpTsmLCDTable. If none exists, it will create one using > the provided info, by default using the SSHTM-recommended > securityName. > > For both incoming and outgoing, the TSM will check the policy before > creating an entry. Presumably, an error will be returned to the > calling module and the processing will be aborted, if the policy says > do not create the entry. The error-handling will become clear when I > do the EOP. > > dbh > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jun 25 22:53:27 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03E03A6961; Wed, 25 Jun 2008 22:53:27 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391E828C0EF for ; Wed, 25 Jun 2008 22:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rp-DsT-oX5G for ; Wed, 25 Jun 2008 22:53:25 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 3AC703A67B7 for ; Wed, 25 Jun 2008 22:53:25 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA09.westchester.pa.mail.comcast.net with comcast id iVq31Z0010xGWP85900900; Thu, 26 Jun 2008 05:53:27 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA12.westchester.pa.mail.comcast.net with comcast id iVtA1Z0021m6Z1J3YVtE9f; Thu, 26 Jun 2008 05:53:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=7AoCz7iGN4vfJ4cAkm4A:9 a=YAh8aN_ZnaIpWxIQEGgA:7 a=y4QYvxMAx7BfjfHHrSdVn2sybMEA:4 a=-utQw5L2n1AA:10 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'David B. Nelson'" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> Date: Thu, 26 Jun 2008 13:53:09 +0800 Message-ID: <019701c8d750$f2cdfac0$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAUbwAJA= Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] > Sent: Friday, June 20, 2008 2:08 AM > To: isms@ietf.org > Cc: 'David Harrington' > Subject: RE: [Isms] pre-08 for TSM document > > "These MIB objects SHOULD NOT be modified via other documents." > > DBN: You mean "by subsystems or models described in other documents"? fixed. > > snmpTsmInadequateSecurityLevels OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The number of incoming messages dropped because > the actual securityLevel provided was less than > the requested securityLevel." > > DBN: Does this assume that individual messages are dropped? > It seems to me > that the securityLevel inadequacy is going to be on a per transport > connection basis, not on a per message basis. All messages > coming through > the same transport connection will have the same securityLevel, no? As explained in another message, securityLevel is defined in two places. The transport model reports what the transport provided (to the best of the TM's knowledge), and the messahe contains a requested securityLevel. These two values are compared. The transport securityLevel is likely the same over the lifetime of the transport session. (I only say likely to accommodate currently-unspecified transport models) The requested securityLevel is specified on a per-message basis, the comparison is done on a per-message basis, and the drop is done on a per-message basis. dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jun 25 22:54:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318843A68DB; Wed, 25 Jun 2008 22:54:40 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03CF3A67B7 for ; Wed, 25 Jun 2008 22:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRvxGfW1diaa for ; Wed, 25 Jun 2008 22:54:37 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 93E173A68DB for ; Wed, 25 Jun 2008 22:54:37 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA03.westchester.pa.mail.comcast.net with comcast id iT2s1Z00D0xGWP85308Z00; Thu, 26 Jun 2008 05:54:38 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA12.westchester.pa.mail.comcast.net with comcast id iVuM1Z0091m6Z1J3YVuRHA; Thu, 26 Jun 2008 05:54:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=39KntjWA8ydGWrye4EMA:9 a=qG0xh2BKmP0IuR73TKoA:7 a=fsXhoJOdPoaQ5p2mXx-aE-XLlh4A:4 a=lZB815dzVvQA:10 a=wCaoJTriV0sA:10 From: "David Harrington" To: "'Purvis, Ray'" , "'David B. Nelson'" References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG> Date: Thu, 26 Jun 2008 13:54:20 +0800 Message-ID: <019801c8d751$1d11d590$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6AC65FD74E2B984A95EED496FBFC59FC05E6C9ED@IMCSRV3.MITRE.ORG> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAAENBpABRhizEA== Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org yes. it is always on a per-SNMP-message basis regardless of transport protocol. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Purvis, Ray > Sent: Friday, June 20, 2008 2:19 AM > To: David B. Nelson > Cc: isms@ietf.org > Subject: Re: [Isms] pre-08 for TSM document > > If a TM is developed under TSM that uses DTLS, or any other > connectionless > protocol based method, then it would be a per message basis, > wouldn't it? > > v/r > > Ray Purvis > > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of > David B. Nelson > Sent: Thursday, June 19, 2008 1:08 PM > To: isms@ietf.org > Subject: Re: [Isms] pre-08 for TSM document > > "These MIB objects SHOULD NOT be modified via other documents." > > DBN: You mean "by subsystems or models described in other documents"? > > snmpTsmInadequateSecurityLevels OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The number of incoming messages dropped because > the actual securityLevel provided was less than > the requested securityLevel." > > DBN: Does this assume that individual messages are dropped? > It seems to me > that the securityLevel inadequacy is going to be on a per transport > connection basis, not on a per message basis. All messages > coming through > the same transport connection will have the same securityLevel, no? > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jun 26 08:55:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E713A6943; Thu, 26 Jun 2008 08:55:31 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D3C3A6943 for ; Thu, 26 Jun 2008 08:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHRwYrDtnhIi for ; Thu, 26 Jun 2008 08:55:29 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 8470E3A68FD for ; Thu, 26 Jun 2008 08:55:29 -0700 (PDT) Received: (qmail 24660 invoked from network); 26 Jun 2008 10:55:30 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 26 Jun 2008 10:55:30 -0400 From: "David B. Nelson" To: References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <019701c8d750$f2cdfac0$51f780de@china.huawei.com> Date: Thu, 26 Jun 2008 10:55:19 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjR+P+cbQ/qSrASSnqKhs6oU6pNdgAO2R8gAUbwAJAAEvSroA== In-Reply-To: <019701c8d750$f2cdfac0$51f780de@china.huawei.com> Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > > snmpTsmInadequateSecurityLevels OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION "The number of incoming messages dropped because > > the actual securityLevel provided was less than > > the requested securityLevel." > > > > DBN: Does this assume that individual messages are dropped? > > It seems to me > > that the securityLevel inadequacy is going to be on a per transport > > connection basis, not on a per message basis. All messages > > coming through > > the same transport connection will have the same securityLevel, no? > The requested securityLevel is specified on a per-message basis, the > comparison is done on a per-message basis, and the drop is done on a > per-message basis. OK, I get it now. Maybe you should modify the DESCRIPTION clause to say: DESCRIPTION "The number of incoming messages dropped because the securityLevel reported by the transport to the SNMP Transport Model was less than the securityLevel requested in the SNMP PDU." _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 00:12:29 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D708C3A6AA1; Fri, 27 Jun 2008 00:12:29 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596CF3A6A31 for ; Fri, 27 Jun 2008 00:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmUCYYV9sptn for ; Fri, 27 Jun 2008 00:12:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AB0553A6AA1 for ; Fri, 27 Jun 2008 00:12:24 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9124C0039; Fri, 27 Jun 2008 09:12:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lkPpnZ6SmEed; Fri, 27 Jun 2008 09:12:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D12FC005B; Fri, 27 Jun 2008 09:12:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A27E75E0EE5; Fri, 27 Jun 2008 09:12:20 +0200 (CEST) Date: Fri, 27 Jun 2008 09:12:20 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20080627071220.GA2713@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , isms@ietf.org References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <007f01c8d5d1$01b0bc20$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote: > Focussing on this I-D, you say that the TM will not alter the LCD > table, but I think that it will struggle to read it, at least on > inbound messages, as it cannot be sure what the securityName is and > so cannot index into the table. It could walk the table looking for > a matching snmpTsmLCDName ... well perhaps not. I fail to see why a TM needs to read the table. The TM just passes the name provided by the transport via the tmStateReferences and TSM then does any mappings as needed. > I assume that snmpTsmLCDName is tmSecurityName; could the names be > more similar or is there a subtle point that I am missing in them > being so different? I agree that finding good labels is important. I am not having a good constructive idea yet... Checking RFC 3411 again, I see there it makes a distinction between a securityName and a security ID, where the security ID seems to be pretty close to our tmSecurityName. Dave, do you agree with this reading of RFC3411? > I am concerned at the length of snmpTsmLCDName, at 32 maximum. I am > aware of no such constraint for an SSH user name. Since snmpTsmLCDName is not used in an INDEX, I think we can easily drop the length restriction. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 00:25:29 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ECAD3A6A31; Fri, 27 Jun 2008 00:25:29 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490E13A6A31 for ; Fri, 27 Jun 2008 00:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsLBJWocMOol for ; Fri, 27 Jun 2008 00:25:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 73AFD3A67E9 for ; Fri, 27 Jun 2008 00:25:26 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24F4EC005E; Fri, 27 Jun 2008 09:25:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wBBsEfZ+sUwp; Fri, 27 Jun 2008 09:25:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1E7EC0035; Fri, 27 Jun 2008 09:25:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 259335E0F2A; Fri, 27 Jun 2008 09:25:19 +0200 (CEST) Date: Fri, 27 Jun 2008 09:25:19 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080627072519.GB2713@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Thu, Jun 19, 2008 at 07:43:22PM +0800, David Harrington wrote: > I started calling this the snmpTsmUserTable, but that could be > misleading, so I changed it the snmpTsmLCDTable. Let me know which > you prefer, or if you have another name you prefer. I find snmpTsmLCDTable too broad; the snmpTsmLCDTransformTable is also stored in the LCD. The table really is a snmpTsmSecurityNameMappingTable or a snmpTsmTmMappingTable or a snmpTsmNameMappingTable. Or what about snmpTsmTmNameTable? Nits: - s/2007/2008/ - The import of TEXTUAL-CONVENTION is not used. - Missing dot at the end of the first sentence in section 6.3.2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 04:55:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3AD3A6B75; Fri, 27 Jun 2008 04:55:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91E23A6B75 for ; Fri, 27 Jun 2008 04:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZfqFuDRgUvn for ; Fri, 27 Jun 2008 04:55:46 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id CAC063A6B55 for ; Fri, 27 Jun 2008 04:55:41 -0700 (PDT) X-Trace: 1241809/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.60.165 X-SBRS: None X-RemoteIP: 213.116.60.165 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAKhyZEjVdDyl/2dsb2JhbACDXzGID6YnAw X-IronPort-AV: E=Sophos;i="4.27,715,1204502400"; d="scan'208";a="1241809" X-IP-Direction: IN Received: from 1cust165.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.165]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Jun 2008 12:55:37 +0100 Message-ID: <008f01c8d843$954821c0$0601a8c0@allison> From: "tom.petch" To: References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> Date: Fri, 27 Jun 2008 12:49:25 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: [Isms] tm table was Re: pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Just continuing with the first point, my concern is a SSHTM one in that I cannot see how it works. On an incoming call, the SSHTM will know transport addresses, ports and type, SSH user name, SSH host name and will have an SSH session identifier; I assume that this will be stored in an internal SSHTM table(or cache). When a message subsequently arrives over that session, SSHTM cannot know the securityLevel or securityName (as generated by the message originator), the former is buried in the ASN.1, the latter is the province of the SM not the TM. So on an outgoing message at some later time, it cannot match the 4-tuple of transportDomain and transportAddress, securityName and securityLevel that is used elsewhere in the stack to identify the session to be used for a message. I thought that snmpTsmLCDTable would provide an answer but I don't see it. (The SSHTM I-D says " 1) Determine the target index by extracting the transportDomain, transportAddress, securityName, and securityLevel from the tmStateReference. 2) Lookup the session in the Local Configuration Datastore using the target index " ) Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "David Harrington" ; Sent: Friday, June 27, 2008 9:12 AM Subject: Re: [Isms] pre-08 for TSM document > On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote: > > > Focussing on this I-D, you say that the TM will not alter the LCD > > table, but I think that it will struggle to read it, at least on > > inbound messages, as it cannot be sure what the securityName is and > > so cannot index into the table. It could walk the table looking for > > a matching snmpTsmLCDName ... well perhaps not. > > I fail to see why a TM needs to read the table. The TM just passes the > name provided by the transport via the tmStateReferences and TSM then > does any mappings as needed. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 05:03:21 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753793A6B87; Fri, 27 Jun 2008 05:03:21 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE023A6847 for ; Fri, 27 Jun 2008 05:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud3slXdfp4ft for ; Fri, 27 Jun 2008 05:03:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 92B023A6B86 for ; Fri, 27 Jun 2008 05:02:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E336C0062; Fri, 27 Jun 2008 14:02:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id P5EK3YcsuRke; Fri, 27 Jun 2008 14:01:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 887B9C0061; Fri, 27 Jun 2008 14:01:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CCAF35E17C4; Fri, 27 Jun 2008 14:01:57 +0200 (CEST) Date: Fri, 27 Jun 2008 14:01:57 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20080627120157.GA3431@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , isms@ietf.org References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> <008f01c8d843$954821c0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <008f01c8d843$954821c0$0601a8c0@allison> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] tm table was Re: pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, Jun 27, 2008 at 12:49:25PM +0200, tom.petch wrote: > On an incoming call, the SSHTM will know transport addresses, ports > and type, SSH user name, SSH host name and will have an SSH session > identifier; I assume that this will be stored in an internal SSHTM > table(or cache). When a message subsequently arrives over that > session, SSHTM cannot know the securityLevel or securityName (as > generated by the message originator), the former is buried in the > ASN.1, the latter is the province of the SM not the TM. The TM caches the authenticated identity and passes this on via the tmStateReference. The SM picks up the value, it knows which TM has passed the tmStateReference, and it knows the actual security level and can check them. > So on an outgoing message at some later time, it cannot match the > 4-tuple of transportDomain and transportAddress, securityName and > securityLevel that is used elsewhere in the stack to identify the > session to be used for a message. I thought that snmpTsmLCDTable > would provide an answer but I don't see it. Why not? What do you think is missing? > (The SSHTM I-D says > " 1) Determine the target index by extracting the transportDomain, > transportAddress, securityName, and securityLevel from the > tmStateReference. > 2) Lookup the session in the Local Configuration Datastore using > the target index " ) I do not yet see why it won't work. Please explain. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 05:51:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B51F3A6A93; Fri, 27 Jun 2008 05:51:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAAE3A6A59 for ; Fri, 27 Jun 2008 05:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W69VOS13GJY for ; Fri, 27 Jun 2008 05:51:55 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 671393A68B3 for ; Fri, 27 Jun 2008 05:51:55 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA10.westchester.pa.mail.comcast.net with comcast id j09h1Z00N1HzFnQ5A06400; Fri, 27 Jun 2008 12:51:56 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA14.westchester.pa.mail.comcast.net with comcast id j0rV1Z00H1m6Z1J3a0rZxQ; Fri, 27 Jun 2008 12:51:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=apmEi2ZK6HQGKPnnKugA:9 a=RiZtXNwEufVwXhaDAhIA:7 a=kSWsWJcuRv2jEHnh6-BXLnUqA_wA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'tom.petch'" References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> Date: Fri, 27 Jun 2008 20:51:28 +0800 Message-ID: <029401c8d854$8cc78e80$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080627071220.GA2713@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjYJSxgK8qs7uzkQzGtS1DBISWDfgALKYJw Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, June 27, 2008 3:12 PM > To: tom.petch > Cc: David Harrington; isms@ietf.org > Subject: Re: [Isms] pre-08 for TSM document > > On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote: > > > Focussing on this I-D, you say that the TM will not alter the LCD > > table, but I think that it will struggle to read it, at least on > > inbound messages, as it cannot be sure what the securityName is and > > so cannot index into the table. It could walk the table looking for > > a matching snmpTsmLCDName ... well perhaps not. > > I fail to see why a TM needs to read the table. The TM just passes the > name provided by the transport via the tmStateReferences and TSM then > does any mappings as needed. A TM should not use this TSM table. This table is really all about getting the securityName, which is an SM thing. As I began to update the secshell document, I decided the "security ID" (snmpTsmLCDName) really should be in the TM, not the SM. The TM should provide a mapping from secuity ID to tmSecurityName, ans TSM should simply take tmSecurityName as securityName. Therefore, TSM doesn't need a mapping table, TM does. So I have started moving the mapping table to SSHTM. The Transform table really belongs in TM as well. I think the TM-disable belongs in TSM though, so I am splitting the TransformTable into a TSM-disable-domain-table, and an SSHTM-which-mapping-transform-table. You are absolutely right that on an incoming message, the TM will have a hard time reading the table because it is indexed by securityName, so the transform will need to be done before the table can be read to see if an entry already exists. I considered searching the table for address/LCDName, but since that is not an index, it is not guaranteed to be unique, and it is reasonable that a given address might have multiple SSH users. > > > I assume that snmpTsmLCDName is tmSecurityName; could the names be > > more similar or is there a subtle point that I am missing in them > > being so different? I think they really would be the same, but with the chnages I am proposing, that will not be an issue. > > I agree that finding good labels is important. I am not having a good > constructive idea yet... Checking RFC 3411 again, I see there it makes > a distinction between a securityName and a security ID, where the > security ID seems to be pretty close to our tmSecurityName. Dave, do > you agree with this reading of RFC3411? When I move this to SSHTM, we could simply name this SSHTMPrincipal or something similar. We have so many variations of securityName, this is sure to be confusing to people. > > > I am concerned at the length of snmpTsmLCDName, at 32 maximum. I am > > aware of no such constraint for an SSH user name. > > Since snmpTsmLCDName is not used in an INDEX, I think we can easily > drop the length restriction. Is there a limit to SSH user name? We should make sure they are consistent. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 06:06:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E279B3A6846; Fri, 27 Jun 2008 06:06:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32FB3A6846 for ; Fri, 27 Jun 2008 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGCq21JfQDWV for ; Fri, 27 Jun 2008 06:06:41 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id A34553A63EC for ; Fri, 27 Jun 2008 06:06:41 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA06.westchester.pa.mail.comcast.net with comcast id izyq1Z00317dt5G5604100; Fri, 27 Jun 2008 13:06:45 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA13.westchester.pa.mail.comcast.net with comcast id j1651Z0081m6Z1J3Z169MX; Fri, 27 Jun 2008 13:06:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=GP8MLVbdppoA:10 a=sit-KmRkgt0A:10 a=p4_xu-fAtNyT0iIK0CIA:9 a=FciDeqm8Oi5tqXqj1HUA:7 a=thdAaw3v44Ijw_mATAnakybdxcEA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'tom.petch'" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> <008f01c8d843$954821c0$0601a8c0@allison> Date: Fri, 27 Jun 2008 21:06:04 +0800 Message-ID: <029801c8d856$96c180b0$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <008f01c8d843$954821c0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjYTLz+26ZLbk1MQ2aZTG5QjmFW5AAB/d4A Cc: isms@ietf.org Subject: Re: [Isms] tm table was Re: pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, June 27, 2008 6:49 PM > To: j.schoenwaelder@jacobs-university.de > Cc: David Harrington; isms@ietf.org > Subject: tm table was Re: [Isms] pre-08 for TSM document > > Juergen > > Just continuing with the first point, my concern is a SSHTM > one in that I cannot > see how it works. > > On an incoming call, the SSHTM will know transport addresses, > ports and type, > SSH user name, SSH host name and will have an SSH session > identifier; I assume > that this will be stored in an internal SSHTM table(or > cache). When a message > subsequently arrives over that session, SSHTM cannot know the > securityLevel or > securityName (as generated by the message originator), the > former is buried in > the ASN.1, the latter is the province of the SM not the TM. Correct, the TM knows nothing about what is requested in the ASN.1 message. The tmSecurityLevel in the TM for an incoming message is supplied by interpreting the SSH security proprties. In SSH, this is not necessarily available so we assert that it is always authPriv. The SM will compare tmSecurityLevel with msgSecurityLevel to see if thSecurityLevel is greater than or equal to msgSecurityLevel (and for SSHTM, it always will be because authpriv is the highest level). > > So on an outgoing message at some later time, it cannot match > the 4-tuple of > transportDomain and transportAddress, securityName and > securityLevel that is > used elsewhere in the stack to identify the session to be > used for a message. I > thought that snmpTsmLCDTable would provide an answer but I > don't see it. The tmStateReference actually contains the requested level for an outgoing message (tmRequestedSecurityLevel). SSHTM then tells SSH to apply authpriv regardless of the (possibly lower level) request. Are you trying to identify a particular SSH session, where there might be multiple sessions associated with the 4-tuple? We have explicitly said the 4-tuple is unique; there cannot be two sessions for the same 4-tuple in SSHTM. > > (The SSHTM I-D says > " 1) Determine the target index by extracting the transportDomain, > transportAddress, securityName, and securityLevel from the > tmStateReference. > 2) Lookup the session in the Local Configuration Datastore using > the target index " ) > > Tom Petch > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "tom.petch" > Cc: "David Harrington" ; > Sent: Friday, June 27, 2008 9:12 AM > Subject: Re: [Isms] pre-08 for TSM document > > > > On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote: > > > > > Focussing on this I-D, you say that the TM will not alter the LCD > > > table, but I think that it will struggle to read it, at least on > > > inbound messages, as it cannot be sure what the > securityName is and > > > so cannot index into the table. It could walk the table > looking for > > > a matching snmpTsmLCDName ... well perhaps not. > > > > I fail to see why a TM needs to read the table. The TM just > passes the > > name provided by the transport via the tmStateReferences > and TSM then > > does any mappings as needed. > > > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 06:52:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B003A698A; Fri, 27 Jun 2008 06:52:14 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A003A6965 for ; Fri, 27 Jun 2008 06:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03nLQh65yNUM for ; Fri, 27 Jun 2008 06:52:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 863AA3A6918 for ; Fri, 27 Jun 2008 06:52:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4382C002E; Fri, 27 Jun 2008 15:52:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FbzCUAA6eMfW; Fri, 27 Jun 2008 15:52:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E430C0040; Fri, 27 Jun 2008 15:52:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A84DF5E1C0D; Fri, 27 Jun 2008 15:52:01 +0200 (CEST) Date: Fri, 27 Jun 2008 15:52:01 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080627135201.GD3294@elstar.local> Mail-Followup-To: David Harrington , "'tom.petch'" , isms@ietf.org References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> <029401c8d854$8cc78e80$51f780de@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <029401c8d854$8cc78e80$51f780de@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, Jun 27, 2008 at 08:51:28PM +0800, David Harrington wrote: > Is there a limit to SSH user name? We should make sure they are > consistent. usmUserName is SnmpAdminString (SIZE(1..32)) so there is a limit. On the other hand, there is no limit for snmpCommunityName. I am not sure we need to have identical limits for security IDs. The fun part is that in several places there is no limit for a securityName but VACM says vacmSecurityName is SnmpAdminString (SIZE(1..32)). So you can configure USM to map a user name to an snmpSecurityName for which it is impossible to specify access control rules in VACM. It looks we should have defined an SnmpSecurityName TC to make things really consistent... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 11:16:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BAD3A67E2; Fri, 27 Jun 2008 11:16:39 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3688B3A67E2 for ; Fri, 27 Jun 2008 11:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG-jkN783x+f for ; Fri, 27 Jun 2008 11:16:37 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id D67C23A679C for ; Fri, 27 Jun 2008 11:16:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAEBvV0g+vIJz/2dsb2JhbACLfaMHAw X-IronPort-AV: E=Sophos;i="4.27,716,1204502400"; d="scan'208";a="137627047" X-IP-Direction: IN Received: from 1cust115.tnt1.lnd4.gbr.da.uu.net (HELO allison) ([62.188.130.115]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Jun 2008 19:16:35 +0100 Message-ID: <049801c8d878$ce03f4a0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> <008f01c8d843$954821c0$0601a8c0@allison> <029801c8d856$96c180b0$51f780de@china.huawei.com> Date: Fri, 27 Jun 2008 19:10:08 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] tm table was Re: pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; Cc: Sent: Friday, June 27, 2008 3:06 PM Subject: RE: tm table was Re: [Isms] pre-08 for TSM document > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Friday, June 27, 2008 6:49 PM > > To: j.schoenwaelder@jacobs-university.de > > Cc: David Harrington; isms@ietf.org > > Subject: tm table was Re: [Isms] pre-08 for TSM document > > > > Juergen > > > > Just continuing with the first point, my concern is a SSHTM > > one in that I cannot > > see how it works. > > > > On an incoming call, the SSHTM will know transport addresses, > > ports and type, > > SSH user name, SSH host name and will have an SSH session > > identifier; I assume > > that this will be stored in an internal SSHTM table(or > > cache). When a message > > subsequently arrives over that session, SSHTM cannot know the > > securityLevel or > > securityName (as generated by the message originator), the > > former is buried in > > the ASN.1, the latter is the province of the SM not the TM. > > Correct, the TM knows nothing about what is requested in the ASN.1 > message. > > The tmSecurityLevel in the TM for an incoming message is supplied by > interpreting the SSH security proprties. In SSH, this is not > necessarily available so we assert that it is always authPriv. The SM > will compare tmSecurityLevel with msgSecurityLevel to see if > thSecurityLevel is greater than or equal to msgSecurityLevel (and for > SSHTM, it always will be because authpriv is the highest level). > Understand and am happy with that. > > > > So on an outgoing message at some later time, it cannot match > > the 4-tuple of > > transportDomain and transportAddress, securityName and > > securityLevel that is > > used elsewhere in the stack to identify the session to be > > used for a message. I > > thought that snmpTsmLCDTable would provide an answer but I > > don't see it. > > The tmStateReference actually contains the requested level for an > outgoing message (tmRequestedSecurityLevel). SSHTM then tells SSH to > apply authpriv regardless of the (possibly lower level) request. > Understand again. > Are you trying to identify a particular SSH session, where there might > be multiple sessions associated with the 4-tuple? We have explicitly > said the 4-tuple is unique; there cannot be two sessions for the same > 4-tuple in SSHTM. > Again, understand, but ... > > (The SSHTM I-D says > > " 1) Determine the target index by extracting the > transportDomain, > > transportAddress, securityName, and securityLevel from the > > tmStateReference. > > 2) Lookup the session in the Local Configuration Datastore > using > > the target index " ) ... from the information that the SSHTM has from receiving a session and subsequent inbound messages, it has no knowledge of securityName and securityLevel. So when an outbound message is passed down to it, and the SSHTM, as per EOP, is expected to use the 4-tuple to look for a session, then this may be the first that the SSHTM has ever heard of the particular values of securityName and securityLevel; it may have a match on tranportAddress and transportDomain in the table of sessions it has (initiated or) received (along with other SSH data), it could have several but how can it tell if the two security parameters match? (eg it cannot use tmTransportSecurityLevel as that is always authPriv for SSH and the application creating the outbound message may have had other ideas) I was envisaging that some unique index could pass from TM to SM so that SM could hand back index+securityName+securityLevel; or that there is a common table into which SM inserts securityName+securityLevel so that TM now can associate them with a session (but which the structure of the snmpTsmLCDTable now seems to rule out as a candiate) or .. Puzzled, Tom Petch > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: "tom.petch" > > Cc: "David Harrington" ; > > Sent: Friday, June 27, 2008 9:12 AM > > Subject: Re: [Isms] pre-08 for TSM document > > > > > > > On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote: > > > > > > > Focussing on this I-D, you say that the TM will not alter the > LCD > > > > table, but I think that it will struggle to read it, at least on > > > > inbound messages, as it cannot be sure what the > > securityName is and > > > > so cannot index into the table. It could walk the table > > looking for > > > > a matching snmpTsmLCDName ... well perhaps not. > > > > > > I fail to see why a TM needs to read the table. The TM just > > passes the > > > name provided by the transport via the tmStateReferences > > and TSM then > > > does any mappings as needed. > > > > > > > > > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jun 27 19:46:42 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E7A3A6A62; Fri, 27 Jun 2008 19:46:42 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326FC3A6A62 for ; Fri, 27 Jun 2008 19:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djxZ6jJWp9vU for ; Fri, 27 Jun 2008 19:46:40 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 0B5E83A695B for ; Fri, 27 Jun 2008 19:46:36 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA09.westchester.pa.mail.comcast.net with comcast id izDC1Z0070xGWP85916800; Sat, 28 Jun 2008 02:46:42 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA12.westchester.pa.mail.comcast.net with comcast id jEmM1Z0091m6Z1J3YEmST2; Sat, 28 Jun 2008 02:46:37 +0000 X-Authority-Analysis: v=1.0 c=1 a=GP8MLVbdppoA:10 a=sit-KmRkgt0A:10 a=XT-pehpcFIJmjRIWtu4A:9 a=TEvbds8q7HvIKqfuRrAA:7 a=ijuBidnygzqvZPTpXLpLfSZG55cA:4 a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'tom.petch'" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> <008f01c8d843$954821c0$0601a8c0@allison> <029801c8d856$96c180b0$51f780de@china.huawei.com> <049801c8d878$ce03f4a0$0601a8c0@allison> Date: Sat, 28 Jun 2008 10:46:20 +0800 Message-ID: <02fc01c8d8c9$2f1dfe20$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <049801c8d878$ce03f4a0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjYgfFAIEQYjAv7TCy7+nNOKE0PtgAREUTQ Cc: isms@ietf.org Subject: Re: [Isms] tm table was Re: pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > > > (The SSHTM I-D says > > > " 1) Determine the target index by extracting the > > transportDomain, > > > transportAddress, securityName, and securityLevel from the > > > tmStateReference. > > > 2) Lookup the session in the Local Configuration Datastore > > using > > > the target index " ) > > ... from the information that the SSHTM has from receiving a > session and > subsequent inbound messages, it has no knowledge of securityName and > securityLevel. OK. sometimes we talk about the concept instead the exact variable name that must be used. We are not implementing this, we are describing how it works conceptually. I will make sure to change this to say tmSecurityName and tmSecurityLevel. (or more accurately, tmRequestedSecurityLevel and tmTransportSecurityLevel). > So when an outbound message is passed down to > it, and the SSHTM, > as per EOP, is expected to use the 4-tuple to look for a > session, then this may > be the first that the SSHTM has ever heard of the particular values of > securityName and securityLevel; it may have a match on > tranportAddress and > transportDomain in the table of sessions it has (initiated > or) received (along > with other SSH data), it could have several but how can it > tell if the two > security parameters match? > > (eg it cannot use tmTransportSecurityLevel as that is always > authPriv for SSH > and the application creating the outbound message may have > had other ideas) > > I was envisaging that some unique index could pass from TM to > SM so that SM > could hand back index+securityName+securityLevel; or that > there is a common > table into which SM inserts securityName+securityLevel so > that TM now can > associate them with a session (but which the structure of the > snmpTsmLCDTable > now seems to rule out as a candiate) or .. > > Puzzled, > > Tom Petch > > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Juergen Schoenwaelder" > > > > To: "tom.petch" > > > Cc: "David Harrington" ; > > > Sent: Friday, June 27, 2008 9:12 AM > > > Subject: Re: [Isms] pre-08 for TSM document > > > > > > > > > > On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote: > > > > > > > > > Focussing on this I-D, you say that the TM will not alter the > > LCD > > > > > table, but I think that it will struggle to read it, > at least on > > > > > inbound messages, as it cannot be sure what the > > > securityName is and > > > > > so cannot index into the table. It could walk the table > > > looking for > > > > > a matching snmpTsmLCDName ... well perhaps not. > > > > > > > > I fail to see why a TM needs to read the table. The TM just > > > passes the > > > > name provided by the transport via the tmStateReferences > > > and TSM then > > > > does any mappings as needed. > > > > > > > > > > > > > > > > > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jun 30 10:33:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A83A3A6831; Mon, 30 Jun 2008 10:33:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC453A6832 for ; Mon, 30 Jun 2008 10:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg1AzHMPZh4E for ; Mon, 30 Jun 2008 10:33:04 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id D0DA13A6822 for ; Mon, 30 Jun 2008 10:33:03 -0700 (PDT) X-Trace: 138808545/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.144.119 X-SBRS: None X-RemoteIP: 62.188.144.119 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAEBvV0g+vJB3/2dsb2JhbACLfaMHAw X-IronPort-AV: E=Sophos;i="4.27,728,1204502400"; d="scan'208";a="138808545" X-IP-Direction: IN Received: from 1cust119.tnt15.lnd4.gbr.da.uu.net (HELO allison) ([62.188.144.119]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Jun 2008 18:33:09 +0100 Message-ID: <001e01c8dace$3a7c4540$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> <008f01c8d843$954821c0$0601a8c0@allison> <029801c8d856$96c180b0$51f780de@china.huawei.com> <049801c8d878$ce03f4a0$0601a8c0@allison> <02fc01c8d8c9$2f1dfe20$51f780de@china.huawei.com> Date: Mon, 30 Jun 2008 18:23:31 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] tm table was Re: pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; Cc: Sent: Saturday, June 28, 2008 4:46 AM Subject: RE: tm table was Re: [Isms] pre-08 for TSM document > > > > (The SSHTM I-D says > > > > " 1) Determine the target index by extracting the > > > transportDomain, > > > > transportAddress, securityName, and securityLevel from the > > > > tmStateReference. > > > > 2) Lookup the session in the Local Configuration Datastore > > > using > > > > the target index " ) > > > > ... from the information that the SSHTM has from receiving a > > session and > > subsequent inbound messages, it has no knowledge of securityName and > > securityLevel. > > OK. sometimes we talk about the concept instead the exact variable > name that must be used. We are not implementing this, we are > describing how it works conceptually. I will make sure to change this > to say tmSecurityName and tmSecurityLevel. (or more accurately, > tmRequestedSecurityLevel and tmTransportSecurityLevel). > I still think that it cannot work, conceptually or otherwise:-) A session is received, the TM gets information about the session which it can use to identify it but which cannot include the securityName and securityLevel as used by the application which has or is about to transport a message over the session. A message is received over this session which has this security information embedded within it but which is inaccessible to the TM, only to SM and MPM respectively, neither of which tell the TM about it; the TSM will put such information into a cache, which, as Juergen said, he saw no point in the TM even reading. An outbound message is now passed to the TM and the session to use is identified by the 4-tuple which includes securityName and securityLevel, which the TM has never heard of and which there is nowhere to use as an index to translate to information which the TM does understand (eg SSH session ID, SSH host name, SSH user name ...). Nor do I see how any model in the stack can create such a translation table so I do not see how can a message ever be sent over a session that already exists, and that includes a response to a request. The part that does work is when an outbound message creates a session; then and only then does the TM know the securityLevel and securityName associated with the session (and to create a new session if the transport details match but the security details differ). When I use securityName and securityLevel here I mean literally that, the values used by the application and most of the models in the stack to identify the session to be used (in conjunction with the two transport parameters) and not the proposed or such level parameters that may be translated into or from the application level parameters by the Security Model.. Tom Petch > > So when an outbound message is passed down to > > it, and the SSHTM, > > as per EOP, is expected to use the 4-tuple to look for a > > session, then this may > > be the first that the SSHTM has ever heard of the particular values > of > > securityName and securityLevel; it may have a match on > > tranportAddress and > > transportDomain in the table of sessions it has (initiated > > or) received (along > > with other SSH data), it could have several but how can it > > tell if the two > > security parameters match? > > > > (eg it cannot use tmTransportSecurityLevel as that is always > > authPriv for SSH > > and the application creating the outbound message may have > > had other ideas) > > > > I was envisaging that some unique index could pass from TM to > > SM so that SM > > could hand back index+securityName+securityLevel; or that > > there is a common > > table into which SM inserts securityName+securityLevel so > > that TM now can > > associate them with a session (but which the structure of the > > snmpTsmLCDTable > > now seems to rule out as a candiate) or .. > > > > Puzzled, > > > > Tom Petch > > > > > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "Juergen Schoenwaelder" > > > > > > To: "tom.petch" > > > > Cc: "David Harrington" ; > > > > Sent: Friday, June 27, 2008 9:12 AM > > > > Subject: Re: [Isms] pre-08 for TSM document > > > > > > > > > > > > > On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote: > > > > > > > > > > > Focussing on this I-D, you say that the TM will not alter > the > > > LCD > > > > > > table, but I think that it will struggle to read it, > > at least on > > > > > > inbound messages, as it cannot be sure what the > > > > securityName is and > > > > > > so cannot index into the table. It could walk the table > > > > looking for > > > > > > a matching snmpTsmLCDName ... well perhaps not. > > > > > > > > > > I fail to see why a TM needs to read the table. The TM just > > > > passes the > > > > > name provided by the transport via the tmStateReferences > > > > and TSM then > > > > > does any mappings as needed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms