From owner-snmpv3@lists.tislabs.com Mon Oct 6 15:22:09 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18622 for ; Mon, 6 Oct 2003 15:22:08 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14042 Mon, 6 Oct 2003 14:07:53 -0400 (EDT) Message-Id: <200310061713.NAA12837@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpv3@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt Date: Mon, 06 Oct 2003 13:13:42 -0400 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Security Based Session Model (SBSM) for the Simple Network Management Protocol (SNMP). Author(s) : W. Hardaker Filename : draft-hardaker-snmp-session-sm-00.txt Pages : 39 Date : 2003-10-6 This document describes a Session Based Security Model (SBSM) for use within the Simple Network Management Protocol (SNMP). The security model is designed to establish a 'session' between two interacting hosts, over which SNMP operations can be sent. It provides a number of security properties not previously available in defined SNMP security models, such as public key based authentication, limited life-time keying, and the ability to make use of previously implemented and deployed security infrastructures for purposes of identification and authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hardaker-snmp-session-sm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hardaker-snmp-session-sm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-6105644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hardaker-snmp-session-sm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hardaker-snmp-session-sm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-6105644.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpv3@lists.tislabs.com Tue Oct 7 19:38:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27855 for ; Tue, 7 Oct 2003 19:38:41 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21890 Tue, 7 Oct 2003 18:25:58 -0400 (EDT) To: Steve Bellovin , uri@bell-labs.com, fmaino@andiamo.com, kzm@cisco.com Cc: snmpv3@lists.tislabs.com Subject: Comments on the current AES draft From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Tue, 07 Oct 2003 15:34:37 -0700 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk I had a few comments on the current aes-usm draft. I noticed it has gone through 2 revisions since last call, and I just noticed it is in IESG review but here they are anyway. First off, the draft is much better worded and clearer than the last time I read it, so thanks to the authors for doing a nice job. - I find the discussion in section 1.2 and 1.3 a bit confusing because it doesn't paint a clear picture of how passwords get converted into master keys (Ku) and then converted into localized keys (Kul). I understand it as is but only because I adequately understand the semantics with how the USM keying mechanisms work. It would be better, IMHO, if you tie the wording together with RFC3414 a bit better. - 1.3: "Implementation SHOULD support the use of randomly generated passwords as a stronger form of security". I think you mean "randomly generated keys" (Ku) instead here. - Section 3.1.2.1 4th paragraph: The problem is much more prevalent when considering a large number of agents sending INFORMs to a manager, which is a much more likely case for a IV collision than a few managers to a large number of agents. The odds are still remote for "todays technology" but a few decades (2ish, maybe less) out it might be more of a problem. - Section 4: Security Considerations. The first paragraph basically says that all the SHOULDs in section 1.3 MUST be implemented. This certainly MUST/SHOULD be corrected before publication as an RFC. -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Thu Oct 9 12:30:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27054 for ; Thu, 9 Oct 2003 12:30:19 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06863 Thu, 9 Oct 2003 11:06:49 -0400 (EDT) Message-ID: From: "Golovinsky, Eugene" To: snmpv3@lists.tislabs.com Cc: snmpv3@lists.tislabs.com Subject: RE: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt Date: Thu, 9 Oct 2003 10:15:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Wes. For your TODO list. I think we also need to have a section that allows management of sessions. In other words an "administrator" should be able to get a list of active sessions with associated statistics, to be able to remove/disable/suspend sessions and to revoke session keys if necessary. Simply relaying on aging of the session or the key may not be enough. Cheers. --Gene Gene Golovinsky BMC Software, Inc Cross Business Unit Development eugene_golovinsky@bmc.com Office: 713-918-1816 Mobile: 832-876-2726 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, October 06, 2003 12:14 PM Cc: snmpv3@lists.tislabs.com Subject: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Security Based Session Model (SBSM) for the Simple Network Management Protocol (SNMP). Author(s) : W. Hardaker Filename : draft-hardaker-snmp-session-sm-00.txt Pages : 39 Date : 2003-10-6 This document describes a Session Based Security Model (SBSM) for use within the Simple Network Management Protocol (SNMP). The security model is designed to establish a 'session' between two interacting hosts, over which SNMP operations can be sent. It provides a number of security properties not previously available in defined SNMP security models, such as public key based authentication, limited life-time keying, and the ability to make use of previously implemented and deployed security infrastructures for purposes of identification and authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hardaker-snmp-session-sm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hardaker-snmp-session-sm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-snmpv3@lists.tislabs.com Thu Oct 9 14:27:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02623 for ; Thu, 9 Oct 2003 14:27:14 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08125 Thu, 9 Oct 2003 13:21:00 -0400 (EDT) To: "Golovinsky, Eugene" Cc: snmpv3@lists.tislabs.com Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt References: From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Thu, 09 Oct 2003 10:29:38 -0700 In-Reply-To: (Eugene Golovinsky's message of "Thu, 9 Oct 2003 10:15:40 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Thu, 9 Oct 2003 10:15:40 -0500 , "Golovinsky, Eugene" said: Eugene> For your TODO list. I think we also need to have a section that allows Eugene> management of sessions. Yep. It's actually planned for the MIB, and David Perkins has promised to write a MIB to do a good number of the tasks you've talked about. Eugene> Simply relaying on aging of the session or the key may not be enough. Agreed. Thanks for the comments! (and the feedback to let us know that you think a management element is needed as well) -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Mon Oct 13 20:31:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06974 for ; Mon, 13 Oct 2003 20:31:36 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07632 Mon, 13 Oct 2003 19:22:24 -0400 (EDT) Message-ID: <3549C09B853DD5119B540002A52CDD3408DFA7EB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: snmpv3@lists.tislabs.com Cc: Wes Hardaker Subject: RE: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt Date: Mon, 13 Oct 2003 19:31:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi I've only skimmed the draft, but I suspect a MIB to do cleanup may not be the best approach. If things are setup using non-SNMP means, shouldn't tear down be done that way? If I understood things from my quick skim, I think I like the approach of not using SNMP to set up the session since it avoids all the bootstrap issues and is easier to sell to people who don't think they want to use SNMP for configuration. Sharon -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Thursday, October 09, 2003 1:30 PM To: Golovinsky, Eugene Cc: snmpv3@lists.tislabs.com Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt >>>>> On Thu, 9 Oct 2003 10:15:40 -0500 , "Golovinsky, Eugene" >>>>> said: Eugene> For your TODO list. I think we also need to have a section that Eugene> allows management of sessions. Yep. It's actually planned for the MIB, and David Perkins has promised to write a MIB to do a good number of the tasks you've talked about. Eugene> Simply relaying on aging of the session or the key may not be Eugene> enough. Agreed. Thanks for the comments! (and the feedback to let us know that you think a management element is needed as well) -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Tue Oct 14 02:05:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20536 for ; Tue, 14 Oct 2003 02:05:57 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA09691 Tue, 14 Oct 2003 00:53:14 -0400 (EDT) To: "Sharon Chisholm" Cc: snmpv3@lists.tislabs.com Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt References: <3549C09B853DD5119B540002A52CDD3408DFA7EB@zcard0ka.ca.nortel.com> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Mon, 13 Oct 2003 22:01:55 -0700 In-Reply-To: <3549C09B853DD5119B540002A52CDD3408DFA7EB@zcard0ka.ca.nortel.com> (Sharon Chisholm's message of "Mon, 13 Oct 2003 19:31:24 -0400") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Mon, 13 Oct 2003 19:31:24 -0400, "Sharon Chisholm" said: Sharon> I've only skimmed the draft, but I suspect a MIB to do cleanup Sharon> may not be the best approach. If things are setup using Sharon> non-SNMP means, shouldn't tear down be done that way? The MIB is more for super-management. The draft already supports either side randomly dropping the session, and will support (IE, its not there now) a notification mechanism to the other side that one side intentionally dropped a connection. This will all be "within-SBSM-messages". Greater ability may be controlled by the accompanying MIB module, but the details haven't been worked out. Thanks for the comments! Sharon> If I understood things from my quick skim, I think I like the Sharon> approach of not using SNMP to set up the session since it Sharon> avoids all the bootstrap issues and is easier to sell to Sharon> people who don't think they want to use SNMP for Sharon> configuration. That was the primary goal; reuse of existing authentication mechanisms. Things like password databases, radius, ... are all heavily used and there is no reason they can't be used within SNMP as well. -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Tue Oct 14 10:07:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10520 for ; Tue, 14 Oct 2003 10:07:22 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12013 Tue, 14 Oct 2003 08:59:14 -0400 (EDT) Message-ID: <3549C09B853DD5119B540002A52CDD3408DFA979@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: snmpv3@lists.tislabs.com Cc: Wes Hardaker Subject: RE: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt Date: Tue, 14 Oct 2003 09:08:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi Might I suggest then that providing a MIB way of doing the same thing might just be noise? As for more detailed configuration, why can't this be done in the protocol? A monitoring MIB would be useful though if you can keep it nice and simple - i.e. no superfluous configuration. Sharon -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Tuesday, October 14, 2003 1:02 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Cc: snmpv3@lists.tislabs.com Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt >>>>> On Mon, 13 Oct 2003 19:31:24 -0400, "Sharon Chisholm" >>>>> said: Sharon> I've only skimmed the draft, but I suspect a MIB to do cleanup Sharon> may not be the best approach. If things are setup using non-SNMP Sharon> means, shouldn't tear down be done that way? The MIB is more for super-management. The draft already supports either side randomly dropping the session, and will support (IE, its not there now) a notification mechanism to the other side that one side intentionally dropped a connection. This will all be "within-SBSM-messages". Greater ability may be controlled by the accompanying MIB module, but the details haven't been worked out. Thanks for the comments! Sharon> If I understood things from my quick skim, I think I like the Sharon> approach of not using SNMP to set up the session since it avoids Sharon> all the bootstrap issues and is easier to sell to people who Sharon> don't think they want to use SNMP for configuration. That was the primary goal; reuse of existing authentication mechanisms. Things like password databases, radius, ... are all heavily used and there is no reason they can't be used within SNMP as well. -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Tue Oct 14 13:06:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19427 for ; Tue, 14 Oct 2003 13:06:29 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13144 Tue, 14 Oct 2003 11:51:34 -0400 (EDT) Message-ID: <002f01c3926c$5e6e0e20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <3549C09B853DD5119B540002A52CDD3408DFA979@zcard0ka.ca.nortel.com> Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt Date: Tue, 14 Oct 2003 09:01:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - > From: "Sharon Chisholm" > To: > Cc: "Wes Hardaker" > Sent: Tuesday, October 14, 2003 6:08 AM > Subject: RE: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt ... > Might I suggest then that providing a MIB way of doing the same thing might > just be noise? As for more detailed configuration, why can't this be done in > the protocol? A monitoring MIB would be useful though if you can keep it > nice and simple - i.e. no superfluous configuration. ... I agree that *superluous* configuration should be avoided, but I think that some very basic configuration / control capabilities are essential, such as permitting a security administrator to kill a session in progress (getting back to the issues Gene originally raised much earlier in this thread). As to the basic question "why can't this be done in the protocol", I think the answer centers around the question of *who* should have the rights to do such configuration. My intuition is that it would normally be a security administrator, rather than the session user, who would set things up, kill sessions, and so on. If this is correct, then building it into the protocol would not make sense, since the wrong user would be behind the protocol operations requesting the configuration change. Randy From owner-snmpv3@lists.tislabs.com Wed Oct 15 19:20:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29431 for ; Wed, 15 Oct 2003 19:20:22 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28127 Wed, 15 Oct 2003 18:17:59 -0400 (EDT) To: "Sharon Chisholm" Cc: snmpv3@lists.tislabs.com Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt References: <3549C09B853DD5119B540002A52CDD3408DFA979@zcard0ka.ca.nortel.com> From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Wed, 15 Oct 2003 15:26:48 -0700 In-Reply-To: <3549C09B853DD5119B540002A52CDD3408DFA979@zcard0ka.ca.nortel.com> (Sharon Chisholm's message of "Tue, 14 Oct 2003 09:08:13 -0400") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Tue, 14 Oct 2003 09:08:13 -0400, "Sharon Chisholm" said: Sharon> Might I suggest then that providing a MIB way of doing the Sharon> same thing might just be noise? As for more detailed Sharon> configuration, why can't this be done in the protocol? A Sharon> monitoring MIB would be useful though if you can keep it nice Sharon> and simple - i.e. no superfluous configuration. Because the complexity of the protocol would get pretty nasty. We already *have* a management protocol and it doesn't make much sense not to use it to self-manage ;-) -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Thu Oct 16 09:35:47 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02615 for ; Thu, 16 Oct 2003 09:35:46 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01711 Thu, 16 Oct 2003 08:27:09 -0400 (EDT) To: "Golovinsky, Eugene" Cc: "'Sharon Chisholm'" , snmpv3@lists.tislabs.com Subject: Re: I-D ACTION:draft-hardaker-snmp-session-sm-00.txt References: From: Wes Hardaker Organization: Sparta Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXotKX87e8eDA4GAQbQgmlzNycHAwizYkruzul2AAACaUlEQVR4nFXUTW/jIBAGYFI56jWutuq1S9b2dddW6dWtQFxbq4jzwq73Glmg+fv7DiT9QJGS+GEGhiER67TWEQ5CtOeh21ZcIIbmOPq5QvMZYlyV6u+/gsJLTSrGIL/CxEPxQuPAcP0JYlQsq3x5B3UJmUaEyB6yZ+CQ+pwXCzKsbXtbIhg4KtZypPz+AVGtlxH69c87qAqRY6Rc5QUmZMGeAj+TfVjjUwE1lflKys5JGXpM+V0hltqCJ0qL7Plkft4wRM6lxi5p3Wyy7O7fB8TgtdZivxy5rvAB6wSYhbA9vn+GOCaOEGJRPO2mHgk+q1Chyf0Up3AG0NjhOXI19ogEFziq6M+ZtN3kUZ13NW4qUCprC3CW668C06M5jihON1Vsjq8F1CPJB8LINNeQfscwxUEvAwM5Xghvsq2pBr3hnKhbDIrMS3cBRDx70uS9JW2dy667gM0AbZFFmyvn3GOBGB8wG9kppaSNz357LaCmUdtSny5LU9qeCrglvJmyH20TwkjnXQE0usscIWayCWZJ7OpZ4QbUVGRnhuTub3cMYRk99oSplDIfibzfn0FyXyk7z8XThuvC0P/dGCwee7O8aZJBmh0vPixy0NrYhDaR02aR3W0BbyT6h23OB5Hzybj+DOm5w6XCOZG13p5Oh/bursJVh9S+bBiFnPCDuntpcTH080AO+7GlW1i3bRphBM04dZ2dI6yMLjmGFqnIok/cB1YU8sJAACTeuHOd5+lumQHfDM6KyLqEm4aWkkcc1m4PqBewZxBZOg44lT+aJiexDteewboiVhxAjSHxQwhiYJEdCR6tMN1/uckirDRNbsgAAAAASUVORK5CYII= Date: Wed, 15 Oct 2003 15:35:27 -0700 In-Reply-To: (Eugene Golovinsky's message of "Tue, 14 Oct 2003 08:01:51 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> On Tue, 14 Oct 2003 08:01:51 -0500, "Golovinsky, Eugene" said: Eugene> My understanding is that when sessions die from natural causes Eugene> it'll clean up key(s) associated with it. That is done without Eugene> MIB involved. On the other hand I would like to be able to Eugene> manage and administer the entity while session is active (per Eugene> session statistics, retries, failed sessions, whatever else) Eugene> and to be able to cancel the key if there is a need. If not Eugene> through the MIB, then we'll have to come up with other way Eugene> (protocol ??) to do that. I'd rather stick to SNMP here. My expectation is that the following three methods will be available for tearing down connections: 1) An in-protocol CONNECTION-DELETED to inform the other side that it should release and clean resources (MUST actually, especially keys). Functionally, it's a FIN. 2) A MIB method for control by SNMP, either within the same session or by someone with administrative rights. 3) If either side simply deletes its side of the session, then the other side will be unable to communicate over it (this must always be supported since things like reboots will normally clean the session information within a device). -- Wes Hardaker Sparta From owner-snmpv3@lists.tislabs.com Wed Oct 29 11:41:10 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18072 for ; Wed, 29 Oct 2003 11:41:04 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05830 Wed, 29 Oct 2003 10:01:42 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502C833AA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpv3-wg (E-mail)" Subject: FW: Airespace Wireless Lan has SNMPv3 Date: Wed, 29 Oct 2003 16:09:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk The Reviewmeister is taking a tour of wireless LAN switches this week and next, so let's start with the A's, today we'll look at Airespace. Next time, we'll look at Aruba. ... snip ... The Airespace Web interface was the most intuitive of ones we tested, with well-organized divisions of various WLAN and switch management functions. Airespace also is the only vendor to support SNMP Version 3, which offers much better security than its predecessors. ... snip ... From owner-snmpv3@lists.tislabs.com Wed Oct 29 13:09:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24210 for ; Wed, 29 Oct 2003 13:09:37 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06472 Wed, 29 Oct 2003 11:51:34 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Airespace Wireless Lan has SNMPv3 Date: Wed, 29 Oct 2003 09:01:17 -0800 Message-ID: Thread-Topic: Airespace Wireless Lan has SNMPv3 Thread-Index: AcOePBHVTHoTeEIuQFGF9rw9uZLoDgAAa30A From: "Jeff Johnson" To: "Wijnen, Bert (Bert)" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA06469 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit FYI we didn't have product ready in time for the demo being quoted, but AirFlow Networks Release 2.0 (currently in Beta) also has support for SNMPv3. /jeff > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, October 29, 2003 7:10 AM > To: Snmpv3-wg (E-mail) > Subject: FW: Airespace Wireless Lan has SNMPv3 > > The Reviewmeister is taking a tour of wireless LAN switches this > week and next, so let's start with the A's, today we'll look at > Airespace. Next time, we'll look at Aruba. > > ... snip ... > > The Airespace Web interface was the most intuitive of ones we > tested, with well-organized divisions of various WLAN and switch > management functions. Airespace also is the only vendor to > support SNMP Version 3, which offers much better security than > its predecessors. > > ... snip ...