From mailman-bounces@core3.amsl.com Fri Feb 1 06:25:16 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DE128C621 for ; Fri, 1 Feb 2008 06:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0lVpX+IZqa6 for ; Fri, 1 Feb 2008 06:23:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F8A28D8D2 for ; Fri, 1 Feb 2008 05:55:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: isms-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:07:05 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/isms/isms-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:25:35 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B9928DDE5 for ; Fri, 1 Feb 2008 06:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAT6sKBmarS8 for ; Fri, 1 Feb 2008 06:23:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2382A34EC for ; Fri, 1 Feb 2008 05:55:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: isms-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:07:06 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/isms/isms-archive%40megatron.ietf.org From isms-bounces@ietf.org Tue Feb 5 14:20:57 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020C83A7415; Tue, 5 Feb 2008 14:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UszBU+UT3ogy; Tue, 5 Feb 2008 14:20:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1A73AA1B7; Tue, 5 Feb 2008 13:56:41 -0800 (PST) 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 AAB643A8613 for ; Tue, 5 Feb 2008 13:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj-F07iCqHF9 for ; Tue, 5 Feb 2008 13:56:38 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id C28B33AA1B7 for ; Tue, 5 Feb 2008 13:35:36 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA07.westchester.pa.mail.comcast.net with comcast id luSg1Y00W0cZkys570By00; Tue, 05 Feb 2008 21:37:02 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id lxd41Y0024HwxpC3W00000; Tue, 05 Feb 2008 21:37:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=yzxyBjtJUVUA:10 a=48vgC7mUAAAA:8 a=VebO1WKASBvhLNbWjGEA:9 a=xpD--uz-MvpY0xRQ15wA:7 a=WFlQtW1ektCXQT7aX29HtBcDsmsA:4 a=4dyfk4FV-b8A:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=OS7PZEPQ3MUA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , References: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> <025601c861f3$937a1d60$6502a8c0@china.huawei.com> Date: Tue, 5 Feb 2008 16:37:08 -0500 Message-ID: <011301c8683f$4254ef30$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Achftg0YB/pE3kRqQ0K6hXaIOC7zWQCIcPBgAAUffOABj+j5IAACHZvg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM 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, RFC3412 forces a binding to exist between the message processing model and the security model, since one provides the parameters for the other. To make transport models work, we needed to modify the architecture to create a binding mechanism between transport models and security models, in the form of tmStateReference, since one provides the parameters for the other. We rechartered to permit us to add the tmStateReference to the ASIs, whatever its content. We did not have to recharter to add the securityName, and then to recharter again to add the securityLevel, and then to recharter again to add the sameSession parameter, and so on. The change that is required to allow transport models to select the corresaponding security model is to provide that an additional parameter - the securityModel parameter - be added to tmStateReference. Why must we recharter to add this parameter? The charter says "The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model" and we are supposed to "- Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into the SNMPv3 architecture." The charter does not say we are constrained to supporting only messages in the SNMPv3MessageSyntax. tmStateReference (and the modified ASIs) is the architectural extension, and part of describing how transport model security models fit within the architecture would include how the securityModel parameter is utilized by the subsystems that get the tmStateReference. We are not trying to change any other aspect of the SNMP architecture (e.g. PDUs). dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, February 05, 2008 2:25 PM > To: David Harrington; isms@ietf.org > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > My issues are actually not technical, nor am I in favor of sticking at > any price to architectural purity if deployment realities ask > differently. I cannot convince myself however that binding > the security > model for SNMPv2c is within the current ISMS charter, and I > suspect that > other IESG members will ask the same question. So we either need to > discuss a re-chartering for this WG or we need to think about > making all > or part of this work Experimental. > > Dan > > > > > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, January 28, 2008 11:20 PM > > To: Romascanu, Dan (Dan); isms@ietf.org > > Subject: RE: [Isms] ISMS #8: support of v1/v2c > transport-authn for ACM > > > > Hi Dan, > > > > I am curious as to what other issues you do not like in > this proposal. > > > > The SNMPv3 architecture was designed to permit various models > > to be used together in different combinations. I am trying to > > make it possible to use different security models with > > different message versions. I think that is very consistent > > with the SNMPv3 WG intentions of modularity. > > > > The one place where the SNMPv3 WG found a need to "bind" > > models was between the SNMPv3 message format and the named > > security models, because the security parameters that are > > needed by the different security models are passed in the > > SNMPv3 message header. Unfotunately, we also needed to bind > > SNMPv1 and the SNMPv1 security model directly, and the > > SNMPv2c message format to the SNMPv2 security model directly, > > because the security parameters are extracted from the fields > > of the message headers and we had no way to pass > > securityModel in the headers. > > > > With secure transports, the security parameters are actually > > provided by the transport layer protocol security - all > > except the securityModel parameter. The proposal is to make > > the transport model responsible for identifying the > > securityModel that will know how to properly process the > > securityparameters provided. This is equivalent to what the > > SNMPv3 message header provides now. > > > > And by doing this in the transport model, we can use RADIUS > > to provide during authentication some centralized control > > over the securityModel runtime decision that is so important > > to data access authorization. > > > > dbh > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Monday, January 28, 2008 1:56 PM > > > To: Randy Presuhn; isms@ietf.org > > > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for > > ACM > > > > > > You cannot actually have such a downref. > > > > > > Of course, this is not the only issue that I do not like in this > > > proposal. > > > > > > Dan > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > > > Sent: Saturday, January 26, 2008 2:55 AM > > > > To: isms@ietf.org > > > > Subject: Re: [Isms] ISMS #8: support of v1/v2c > > > transport-authn for ACM > > > > > > > > Hi - > > > > > > > > Just a procedural question - > > > > > > > > How would having a normative dependency on an experimental > > > > (SNMPvc) RFC affect this work process-wise? > > > > > > > > Or is the real sub-text of this discussion that SNMPv3 > should be > > > > withdrawn from the standards track? > > > > > > > > Randy > > > > > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > This email was protected during delivery to Avaya with TLS > > > encryption > > > > > > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Feb 5 14:35:20 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894153A77E9; Tue, 5 Feb 2008 14:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm3KDCig0rls; Tue, 5 Feb 2008 14:35:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF503A7EC7; Tue, 5 Feb 2008 14:14:22 -0800 (PST) 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 178893A7EBF for ; Tue, 5 Feb 2008 14:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCMF9CC2bjKC for ; Tue, 5 Feb 2008 14:14:19 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id E6CCA3A83CD for ; Tue, 5 Feb 2008 13:50:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,308,1199682000"; d="scan'208";a="91074068" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Feb 2008 14:25:18 -0500 X-IronPort-AV: E=Sophos;i="4.25,308,1199682000"; d="scan'208";a="151296192" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Feb 2008 14:25:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Feb 2008 20:24:55 +0100 Message-ID: In-Reply-To: <025601c861f3$937a1d60$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Thread-Index: Achftg0YB/pE3kRqQ0K6hXaIOC7zWQCIcPBgAAUffOABj+j5IA== References: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> <025601c861f3$937a1d60$6502a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM 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 My issues are actually not technical, nor am I in favor of sticking at any price to architectural purity if deployment realities ask differently. I cannot convince myself however that binding the security model for SNMPv2c is within the current ISMS charter, and I suspect that other IESG members will ask the same question. So we either need to discuss a re-chartering for this WG or we need to think about making all or part of this work Experimental. Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, January 28, 2008 11:20 PM > To: Romascanu, Dan (Dan); isms@ietf.org > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > Hi Dan, > > I am curious as to what other issues you do not like in this proposal. > > The SNMPv3 architecture was designed to permit various models > to be used together in different combinations. I am trying to > make it possible to use different security models with > different message versions. I think that is very consistent > with the SNMPv3 WG intentions of modularity. > > The one place where the SNMPv3 WG found a need to "bind" > models was between the SNMPv3 message format and the named > security models, because the security parameters that are > needed by the different security models are passed in the > SNMPv3 message header. Unfotunately, we also needed to bind > SNMPv1 and the SNMPv1 security model directly, and the > SNMPv2c message format to the SNMPv2 security model directly, > because the security parameters are extracted from the fields > of the message headers and we had no way to pass > securityModel in the headers. > > With secure transports, the security parameters are actually > provided by the transport layer protocol security - all > except the securityModel parameter. The proposal is to make > the transport model responsible for identifying the > securityModel that will know how to properly process the > securityparameters provided. This is equivalent to what the > SNMPv3 message header provides now. > > And by doing this in the transport model, we can use RADIUS > to provide during authentication some centralized control > over the securityModel runtime decision that is so important > to data access authorization. > > dbh > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Monday, January 28, 2008 1:56 PM > > To: Randy Presuhn; isms@ietf.org > > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for > ACM > > > > You cannot actually have such a downref. > > > > Of course, this is not the only issue that I do not like in this > > proposal. > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > > Sent: Saturday, January 26, 2008 2:55 AM > > > To: isms@ietf.org > > > Subject: Re: [Isms] ISMS #8: support of v1/v2c > > transport-authn for ACM > > > > > > Hi - > > > > > > Just a procedural question - > > > > > > How would having a normative dependency on an experimental > > > (SNMPvc) RFC affect this work process-wise? > > > > > > Or is the real sub-text of this discussion that SNMPv3 should be > > > withdrawn from the standards track? > > > > > > Randy > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > This email was protected during delivery to Avaya with TLS > > encryption > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Feb 5 23:47:49 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796513A6A42; Tue, 5 Feb 2008 23:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwlRdSTEsGdM; Tue, 5 Feb 2008 23:47:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D503A69B1; Tue, 5 Feb 2008 23:47:48 -0800 (PST) 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 601193A6A07 for ; Tue, 5 Feb 2008 23:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPmnXBubaiuT for ; Tue, 5 Feb 2008 23:47:46 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (unknown [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id BD6CA3A698A for ; Tue, 5 Feb 2008 23:47:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,311,1199682000"; d="scan'208";a="91183379" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Feb 2008 02:49:15 -0500 X-IronPort-AV: E=Sophos;i="4.25,311,1199682000"; d="scan'208";a="151559753" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 06 Feb 2008 02:49:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 08:48:40 +0100 Message-ID: In-Reply-To: <011301c8683f$4254ef30$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Thread-Index: Achftg0YB/pE3kRqQ0K6hXaIOC7zWQCIcPBgAAUffOABj+j5IAACHZvgABS7U/A= References: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> <025601c861f3$937a1d60$6502a8c0@china.huawei.com> <011301c8683f$4254ef30$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM 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 OK, I believe that I got it now and I can support this. The references issue raised by Randy still needs to be solved somehow. Some of the SNMPv2 documents were Experimental and are now Historic. They can't be normative references in standards track documents. Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, February 05, 2008 11:37 PM > To: Romascanu, Dan (Dan); isms@ietf.org > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > Hi, > > RFC3412 forces a binding to exist between the message > processing model and the security model, since one provides > the parameters for the other. > > To make transport models work, we needed to modify the > architecture to create a binding mechanism between transport > models and security models, in the form of tmStateReference, > since one provides the parameters for the other. > > We rechartered to permit us to add the tmStateReference to > the ASIs, whatever its content. We did not have to recharter > to add the securityName, and then to recharter again to add > the securityLevel, and then to recharter again to add the > sameSession parameter, and so on. > > The change that is required to allow transport models to > select the corresaponding security model is to provide that > an additional parameter - the securityModel parameter - be > added to tmStateReference. Why must we recharter to add this > parameter? > > The charter says "The goal of the ISMS working group is > developing a new security model for SNMP that integrates with > widely deployed user and key management systems, as a > supplement to the USM security model" > and we are supposed to "- Specify an architectural extension > that describes how transport mapping security models (TMSMs) > fit into the > SNMPv3 architecture." > > The charter does not say we are constrained to supporting > only messages in the SNMPv3MessageSyntax. tmStateReference > (and the modified ASIs) is the architectural extension, and > part of describing how transport model security models fit > within the architecture would include how the securityModel > parameter is utilized by the subsystems that get the > tmStateReference. We are not trying to change any other > aspect of the SNMP architecture (e.g. PDUs). > > dbh > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, February 05, 2008 2:25 PM > > To: David Harrington; isms@ietf.org > > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for > ACM > > > > My issues are actually not technical, nor am I in favor of sticking > at > > any price to architectural purity if deployment realities ask > > differently. I cannot convince myself however that binding the > > security model for SNMPv2c is within the current ISMS > charter, and I > > suspect that other IESG members will ask the same question. So we > > either need to discuss a re-chartering for this WG or we > need to think > > about making all or part of this work Experimental. > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Monday, January 28, 2008 11:20 PM > > > To: Romascanu, Dan (Dan); isms@ietf.org > > > Subject: RE: [Isms] ISMS #8: support of v1/v2c > > transport-authn for ACM > > > > > > Hi Dan, > > > > > > I am curious as to what other issues you do not like in > > this proposal. > > > > > > The SNMPv3 architecture was designed to permit various > models to be > > > used together in different combinations. I am trying to make it > > > possible to use different security models with different message > > > versions. I think that is very consistent with the SNMPv3 WG > > > intentions of modularity. > > > > > > The one place where the SNMPv3 WG found a need to "bind" > > > models was between the SNMPv3 message format and the > named security > > > models, because the security parameters that are needed by the > > > different security models are passed in the > > > SNMPv3 message header. Unfotunately, we also needed to bind > > > SNMPv1 and the SNMPv1 security model directly, and the SNMPv2c > > > message format to the SNMPv2 security model directly, because the > > > security parameters are extracted from the fields of the message > > > headers and we had no way to pass securityModel in the headers. > > > > > > With secure transports, the security parameters are actually > > > provided by the transport layer protocol security - all > except the > > > securityModel parameter. The proposal is to make the > transport model > > > responsible for identifying the securityModel that will > know how to > > > properly process the securityparameters provided. This is > equivalent > > > to what the > > > SNMPv3 message header provides now. > > > > > > And by doing this in the transport model, we can use RADIUS to > > > provide during authentication some centralized control over the > > > securityModel runtime decision that is so important to > data access > > > authorization. > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: Monday, January 28, 2008 1:56 PM > > > > To: Randy Presuhn; isms@ietf.org > > > > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn > for > > > ACM > > > > > > > > You cannot actually have such a downref. > > > > > > > > Of course, this is not the only issue that I do not like in this > > > > > proposal. > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > > > > Sent: Saturday, January 26, 2008 2:55 AM > > > > > To: isms@ietf.org > > > > > Subject: Re: [Isms] ISMS #8: support of v1/v2c > > > > transport-authn for ACM > > > > > > > > > > Hi - > > > > > > > > > > Just a procedural question - > > > > > > > > > > How would having a normative dependency on an experimental > > > > > (SNMPvc) RFC affect this work process-wise? > > > > > > > > > > Or is the real sub-text of this discussion that SNMPv3 > > should be > > > > > withdrawn from the standards track? > > > > > > > > > > Randy > > > > > > > > > > > > > > > _______________________________________________ > > > > > Isms mailing list > > > > > Isms@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > This email was protected during delivery to Avaya with TLS > > > > encryption > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > > > > > > > > _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 6 06:33:05 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328083A6E7C; Wed, 6 Feb 2008 06:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EOsvi7Ryghg; Wed, 6 Feb 2008 06:33:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBC23A6E37; Wed, 6 Feb 2008 06:33:03 -0800 (PST) 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 6693F3A6E54 for ; Wed, 6 Feb 2008 06:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp7i9VDEG330 for ; Wed, 6 Feb 2008 06:33:01 -0800 (PST) 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 288C73A6E9D for ; Wed, 6 Feb 2008 06:32:39 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA06.westchester.pa.mail.comcast.net with comcast id mBJS1Y0090Fqzac560CV00; Wed, 06 Feb 2008 14:34:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id mEa61Y0094HwxpC3U00000; Wed, 06 Feb 2008 14:34:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=yzxyBjtJUVUA:10 a=48vgC7mUAAAA:8 a=UtC9sYIGqKW-eJp9sSEA:9 a=Uq12HCKlO6J55AxzXhUA:7 a=CZMnpZ_CgY1yZ_nfYPPeAt2ut30A:4 a=4dyfk4FV-b8A:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=OS7PZEPQ3MUA:10 a=gi0PWCVxevcA:10 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , References: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> <025601c861f3$937a1d60$6502a8c0@china.huawei.com> <011301c8683f$4254ef30$0600a8c0@china.huawei.com> Date: Wed, 6 Feb 2008 09:34:10 -0500 Message-ID: <018701c868cd$563b4b50$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Achftg0YB/pE3kRqQ0K6hXaIOC7zWQCIcPBgAAUffOABj+j5IAACHZvgABS7U/AAEUxRAA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM 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 I don't think the issue ever existed. We do not now, and do not plan to, have a reference to SNMPv1 or SNMPv2c documents. The closest we currently get is referencing RFC3584, which is a BCP, to explain the security considerations of NOT using the SSH authentication when doing access control for an operation contained in an SNMPv1 or SNMPv2c message delivered over an SSH connection. Hopefully, the proposed change will eliminate that security vulnerability. dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, February 06, 2008 2:49 AM > To: David Harrington; isms@ietf.org > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > OK, I believe that I got it now and I can support this. The references > issue raised by Randy still needs to be solved somehow. Some of the > SNMPv2 documents were Experimental and are now Historic. They can't be > normative references in standards track documents. > > Dan > > > > > > > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Tuesday, February 05, 2008 11:37 PM > > To: Romascanu, Dan (Dan); isms@ietf.org > > Subject: RE: [Isms] ISMS #8: support of v1/v2c > transport-authn for ACM > > > > Hi, > > > > RFC3412 forces a binding to exist between the message > > processing model and the security model, since one provides > > the parameters for the other. > > > > To make transport models work, we needed to modify the > > architecture to create a binding mechanism between transport > > models and security models, in the form of tmStateReference, > > since one provides the parameters for the other. > > > > We rechartered to permit us to add the tmStateReference to > > the ASIs, whatever its content. We did not have to recharter > > to add the securityName, and then to recharter again to add > > the securityLevel, and then to recharter again to add the > > sameSession parameter, and so on. > > > > The change that is required to allow transport models to > > select the corresaponding security model is to provide that > > an additional parameter - the securityModel parameter - be > > added to tmStateReference. Why must we recharter to add this > > parameter? > > > > The charter says "The goal of the ISMS working group is > > developing a new security model for SNMP that integrates with > > widely deployed user and key management systems, as a > > supplement to the USM security model" > > and we are supposed to "- Specify an architectural extension > > that describes how transport mapping security models (TMSMs) > > fit into the > > SNMPv3 architecture." > > > > The charter does not say we are constrained to supporting > > only messages in the SNMPv3MessageSyntax. tmStateReference > > (and the modified ASIs) is the architectural extension, and > > part of describing how transport model security models fit > > within the architecture would include how the securityModel > > parameter is utilized by the subsystems that get the > > tmStateReference. We are not trying to change any other > > aspect of the SNMP architecture (e.g. PDUs). > > > > dbh > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Tuesday, February 05, 2008 2:25 PM > > > To: David Harrington; isms@ietf.org > > > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for > > ACM > > > > > > My issues are actually not technical, nor am I in favor > of sticking > > at > > > any price to architectural purity if deployment realities ask > > > differently. I cannot convince myself however that binding the > > > security model for SNMPv2c is within the current ISMS > > charter, and I > > > suspect that other IESG members will ask the same question. So we > > > either need to discuss a re-chartering for this WG or we > > need to think > > > about making all or part of this work Experimental. > > > > > > Dan > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > > Sent: Monday, January 28, 2008 11:20 PM > > > > To: Romascanu, Dan (Dan); isms@ietf.org > > > > Subject: RE: [Isms] ISMS #8: support of v1/v2c > > > transport-authn for ACM > > > > > > > > Hi Dan, > > > > > > > > I am curious as to what other issues you do not like in > > > this proposal. > > > > > > > > The SNMPv3 architecture was designed to permit various > > models to be > > > > used together in different combinations. I am trying to make it > > > > possible to use different security models with > different message > > > > versions. I think that is very consistent with the SNMPv3 WG > > > > intentions of modularity. > > > > > > > > The one place where the SNMPv3 WG found a need to "bind" > > > > models was between the SNMPv3 message format and the > > named security > > > > models, because the security parameters that are needed by the > > > > different security models are passed in the > > > > SNMPv3 message header. Unfotunately, we also needed to bind > > > > SNMPv1 and the SNMPv1 security model directly, and the SNMPv2c > > > > message format to the SNMPv2 security model directly, > because the > > > > security parameters are extracted from the fields of > the message > > > > headers and we had no way to pass securityModel in the headers. > > > > > > > > With secure transports, the security parameters are actually > > > > provided by the transport layer protocol security - all > > except the > > > > securityModel parameter. The proposal is to make the > > transport model > > > > responsible for identifying the securityModel that will > > know how to > > > > properly process the securityparameters provided. This is > > equivalent > > > > to what the > > > > SNMPv3 message header provides now. > > > > > > > > And by doing this in the transport model, we can use RADIUS to > > > > provide during authentication some centralized control over the > > > > securityModel runtime decision that is so important to > > data access > > > > authorization. > > > > > > > > dbh > > > > > > > > > -----Original Message----- > > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > > Sent: Monday, January 28, 2008 1:56 PM > > > > > To: Randy Presuhn; isms@ietf.org > > > > > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn > > for > > > > ACM > > > > > > > > > > You cannot actually have such a downref. > > > > > > > > > > Of course, this is not the only issue that I do not > like in this > > > > > > > proposal. > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > > > > > Sent: Saturday, January 26, 2008 2:55 AM > > > > > > To: isms@ietf.org > > > > > > Subject: Re: [Isms] ISMS #8: support of v1/v2c > > > > > transport-authn for ACM > > > > > > > > > > > > Hi - > > > > > > > > > > > > Just a procedural question - > > > > > > > > > > > > How would having a normative dependency on an experimental > > > > > > (SNMPvc) RFC affect this work process-wise? > > > > > > > > > > > > Or is the real sub-text of this discussion that SNMPv3 > > > should be > > > > > > withdrawn from the standards track? > > > > > > > > > > > > Randy > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Isms mailing list > > > > > > Isms@lists.ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > > This email was protected during delivery to Avaya with TLS > > > > > encryption > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Isms mailing list > > > > > Isms@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 18 19:37:09 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4223A6BD1; Mon, 18 Feb 2008 19:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 fZ5Z-XnVNUGp; Mon, 18 Feb 2008 19:37:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267A03A697A; Mon, 18 Feb 2008 19:37:09 -0800 (PST) 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 EEDD83A697A for ; Mon, 18 Feb 2008 19:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 NezWq6JNbbrj for ; Mon, 18 Feb 2008 19:37:08 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id 254E03A6826 for ; Mon, 18 Feb 2008 19:37:08 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWG00LJPVDJKE@szxga02-in.huawei.com> for isms@ietf.org; Tue, 19 Feb 2008 11:36:55 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWG00FIOVDIII@szxga02-in.huawei.com> for isms@ietf.org; Tue, 19 Feb 2008 11:36:55 +0800 (CST) Received: from l67563 ([10.111.12.60]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWG00HIZVDHPJ@szxml04-in.huawei.com> for isms@ietf.org; Tue, 19 Feb 2008 11:36:54 +0800 (CST) Date: Tue, 19 Feb 2008 11:36:53 +0800 From: li chunxiu To: isms@ietf.org Message-id: <02ca01c872a8$abdabb10$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchyqKtJd3zl51pNTI2mlry07oootw== Subject: [Isms] questions about draft-ietf-isms-radius-usage-01 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 1 .In the second paragraph in"1.1general" of draft-ietf-isms-radius-usage-01, what does "a common identity" of the RADIUS protocol refer to? 2. In page 4: "When that service provisioning does not match the capabilities of the NAS, or of the particular interface to the NAS over which the user is requesting access, RFC2865 [RFC2865] requires that the NAS MUST reject the access request." What does "the particular interface" refer to? "the NAS MUST reject the access request." Means the NAS reject the user directly or the RADIUS server do the reject action? It seems ambiguous here. 3. in page 6" 2. RADIUS Usage for SNMP Transport Models", why "the distinction between user authentication and service authorization for the SNMP Transport Models and the SNMP Transport Security Model(TSM) is relevant, and perhaps important."? Does it need some details for it? 4 . the content of the last paragraph of page 4 and " 2.1. RADIUS Authentication for Transport Protocols" in page 7 belongs to one meaning, maybe they could be described in a whole part to express compactly. Thank you very much! Chunxiu li _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 18 23:22:20 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0971E3A6D7A; Mon, 18 Feb 2008 23:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.181 X-Spam-Level: * X-Spam-Status: No, score=1.181 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 NJ-pV3A6ugbX; Mon, 18 Feb 2008 23:22:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD893A6A4B; Mon, 18 Feb 2008 23:22:19 -0800 (PST) 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 9413A3A699D for ; Mon, 18 Feb 2008 23:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 NWA9QyRvVrDn for ; Mon, 18 Feb 2008 23:22:17 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [61.144.161.53]) by core3.amsl.com (Postfix) with ESMTP id 7A4F83A69F6 for ; Mon, 18 Feb 2008 23:21:56 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWH00KUN5S6TP@szxga01-in.huawei.com> for isms@ietf.org; Tue, 19 Feb 2008 15:21:42 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWH00G1X5S6V6@szxga01-in.huawei.com> for isms@ietf.org; Tue, 19 Feb 2008 15:21:42 +0800 (CST) Received: from l67563 ([10.111.12.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWH003VT5S5BW@szxml03-in.huawei.com> for isms@ietf.org; Tue, 19 Feb 2008 15:21:42 +0800 (CST) Date: Tue, 19 Feb 2008 15:21:41 +0800 From: li chunxiu To: isms@ietf.org Message-id: <02d401c872c8$13519b00$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchyyBLk9G2xCZzhR/+cpM08wvGkRg== Subject: [Isms] a mistake about draft-ietf-isms-tmsm-11 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 first paragraph in page 5"User-based Secutiry Model", there is a spelling mistake of the word"security". Chunxiu li _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 20 05:40:33 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495B228C25B; Wed, 20 Feb 2008 05:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.956, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 AnTO7DB8znzK; Wed, 20 Feb 2008 05:40:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A4028C149; Wed, 20 Feb 2008 05:40:29 -0800 (PST) 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 9E40828C149 for ; Wed, 20 Feb 2008 05:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 wHi3dF7r785X for ; Wed, 20 Feb 2008 05:40:26 -0800 (PST) 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 9C0A03A69AF for ; Wed, 20 Feb 2008 05:40:26 -0800 (PST) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id rpNV1Y0020b6N64A101B00; Wed, 20 Feb 2008 13:39:57 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id rpgH1Y00M24Kx1C8P00000; Wed, 20 Feb 2008 13:40:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=qEuGyoFmv95W6YQvG9sA:9 a=ELOheTjrZHFEr6LzeOkA:7 a=x8rTifvtZE-VTuzw8Efu9Jox-ukA:4 a=DLWQtoLnVnAA:10 From: "David B. Nelson" To: References: <02ca01c872a8$abdabb10$3c0c6f0a@china.huawei.com> Date: Wed, 20 Feb 2008 08:40:17 -0500 Message-ID: <075101c873c6$22132ce0$011716ac@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchyqKtJd3zl51pNTI2mlry07oootwBGMorg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <02ca01c872a8$abdabb10$3c0c6f0a@china.huawei.com> Subject: Re: [Isms] questions about draft-ietf-isms-radius-usage-01 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 Li Chunxiu writes... > 1 .In the second paragraph in "1.1 general" of > draft-ietf-isms-radius-usage-01, what does "a common identity" of the > RADIUS protocol refer to? The RADIUS protocol also provides the advantage of allowing a common identity to be used with or shared across disparate management protocols, since the other network management interfaces such as NETCONF are capable of authentication with the same RADIUS server. This means that a common identity database is often behind the RADIUS server, such as NIS, LDAP, Active Directory, etc. While RADIUS servers commonly provide a native user database feature, most organizations deploying RADIUS tie their RADIUS servers into an existing authentication infrastructure. In addition, it means that any device (NAS) that authenticates against a common RADIUS server (or set of RADIUS servers in a common administrative domain) will be able to authenticate users against a common identity database. > 2. In page 4: "When that service provisioning does not match the > capabilities of the NAS, or of the particular interface to the NAS over > which the user is requesting access, RFC2865 [RFC2865] requires that the > NAS MUST reject the access request." What does "the particular interface" > refer to? It means the physical or virtual interface for or over which service request is being requested. In the simplest case of an 802.1X authentication is it the 802.1D switch port. The interface in question may be represented using the NAS-Port or NAS-Port-ID attributes. > "the NAS MUST reject the access request." Means the NAS reject the > user directly or the RADIUS server do the reject action? When that service provisioning does not match the capabilities of the NAS, or of the particular interface to the NAS over which the user is requesting access, RFC 2865 [RFC2865] requires that the NAS MUST reject the access request. For a description of the basic set of attributes, refer to [RFC2865]. It means that the NAS (the device that contains the RADIUS Client) must perform the rejection. By the way, this is not a new normative requirement. It is simply a reiteration of the requirements of RFC 2865, placed here for background information. Previous ISMS WG comments requested a basic review of "RADIUS Theory of Operation" in this document. > It seems ambiguous here. Hmmm. The statement "... requires that the NAS MUST reject the access request." seems pretty clear to me. Can you suggest some alternate text? > 3. in page 6" 2. RADIUS Usage for SNMP Transport Models", why "the > distinction between user authentication and service authorization for the > SNMP Transport Models and the SNMP Transport Security Model(TSM) is > relevant, and perhaps important."? It is relevant because of the way in which SSH implementations have traditionally integrated with RADIUS Clients. Those SSH implementations traditionally seek to obtain user authentication (e.g. validation of a username and password) from an outside authentication service, often via a Pluggable Authentication Module (PAM) style interface. The service authorization in traditional SSH server implementations comes via the restrictions that the operating system (OS) shell (and file system, etc.) place on the user by means of access controls tied to the username or the username's membership in various user groups. These OS-style access controls are distinct from the service provisioning (authorization) features of RADIUS. If we wish to use existing SSH server implementations (or slightly adapt them) for use with SNMP Transport Models, we need to be aware that the RADIUS service authorization information may or may not be passed along to the relevant SNMP modules by the SSH module. > Does it need some details for it? Perhaps. Does the above explanation help? It may also help to explain why RADIUS service authorization is desirable in the first place. If that isn't clear from other sections of text in the document, it should be clarified, as well. > 4 . the content of the last paragraph of page 4 and " 2.1. RADIUS > Authentication for Transport Protocols" in page 7 belongs to one meaning, > maybe they could be described in a whole part to express compactly. It could be merged. As I indicated above, a previous commenter requested that a basic RADIUS theory of operation be provided as introductory material before any SNMP specifics were discussed. This leads to some redundancy, wherein the material is first reviewed in general terms and is later discussed again in the specific context of SNMP Transport Models. _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 21 20:02:51 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C6528C6D0; Thu, 21 Feb 2008 20:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] 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 JV5YKsMGGMkt; Thu, 21 Feb 2008 20:02:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A704D28C5EA; Thu, 21 Feb 2008 20:02:50 -0800 (PST) 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 450DB28C1D6 for ; Thu, 21 Feb 2008 20:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 d5IhLusBAw1H for ; Thu, 21 Feb 2008 20:02:47 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id AEB933A68FC for ; Thu, 21 Feb 2008 20:01:47 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWM00AYFGFQ1U@szxga02-in.huawei.com> for isms@ietf.org; Fri, 22 Feb 2008 11:59:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWM00H6NGFQJQ@szxga02-in.huawei.com> for isms@ietf.org; Fri, 22 Feb 2008 11:59:50 +0800 (CST) Received: from l67563 ([10.111.12.60]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWM00LQLGFL1R@szxml04-in.huawei.com> for isms@ietf.org; Fri, 22 Feb 2008 11:59:50 +0800 (CST) Date: Fri, 22 Feb 2008 11:59:45 +0800 From: li chunxiu In-reply-to: <075101c873c6$22132ce0$011716ac@NEWTON603> To: "'David B. Nelson'" , isms@ietf.org Message-id: <016201c87507$5f28cf30$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AchyqKtJd3zl51pNTI2mlry07oootwBGMorgABj5IYA= Subject: Re: [Isms] questions about draft-ietf-isms-radius-usage-01 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="gb2312" Content-Transfer-Encoding: base64 Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org SGksRGF2aWQgQi5OZWxzb24KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBkZXRhaWxlZCBl eHBsYW5hdGlvbiBmb3IgbXkgcXVlc3Rpb25zLiAKQW5kIEkgYW0gc29ycnkgZm9yIHRoZSBiYWQg Zm9ybWF0IG9mIG15IGVtYWlsLCBJIHdpbGwgdGFrZSBjYXJlIG9mIGl0IG5leHQKdGltZS4gT2uj rEkgdW5kZXJzdGFuZCB0aGUgYW5zd2VycyBub3csIGFuZCB0aGVyZSBhcmUgdmVyeSBjbGVhci4K QW5kIEkgYWxzbyB1bmRlcnN0YW5kIHRoZSBsb2dpYyBvZiBnZW5lcmFsIHRlcm1zIGFuZCBzcGVj aWZpYyBjb250ZXh0IG5vdy4gClRoYW5rIHlvdSEKCmEgbWlzdGFrZSBvZiB0aGlzIGRyYWZ0Ogpz ZWMgNS5TZWN1cml0eSBDb25zaWRlcmF0aW9ucyAKICAgQWRkaXRpb25hbCBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBmb3IgdXNlIG9mIFNOTVAgd2l0aCBzZWN1cmUKICAgVHJhbnNwb3J0IE1vZGVs cyBbc3NodG1dIGFuZCB0aGUgVHJhbnNwb3J0IFNlY3VyaXR5IE1vZGVsIFtzc2h0bV0gYXJlCiAg IGZvdW5kIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9ucyBvZiB0aGUgcmVz cGVjdGl2ZQogICBkb2N1bWVudHMuCgp0aGVyZSBpcyBhIG1pc3Rha2Ugb2YgMiBhYmJyZXZpYXRp b25zLgoKQ2h1bnhpdSBsaQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KSXNtcyBtYWlsaW5nIGxpc3QKSXNtc0BpZXRmLm9yZwpodHRwOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXNtcwo= From isms-bounces@ietf.org Thu Feb 21 20:25:16 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD5D3A6BBA; Thu, 21 Feb 2008 20:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 6hvLGrACC240; Thu, 21 Feb 2008 20:25:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067F03A6B46; Thu, 21 Feb 2008 20:25:16 -0800 (PST) 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 C09FB3A6B46 for ; Thu, 21 Feb 2008 20:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 DuqDwyz84BrC for ; Thu, 21 Feb 2008 20:25:14 -0800 (PST) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by core3.amsl.com (Postfix) with SMTP id BD9B53A6AB5 for ; Thu, 21 Feb 2008 20:25:12 -0800 (PST) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa24642; 21 Feb 2008 23:24 EST Date: Thu, 21 Feb 2008 23:24:33 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: li chunxiu In-Reply-To: <016201c87507$5f28cf30$3c0c6f0a@china.huawei.com> Message-ID: MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] questions about draft-ietf-isms-radius-usage-01 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, 22 Feb 2008, li chunxiu wrote: > a mistake of this draft: > sec 5.Security Considerations > Additional security considerations for use of SNMP with secure > Transport Models [sshtm] and the Transport Security Model [sshtm] are > found in the Security Considerations sections of the respective > documents. > > there is a mistake of 2 abbreviations. Which is to say, there are two references to [sshtm], at least one of which is wrong. In fact, they are both incorrect - the first should be to [tmsm] and the second to [tsm]. Furthermore, the [tsm] reference itself uses the wrong title; it should be "Transport Security Model for SNMP". -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 21 22:10:03 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEEA3A6B5A; Thu, 21 Feb 2008 22:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 qKEKs+rVxiJV; Thu, 21 Feb 2008 22:10:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDBF3A6AED; Thu, 21 Feb 2008 22:10:03 -0800 (PST) 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 729953A6AED for ; Thu, 21 Feb 2008 22:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 RpaQ66pEudIj for ; Thu, 21 Feb 2008 22:10:01 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [61.144.161.54]) by core3.amsl.com (Postfix) with ESMTP id 9735E3A6A2E for ; Thu, 21 Feb 2008 22:10:01 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWM00FVKMGBDD@szxga02-in.huawei.com> for isms@ietf.org; Fri, 22 Feb 2008 14:09:47 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWM0081CMGAX2@szxga02-in.huawei.com> for isms@ietf.org; Fri, 22 Feb 2008 14:09:47 +0800 (CST) Received: from l67563 ([10.111.12.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWM0014OMGACN@szxml03-in.huawei.com> for isms@ietf.org; Fri, 22 Feb 2008 14:09:46 +0800 (CST) Date: Fri, 22 Feb 2008 14:09:45 +0800 From: li chunxiu In-reply-to: To: 'Jeffrey Hutzelman' Message-id: <017301c87519$86011830$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ach1CuYQe9fAQ+HWT3uBFxWFLuL5ngADjzsg Cc: isms@ietf.org Subject: Re: [Isms] questions about draft-ietf-isms-radius-usage-01 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, Jeffrey Hutzelman Yes, I agree with your opinion. thank you! > Which is to say, there are two references to [sshtm], at least one of > which is wrong. In fact, they are both incorrect - the first should be to > [tmsm] and the second to [tsm]. Furthermore, the [tsm] reference itself > uses the wrong title; it should be "Transport Security Model for SNMP". Chunxiu li _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Feb 22 06:28:31 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CE328CAC1; Fri, 22 Feb 2008 06:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 MfWXyOoCNLQY; Fri, 22 Feb 2008 06:28:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9894A28CB53; Fri, 22 Feb 2008 06:22:00 -0800 (PST) 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 173F428C752 for ; Fri, 22 Feb 2008 06:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 3E+rcLT+twL0 for ; Fri, 22 Feb 2008 06:21:55 -0800 (PST) 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 2E40A28CC19 for ; Fri, 22 Feb 2008 06:17:48 -0800 (PST) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id scMX1Y0010EPchoA407l00; Fri, 22 Feb 2008 14:17:16 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id seHi1Y00B24Kx1C8M00000; Fri, 22 Feb 2008 14:17:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=9aE2VA-NbJtGkJBJKOoA:9 a=d2kFE6YXIZSowWXp3W48Jaqs3CwA:4 a=DLWQtoLnVnAA:10 From: "David B. Nelson" To: References: <075101c873c6$22132ce0$011716ac@NEWTON603> <016201c87507$5f28cf30$3c0c6f0a@china.huawei.com> Date: Fri, 22 Feb 2008 09:17:44 -0500 Message-ID: <0c1301c8755d$b258ee00$011716ac@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchyqKtJd3zl51pNTI2mlry07oootwBGMorgABj5IYAATf41sA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <016201c87507$5f28cf30$3c0c6f0a@china.huawei.com> Subject: Re: [Isms] questions about draft-ietf-isms-radius-usage-01 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 Li Chunxiu writes... > Thank you very much for your detailed explanation for my questions. > And I am sorry for the bad format of my email... I thought your e-mail was easy to read. Thank you for your questions and comments. > a mistake of this draft: > sec 5.Security Considerations > Additional security considerations for use of SNMP with secure > Transport Models [sshtm] and the Transport Security Model [sshtm] are > found in the Security Considerations sections of the respective > documents. > > there is a mistake of 2 abbreviations. OK. Thanks! I'll fix that. _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Feb 22 06:28:34 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A82A28CB2E; Fri, 22 Feb 2008 06:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 9lTE9qaP6MOy; Fri, 22 Feb 2008 06:28:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D522228CACD; Fri, 22 Feb 2008 06:22:11 -0800 (PST) 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 4F19628CB7F for ; Fri, 22 Feb 2008 06:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 jWjEGtA8D4lh for ; Fri, 22 Feb 2008 06:22:09 -0800 (PST) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id CCFBF28CC51 for ; Fri, 22 Feb 2008 06:18:54 -0800 (PST) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id sbnT1Y00G0QkzPwAA0D000; Fri, 22 Feb 2008 14:18:03 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id seJp1Y00D24Kx1C8N00000; Fri, 22 Feb 2008 14:18:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=aVU62IF_h4YfG_rqzEsA:9 a=Q92JwKaeK2_pPFzfLmQ5dFXtJhMA:4 a=QMgMR9M9BAsA:10 From: "David B. Nelson" To: References: <016201c87507$5f28cf30$3c0c6f0a@china.huawei.com> Date: Fri, 22 Feb 2008 09:18:51 -0500 Message-ID: <0c1401c8755d$da249ce0$011716ac@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach1CuRGnZOxCvGMQw6PYX/nct+UbAAUtOpg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Isms] questions about draft-ietf-isms-radius-usage-01 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 writes... > Which is to say, there are two references to [sshtm], at least one of > which is wrong. In fact, they are both incorrect - the first should be to > [tmsm] and the second to [tsm]. Furthermore, the [tsm] reference itself > uses the wrong title; it should be "Transport Security Model for SNMP". Will fix. Thanks! _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Feb 24 21:00:08 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD1728C506; Sun, 24 Feb 2008 21:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 RjAOvgvGMxAD; Sun, 24 Feb 2008 21:00:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FC728C4A1; Sun, 24 Feb 2008 21:00:07 -0800 (PST) X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D23D83A6BAE; Sun, 24 Feb 2008 21:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225050001.D23D83A6BAE@core3.amsl.com> Date: Sun, 24 Feb 2008 21:00:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-usage-02.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-02.txt Pages : 14 Date : 2008-02-24 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-isms-radius-usage-02.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-ietf-isms-radius-usage-02.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: <2008-02-24205531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-radius-usage-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-radius-usage-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24205531.I-D\@ietf.org> --OtherAccess-- --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 http://www.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Mon Feb 25 06:20:58 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5C128C645; Mon, 25 Feb 2008 06:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 RFtW82nYw7yD; Mon, 25 Feb 2008 06:20:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7411128C635; Mon, 25 Feb 2008 06:20:23 -0800 (PST) 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 6BB7B28C65E for ; Mon, 25 Feb 2008 06:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 2OCeIAtXmHrj for ; Mon, 25 Feb 2008 06:20:21 -0800 (PST) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 2E09228C3FE for ; Mon, 25 Feb 2008 06:19:41 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id tnJm1Y0010lTkoCA80HN00; Mon, 25 Feb 2008 14:19:12 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id tqKa1Y00724Kx1C8Q00000; Mon, 25 Feb 2008 14:19:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=q2mnWW9aPHweAf35ukAA:9 a=FT5MmFSYjxApuV-vzHdhs4tRaC4A:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: References: <20080225050001.D23D83A6BAE@core3.amsl.com> Date: Mon, 25 Feb 2008 09:19:40 -0500 Message-ID: <14a201c877b9$76268470$011716ac@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach3a4/tmt4wo7JpSamvKA+rY2vBIAATUe4A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080225050001.D23D83A6BAE@core3.amsl.com> Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-usage-02.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > 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-02.txt > Pages : 14 > Date : 2008-02-24 > > 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. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-02.txt The -02 version of this draft addresses all open issues from the ISMS mailing list. It also synchronizes with the -02 version of the RADIUS Management Authorization draft, http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati on-02.txt . As always, additional comments are welcome. _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 25 09:34:15 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A543A6DE1; Mon, 25 Feb 2008 09:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 QF-6qt0PrNv8; Mon, 25 Feb 2008 09:34:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FAD28C832; Mon, 25 Feb 2008 09:32:22 -0800 (PST) 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 8876528C810 for ; Mon, 25 Feb 2008 09:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 GYC31+f54uT8 for ; Mon, 25 Feb 2008 09:32:20 -0800 (PST) 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 CC56A28C85C for ; Mon, 25 Feb 2008 09:27:52 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id tqQe1Y00U0S2fkCA90A300; Mon, 25 Feb 2008 17:27:09 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id ttTi1Y00C4HwxpC8V00000; Mon, 25 Feb 2008 17:27:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=fU9uEiZbJ4QlEt1xWwoA:9 a=0bKnJAPfwo32BPfVhB0A:7 a=0M8sSb7ltZ-VNiriV0S2J_wI4I8A:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'li chunxiu'" , References: <02d401c872c8$13519b00$3c0c6f0a@china.huawei.com> Date: Mon, 25 Feb 2008 12:27:42 -0500 Message-ID: <062f01c877d3$badd28c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchyyBLk9G2xCZzhR/+cpM08wvGkRgFC3oBw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <02d401c872c8$13519b00$3c0c6f0a@china.huawei.com> Subject: Re: [Isms] a mistake about draft-ietf-isms-tmsm-11 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 have corrected this in my sources, so it will appear in the next revision. Currently, I have no other changes suggested, so I will not publish a new revision yet. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of li chunxiu > Sent: Tuesday, February 19, 2008 2:22 AM > To: isms@ietf.org > Subject: [Isms] a mistake about draft-ietf-isms-tmsm-11 > > > The first paragraph in page 5"User-based Secutiry Model", there is a > spelling mistake of the word"security". > > Chunxiu li > > _______________________________________________ > Isms mailing list > Isms@ietf.org > http://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 25 10:02:38 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36C728C742; Mon, 25 Feb 2008 10:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_35=0.6, RDNS_NONE=0.1] 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 yAhAqEvdQFoA; Mon, 25 Feb 2008 10:02:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4932C28C88A; Mon, 25 Feb 2008 09:58:26 -0800 (PST) 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 3129528C88A for ; Mon, 25 Feb 2008 09:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 em+1nplFBHy3 for ; Mon, 25 Feb 2008 09:58:24 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 867FC28C894 for ; Mon, 25 Feb 2008 09:55:37 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id tpo61Y0060x6nqcA50QC00; Mon, 25 Feb 2008 17:54:47 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id ttvR1Y00E4HwxpC8Y00000; Mon, 25 Feb 2008 17:55:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=UhK1TZbEbdB5V0avjJQA:9 a=3yH6VnTEBOmE3XjQXmIA:7 a=ExxB0tNxkJi6T0zP9iN1qLdSk9QA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , "'Jeffrey Hutzelman'" , References: <20080123204607.GB13934@elstar.local><017a01c85e02$391433f0$0600a8c0@china.huawei.com> <6B96CA4988BA3B036169B819@atlantis.pc.cs.cmu.edu> <04c401c85f61$750cd1e0$0601a8c0@pc6> Date: Mon, 25 Feb 2008 12:55:25 -0500 Message-ID: <067201c877d7$9a8c7770$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchfahmO5qzuCcwWQZeZMzE7nuxDpgYbKg6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <04c401c85f61$750cd1e0$0601a8c0@pc6> Subject: Re: [Isms] ISMS #1: tmStateReference 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, The text now says: The SSH Transport Model has the responsibility for explicitly releasing the complete tmStateReference and associated information when a session is closed. I believe this addresses this issue. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, January 25, 2008 8:48 AM > To: Jeffrey Hutzelman; David Harrington; isms@ietf.org > Subject: Re: [Isms] ISMS #1: tmStateReference > > ----- Original Message ----- > From: "Jeffrey Hutzelman" > To: "David Harrington" ; > Cc: > Sent: Wednesday, January 23, 2008 10:35 PM > Subject: RE: [Isms] ISMS #1: tmStateReference > > > > --On Wednesday, January 23, 2008 03:55:01 PM -0500 David Harrington > > wrote: > > > > > Hi, > > > > > > tmStateReference contains information that may be > > > implementation-specific, and some of the information may > need to be > > > static to allow preconfiguration of state in the target-mib and > > > associated tables. > > > > > > The text says it is the responsibility of the transport model to > > > explicitly release the tmStateReference and associated > information. > > > Should this be implementation-dependent, and if so, are there any > > > operational (e.g., notifications) or security issues with > released or > > > non-released transport/security state? > > > > It sounds like "explicitly release" in this case means > things like freeing > > the memory occupied by the tmStateReference or whatever it > points to, or > > returning an object or identifier to a free pool. Both the > mechanism and > > timing of this, as well as who is responsible for doing it, > seem highly > > implementation-dependent. I don't think this is a detail we need to > > specify. > > > > I think that that creates a security exposure. > > There is no pointer on an outgoing message for which session > to use. The > (rather loose) binding is based on a match in the cache for > transportDomain/Address + securityName/Level/Model so if a > session with > instances of these objects is taken down and replaced by > another with the same > instances, and the cache is not cleared when the session is > taken down, then the > outgoing message could go over an inappropriate session. So > I think yes, > session failure MUST clear cache. > > Tom Petch > > > -- Jeff > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@ietf.org http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 25 12:53:48 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3801128D186; Mon, 25 Feb 2008 12:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 gQnD9j1SPaLu; Mon, 25 Feb 2008 12:53:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403B428CB23; Mon, 25 Feb 2008 12:45:32 -0800 (PST) X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 218D728CA45; Mon, 25 Feb 2008 12:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225204502.218D728CA45@core3.amsl.com> Date: Mon, 25 Feb 2008 12:45:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-tmsm-12.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 : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-12.txt Pages : 34 Date : 2008-02-25 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-isms-tmsm-12.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-ietf-isms-tmsm-12.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: <2008-02-25124103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25124103.I-D\@ietf.org> --OtherAccess-- --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 http://www.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Mon Feb 25 12:53:50 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6327328D1A7; Mon, 25 Feb 2008 12:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 8SgtosAUnhcq; Mon, 25 Feb 2008 12:53:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE0128CB5B; Mon, 25 Feb 2008 12:45:34 -0800 (PST) X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 603B428CA42; Mon, 25 Feb 2008 12:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225204502.603B428CA42@core3.amsl.com> Date: Mon, 25 Feb 2008 12:45:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-10.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 : Secure Shell Transport Model for SNMP Author(s) : D. Harrington, J. Salowey Filename : draft-ietf-isms-secshell-10.txt Pages : 37 Date : 2008-02-25 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-isms-secshell-10.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-ietf-isms-secshell-10.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: <2008-02-25124046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-secshell-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25124046.I-D\@ietf.org> --OtherAccess-- --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 http://www.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Tue Feb 26 02:46:33 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F3C3A6CF2; Tue, 26 Feb 2008 02:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 6zAKQtll70o7; Tue, 26 Feb 2008 02:46:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8F93A6D07; Tue, 26 Feb 2008 02:46:28 -0800 (PST) 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 5D7583A6CEF for ; Tue, 26 Feb 2008 02:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 A7TxNeanwpAa for ; Tue, 26 Feb 2008 02:46:22 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E62323A6BDF for ; Tue, 26 Feb 2008 02:46:21 -0800 (PST) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4A618A7D4; Tue, 26 Feb 2008 11:46:15 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 32297-02-39; Tue, 26 Feb 2008 11:46:10 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2103E8656E; Tue, 26 Feb 2008 11:42:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1AA844D030C; Tue, 26 Feb 2008 11:42:36 +0100 (CET) Date: Tue, 26 Feb 2008 11:42:35 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20080226104235.GA2112@elstar.local> Mail-Followup-To: "David B. Nelson" , isms@ietf.org References: <20080225050001.D23D83A6BAE@core3.amsl.com> <14a201c877b9$76268470$011716ac@NEWTON603> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <14a201c877b9$76268470$011716ac@NEWTON603> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: isms@ietf.org Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-usage-02.txt 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 Mon, Feb 25, 2008 at 09:19:40AM -0500, David B. Nelson wrote: > The -02 version of this draft addresses all open issues from the ISMS > mailing list. It also synchronizes with the -02 version of the RADIUS > Management Authorization draft. Thanks David. It would be helpful if people take a look at his draft. Also note that there were some more drastic changes in the RADEXT draft this depends on, so people should look at these two drafts in combination. draft-ietf-isms-radius-usage-02.txt [14 pages] draft-ietf-radext-management-authorization-02.txt [20 pages] /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 http://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 27 04:34:23 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB1028C6F3; Wed, 27 Feb 2008 04:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] 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 u+PyE690Vt84; Wed, 27 Feb 2008 04:34:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B8128C639; Wed, 27 Feb 2008 04:34:23 -0800 (PST) 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 2484F28C6A7 for ; Wed, 27 Feb 2008 04:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 y7-KZDK7uCYs for ; Wed, 27 Feb 2008 04:34:20 -0800 (PST) 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 462B928C6F7 for ; Wed, 27 Feb 2008 04:34:20 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id uaj31Y0010S2fkCA406800; Wed, 27 Feb 2008 12:33:38 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id ucaA1Y00124Kx1C8V00000; Wed, 27 Feb 2008 12:34:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=rcgMTcw66C4A:10 a=48vgC7mUAAAA:8 a=Cv6e0pkHAAAA:8 a=HmQAdqdetg-G5dQjnhIA:9 a=I91Nzm6YOAqV7RkjczcA:7 a=0PRwO30UFnCC-Uwcx7pn6Qy3FuUA:4 a=zoKOyUDlhksA:10 From: "David B. Nelson" To: Date: Wed, 27 Feb 2008 07:34:09 -0500 Message-ID: <1b1701c8793d$0de1ffe0$011716ac@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach491ishn12o/RWQ3O1M0GWoJe2MQARRdiQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] FW: RADEXT WG Last Call on NAS Management Authorization Specification 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Because the subject draft is of interest to ISMS, I'm forwarding this RADEXT WGLC notice to the ISMS mailing list. > This is to announce a RADEXT WG last call on the NAS Management > Authorization specification prior to its being sent on to the IESG for > consideration as a Proposed Standard.=A0 The document is available for > inspection here: > > http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati on-02.txt >=A0 > RADEXT WG last call will last until Friday, March 28, 2008.=A0=A0 Please > respond to this WG last call announcement indicating whether or not you > approve of the document, even if you have no comments to offer.=A0 If you > have comments to offer, please send them to the RADEXT WG mailing list = > in the format described in the RADEXT WG Issues list:=A0 = > http://www.drizzle.com/~aboba/RADEXT/ _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 28 01:05:29 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D77C28C5BE; Thu, 28 Feb 2008 01:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 nSHprz9rsz8d; Thu, 28 Feb 2008 01:05:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203A428C56C; Thu, 28 Feb 2008 01:05:23 -0800 (PST) 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 4BD0C28C3BA for ; Thu, 28 Feb 2008 01:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 IP+D2yPunmY2 for ; Thu, 28 Feb 2008 01:05:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2E2AA28C347 for ; Thu, 28 Feb 2008 01:05:14 -0800 (PST) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA0E98A727 for ; Thu, 28 Feb 2008 10:05:06 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28855-10-4; Thu, 28 Feb 2008 10:05:02 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 185498A710; Thu, 28 Feb 2008 10:04:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 033B94D4BE3; Thu, 28 Feb 2008 10:04:42 +0100 (CET) Date: Thu, 28 Feb 2008 10:04:42 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080228090442.GA7656@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Subject: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP 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 Dear all, this is the start of the working group last call on the ISMS RADIUS integration document: Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models The authors and the chairs think that this document is mature enough for WGLC. Please do review these document and post your comments on this list until Friday, March 28, 2008. Please respond to this WG last call announcement indicating whether or not you approve the document, even if you have no comments to offer. Note that this document is based on the RADIUS Management Authorization specification: Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management This document is under last call in the RADEXT WG. So if you read this document as well, please let the RADEXT chairs and/or the RADEXT WG know about it. /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 Thu Feb 28 01:48:28 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DBA28C59E; Thu, 28 Feb 2008 01:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 RrzUiBgzB8s7; Thu, 28 Feb 2008 01:48:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487B13A6BC1; Thu, 28 Feb 2008 01:48:27 -0800 (PST) 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 57A5C3A6B9E for ; Thu, 28 Feb 2008 01:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 ObSE54btbscy for ; Thu, 28 Feb 2008 01:48:20 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [61.144.161.7]) by core3.amsl.com (Postfix) with ESMTP id DE19E3A686A for ; Thu, 28 Feb 2008 01:47:26 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWY004RI0IT6D@szxga04-in.huawei.com> for isms@ietf.org; Thu, 28 Feb 2008 17:47:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JWY00A8Z0IPOI@szxga04-in.huawei.com> for isms@ietf.org; Thu, 28 Feb 2008 17:47:17 +0800 (CST) Received: from l67563 ([10.111.12.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWY0080O0IO2V@szxml03-in.huawei.com> for isms@ietf.org; Thu, 28 Feb 2008 17:47:13 +0800 (CST) Date: Thu, 28 Feb 2008 17:47:12 +0800 From: li chunxiu In-reply-to: <20080228090442.GA7656@elstar.local> To: isms@ietf.org Message-id: <008d01c879ee$e4fea490$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ach56S46tM+iehoJRbifS+p345OLIAABKi4Q Subject: Re: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP 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 have a question: -sec "3. Table of Attributes" Does the "Framed-Management-Protection" should be "Framed-Management-Protocol "? Thank you! Chunxiu li > Dear all, > > this is the start of the working group last call on the ISMS > RADIUS integration document: > > Remote Authentication Dial-In User Service (RADIUS) Usage for > Simple Network Management Protocol (SNMP) Transport Models > > > The authors and the chairs think that this document is mature > enough for WGLC. Please do review these document and post your > comments on this list until Friday, March 28, 2008. > > Please respond to this WG last call announcement indicating > whether or not you approve the document, even if you have no > comments to offer. > > Note that this document is based on the RADIUS Management > Authorization specification: > > Remote Authentication Dial-In User Service (RADIUS) > Authorization for Network Access Server (NAS) Management > > > This document is under last call in the RADEXT WG. So if you read > this document as well, please let the RADEXT chairs and/or the > RADEXT WG know about it. > > /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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 28 05:08:39 2008 Return-Path: X-Original-To: ietfarch-isms-archive@core3.amsl.com Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043263A6EA1; Thu, 28 Feb 2008 05:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 KgG8OJnT1mC5; Thu, 28 Feb 2008 05:08:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5243A6E4E; Thu, 28 Feb 2008 05:08:28 -0800 (PST) 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 9EF993A69B7 for ; Thu, 28 Feb 2008 05:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 UV9xoRUNeXeL for ; Thu, 28 Feb 2008 05:08:25 -0800 (PST) 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 C543C28C47F for ; Thu, 28 Feb 2008 05:07:50 -0800 (PST) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id uzyY1Y0020b6N64A204W00; Thu, 28 Feb 2008 13:07:13 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id v17i1Y00124Kx1C8P00000; Thu, 28 Feb 2008 13:07:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=97RE6CVaQtYA:10 a=r3MfflVQz8UUfmzMh4kA:9 a=e6NrQ5oa-y92PsyXs60fnfMi7Y0A:4 a=DLWQtoLnVnAA:10 From: "David B. Nelson" To: References: <20080228090442.GA7656@elstar.local> <008d01c879ee$e4fea490$3c0c6f0a@china.huawei.com> Date: Thu, 28 Feb 2008 08:07:43 -0500 Message-ID: <1cba01c87a0a$e86d06a0$011716ac@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach56S46tM+iehoJRbifS+p345OLIAABKi4QAAcedWA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <008d01c879ee$e4fea490$3c0c6f0a@china.huawei.com> Subject: Re: [Isms] ISMS WG Last Call on RADIUS mapping for SNMP 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 Li Chunxiu writes... > -sec "3. Table of Attributes" > Does the "Framed-Management-Protection" should be > "Framed-Management-Protocol "? Yes. It should be: 0-1 0-1 0 0 TBA Framed-Management-Protocol 0-1 0-1 0 0 TBA Management-Transport-Protection One too many steps in the "global search and replace". :-) Thanks for catching this. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms