From wjhns1@hardakers.net Thu Jul 1 08:14:20 2010 Return-Path: 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 DCEF03A69B3 for ; Thu, 1 Jul 2010 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaxTJZ1jnw-r for ; Thu, 1 Jul 2010 08:14:18 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 3940B3A68F2 for ; Thu, 1 Jul 2010 08:14:17 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id EB15398124; Thu, 1 Jul 2010 08:14:28 -0700 (PDT) From: Wes Hardaker To: Robert Story Organization: Sparta References: <20100629202338.5eaff6a8@sparta.com> <20100630031659.GA43495@elstar.local> <20100630011349.00ae4e73@sparta.com> <20100630054809.GB43772@elstar.local> <20100630114451.0dba9bc6@sparta.com> <20100630205213.GC45229@elstar.local> Date: Thu, 01 Jul 2010 08:14:28 -0700 In-Reply-To: <20100630205213.GC45229@elstar.local> (Juergen Schoenwaelder's message of "Wed, 30 Jun 2010 22:52:13 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" , Wes Hardaker Subject: Re: [Isms] SNMP-TLS-TM-MIB errata 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: , X-List-Received-Date: Thu, 01 Jul 2010 15:14:20 -0000 >>>>> On Wed, 30 Jun 2010 22:52:13 +0200, Juergen Schoenwaelder said: JS> I agree we should use the 1x format to avoid this pitfall. And encourage everyone to fix their implementations for future MIBs too ;-) -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Thu Jul 1 10:39:00 2010 Return-Path: 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 4313D3A67A3 for ; Thu, 1 Jul 2010 10:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=1.245, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7KK8lTUDgu6 for ; Thu, 1 Jul 2010 10:38:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D304E3A685A for ; Thu, 1 Jul 2010 10:38:56 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A233C002B; Thu, 1 Jul 2010 19:39:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id f3MCozmDeETG; Thu, 1 Jul 2010 19:39:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31748C000C; Thu, 1 Jul 2010 19:39:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1737213762FE; Thu, 1 Jul 2010 19:39:01 +0200 (CEST) Date: Thu, 1 Jul 2010 19:39:01 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100701173900.GA48157@elstar.local> Mail-Followup-To: Wes Hardaker , Robert Story , "isms@ietf.org" , Wes Hardaker References: <20100629202338.5eaff6a8@sparta.com> <20100630031659.GA43495@elstar.local> <20100630011349.00ae4e73@sparta.com> <20100630054809.GB43772@elstar.local> <20100630114451.0dba9bc6@sparta.com> <20100630205213.GC45229@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Wes Hardaker , "isms@ietf.org" , Robert Story Subject: Re: [Isms] SNMP-TLS-TM-MIB errata X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:39:00 -0000 On Thu, Jul 01, 2010 at 05:14:28PM +0200, Wes Hardaker wrote: > >>>>> On Wed, 30 Jun 2010 22:52:13 +0200, Juergen Schoenwaelder said: > > JS> I agree we should use the 1x format to avoid this pitfall. > > And encourage everyone to fix their implementations for future MIBs too ;-) That requires to first figure out what a correct implementation should really do and to post an errata to 2579... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Jul 4 03:30:26 2010 Return-Path: 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 D86C93A67CF for ; Sun, 4 Jul 2010 03:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.85 X-Spam-Level: X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_60=1, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G250m-TDPIwD for ; Sun, 4 Jul 2010 03:30:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8E4363A67A5 for ; Sun, 4 Jul 2010 03:30:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39959C0064; Sun, 4 Jul 2010 12:30:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id snVVRgk681+S; Sun, 4 Jul 2010 12:30:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83659C0006; Sun, 4 Jul 2010 12:30:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43F841382970; Sun, 4 Jul 2010 12:30:22 +0200 (CEST) Date: Sun, 4 Jul 2010 12:30:22 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100704103022.GA25653@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <004301cb1504$bee19b60$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004301cb1504$bee19b60$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] Fw: I-D Action:draft-presuhn-isms-radius-vacm-alt-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 10:30:26 -0000 On Sat, Jun 26, 2010 at 09:54:02AM +0200, Randy Presuhn wrote: > I've updated the individual i-d exploring how we might resolve David > Harrington's WG last call comments on the RADIUS/VACM i-d. I have reviewed draft-presuhn-isms-radius-vacm-alt-01.txt and I think it is technically in a good shape. I have a number of editorial comments as detailed below. As co-chair, I like to ask Randy to submit another revision as draft-ietf-isms-radius-vacm-07.txt. Once in place, I will do a final quick check to confirm the changes that have been made. Here are my comments. The last one is a suggestion to rename MIB objects which requires some editorial effort to ensure internal consistency of the document - the others are rather simple editorial fixes I think. a) s/specifies an way/specifies a way/ b) I suggest to spell out the acronyms VACM and AAA in the introduction so that the main body of the document does not depend on the abstract (where these terms are spelled out) c) s/such as [RFC5592]/such as the Secure Shell Transport Model [RFC5592]/ d) s/of of/of/ e) p10: s/Extended-View-based/AAA Enabled View-based/ f) s/VacmSecurityToGroupTable/vacmSecurityToGroupTable/ (occurs multiple times) g) s/vacmSecurityToGroup table/vacmSecurityToGroupTable/ (occurs multiple times) h) I am wondering whether we should change the naming scheme. Extended VACM is perhaps to too wide name and we do not follow the VACM MIB prefixing scheme. Here is what I have in mind: OLD: NEW: SNMP-EXT-VACM-MIB SNMP-VACM-AAA-MIB snmpExtVacmMIB snmpVacmAaaMIB extVacmMIBObjects vacmAaaMIBObjects extVacmMIBConformance vacmAAAMIBConformance extVacmSecurityToGroupTable vacmAaaSecurityToGroupTable extVacmSecurityToGroupEntry vacmAaaSecurityToGroupEntry ExtVacmSecurityToGroupEntry VacmAaaSecurityToGroupEntry extVacmSecurityModel vacmAaaSecurityModel extVacmSecurityName vacmAaaSecurityName extVacmTransportModel vacmAaaTransportModel extVacmTransportSessionID vacmAaaTransportSessionID extVacmGroupName vacmAaaGroupName extVacmMIBCompliances vacmAaaMIBCompliances extVacmMIBGroups vacmAaaMIBGroups extVacmMIBBasicCompliance vacmAaaMIBBasicCompliance extVacmGroup vacmAaaGroup This proposed change requires some editorial effort but does technically not change anything except that we are dealing more carefully with the descriptor namespace. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Mon Jul 5 10:36:33 2010 Return-Path: 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 C5FD83A686E for ; Mon, 5 Jul 2010 10:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttCk7tJ2qWPN for ; Mon, 5 Jul 2010 10:36:32 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id B8D1A3A6833 for ; Mon, 5 Jul 2010 10:36:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iefWQyW7mMf/bfk3TdVTkrinWYz2DCFNH8q3qzVbWIv6JStKse3yPcXsfkRz40tU; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.173.118] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OVpah-0000TP-Ma for isms@ietf.org; Mon, 05 Jul 2010 13:36:24 -0400 Message-ID: <001201cb1c68$d49e1ee0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <004301cb1504$bee19b60$6801a8c0@oemcomputer> <20100704103022.GA25653@elstar.local> Date: Mon, 5 Jul 2010 10:37:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc7205327803562f3cbed5ecd019117a01fea1e483041350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.173.118 Subject: Re: [Isms] Fw: I-D Action:draft-presuhn-isms-radius-vacm-alt-01.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: , X-List-Received-Date: Mon, 05 Jul 2010 17:36:33 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Sunday, July 04, 2010 3:30 AM > Subject: Re: [Isms] Fw: I-D Action:draft-presuhn-isms-radius-vacm-alt-01.txt ... > Here are my comments. The last one is a suggestion to rename MIB > objects which requires some editorial effort to ensure internal > consistency of the document - the others are rather simple editorial > fixes I think. > > a) s/specifies an way/specifies a way/ fixed. > b) I suggest to spell out the acronyms VACM and AAA in the > introduction so that the main body of the document does not depend > on the abstract (where these terms are spelled out) done > c) s/such as [RFC5592]/such as the Secure Shell Transport Model [RFC5592]/ done > d) s/of of/of/ fixed > e) p10: s/Extended-View-based/AAA Enabled View-based/ done > f) s/VacmSecurityToGroupTable/vacmSecurityToGroupTable/ > > (occurs multiple times) fixed > g) s/vacmSecurityToGroup table/vacmSecurityToGroupTable/ > > (occurs multiple times) fixed > h) I am wondering whether we should change the naming scheme. Extended > VACM is perhaps to too wide name and we do not follow the VACM MIB > prefixing scheme. Here is what I have in mind: > > OLD: NEW: > > SNMP-EXT-VACM-MIB SNMP-VACM-AAA-MIB > snmpExtVacmMIB snmpVacmAaaMIB > extVacmMIBObjects vacmAaaMIBObjects > extVacmMIBConformance vacmAAAMIBConformance > extVacmSecurityToGroupTable vacmAaaSecurityToGroupTable > extVacmSecurityToGroupEntry vacmAaaSecurityToGroupEntry > ExtVacmSecurityToGroupEntry VacmAaaSecurityToGroupEntry > extVacmSecurityModel vacmAaaSecurityModel > extVacmSecurityName vacmAaaSecurityName > extVacmTransportModel vacmAaaTransportModel > extVacmTransportSessionID vacmAaaTransportSessionID > extVacmGroupName vacmAaaGroupName > extVacmMIBCompliances vacmAaaMIBCompliances > extVacmMIBGroups vacmAaaMIBGroups > extVacmMIBBasicCompliance vacmAaaMIBBasicCompliance > extVacmGroup vacmAaaGroup > > This proposed change requires some editorial effort but does > technically not change anything except that we are dealing more > carefully with the descriptor namespace. Done. I've posted an updated version as draft-presuhn-isms-radius-vacm-alt-02.txt Randy From randy_presuhn@mindspring.com Mon Jul 5 10:58:33 2010 Return-Path: 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 9321A28C0CE for ; Mon, 5 Jul 2010 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdtLYBpSLFzp for ; Mon, 5 Jul 2010 10:58:32 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id B69B928B23E for ; Mon, 5 Jul 2010 10:58:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QqkWvns+SGj5Wc0WBCFQlkv9LkZGuuSO5CtpRjeBbEi+485fcEGg/915NIfab04k; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.173.118] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OVpw9-0005Rh-Gj for isms@ietf.org; Mon, 05 Jul 2010 13:58:33 -0400 Message-ID: <002601cb1c6b$fc22ab40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Mon, 5 Jul 2010 11:00:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780356da3c239d712ddfb89b5428ab939722c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.173.118 Subject: [Isms] Fw: I-D Action:draft-presuhn-isms-radius-vacm-alt-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: , X-List-Received-Date: Mon, 05 Jul 2010 17:58:33 -0000 Hi - I've included Juergen's comments in this update. Randy ----- Original Message ----- > From: > To: > Sent: Monday, July 05, 2010 10:45 AM > Subject: I-D Action:draft-presuhn-isms-radius-vacm-alt-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings > Author(s) : K. Narayan, et al. > Filename : draft-presuhn-isms-radius-vacm-alt-02.txt > Pages : 18 > Date : 2010-07-05 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols. It describes the use of > information provided by Authentication, Authorization, and Accounting > (AAA) services, such as the Remote Authentication Dial-In User > Service (RADIUS), to dynamically update user-to-group mappings in the > View-Based Access Control Model (VACM). > > Comments are solicited and should be addressed to the working group's > mailing list at isms@ietf.org. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-presuhn-isms-radius-vacm-alt-02.txt ... From randy_presuhn@mindspring.com Mon Jul 5 11:00:05 2010 Return-Path: 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 CBE7728C0D0 for ; Mon, 5 Jul 2010 11:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyY6DVOzQffF for ; Mon, 5 Jul 2010 11:00:04 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4A51C28C0E2 for ; Mon, 5 Jul 2010 11:00:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KYp/7G2ikx559p+ItaqzINyNh7x1z3s6JF5n4JspzmGnix+dtZASwWCpM5HlnkW/; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.173.118] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OVpxd-0001Fj-5M for isms@ietf.org; Mon, 05 Jul 2010 14:00:05 -0400 Message-ID: <002b01cb1c6c$333443a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <004301cb1504$bee19b60$6801a8c0@oemcomputer> <20100704103022.GA25653@elstar.local> Date: Mon, 5 Jul 2010 11:02:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc7205327803530850f25f10eb477c1d5455d3ca33fdb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.173.118 Subject: Re: [Isms] Fw: I-D Action:draft-presuhn-isms-radius-vacm-alt-01.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: , X-List-Received-Date: Mon, 05 Jul 2010 18:00:05 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Sunday, July 04, 2010 3:30 AM > Subject: Re: [Isms] Fw: I-D Action:draft-presuhn-isms-radius-vacm-alt-01.txt > > On Sat, Jun 26, 2010 at 09:54:02AM +0200, Randy Presuhn wrote: > > > I've updated the individual i-d exploring how we might resolve David > > Harrington's WG last call comments on the RADIUS/VACM i-d. > > I have reviewed draft-presuhn-isms-radius-vacm-alt-01.txt and I think > it is technically in a good shape. I have a number of editorial > comments as detailed below. > > As co-chair, I like to ask Randy to submit another revision as > draft-ietf-isms-radius-vacm-07.txt. Once in place, I will do a final > quick check to confirm the changes that have been made. I've updated the individual i-d. A bunch of holiday guests just arrived, so I won't be able to update the WG i-d until later today. Randy From root@core3.amsl.com Mon Jul 5 16:30:02 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 576633A67B1; Mon, 5 Jul 2010 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705233002.576633A67B1@core3.amsl.com> Date: Mon, 5 Jul 2010 16:30:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-07.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: , X-List-Received-Date: Mon, 05 Jul 2010 23:30:02 -0000 --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 : Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-07.txt Pages : 18 Date : 2010-07-05 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-Based Access Control Model (VACM). Comments are solicited and should be addressed to the working group's mailing list at isms@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-vacm-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05162512.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Tue Jul 6 03:01:14 2010 Return-Path: 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 297013A68F6; Tue, 6 Jul 2010 03:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.824 X-Spam-Level: X-Spam-Status: No, score=-0.824 tagged_above=-999 required=5 tests=[AWL=1.425, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsKt8FbfwEaP; Tue, 6 Jul 2010 03:01:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7659A3A6907; Tue, 6 Jul 2010 03:01:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AE84C0007; Tue, 6 Jul 2010 12:01:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TMOVsKffIOu4; Tue, 6 Jul 2010 12:01:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18988C0002; Tue, 6 Jul 2010 12:01:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E575913874E7; Tue, 6 Jul 2010 12:01:08 +0200 (CEST) Date: Tue, 6 Jul 2010 12:01:08 +0200 From: Juergen Schoenwaelder To: "Internet-Drafts@ietf.org" Message-ID: <20100706100108.GB31883@elstar.local> Mail-Followup-To: "Internet-Drafts@ietf.org" , "isms@ietf.org" References: <20100705233002.576633A67B1@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100705233002.576633A67B1@core3.amsl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-07.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 10:01:14 -0000 On Tue, Jul 06, 2010 at 01:30:02AM +0200, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. [...] > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-07.txt Minor nit: It seems vacmAAAMIBConformance should be vacmAaaMIBConformance for consistency. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Jul 6 04:22:32 2010 Return-Path: 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 557C43A6876 for ; Tue, 6 Jul 2010 04:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.191 X-Spam-Level: X-Spam-Status: No, score=0.191 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwNf30RPHzWt for ; Tue, 6 Jul 2010 04:22:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B31983A685E for ; Tue, 6 Jul 2010 04:22:30 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81E6BC0006 for ; Tue, 6 Jul 2010 13:22:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gptIxPg8zszA; Tue, 6 Jul 2010 13:22:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77E21C0002; Tue, 6 Jul 2010 13:22:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D42941387E17; Tue, 6 Jul 2010 13:22:28 +0200 (CEST) Date: Tue, 6 Jul 2010 13:22:28 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100706112228.GB32765@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] final last call on isms-radius-vacm-07 (deadline 2010-07-13) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 11:22:32 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Randy posted http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-07 and here is the final last call to verify that everybody is happy with revision. As you might recall, the last rewrite resulted from comments we received from David Harrington. This final last call ends in one week on July 13th. This is going to be a strict deadline. Small nits that are discovered during this review period can be collected by the editor (Randy) and then we can decide whether we deal with them as part of the IESG procedure or spin a new ID (the reason is that we hit the cutoff period). I am attaching my document writeup. I am also happy to receive feedback on the document writeup, in particular information whether anybody is implementing this specification or planning to implement this specification. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-radius-vacm-writeup.txt" Document: draft-ietf-isms-radius-vacm-07.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Schoenwaelder is the document shepherd. I have reviewed the document several times including the latest version and I believe it is ready for forwarding it to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has received WG last call reviews and comments from - Dave Nelson - David Harrington - Juergen Schoenwaelder - Andrew Donati - Jeffrey Hutzelman and I do not have any concerns regarding the level of review for this document, given that the document is also a minor addition to SNMP. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not think the document needs special reviews. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been checked with idnits 2.12.00. The document contains a MIB module and should go through the MIB doctor review processs. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative documents have been published. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document requests a number of assignment in an existing registry. It does not create any new registries. I believe the IANA instructions are clear. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The MIB module has been checked using smilint for syntactic correctness. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The document describes how to use Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), for access control authorization within the Simple Network Management Protocol (SNMP) framework. A MIB module is provided to dynamically update user-to-group mappings in the View-Based Access Control Model (VACM). Working Group Summary The working group went over several revisions of this document and the document and all WG last call comments have been resolved. There has been strong WG consensus to publish this document as Proposed Standard. Document Quality The chair is not aware of any implementations at this point in time. Dave Harrington has provided significant reviews that helped to with the clarity and modularity aspects of the SNMP specifications. --/04w6evG8XlLl3ft-- From ietfdbh@comcast.net Tue Jul 6 10:22:42 2010 Return-Path: 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 0AED63A699C for ; Tue, 6 Jul 2010 10:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrVnGsuQYCP7 for ; Tue, 6 Jul 2010 10:22:40 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 5CE5A3A6846 for ; Tue, 6 Jul 2010 10:22:40 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id ebop1e0090bG4ec55hNjeR; Tue, 06 Jul 2010 17:22:43 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta03.westchester.pa.mail.comcast.net with comcast id ehNi1e00h2JQnJT3PhNiPV; Tue, 06 Jul 2010 17:22:43 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , References: <20100706112228.GB32765@elstar.local> Date: Tue, 6 Jul 2010 13:22:37 -0400 Message-ID: <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acsc/Yq64+m3s+m8QHyJ5W353smnTwAHmURQ In-Reply-To: <20100706112228.GB32765@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline 2010-07-13) 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: , X-List-Received-Date: Tue, 06 Jul 2010 17:22:42 -0000 Hi, me again. really guys, I'm trying to reach a point of full support for the doc, without raising any new issues. but I have a few concerns about the new text that I think should be addressed before sending this to IESG. and unfortunately, I'm not sure an RFC editor note will suffice for some of it. I know I looked at the rewrite already, but the same eyes on different days see different things. Sorry for the verbosity, but I'm trying to explain the problem, not just propose simple rewordings. Maybe I'm wrong and these things can be ignored, but please at least look at these points. 1) in 5.2, there is a discussion of multiple concurrent security models. Doesn't this also support multiple concurrent transport models, now that we use the prefix to disambiguate the transport model associated with the sessionID? I don't think that's clear in 5.2 (but might be clear enough elsewhere) 2) I think the "unique identifier of a session" is really the unique identifier of a transport model session, and tmsessionid depends on a transport model to generate such an id. (Note that I am not saying the unique identifier of a transport session, only the transport model session.) (Hmmm, let's see, have I argued that transport sessino ID should not be used because the VACM subsytem shouldn't have access to the transport model info? Am I contradicting myself? I don't remember. boy this architecture makes my head hurt ...) While there is text that says other AAA or non-AAA mechanisms can be used as well, you really need an identifier that signifies/implies/provides the binding between a transport connection (I think this might be the NAS session in AAA terms) and the authenticated identity and the dynamically-provided service-authorization (as is provided by SSHTM and TLSTM). This is the purpose of a transport model session. Then this specification adds the data-access-authorization to the existing transport/user/service binding. So, if, as an implementer, I am using my own home-grown authentication and authorization mechanism, I will need to provide some type of tmsessionID that implies a security binding between the connection, the identity, and the service. i.e., I need to provide a tmsessionID. and **tm**sessionID implies I really need to define (at least loosely) a transport model. The tmsessionid is used as an example, but I am not sure any other sessionid would work. Guidelines for developing a transport model are provided in the 559x series, but by having this spec not say that they really need to develop a transport model, implementers might be more apt to not follow the guidelines and to make mistakes. So I think the text about other mechanisms should be tightened up to being "other standard or proprietary transport models", possibly with a pointer to the requirements specified in 5590. 3) in 7.2 we start dealing with the transport model prefix. I like this choice because the prefix makes it pretty clear what's in use, compared to an OID. This has a couple implications however. Registry Name: SNMP Transport Domains Reference: [RFC2578] [RFC3417] [RFC5590] Registration Procedures: Specification Required Each domain is assigned a MIB-defined OID under snmpDomains 3a) I think the text needs to identify the IANA registry more clearly. Currently, the text just points to RFC5590; I think it should reference the IANA registry directly, because other RFCs define prefixes as well. Since we only point to 5590, it might not be clear that 5592 also registers some prefixes. And TLSTM registers prefixes. And other specfications used to register prefixes won't be obvious from looking at 5590, but would be obvious looking at the registry. (and someplace the rfc editor provided guidance about how to reference IANA registries.) 3b) the text refers to the "registered prefix". This means any prefix used for AAA-VACM must be registered. The registry requires a specification, and requires transport domains that are registered under snmpDomains. I don't think the current text that talks about other mechanisms makes it clear that these specification and registration requirements exist. 4) If somebody makes up their own prefix without registering it, they could create conflicts with existing standard prefixes (or two proprietary implementations might choose the same prefix). The registration mechanism basically asserts the need to develop a ***transport model*** specification to help ensure interoperability. (supporting my point 2) 5) If an implementer mistakenly used "ssh" as the prefix for their own SSH-based authentication mechanism without all the MUST NOTs found in 5592, this would assert to an operator-configured AAA-VACM that the tmSessionID was generated by SSHTM, and this could create security vulnerabiltiies as a result of using two concurrent transport models that are not clearly dis-ambiguated. Since AAA-VACM doesn't check the authentication assertion implicit in the "ssh" prefix, a hacker might be able to compromise the system. The potential vulnerabilities of prefix usage is not discussed in security considerations. (Given thet we just added the transport model identifier, SecCons doesn't talk about a false assertion of the transport model at all, whether identified using a prefix or an OID. I'm not quite sure what the vulnerability might be.) 6) in 7.1, early session termination MAY result in denial of access. should this be a SHOULD? (with an example exception being that an implementation can distinguish between requests received before session termination but not yet processed, from those recieved after session termination). In AAA standards, is there support for deliberately interupting processing to revoke existing authorization policy? If so, then maybe this should be a MUST. or maybe SHOULD is appropriate because it depends on the specific authorization mechanism, and might be MAY for some, SHOULD for others, and MUST for some (and if this is the case, this should be discussed in SecCons). 7) I think the security considerations should include a pointer to 7.2.3. I am not sure if somehow this could be turned into an attack, but a security admin looking at the security considerations should be made aware that this groupname re-assignment is supported, because the assumptions in this spec need to match the assumptions in the AAA-style authorization mechanism. Just a SecCons note with a pointer to 7.2.3 is all I suggest. 8) an operational consideration: tmsessionid is being used as an index in the mib. is tmsessionid guaranteed to be sufficiently predictable, including with proprietary transport models, to ensure that an operator can do manual config of an entry when needed, suhc as for debugging? 9) I am a bit concerned about the ambiguity in the name of vacmAaaTransportSessionID, and the description in the table that talks about a session, without clarifying it is a transport model session, not necessarily a transport session. Hope this helps. Randy (and the rest of the WG), keep up the good work. I know this is irritating to get these late comments. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, July 06, 2010 7:22 AM > To: isms@ietf.org > Subject: [Isms] final last call on isms-radius-vacm-07 > (deadline 2010-07-13) > > Hi, > > Randy posted http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-07 > and here is the final last call to verify that everybody is > happy with revision. As you might recall, the last rewrite > resulted from comments we received from David Harrington. > This final last call ends in one week on July 13th. This is > going to be a strict deadline. > > Small nits that are discovered during this review period can > be collected by the editor (Randy) and then we can decide > whether we deal with them as part of the IESG procedure or > spin a new ID (the reason is that we hit the cutoff period). > > I am attaching my document writeup. I am also happy to > receive feedback on the document writeup, in particular > information whether anybody is implementing this > specification or planning to implement this specification. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From randy_presuhn@mindspring.com Tue Jul 6 10:34:24 2010 Return-Path: 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 B1AC03A6878 for ; Tue, 6 Jul 2010 10:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQEXm6ZkOoxl for ; Tue, 6 Jul 2010 10:34:23 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 95E403A6944 for ; Tue, 6 Jul 2010 10:34:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lEujhA1kiNt0lny47FE63TNgIEqmbSvE+5XK2QeEbkmZwvu+Zj3f90JrxIuz1uen; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.24.210] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWC2L-0008Tw-D3 for isms@ietf.org; Tue, 06 Jul 2010 13:34:25 -0400 Message-ID: <005301cb1d31$c87e1420$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100705233002.576633A67B1@core3.amsl.com> <20100706100108.GB31883@elstar.local> Date: Tue, 6 Jul 2010 10:36:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035608fae0b99977d1fda42693142c4904a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.24.210 Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-07.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: , X-List-Received-Date: Tue, 06 Jul 2010 17:34:24 -0000 Hi - Fixed. -08 should soon appear. Randy > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Tuesday, July 06, 2010 3:01 AM > Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-07.txt > > On Tue, Jul 06, 2010 at 01:30:02AM +0200, Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > [...] > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-07.txt > > Minor nit: It seems > > vacmAAAMIBConformance > > should be > > vacmAaaMIBConformance > > for consistency. > > /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 randy_presuhn@mindspring.com Tue Jul 6 10:37:41 2010 Return-Path: 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 CAA033A684B for ; Tue, 6 Jul 2010 10:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr5lnowuFDnk for ; Tue, 6 Jul 2010 10:37:40 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 9651B3A683A for ; Tue, 6 Jul 2010 10:37:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CO41EMeJIsCYu7XzgpQwniIYQRstf3HVrJxqRMpguG36h03D2Uj/R69UXSt0oPnN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.24.210] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWC5W-0002Dy-Ga for isms@ietf.org; Tue, 06 Jul 2010 13:37:42 -0400 Message-ID: <006a01cb1d32$3ebdfd80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100706112228.GB32765@elstar.local> Date: Tue, 6 Jul 2010 10:39:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780356fb5716b3323958e07569c56756eecc4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.24.210 Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline 2010-07-13) 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: , X-List-Received-Date: Tue, 06 Jul 2010 17:37:41 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Tuesday, July 06, 2010 4:22 AM > Subject: [Isms] final last call on isms-radius-vacm-07 (deadline 2010-07-13) > > Hi, > > Randy posted http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-07 > and here is the final last call to verify that everybody is happy with > revision. As you might recall, the last rewrite resulted from comments > we received from David Harrington. This final last call ends in one > week on July 13th. This is going to be a strict deadline. > > Small nits that are discovered during this review period can be > collected by the editor (Randy) and then we can decide whether we deal > with them as part of the IESG procedure or spin a new ID (the reason > is that we hit the cutoff period). Ooops. I already posted -08 with the spelling change Juergen requested. > I am attaching my document writeup. I am also happy to receive > feedback on the document writeup, in particular information whether > anybody is implementing this specification or planning to implement > this specification. In the writeup, s/helped to with/helped with/ Randy From root@core3.amsl.com Tue Jul 6 10:45:02 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 41B413A695B; Tue, 6 Jul 2010 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100706174502.41B413A695B@core3.amsl.com> Date: Tue, 6 Jul 2010 10:45:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-08.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: , X-List-Received-Date: Tue, 06 Jul 2010 17:45:02 -0000 --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 : Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-08.txt Pages : 18 Date : 2010-07-06 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-Based Access Control Model (VACM). Comments are solicited and should be addressed to the working group's mailing list at isms@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-vacm-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-06103345.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Tue Jul 6 11:59:13 2010 Return-Path: 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 EFC313A686E for ; Tue, 6 Jul 2010 11:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFXG7IsjPMAe for ; Tue, 6 Jul 2010 11:59:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E73E23A6848 for ; Tue, 6 Jul 2010 11:59:11 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08EC6C0006; Tue, 6 Jul 2010 20:59:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IP3cwdCzWZYA; Tue, 6 Jul 2010 20:59:13 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A126BC0002; Tue, 6 Jul 2010 20:59:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD019138931C; Tue, 6 Jul 2010 20:59:08 +0200 (CEST) Date: Tue, 6 Jul 2010 20:59:08 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100706185908.GA2197@elstar.local> Mail-Followup-To: David Harrington , "isms@ietf.org" References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline 2010-07-13) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 18:59:13 -0000 On Tue, Jul 06, 2010 at 07:22:37PM +0200, David Harrington wrote: > [...] Sorry for the verbosity, but I'm trying to explain the > problem, not just propose simple rewordings. Maybe I'm wrong and > these things can be ignored, but please at least look at these > points. As co-chair, I like to ask you to send us proposed rewordings so that we can be sure we understand the changes you want to be carried out. This is going to be the final WG last call - contributors who want additional changes to the document are expected to help us by being precise concerning the changes they want applied to the document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Tue Jul 6 20:07:48 2010 Return-Path: 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 A83963A6970 for ; Tue, 6 Jul 2010 20:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbC0b1JiATVM for ; Tue, 6 Jul 2010 20:07:47 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 2966F3A6967 for ; Tue, 6 Jul 2010 20:07:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rkCtizB2BgjVaZoIieHS8/RFg56zFZhMv3vOIMs9Kbx6kKiKgKCI86P/JeaRgcKT; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.93.119] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWKzD-0006Ls-6o for isms@ietf.org; Tue, 06 Jul 2010 23:07:47 -0400 Message-ID: <000601cb1d81$e32c2960$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> Date: Tue, 6 Jul 2010 20:09:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc7205327803570af161fa4ccbac2edd5d5bce780b2fa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.119 Subject: [Isms] radius-vacm section 5.2 (was: final last call on isms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 03:07:48 -0000 Hi - (As a technical contributor) > From: "David Harrington" > To: "'Juergen Schoenwaelder'" ; > Sent: Tuesday, July 06, 2010 10:22 AM > Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13) .... > 1) in 5.2, there is a discussion of multiple concurrent security > models. Doesn't this also support multiple concurrent transport > models, now that we use the prefix to disambiguate the transport model > associated with the sessionID? I don't think that's clear in 5.2 (but > might be clear enough elsewhere) Rather than adding more verbiage, I propose deleting the following sentence from section 5.2 to address this comment: This index structure was chosen to support use cases in which a given user could potentially have multiple concurrent sessions, and to support environments in which multiple security models might find concurrent usage. Since this is only explanatory text, deleting it will have no normative impact. Randy From randy_presuhn@mindspring.com Tue Jul 6 20:18:18 2010 Return-Path: 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 EFC373A67F6 for ; Tue, 6 Jul 2010 20:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X70Szgm3RBxw for ; Tue, 6 Jul 2010 20:18:16 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 1D03B3A67B4 for ; Tue, 6 Jul 2010 20:18:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VeZocjf0uosIJL2KQ+63ojTV7c2+jG8EUb/S1Z/yrFqHE6MOgumB0s/2qjZrDDsF; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.93.119] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWL9O-0000ek-6p for isms@ietf.org; Tue, 06 Jul 2010 23:18:18 -0400 Message-ID: <000901cb1d83$5b4d3960$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> Date: Tue, 6 Jul 2010 20:20:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780350ab9a7ca971650604073b3d4892f14a2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.119 Subject: [Isms] radius/vacm section 7.2 (was Re: final last call on isms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 03:18:18 -0000 Hi - As a technical contributor... > From: "David Harrington" > To: "'Juergen Schoenwaelder'" ; > Sent: Tuesday, July 06, 2010 10:22 AM > Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13) ... > 3) in 7.2 we start dealing with the transport model prefix. I like > this choice because the prefix makes it pretty clear what's in use, > compared to an OID. This has a couple implications however. > > Registry Name: SNMP Transport Domains > Reference: [RFC2578] [RFC3417] [RFC5590] > Registration Procedures: Specification Required > Each domain is assigned a MIB-defined OID under snmpDomains > > 3a) I think the text needs to identify the IANA registry more clearly. > Currently, the text just points to RFC5590; I think it should > reference the IANA registry directly, because other RFCs define > prefixes as well. Since we only point to 5590, it might not be clear > that 5592 also registers some prefixes. And TLSTM registers prefixes. > And other specfications used to register prefixes won't be obvious > from looking at 5590, but would be obvious looking at the registry. > (and someplace the rfc editor provided guidance about how to reference > IANA registries.) Proposed change to section 4.1: OLD: The tmSessionID (along with its transport model prefix) [RFC5590] is a suitable identifier for a AAA-authorized "session". This is NEW: The tmSessionID (along with its transport model prefix from the SNMP Transport Domains registry) [RFC5590] is a suitable identifier for a AAA-authorized "session". This is Proposed change to section 6.2: OLD: [RFC3411]. The module also relies on the IANA registry defined in [RFC5590] for transport domain prefixes. NEW: [RFC3411]. The module also relies on the IANA SNMP Transport Domains registry defined in [RFC5590] for transport domain prefixes. Section 7.2: OLD: o a session identifier, such as tmSessionID [RFC5590] along with the prefix for its transport domain, as a definitive identifier of the transport session that the AAA authorization is tied to; NEW: o a session identifier, such as tmSessionID [RFC5590] along with the prefix for its transport domain from the SNMP Transport Domains registry, as a definitive identifier of the transport session that the AAA authorization is tied to; > 3b) the text refers to the "registered prefix". This means any prefix > used for AAA-VACM must be registered. The registry requires a > specification, and requires transport domains that are registered > under snmpDomains. I don't think the current text that talks about > other mechanisms makes it clear that these specification and > registration requirements exist. I see no need to replicate requirements from other RFCs - to do so is simply to invite maintenance headaches. Randy From randy_presuhn@mindspring.com Tue Jul 6 20:37:21 2010 Return-Path: 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 EDB423A6825 for ; Tue, 6 Jul 2010 20:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-yoq4CFQECb for ; Tue, 6 Jul 2010 20:37:15 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DB8173A67EF for ; Tue, 6 Jul 2010 20:37:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mT2jljoOpmNiLa8iaYS33whXuQNfNzb4BuO4Xu9RYnPdBb/WhdV9qXd9QsnCs1qs; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.93.119] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWLRl-0006pJ-1k for isms@ietf.org; Tue, 06 Jul 2010 23:37:17 -0400 Message-ID: <000e01cb1d86$0218e440$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> Date: Tue, 6 Jul 2010 20:39:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780350cd377268be831a7357c72fd7fa8f180350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.119 Subject: [Isms] prefix clashes (was: Re: final last call on isms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 03:37:21 -0000 Hi - As a technical contributor... > From: "David Harrington" > To: "'Juergen Schoenwaelder'" ; > Sent: Tuesday, July 06, 2010 10:22 AM > Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13) ... > 4) If somebody makes up their own prefix without registering it, they > could create conflicts with existing standard prefixes (or two > proprietary implementations might choose the same prefix). The > registration mechanism basically asserts the need to develop a > ***transport model*** specification to help ensure interoperability. > (supporting my point 2) The prefix only serves to make the ID unique. (in any sane implementation strategy, the ID would be unique anyway, IMO - the need for the prefix is merely an artefact of the way the architecture is described, and makes no sense in terms of what needs to happen inside a master agent) It doesn't really matter what the value is, as long as there are no clashes within a particular implementation. > 5) If an implementer mistakenly used "ssh" as the prefix for their own > SSH-based authentication mechanism without all the MUST NOTs found in > 5592, this would assert to an operator-configured AAA-VACM that the What do you mean by "operator-configured"? There are no configurable objects in this MIB module. > tmSessionID was generated by SSHTM, and this could create security > vulnerabiltiies as a result of using two concurrent transport models > that are not clearly dis-ambiguated. Since AAA-VACM doesn't check the > authentication assertion implicit in the "ssh" prefix, a hacker might > be able to compromise the system. An earlier version of the i-d specifically addressed the trust issues - folks were quite adamant in wanting them removed. > The potential vulnerabilities of prefix usage is not discussed in > security considerations. Broken implementations are infinitely vulnerable. I think trying to identify all the possible bugs that might occur in implementations would not be at all helpful. > (Given thet we just added the transport model identifier, SecCons > doesn't talk about a false assertion of the transport model at all, > whether identified using a prefix or an OID. I'm not quite sure what > the vulnerability might be.) Previous comments removed the language from the security considerations section that would have pre-emptively addressed this issue. But the fact is that the transport model identifier is merely a uniquifier. NOTHING in this MIB module attributes any semantics to the value. If we do *anything* about this comment, my preference would be to remove all reference to the transport model identifier, and instead of providing any helpful references to tmSessionID, to simply replace it with words about a "unique identifier for each session, derived in an implementation-specific manner". Randy From randy_presuhn@mindspring.com Tue Jul 6 20:45:30 2010 Return-Path: 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 7227E3A6970 for ; Tue, 6 Jul 2010 20:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01EEFWC5iwue for ; Tue, 6 Jul 2010 20:45:28 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 660BF3A6967 for ; Tue, 6 Jul 2010 20:45:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d+ks7BJXHWeI+osj3C6MU9yVO6imbUnfszxf6qzJJIeQK7xHeywfhh/KEVmaeQrl; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.93.119] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWLZh-0005NG-DR; Tue, 06 Jul 2010 23:45:29 -0400 Message-ID: <001301cb1d87$277ec140$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "David Harrington" , "'Juergen Schoenwaelder'" , References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> Date: Tue, 6 Jul 2010 20:47:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780353f82d6101ff2e62d8c26bf3672207e40350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.119 Subject: [Isms] radius/vacm section 7.1 (was Re: final last call on isms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 03:45:30 -0000 Hi - As a technical contributor... > From: "David Harrington" > To: "'Juergen Schoenwaelder'" ; > Sent: Tuesday, July 06, 2010 10:22 AM > Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13) ... > 6) in 7.1, early session termination MAY result in denial of access. > should this be a SHOULD? No. I think you're over-analyzing. Whether termination results in denial of access will depend on how VACM was configured in the first place. For example, if VACM would have allowed access anyway, session termination won't impact the operation, unless the implementation builds in special hooks to terminate in-progress operations. I think *requiring* implementations to add such hooks would be a huge step in the wrong direction. > (with an example exception being that an > implementation can distinguish between requests received before > session termination but not yet processed, from those recieved after > session termination). In AAA standards, is there support for > deliberately interupting processing to revoke existing authorization > policy? If so, then maybe this should be a MUST. or maybe SHOULD is > appropriate because it depends on the specific authorization > mechanism, and might be MAY for some, SHOULD for others, and MUST for > some (and if this is the case, this should be discussed in SecCons). Let's not go there. This is very much bound up in how the master agent queus and dispatches, and I think we should avoid over-prescribing this extreme corner case. Randy From randy_presuhn@mindspring.com Tue Jul 6 20:53:37 2010 Return-Path: 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 44E663A6825 for ; Tue, 6 Jul 2010 20:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLHcK77lDwJT for ; Tue, 6 Jul 2010 20:53:36 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 3F65E3A6813 for ; Tue, 6 Jul 2010 20:53:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tMv8zyO6E3JtfJm2I8j2L/nrnVrzcHO/r/fkYMYZOaIZBcGEGK0MNRsGWpriphnp; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.93.119] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWLha-0005Wr-CQ for isms@ietf.org; Tue, 06 Jul 2010 23:53:38 -0400 Message-ID: <002401cb1d88$4b0704a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> Date: Tue, 6 Jul 2010 20:55:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780357c877b8a80e4bf9ea9473ba0701b20cb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.119 Subject: [Isms] pointer to 7.2.3 Re: final last call on isms-radius-vacm-07 (deadline2010-07-13) 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: , X-List-Received-Date: Wed, 07 Jul 2010 03:53:37 -0000 Hi - (as a technical contributor...) > From: "David Harrington" > To: "'Juergen Schoenwaelder'" ; > Sent: Tuesday, July 06, 2010 10:22 AM > Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13) ... > 7) I think the security considerations should include a pointer to > 7.2.3. I am not sure if somehow this could be turned into an attack, > but a security admin looking at the security considerations should be > made aware that this groupname re-assignment is supported, because the > assumptions in this spec need to match the assumptions in the > AAA-style authorization mechanism. Just a SecCons note with a pointer > to 7.2.3 is all I suggest. Uhhh... What about the current first paragraph of the security considerations section? It spells out the issue in full detail. I suggest no action is needed here. Randy From randy_presuhn@mindspring.com Tue Jul 6 20:57:09 2010 Return-Path: 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 7EA323A696F for ; Tue, 6 Jul 2010 20:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf8-FXEis-To for ; Tue, 6 Jul 2010 20:57:08 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id A7BEA3A6813 for ; Tue, 6 Jul 2010 20:57:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MGeMtyP56jwWfA9Mr1s8qHVkJ5L/mQaC2eOfERWxsH+Zh7ToyZTI3aRvjHSqwB7P; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.93.119] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWLkq-0002rz-VI for isms@ietf.org; Tue, 06 Jul 2010 23:57:01 -0400 Message-ID: <002b01cb1d88$b4f7fd60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> Date: Tue, 6 Jul 2010 20:58:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035275124bc8435e6b719d1ad5d2405b1fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.119 Subject: [Isms] radius/vacm - manual config (was Re: final last call on isms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 03:57:09 -0000 Hi - As a technical contributor... > From: "David Harrington" > To: "'Juergen Schoenwaelder'" ; > Sent: Tuesday, July 06, 2010 10:22 AM > Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13) ... > 8) an operational consideration: tmsessionid is being used as an index > in the mib. is tmsessionid guaranteed to be sufficiently predictable, > including with proprietary transport models, to ensure that an > operator can do manual config of an entry when needed, suhc as for > debugging? Since there are no writeable objects in this MIB module, I think this issue is out of scope, and no action is needed. Randy From randy_presuhn@mindspring.com Tue Jul 6 21:07:36 2010 Return-Path: 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 B60D23A6957 for ; Tue, 6 Jul 2010 21:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M1XNSjyGPWN for ; Tue, 6 Jul 2010 21:07:34 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 7178B3A6813 for ; Tue, 6 Jul 2010 21:07:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sJfXLtw7/GGOlBaoaXqAD4Kva9CsRFATzagjwOl2TY4Z1wb5oP7RphOFsKl9F1YA; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.93.119] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWLuw-0002NC-Nm for isms@ietf.org; Wed, 07 Jul 2010 00:07:27 -0400 Message-ID: <003001cb1d8a$29d1d1a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> Date: Tue, 6 Jul 2010 21:08:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035a329c5b3df8f81cdeb823e039206f7b3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.119 Subject: [Isms] transport (model) session? (was: Re: final last call on isms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 04:07:36 -0000 Hi - > From: "David Harrington" > To: "'Juergen Schoenwaelder'" ; > Sent: Tuesday, July 06, 2010 10:22 AM > Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13) ... > 9) I am a bit concerned about the ambiguity in the name of > vacmAaaTransportSessionID, and the description in the table that talks > about a session, without clarifying it is a transport model session, > not necessarily a transport session. Thinking like an implementor, this seems to be a distinction without a difference. The current I-D says: DESCRIPTION "A specific identifier of the session. This value MUST be unique among all currently open sessions within a transport model. The value has no particular significance other to distinguish sessions. An example of a suitable value would be tmSessionID." If this terminology is readlly a problem, I think we should stop trying to be helpful, remove the transport prefix, and just say that the session id is unique within a master agent, derived by implementation- specific means. In sane implementations, it will end up having exactly the same bit pattern as tmSessionID, but we won't mention that. Randy From ietfdbh@comcast.net Wed Jul 7 08:34:40 2010 Return-Path: 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 102A43A67BD for ; Wed, 7 Jul 2010 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 yGozJ8xiBQKA for ; Wed, 7 Jul 2010 08:34:22 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id B16CC3A684D for ; Wed, 7 Jul 2010 08:34:19 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id ezAh1e0040QuhwU513aPrs; Wed, 07 Jul 2010 15:34:23 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta02.westchester.pa.mail.comcast.net with comcast id f3aP1e00G2JQnJT3N3aPhi; Wed, 07 Jul 2010 15:34:23 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20100706112228.GB32765@elstar.local><6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> <000601cb1d81$e32c2960$6801a8c0@oemcomputer> Date: Wed, 7 Jul 2010 11:34:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsdgZeB3npulSpARuW6lIAPHCjYjQAaEXkw In-Reply-To: <000601cb1d81$e32c2960$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] radius-vacm section 5.2 (was: final last call onisms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 15:34:40 -0000 +1 dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Tuesday, July 06, 2010 11:10 PM > To: isms@ietf.org > Subject: [Isms] radius-vacm section 5.2 (was: final last call > onisms-radius-vacm-07 (deadline2010-07-13)) > > Hi - > > (As a technical contributor) > > > From: "David Harrington" > > To: "'Juergen Schoenwaelder'" > ; > > > > Sent: Tuesday, July 06, 2010 10:22 AM > > Subject: Re: [Isms] final last call on isms-radius-vacm-07 > > (deadline2010-07-13) > .... > > 1) in 5.2, there is a discussion of multiple concurrent security > > models. Doesn't this also support multiple concurrent transport > > models, now that we use the prefix to disambiguate the > transport model > > associated with the sessionID? I don't think that's clear > in 5.2 (but > > might be clear enough elsewhere) > > Rather than adding more verbiage, I propose deleting the > following sentence from section 5.2 to address this comment: > > This index structure was chosen to support use cases > in which a given user could potentially have multiple concurrent > sessions, and to support environments in which multiple security > models might find concurrent usage. > > Since this is only explanatory text, deleting it will have no > normative impact. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfdbh@comcast.net Wed Jul 7 09:03:32 2010 Return-Path: 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 71B0E3A672E for ; Wed, 7 Jul 2010 09:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.720, 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 IQZLle3QSiNy for ; Wed, 7 Jul 2010 09:03:30 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 7B1E13A6840 for ; Wed, 7 Jul 2010 09:03:30 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id ezwy1e0041vXlb85D43a33; Wed, 07 Jul 2010 16:03:34 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id f43Z1e00S2JQnJT3d43ZCF; Wed, 07 Jul 2010 16:03:34 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20100706112228.GB32765@elstar.local><6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> <000901cb1d83$5b4d3960$6801a8c0@oemcomputer> Date: Wed, 7 Jul 2010 12:03:36 -0400 Message-ID: <3A8F612FD9634E0D87CF99AD71CFB086@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acsdgw8DCVaCDB+wRBGoyWv2w4d5agAZw2bw In-Reply-To: <000901cb1d83$5b4d3960$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] radius/vacm section 7.2 (was Re: final last call onisms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 16:03:32 -0000 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn +1 on the changes proposed for 3) and 3a) > > > 3b) the text refers to the "registered prefix". This means > any prefix > > used for AAA-VACM must be registered. The registry requires a > > specification, and requires transport domains that are registered > > under snmpDomains. I don't think the current text that talks about > > other mechanisms makes it clear that these specification and > > registration requirements exist. > > I see no need to replicate requirements from other RFCs - to > do so is simply to invite maintenance headaches. My point is that this spec really promotes the idea of "other mechanisms" besides standard AAA and standard transort models. I understand that you want to allow for non-standard AAA, such as TACACS+, and proprietary authentication and authroization mechanisms such as those that already exist internally for CLI transport, authentication and authorization. However, because you are using the transport model prefix, you are forcing it to be true, even for proprietary other mechanisms, that you MUST specify a transport model and MUST register the domain and prefix. It might not be obvious to somebody developing support for other mechanisms (specifically other secure transport, such as a non-5592 SSH-based secure transport) that they need to write a specification, make it publicly available, and register the domain and prefix or it can cause interoperability and security problems. I do not think this spec has been clear on that point and would like to see that stated much more clearly. dbh > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfdbh@comcast.net Wed Jul 7 09:08:01 2010 Return-Path: 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 830E23A67EA for ; Wed, 7 Jul 2010 09:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.654, 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 iW-EbGNQ45pa for ; Wed, 7 Jul 2010 09:08:00 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 3D0D43A6800 for ; Wed, 7 Jul 2010 09:08:00 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id f1fg1e0061GhbT855484ZX; Wed, 07 Jul 2010 16:08:04 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta07.westchester.pa.mail.comcast.net with comcast id f4831e00b2JQnJT3T483SE; Wed, 07 Jul 2010 16:08:04 +0000 From: "David Harrington" To: "'Randy Presuhn'" , "'Juergen Schoenwaelder'" , References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> <001301cb1d87$277ec140$6801a8c0@oemcomputer> Date: Wed, 7 Jul 2010 12:08:06 -0400 Message-ID: <51EB4740FD1C424CB1ABC5053ACABEA3@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsdhtlgtJDG9g12RcO7fpSI/2S4hgAZ6BbQ In-Reply-To: <001301cb1d87$277ec140$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] radius/vacm section 7.1 (was Re: final last call on isms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 16:08:01 -0000 OK. I agree I might be over-analyzing on this point. dbh > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, July 06, 2010 11:48 PM > To: David Harrington; 'Juergen Schoenwaelder'; isms@ietf.org > Subject: radius/vacm section 7.1 (was Re: [Isms] final last > call on isms-radius-vacm-07 (deadline2010-07-13)) > > Hi - > > As a technical contributor... > > > From: "David Harrington" > > To: "'Juergen Schoenwaelder'" > ; > > > > Sent: Tuesday, July 06, 2010 10:22 AM > > Subject: Re: [Isms] final last call on isms-radius-vacm-07 > > (deadline2010-07-13) > ... > > 6) in 7.1, early session termination MAY result in denial of access. > > should this be a SHOULD? > > No. I think you're over-analyzing. > > Whether termination results in denial of access will depend > on how VACM was configured in the first place. For example, > if VACM would have allowed access anyway, session termination > won't impact the operation, unless the implementation builds > in special hooks to terminate in-progress operations. I > think *requiring* implementations to add such hooks would be > a huge step in the wrong direction. > > > (with an example exception being that an implementation can > > distinguish between requests received before session > termination but > > not yet processed, from those recieved after session > termination). In > > AAA standards, is there support for deliberately interupting > > processing to revoke existing authorization policy? If so, > then maybe > > this should be a MUST. or maybe SHOULD is appropriate because it > > depends on the specific authorization mechanism, and might > be MAY for > > some, SHOULD for others, and MUST for some (and if this is > the case, > > this should be discussed in SecCons). > > Let's not go there. > > This is very much bound up in how the master agent queus and > dispatches, and I think we should avoid over-prescribing this > extreme corner case. > > Randy > From ietfdbh@comcast.net Wed Jul 7 09:15:38 2010 Return-Path: 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 C1A633A65A6 for ; Wed, 7 Jul 2010 09:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 cCPjyLfzMn9r for ; Wed, 7 Jul 2010 09:15:37 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 2FBD83A67E5 for ; Wed, 7 Jul 2010 09:15:37 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id f1zq1e0071vXlb8584FhFS; Wed, 07 Jul 2010 16:15:41 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id f4Fh1e0082JQnJT3d4Fhjp; Wed, 07 Jul 2010 16:15:41 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20100706112228.GB32765@elstar.local><6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> <002401cb1d88$4b0704a0$6801a8c0@oemcomputer> Date: Wed, 7 Jul 2010 12:15:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acsdh/1wAS84QaJXR2GafbsD3BUaiAAZ2tFg In-Reply-To: <002401cb1d88$4b0704a0$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] pointer to 7.2.3 Re: final last call on isms-radius-vacm-07(deadline2010-07-13) 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: , X-List-Received-Date: Wed, 07 Jul 2010 16:15:38 -0000 Hi, I disagree that the first paragraph spells out the issue of replacing a groupname in an existing entry. But I'm will to let this slide for the sake of getting the draft submitted. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Tuesday, July 06, 2010 11:56 PM > To: isms@ietf.org > Subject: [Isms] pointer to 7.2.3 Re: final last call on > isms-radius-vacm-07(deadline2010-07-13) > > Hi - > > (as a technical contributor...) > > > From: "David Harrington" > > To: "'Juergen Schoenwaelder'" > ; > > > > Sent: Tuesday, July 06, 2010 10:22 AM > > Subject: Re: [Isms] final last call on isms-radius-vacm-07 > > (deadline2010-07-13) > ... > > 7) I think the security considerations should include a pointer to > > 7.2.3. I am not sure if somehow this could be turned into > an attack, > > but a security admin looking at the security considerations > should be > > made aware that this groupname re-assignment is supported, > because the > > assumptions in this spec need to match the assumptions in the > > AAA-style authorization mechanism. Just a SecCons note with > a pointer > > to 7.2.3 is all I suggest. > > Uhhh... What about the current first paragraph of the > security considerations section? It spells out the issue in > full detail. I suggest no action is needed here. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfdbh@comcast.net Wed Jul 7 10:05:31 2010 Return-Path: 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 37D0D3A687E for ; Wed, 7 Jul 2010 10:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.554, 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 4hWy75CH0NBK for ; Wed, 7 Jul 2010 10:05:27 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 799A83A6874 for ; Wed, 7 Jul 2010 10:05:11 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta09.westchester.pa.mail.comcast.net with comcast id eyzM1e0010QuhwU5955Fi8; Wed, 07 Jul 2010 17:05:15 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta02.westchester.pa.mail.comcast.net with comcast id f55E1e00e2JQnJT3N55F29; Wed, 07 Jul 2010 17:05:15 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20100706112228.GB32765@elstar.local><6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> <003001cb1d8a$29d1d1a0$6801a8c0@oemcomputer> Date: Wed, 7 Jul 2010 13:05:17 -0400 Message-ID: <982C2FEEDAFD4D248ED9DEFF70D94138@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsdifSA5XbsxNJlQKqk5ZgKr54zVgAacHlg In-Reply-To: <003001cb1d8a$29d1d1a0$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] transport (model) session? (was: Re: final last call onisms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 17:05:31 -0000 Hi Let me recommend a slightly different approach. You refer to sane implementations, when what you mean is implementations that would make the same assumptions (presumably sane) that you would make. But some of the assumptions you make are not borne out by existing standards. For example, you assume that in a sane implemntation tmSessionID will be unique across all transport models, so it doesn't really need the prefix. However, the standards only require tmSessionID to be unique within a single transport model, so not all implementers will necessarily make the same assumption you make. Therefore, we require something to disambiguate the transport model within which it is unique. The problem, in my eyes, is that we are overloading tmSessionID to also serve as the AAA-VACM sessionID, but they might actually have different requirements for different purposes. So how about a section of "implementer guidelines" that spell out a few of these potential conflicts between implementer assumptions and the standards? Let's provide guidleines: 1) the sessionID for AAA-VACM is really an identifier of a AAA-authenticated session. 2) since tmSessionID may also represent a AAA-authenticated session, this could make a reasonable sessionID, but these really are designed for different purposes, so an implementer should make no assumptions about the contents of the tmSessionID (which would include the uniqueness across all transport models assumption). 3) (if we drop the usage of prefix, then) SessionID must be unique across all transport models, not just within a single transport model. tmSessionID is unique only within a transport model, but is implementation-defined. An implementation MAY choose to make their tmSessionIDs unique across all transport models, so they can be used as AAA-VACM session IDs. If we do that, we have provided the helpful advice you want, without overloading tmSessionID. we can eliminate the prefix usage, which eliminates the implications I raised. and I will be happy seeing the clear distinction between tmSessionID and the AAA-VACM sessionID. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Wednesday, July 07, 2010 12:09 AM > To: isms@ietf.org > Subject: [Isms] transport (model) session? (was: Re: final > last call onisms-radius-vacm-07 (deadline2010-07-13)) > > Hi - > > > From: "David Harrington" > > To: "'Juergen Schoenwaelder'" > ; > > > > Sent: Tuesday, July 06, 2010 10:22 AM > > Subject: Re: [Isms] final last call on isms-radius-vacm-07 > > (deadline2010-07-13) > ... > > 9) I am a bit concerned about the ambiguity in the name of > > vacmAaaTransportSessionID, and the description in the table > that talks > > about a session, without clarifying it is a transport model > session, > > not necessarily a transport session. > > Thinking like an implementor, this seems to be a distinction > without a difference. > > The current I-D says: > DESCRIPTION "A specific identifier of the session. > This value MUST be unique among all > currently open sessions within a transport model. > The value has no particular significance other > to distinguish sessions. An example of a suitable > value would be tmSessionID." > > If this terminology is readlly a problem, I think we should > stop trying to be helpful, remove the transport prefix, and > just say that the session id is unique within a master agent, > derived by implementation- specific means. In sane > implementations, it will end up having exactly the same bit > pattern as tmSessionID, but we won't mention that. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From randy_presuhn@mindspring.com Wed Jul 7 11:39:43 2010 Return-Path: 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 3D3593A686C for ; Wed, 7 Jul 2010 11:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLUyFQQfOEz5 for ; Wed, 7 Jul 2010 11:39:40 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 9638A3A68DA for ; Wed, 7 Jul 2010 11:39:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=X6QZkYgLH7w+3h1KHcMfSyHdtAJ2pv4p8mE3YZ02O+1BeQxkB3xbs9fkh34e6Na8; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.162.216] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OWZX4-0002q7-Bw for isms@ietf.org; Wed, 07 Jul 2010 14:39:42 -0400 Message-ID: <004701cb1e04$135c2720$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100706112228.GB32765@elstar.local><6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> <000901cb1d83$5b4d3960$6801a8c0@oemcomputer> <3A8F612FD9634E0D87CF99AD71CFB086@23FX1C1> Date: Wed, 7 Jul 2010 11:41:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc7205327803587c6a50850c3e6add5a99c7210e6273f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.162.216 Subject: Re: [Isms] radius/vacm section 7.2 (was Re: final last call onisms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 18:39:43 -0000 Hi - > From: "David Harrington" > To: "'Randy Presuhn'" ; > Sent: Wednesday, July 07, 2010 9:03 AM > Subject: RE: [Isms] radius/vacm section 7.2 (was Re: final last call onisms-radius-vacm-07 (deadline2010-07-13)) ... > However, because you are using the transport model prefix, you are > forcing it to be true, even for proprietary other mechanisms, that you > MUST specify a transport model and MUST register the domain and > prefix. Only because the architecture does not guarantee sessiod ID uniqueness, even though as a practical matter the SNMP engine must maintain some way of uniquely identifying sessions, because command responders MUST have this information in order to send responses to the right place. IMO it's an imaginary tail wagging this dog. > It might not be obvious to somebody developing support for > other mechanisms (specifically other secure transport, such as a > non-5592 SSH-based secure transport) that they need to write a > specification, make it publicly available, and register the domain and > prefix or it can cause interoperability and security problems. I do > not think this spec has been clear on that point and would like to see > that stated much more clearly. I think requiring a specification for such cases is a very good thing. However, I do not see how failure to do so can cause the interoperability or security problems you fear. As long as the prefixes used by the transport models supported by an implementation do not collide, things will just work. The *SOLE* function of the transport model prefix here is to make up for the theoretical lack of uniqueness in implementations that choose to use tmSessionID as the source of those 32 bits of identifier. It doesn't matter what the value of the prefix is, as long as it makes the index unique among all currently open sessions. Randy From yiu_lee@cable.comcast.com Wed Jul 7 15:09:23 2010 Return-Path: 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 642503A6915 for ; Wed, 7 Jul 2010 15:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_NUMERIC_HELO=2.067] 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 NfrJcoBB8qy9 for ; Wed, 7 Jul 2010 15:09:22 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 04DBC3A67AE for ; Wed, 7 Jul 2010 15:09:21 -0700 (PDT) Received: from ([147.191.124.14]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.3413823; Wed, 07 Jul 2010 16:13:15 -0600 Received: from PAOAKEXCSMTP02.cable.comcast.com (10.52.116.31) by COPDCEXHUB03.cable.comcast.com (147.191.124.14) with Microsoft SMTP Server id 14.0.694.0; Wed, 7 Jul 2010 16:09:21 -0600 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 18:09:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 68.81.70.196 ([68.81.70.196]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 7 Jul 2010 22:09:18 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="B_3361370957_106679"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Class: urn:content-classes:message Date: Wed, 7 Jul 2010 18:09:17 -0400 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Keroberos Security Model for SNMPv3 Thread-Index: AcseIQqNmvznn9yr7UK3xIrXTGrIIA== From: "Lee, Yiu" To: X-OriginalArrivalTime: 07 Jul 2010 22:09:19.0547 (UTC) FILETIME=[0C1248B0:01CB1E21] Subject: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Wed, 07 Jul 2010 22:09:23 -0000 --B_3361370957_106679 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, We wrote a draft to present a centralized security model utilizing Keroberos. Unfortunately, we missed the deadline for the IETF-78 submission. We plan to submit the draft to the ietf system as soon as it opens up on 7/26. Meanwhile, please review the draft on the link given below: http:/www.lee-networks.com/draft-pejaver-isms-kerberos-00.txt Comments and thoughts are welcome. Raj and Yiu --B_3361370957_106679 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBShZP4GhTR/CA3lI/mIpKF5VksvmjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA3MDcyMjA5MTdaMA0GCSqGSIb3DQEBAQUABIIBAG4V 3RfP/2LPGDdPzBgLDz4mW7z7Y+3UGRKgMSrzybEGQOUnhJx+YfPdupHHpuqF2Ec7rwOjEJIY BXpjjjTznT1clEJUrK6JHhli7laQtPqd1UWGdBfjrqKpwFm1PBXfqOV8wYazgY1IqYki8ejN 6n+2OVK6Za2GjYvG7bFCDV4pBj7v6gBcakyRcURSOZD+eydvVFQpljAqa6eiNzUG7rzxmhYB VYKX4V1Q9s09MpBtU2ysbhRxe9IybIP3uxdwH+WSPeHylRcCeA+pnHC2N9eEdsdIso4RRQIb 842gRHTLAzKAzGPGZ2NtDTtGA+pM6Yu/aKAauPKZzy1B6lt8wkM= --B_3361370957_106679-- From ietfdbh@comcast.net Wed Jul 7 15:19:11 2010 Return-Path: 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 0AFBB3A69AA for ; Wed, 7 Jul 2010 15:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.514, 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 DSF7ialTUtss for ; Wed, 7 Jul 2010 15:19:10 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id CD41E3A69A5 for ; Wed, 7 Jul 2010 15:19:09 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id f5DG1e00927AodY53AKEu0; Wed, 07 Jul 2010 22:19:14 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta19.westchester.pa.mail.comcast.net with comcast id fAKD1e00Z2JQnJT3fAKDAf; Wed, 07 Jul 2010 22:19:14 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20100706112228.GB32765@elstar.local><6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1><000901cb1d83$5b4d3960$6801a8c0@oemcomputer><3A8F612FD9634E0D87CF99AD71CFB086@23FX1C1> <004701cb1e04$135c2720$6801a8c0@oemcomputer> Date: Wed, 7 Jul 2010 18:19:15 -0400 Message-ID: <64CF6363B9F64978B9CBB3BD14284EC3@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcseA8k6Ny+/RyPJQp6n8ns7miLpjQAHnNVw In-Reply-To: <004701cb1e04$135c2720$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] radius/vacm section 7.2 (was Re: final last callonisms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Wed, 07 Jul 2010 22:19:11 -0000 Hi, As I said, I wanted the WG to consider my points. You have. Randy and Juergen, I trust your judgement. Do as you see fit. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Wednesday, July 07, 2010 2:42 PM > To: isms@ietf.org > Subject: Re: [Isms] radius/vacm section 7.2 (was Re: final > last callonisms-radius-vacm-07 (deadline2010-07-13)) > > Hi - > > > From: "David Harrington" > > To: "'Randy Presuhn'" ; > > > Sent: Wednesday, July 07, 2010 9:03 AM > > Subject: RE: [Isms] radius/vacm section 7.2 (was Re: final > last call > > onisms-radius-vacm-07 (deadline2010-07-13)) > ... > > However, because you are using the transport model prefix, you are > > forcing it to be true, even for proprietary other > mechanisms, that you > > MUST specify a transport model and MUST register the domain and > > prefix. > > Only because the architecture does not guarantee sessiod ID > uniqueness, even though as a practical matter the SNMP engine > must maintain some way of uniquely identifying sessions, > because command responders MUST have this information in > order to send responses to the right place. IMO it's an > imaginary tail wagging this dog. > > > It might not be obvious to somebody developing support for other > > mechanisms (specifically other secure transport, such as a > > non-5592 SSH-based secure transport) that they need to write a > > specification, make it publicly available, and register the > domain and > > prefix or it can cause interoperability and security problems. I do > > not think this spec has been clear on that point and would > like to see > > that stated much more clearly. > > I think requiring a specification for such cases is a very good thing. > > However, I do not see how failure to do so can cause the > interoperability or security problems you fear. As long as > the prefixes used by the transport models supported by an > implementation do not collide, things will just work. > The *SOLE* function of the transport model prefix here is to > make up for the theoretical lack of uniqueness in > implementations that choose to use tmSessionID as the source > of those 32 bits of identifier. It doesn't matter what the > value of the prefix is, as long as it makes the index unique > among all currently open sessions. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Thu Jul 8 05:49:18 2010 Return-Path: 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 B19C33A6A8D for ; Thu, 8 Jul 2010 05:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE3M8UFW0+EA for ; Thu, 8 Jul 2010 05:49:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 47E703A6A8A for ; Thu, 8 Jul 2010 05:49:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08AE1C0002; Thu, 8 Jul 2010 14:49:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RDLy-tIxzxCM; Thu, 8 Jul 2010 14:49:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E930AC000A; Thu, 8 Jul 2010 14:49:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF98B13983A9; Thu, 8 Jul 2010 14:49:14 +0200 (CEST) Date: Thu, 8 Jul 2010 14:49:14 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100708124914.GA23091@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> <003001cb1d8a$29d1d1a0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003001cb1d8a$29d1d1a0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] transport (model) session? (was: Re: final last call on isms-radius-vacm-07 (deadline2010-07-13)) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:49:18 -0000 On Wed, Jul 07, 2010 at 06:08:48AM +0200, Randy Presuhn wrote: > Hi - > > > From: "David Harrington" > > To: "'Juergen Schoenwaelder'" ; > > Sent: Tuesday, July 06, 2010 10:22 AM > > Subject: Re: [Isms] final last call on isms-radius-vacm-07 (deadline2010-07-13) > ... > > 9) I am a bit concerned about the ambiguity in the name of > > vacmAaaTransportSessionID, and the description in the table that talks > > about a session, without clarifying it is a transport model session, > > not necessarily a transport session. > > Thinking like an implementor, this seems to be a distinction without a difference. > > The current I-D says: > DESCRIPTION "A specific identifier of the session. > This value MUST be unique among all > currently open sessions within a transport model. > The value has no particular significance other > to distinguish sessions. An example of a suitable > value would be tmSessionID." > > If this terminology is readlly a problem, I think we should stop trying to > be helpful, remove the transport prefix, and just say that the > session id is unique within a master agent, derived by implementation- > specific means. In sane implementations, it will end up having > exactly the same bit pattern as tmSessionID, but we won't mention that. Speaking as technical contributor... I suggest to remove vacmAaaTransportModel and to make vacmAaaTransportSessionID a unique identifier. DESCRIPTION "A specific identifier of the session. This value MUST be unique among all currently open sessions of all transport models. The value has no particular significance other to distinguish sessions. Implementations in which tmSessionID happens to be unique across all transport models may use the tmSessionID value." This makes the MIB module simpler (simpler table index), ensures the uniqueness required and provides implementation hints covering the most likely case that tmSessionID is actually globally unique. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dnelson@elbrys.com Thu Jul 8 06:28:05 2010 Return-Path: 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 066403A6ACB for ; Thu, 8 Jul 2010 06:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGTnD3h+7w7e for ; Thu, 8 Jul 2010 06:28:01 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 4674C3A67A1 for ; Thu, 8 Jul 2010 06:27:54 -0700 (PDT) Received: from source ([74.125.83.51]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTDXSXWMtrw71ed/uJKyNCvv85/KBiD6a@postini.com; Thu, 08 Jul 2010 06:28:00 PDT Received: by mail-gw0-f51.google.com with SMTP id 23so368567gwj.38 for ; Thu, 08 Jul 2010 06:27:57 -0700 (PDT) Received: by 10.224.52.85 with SMTP id h21mr4586906qag.240.1278595677287; Thu, 08 Jul 2010 06:27:57 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id q31sm33917671qcq.44.2010.07.08.06.27.56 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 06:27:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: "David B. Nelson" In-Reply-To: <20100708124914.GA23091@elstar.local> Date: Thu, 8 Jul 2010 09:27:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9584A56F-48C7-4C10-BC25-6B692311FBB7@elbrys.com> References: <20100706112228.GB32765@elstar.local> <6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1> <003001cb1d8a$29d1d1a0$6801a8c0@oemcomputer> <20100708124914.GA23091@elstar.local> To: isms@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [Isms] transport (model) session? (was: Re: final last call on isms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Thu, 08 Jul 2010 13:28:05 -0000 On Jul 8, 2010, at 8:49 AM, Juergen Schoenwaelder wrote: > > I suggest to remove vacmAaaTransportModel and to make > vacmAaaTransportSessionID a unique identifier. > > DESCRIPTION "A specific identifier of the session. This value > MUST be unique among all currently open sessions of > all transport models. The value has no particular > significance other to distinguish sessions. > Implementations in which tmSessionID happens to be > unique across all transport models may use the > tmSessionID value." > > This makes the MIB module simpler (simpler table index), ensures the > uniqueness required and provides implementation hints covering the > most likely case that tmSessionID is actually globally unique. +1 From ietfdbh@comcast.net Thu Jul 8 08:18:30 2010 Return-Path: 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 6E74B3A6AEA for ; Thu, 8 Jul 2010 08:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, 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 3IT9OVZQx2Eh for ; Thu, 8 Jul 2010 08:18:29 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 84EE83A67F9 for ; Thu, 8 Jul 2010 08:18:29 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id fNLo1e0030EZKEL56TJa4u; Thu, 08 Jul 2010 15:18:34 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta01.westchester.pa.mail.comcast.net with comcast id fTJZ1e00a2JQnJT3MTJaKo; Thu, 08 Jul 2010 15:18:34 +0000 From: "David Harrington" To: "'David B. Nelson'" , References: <20100706112228.GB32765@elstar.local><6BD7114DD9AF446CA44EE1ADE6A0B0EF@23FX1C1><003001cb1d8a$29d1d1a0$6801a8c0@oemcomputer><20100708124914.GA23091@elstar.local> <9584A56F-48C7-4C10-BC25-6B692311FBB7@elbrys.com> Date: Thu, 8 Jul 2010 11:18:37 -0400 Message-ID: <627C07D6214346AC94F00A533020638A@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcseoWorcSGLFfmPSzaVWcPpGyp9vAAD2bMw In-Reply-To: <9584A56F-48C7-4C10-BC25-6B692311FBB7@elbrys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [Isms] transport (model) session? (was: Re: final last call onisms-radius-vacm-07 (deadline2010-07-13)) 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: , X-List-Received-Date: Thu, 08 Jul 2010 15:18:30 -0000 +1 dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > Sent: Thursday, July 08, 2010 9:28 AM > To: isms@ietf.org > Subject: Re: [Isms] transport (model) session? (was: Re: > final last call onisms-radius-vacm-07 (deadline2010-07-13)) > > On Jul 8, 2010, at 8:49 AM, Juergen Schoenwaelder wrote: > > > > I suggest to remove vacmAaaTransportModel and to make > > vacmAaaTransportSessionID a unique identifier. > > > > DESCRIPTION "A specific identifier of the session. This value > > MUST be unique among all currently open > sessions of > > all transport models. The value has no particular > > significance other to distinguish sessions. > > Implementations in which tmSessionID happens to be > > unique across all transport models may use the > > tmSessionID value." > > > > This makes the MIB module simpler (simpler table index), > ensures the > > uniqueness required and provides implementation hints covering the > > most likely case that tmSessionID is actually globally unique. > > +1 > > > > > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From randy_presuhn@mindspring.com Fri Jul 9 13:56:26 2010 Return-Path: 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 9DEE43A6912 for ; Fri, 9 Jul 2010 13:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPggWGCcsMei for ; Fri, 9 Jul 2010 13:56:26 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id C7DCC3A68ED for ; Fri, 9 Jul 2010 13:56:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Jo7zLLKtdcAKi5NGsstk7qErh3J4R5RGNkloieiHclW1pkrLWRpjbMChvGrHeMbE; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.224.128] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OXKcY-0005AV-Kg for isms@ietf.org; Fri, 09 Jul 2010 16:56:30 -0400 Message-ID: <000501cb1fa9$8888ec80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Fri, 9 Jul 2010 13:58:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035d7839ce0f046619ef3dac8032b5490ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.224.128 Subject: [Isms] radius/vacm edits 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: , X-List-Received-Date: Fri, 09 Jul 2010 20:56:26 -0000 Hi - As editor, I think I understand the latest round of edits. The resolution of the transport model prefix issue in particular will result in numerous text changes and signficant change to the MIB module itself. I think it would be a good thing to make those changes available, even as the WG last call continues. However, due to other obligations (yes, I do have a life!) I probably won't be able to generate an update (whether to the "individual" I-D or the WG document) until Sunday afternoon, California time, in order to beat Monday's I-D submission deadline. My question for the co-chairs is whether they want me to wait until the close of the WG last call before assembling the edits and making them available in one form or another. Randy From j.schoenwaelder@jacobs-university.de Sat Jul 10 00:17:37 2010 Return-Path: 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 BA7963A68F9 for ; Sat, 10 Jul 2010 00:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbC3XD4fssHF for ; Sat, 10 Jul 2010 00:17:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9ED523A6813 for ; Sat, 10 Jul 2010 00:17:36 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE962C000A; Sat, 10 Jul 2010 09:17:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bcmzwQRr7mFN; Sat, 10 Jul 2010 09:17:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CF81C0002; Sat, 10 Jul 2010 09:17:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E84F13A5C43; Sat, 10 Jul 2010 09:17:39 +0200 (CEST) Date: Sat, 10 Jul 2010 09:17:39 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100710071739.GA1924@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <000501cb1fa9$8888ec80$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000501cb1fa9$8888ec80$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] radius/vacm edits X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2010 07:17:37 -0000 On Fri, Jul 09, 2010 at 10:58:49PM +0200, Randy Presuhn wrote: > Hi - > > As editor, I think I understand the latest round of edits. > The resolution of the transport model prefix issue in particular > will result in numerous text changes and signficant change > to the MIB module itself. I think it would be a good thing > to make those changes available, even as the WG last call > continues. However, due to other obligations (yes, I do > have a life!) I probably won't be able to generate an > update (whether to the "individual" I-D or the WG document) > until Sunday afternoon, California time, in order to > beat Monday's I-D submission deadline. > > My question for the co-chairs is whether they want me to wait > until the close of the WG last call before assembling the edits > and making them available in one form or another. Here is a plan: The last call ends on Tuesday. Since you won't have time to post an update by the ID cutoff on Monday, I suggest to wait until the WG last call is over. If no other issues pop up, I suggest you update the WG document after Tuesday and post it to the list so that we can cross check consistency of the updates. Once we agree that the edits are fine, we wait until ID submission opens up again at the 78th IETF (I guess 26th of July) at which time you can post the ID and I will hand over the document and the writeup to our AD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Wed Jul 14 14:51:33 2010 Return-Path: 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 A21063A6994 for ; Wed, 14 Jul 2010 14:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2KnYS2baGGf for ; Wed, 14 Jul 2010 14:51:32 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 383D63A6405 for ; Wed, 14 Jul 2010 14:51:32 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id hs7X1e00217dt5G5AxrisC; Wed, 14 Jul 2010 21:51:42 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta13.westchester.pa.mail.comcast.net with comcast id hxrh1e0052JQnJT3ZxrhYT; Wed, 14 Jul 2010 21:51:42 +0000 From: "David Harrington" To: "'Lee, Yiu'" , References: Date: Wed, 14 Jul 2010 17:51:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: Thread-index: AcseIQqNmvznn9yr7UK3xIrXTGrIIAFfXmEA Subject: Re: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Wed, 14 Jul 2010 21:51:33 -0000 Hi, You might want to know that a Kerberos security model for snmpv3 was developed around 1999 (IIRC). I may have a copy of Ken Hornstein's draft if the WG is interested. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Lee, Yiu > Sent: Wednesday, July 07, 2010 6:09 PM > To: Isms@ietf.org > Subject: [Isms] Keroberos Security Model for SNMPv3 > > Hi, > > We wrote a draft to present a centralized security model > utilizing Keroberos. Unfortunately, we missed the deadline > for the IETF-78 submission. > We plan to submit the draft to the ietf system as soon as it > opens up on 7/26. Meanwhile, please review the draft on the > link given below: > > http:/www.lee-networks.com/draft-pejaver-isms-kerberos-00.txt > > Comments and thoughts are welcome. > > Raj and Yiu > > From yiu_lee@cable.comcast.com Wed Jul 14 19:54:32 2010 Return-Path: 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 0E2DF3A677C for ; Wed, 14 Jul 2010 19:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_NUMERIC_HELO=2.067] 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 RAfNNncVjzDG for ; Wed, 14 Jul 2010 19:54:31 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id CB3773A63CB for ; Wed, 14 Jul 2010 19:54:30 -0700 (PDT) Received: from ([147.191.124.13]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.3990088; Wed, 14 Jul 2010 20:58:45 -0600 Received: from PAOAKEXCSMTP01.cable.comcast.com (10.52.116.30) by copdcexhub02.cable.comcast.com (147.191.124.13) with Microsoft SMTP Server id 14.0.694.0; Wed, 14 Jul 2010 20:54:37 -0600 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 22:54:34 -0400 Received: from 24.40.8.152 ([24.40.8.152]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jul 2010 02:53:41 +0000 References: Message-ID: <6C2349C8-5053-47EC-9404-C1E08DF08FF3@cable.comcast.com> From: "Lee, Yiu" To: David Harrington Thread-Topic: [Isms] Keroberos Security Model for SNMPv3 Thread-Index: AcsjyO6cg/XlsUSaSreiTEOSmcYqYA== In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (iPad Mail 7B367) Date: Wed, 14 Jul 2010 22:53:46 -0400 X-OriginalArrivalTime: 15 Jul 2010 02:54:34.0299 (UTC) FILETIME=[0E2670B0:01CB23C9] Cc: Isms@ietf.org Subject: Re: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Thu, 15 Jul 2010 02:54:32 -0000 Hi Dave, You are right, we are aware of that draft. In fact, ours referenced = heavily on it, we also added the centralized authorization. We think = this is useful because Keroberos doesn't rely on session based = transport. We didn't know the history why the Hornstein's draft wasn't = accepted as WG item. Do you know why? Thanks, Yiu=20 On Jul 14, 2010, at 5:52 PM, "David Harrington" = wrote: > Hi, >=20 > You might want to know that a Kerberos security model for snmpv3 was > developed around 1999 (IIRC). >=20 > I may have a copy of Ken Hornstein's draft if the WG is interested. >=20 > dbh=20 >=20 >> -----Original Message----- >> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 >> Behalf Of Lee, Yiu >> Sent: Wednesday, July 07, 2010 6:09 PM >> To: Isms@ietf.org >> Subject: [Isms] Keroberos Security Model for SNMPv3 >>=20 >> Hi, >>=20 >> We wrote a draft to present a centralized security model=20 >> utilizing Keroberos. Unfortunately, we missed the deadline=20 >> for the IETF-78 submission. >> We plan to submit the draft to the ietf system as soon as it=20 >> opens up on 7/26. Meanwhile, please review the draft on the=20 >> link given below: >>=20 >> http:/www.lee-networks.com/draft-pejaver-isms-kerberos-00.txt >>=20 >> Comments and thoughts are welcome. >>=20 >> Raj and Yiu >>=20 >>=20 >=20 From randy_presuhn@mindspring.com Wed Jul 14 21:01:24 2010 Return-Path: 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 D66F13A68C8 for ; Wed, 14 Jul 2010 21:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] 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 nasKDsKuY6D6 for ; Wed, 14 Jul 2010 21:01:24 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 0924F3A6872 for ; Wed, 14 Jul 2010 21:01:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Bjwc7IDBN/zkzD9WRREeapamdXKKNvJFVocbm4dxl7/8WkFcW/pRAMxGLZFehnak; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.24.253] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OZFda-0007uw-Uo for Isms@ietf.org; Thu, 15 Jul 2010 00:01:31 -0400 Message-ID: <000601cb23d2$c1e66fc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <6C2349C8-5053-47EC-9404-C1E08DF08FF3@cable.comcast.com> Date: Wed, 14 Jul 2010 21:03:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035f3c28f08c3ec31591803f3f227724a93350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.24.253 Subject: Re: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Thu, 15 Jul 2010 04:01:24 -0000 Hi - > From: "Lee, Yiu" > To: "David Harrington" > Cc: > Sent: Wednesday, July 14, 2010 7:53 PM > Subject: Re: [Isms] Keroberos Security Model for SNMPv3 ... > we also added the centralized authorization. > We think this is useful because Keroberos doesn't > rely on session based transport. Any thoughts on how this might work with the AAA/Vacm integration? > We didn't know the history why the Hornstein's draft wasn't > accepted as WG item. Do you know why? At the time of that draft (last update was in 2001) the isms working group did not yet exist. Randy From ietfdbh@comcast.net Wed Jul 14 21:20:24 2010 Return-Path: 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 143A03A6874 for ; Wed, 14 Jul 2010 21:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 E1pb2tMn2Ddi for ; Wed, 14 Jul 2010 21:20:23 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by core3.amsl.com (Postfix) with ESMTP id 08D7E3A6844 for ; Wed, 14 Jul 2010 21:20:22 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta12.westchester.pa.mail.comcast.net with comcast id i4La1e0011YDfWL5C4LaNJ; Thu, 15 Jul 2010 04:20:34 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta20.westchester.pa.mail.comcast.net with comcast id i4LZ1e0022JQnJT3g4LZgB; Thu, 15 Jul 2010 04:20:34 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <6C2349C8-5053-47EC-9404-C1E08DF08FF3@cable.comcast.com> <000601cb23d2$c1e66fc0$6801a8c0@oemcomputer> Date: Thu, 15 Jul 2010 00:20:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <000601cb23d2$c1e66fc0$6801a8c0@oemcomputer> Thread-index: Acsj0mx2ymYWMaRBRemDlrmjtgJZqAAAYZNg Subject: Re: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Thu, 15 Jul 2010 04:20:24 -0000 The snmpv3 wg wasn't chartered to work on additional security models beyond USM: "The goal of the Working Group is to produce the necessary set of documents that will provide a single standard for the next generation of core SNMP functions." We were trying to get snmpv3 stable and through the approval process in 2001. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Thursday, July 15, 2010 12:04 AM > To: Isms@ietf.org > Subject: Re: [Isms] Keroberos Security Model for SNMPv3 > > Hi - > > > From: "Lee, Yiu" > > To: "David Harrington" > > Cc: > > Sent: Wednesday, July 14, 2010 7:53 PM > > Subject: Re: [Isms] Keroberos Security Model for SNMPv3 > ... > > we also added the centralized authorization. > > We think this is useful because Keroberos doesn't rely on session > > based transport. > > Any thoughts on how this might work with the AAA/Vacm integration? > > > We didn't know the history why the Hornstein's draft wasn't > accepted > > as WG item. Do you know why? > > At the time of that draft (last update was in 2001) the isms > working group did not yet exist. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From randy_presuhn@mindspring.com Wed Jul 14 22:45:55 2010 Return-Path: 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 7A2D73A6925 for ; Wed, 14 Jul 2010 22:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.834 X-Spam-Level: X-Spam-Status: No, score=0.834 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833] 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 Xv6jL4rrhDmk for ; Wed, 14 Jul 2010 22:45:50 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id F337A3A684A for ; Wed, 14 Jul 2010 22:45:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gVDaBgFOqn9Fbd+KwXhTMm4DzCeAj98JS0IwXsJNn39A9isaA/Fv9bIEwuQ4mrAH; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.54.164] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OZHGg-0000Fy-4M for isms@ietf.org; Thu, 15 Jul 2010 01:45:59 -0400 Message-ID: <000c01cb23e1$598cbb00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Wed, 14 Jul 2010 22:48:26 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_01CB23A6.AC19B3E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780357405dec489b236513ef87f967020a61e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.164 Subject: [Isms] text of what will be the -09 RADIUS/VACM draft 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: , X-List-Received-Date: Thu, 15 Jul 2010 05:45:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01CB23A6.AC19B3E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi - As requested by Juergen, attached are the results of applying my understanding of the edits resulting from the discussion of David Harrington's last call comments, along with a couple of minor formatting cleanups in the MIB module. There are numerous small changes, so the probability of error is high. Please let me know where I got it wrong. One interesting side-effect of the changes was that RFC 5590 is no longer in the references. Randy ------=_NextPart_000_0009_01CB23A6.AC19B3E0 Content-Type: text/plain; name="draft-ietf-isms-radius-vacm-09.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-radius-vacm-09.txt" =0A= =0A= =0A= Network Working Group K. Narayan=0A= Internet-Draft Cisco Systems, Inc.=0A= Intended status: Standards Track D. Nelson=0A= Expires: January 16, 2011 Elbrys Networks, Inc.=0A= R. Presuhn, Ed.=0A= None=0A= July 15, 2010=0A= =0A= =0A= Using Authentication, Authorization, and Accounting services to=0A= Dynamically Provision View-based Access Control Model User-to-Group=0A= Mappings=0A= draft-ietf-isms-radius-vacm-WILLBE09.txt=0A= =0A= Abstract=0A= =0A= This memo defines a portion of the Management Information Base (MIB)=0A= for use with network management protocols. It describes the use of=0A= information provided by Authentication, Authorization, and Accounting=0A= (AAA) services, such as the Remote Authentication Dial-In User=0A= Service (RADIUS), to dynamically update user-to-group mappings in the=0A= View-Based Access Control Model (VACM).=0A= =0A= Comments are solicited and should be addressed to the working group's=0A= mailing list at isms@ietf.org.=0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on January 16, 2011.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2010 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 1]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. The Internet-Standard Management Framework . . . . . . . . . . 3=0A= 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 4.1. Using AAA services with SNMP . . . . . . . . . . . . . . . 3=0A= 4.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4=0A= 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 5=0A= 5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 5=0A= 5.2. The Table Structure . . . . . . . . . . . . . . . . . . . 5=0A= 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 5=0A= 6.1. Relationship to the VACM MIB . . . . . . . . . . . . . . . 6=0A= 6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 6=0A= 7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6=0A= 7.1. Sequencing Requirements . . . . . . . . . . . . . . . . . 6=0A= 7.2. Actions Upon Session Establishment Indication . . . . . . 7=0A= 7.2.1. Creation of Entries in vacmAaaSecurityToGroupTable . . 7=0A= 7.2.2. Creation of Entries in vacmSecurityToGroupTable . . . 8=0A= 7.2.3. Update of vacmGroupName . . . . . . . . . . . . . . . 8=0A= 7.3. Actions Upon Session Termination Indication . . . . . . . 8=0A= 7.3.1. Deletion of Entries from=0A= vacmAaaSecurityToGroupTable . . . . . . . . . . . . . 8=0A= 7.3.2. Deletion of Entries from vacmSecurityToGroupTable . . 9=0A= 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13=0A= 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15=0A= 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15=0A= 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16=0A= 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16=0A= 12.2. Informative References . . . . . . . . . . . . . . . . . . 17=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 2]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo specifies a way to simplify the administration of the=0A= access rights granted to users of network management data. It=0A= functions to dynamically provision selected View-Based Access Control=0A= Model (VACM) [RFC3415] MIB objects, based on information received=0A= from an Authentication, Authorization, and Accounting (AAA) service,=0A= such as RADIUS [RFC2865].=0A= =0A= This memo requires no changes to the Abstract Service Interface for=0A= the Access Control Subsystem, and requires no changes to the Elements=0A= of Procedure for VACM. It provides a MIB module that reflects the=0A= information provided by the AAA service, along with elements of=0A= procedure for maintaining that information and performing=0A= corresponding updates to VACM MIB data.=0A= =0A= =0A= 2. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= =0A= 3. Conventions=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119 [RFC2119].=0A= =0A= =0A= 4. Overview=0A= =0A= 4.1. Using AAA services with SNMP=0A= =0A= There are two use cases for AAA support of management access via=0A= SNMP. These are (a) service authorization and (b) access control=0A= authorization. The former is discussed in detail in [RFC5608]. The=0A= latter is the subject of this memo.=0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 3]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= The use case assumption here is that roles within an organization,=0A= which are reflected in VACM as groups and rules, change infrequently,=0A= while the users assigned to those roles change much more frequently.=0A= This memo describes how the user-to-role (group) mapping can be=0A= delegated to the RADIUS server, avoiding the need to re-provision=0A= managed devices as users are added, deleted, or assigned new roles in=0A= an organization.=0A= =0A= This memo assumes that the detailed access control policies are pre-=0A= configured in VACM, and does not attempt to address the question of=0A= how the policy associated with a given role is put in place.=0A= =0A= The only additional information obtained from the AAA service is the=0A= mapping of the authenticated user's identifier to a specific role (or=0A= "group" in VACM terminology) in the access control policy. Dynamic=0A= user authorization for MIB database access control, as defined=0A= herein, is limited to mapping the authenticated user to a group,=0A= which in turn is mapped to whatever rules are already in place in=0A= VACM.=0A= =0A= The SNMP architecture [RFC3411] maintains strong modularity and=0A= separation of concerns, separating user identity (authentication)=0A= from user database access rights (authorization). RADIUS, on the=0A= other hand, allows for no such separation of authorization from=0A= authentication. Consequently, the approach here is to leverage=0A= existing RADIUS usage for identifying a principal, documented in=0A= [RFC5608], along with the RADIUS Management-Policy-Id Attribute=0A= [RFC5607].=0A= =0A= An implementation-specific identifier is needed for each AAA-=0A= authorized "session", corresponding to a communication channel, such=0A= as a transport session, for which a principal has been AAA-=0A= authenticated and which is authorized to offer SNMP service. When a=0A= RADIUS-Management-Policy-ID Attribute (or equivalent) is bound to=0A= such a session and principal authentication, this binding provides=0A= sufficient information to compute dynamic updates to VACM. How this=0A= information is communicated within an implementation is=0A= implementation-dependent; this memo is only concerned with=0A= externally-observable behaviour.=0A= =0A= 4.2. Applicability=0A= =0A= Though this memo was motivated to support the use of specific=0A= Transport Models, such as the Secure Shell Transport Model [RFC5592],=0A= it MAY be used with other implementation environments satisfying=0A= these requirements:=0A= =0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 4]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= o use an AAA service for sign-on service and data access=0A= authorization;=0A= =0A= o provide an indication of the start of a session for a particular=0A= authenticated principal, identified using a SecurityName, and=0A= provide the corresponding value of vacmGroupName to be used, based=0A= on information provided by the AAA service in use;=0A= =0A= o provide an indication of the end of the need for being able to=0A= make access decisions for a particular authenticated principal, as=0A= at the end of a session, whether due to disconnection, termination=0A= due to timeout, or any other reason.=0A= =0A= Likewise, although this memo specifically refers to RADIUS, it MAY be=0A= used with other AAA services satisfying these requirements:=0A= =0A= =0A= o the service provides information semantically equivalent to the=0A= RADIUS Management-Policy-Id Attribute [RFC5607], which corresponds=0A= to a GroupName;=0A= =0A= o the service provides an authenticated principal identifier (e.g.,=0A= the RADIUS User-Name Attribute [RFC2865]) which can be transformed=0A= to an equivalent principal identifier in the form of a=0A= SecurityName.=0A= =0A= =0A= 5. Structure of the MIB Module=0A= =0A= 5.1. Textual Conventions=0A= =0A= This MIB module makes use of the SnmpAdminString and=0A= SnmpSecurityModel textual conventions.=0A= =0A= 5.2. The Table Structure=0A= =0A= This MIB module defines a single table, the=0A= vacmAaaSecurityToGroupTable. This table is indexed by the integer=0A= assigned to each security model, the protocol-independent=0A= SecurityName corresponding to a principal, and the unique identifier=0A= of a session.=0A= =0A= =0A= 6. Relationship to Other MIB Modules=0A= =0A= This MIB module has a close operational relationship with the SNMP-=0A= VIEW-BASED-ACM-MIB (more commonly known as the "VACM MIB") from=0A= [RFC3415]. It also relies on IMPORTS from several other modules.=0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 5]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= 6.1. Relationship to the VACM MIB=0A= =0A= Although the MIB module defined here has a close relationship with=0A= the VACM MIB's vacmSecurityToGroupTable, it in no way changes the=0A= elements of procedure for VACM, nor does it affect any other tables=0A= defined in VACM. See the elements of procedure (below) for details=0A= of how the contents of the vacmSecurityToGroupTable are affected by=0A= this MIB module.=0A= =0A= 6.2. MIB modules required for IMPORTS=0A= =0A= This MIB module employs definitions from [RFC2578], [RFC2579] and=0A= [RFC3411].=0A= =0A= =0A= 7. Elements of Procedure=0A= =0A= The following elements of procedure are formulated in terms of two=0A= types of events: an indication of the establishment of a session, and=0A= an indication that one has ended. These can result in the creation=0A= of entries in the vacmAaaSecurityToGroupTable, which can in turn=0A= trigger creation, update, or deletion of entries in the=0A= vacmSecurityToGroupTable.=0A= =0A= There are various possible implementation-specific error cases not=0A= spelled out here, such as running out of memory. By their nature,=0A= recovery in such cases will be implementation-specific. Implementors=0A= are advised to consider fail-safe strategies, e.g., prematurely=0A= terminating access in preference to erroneously perpetuating access.=0A= =0A= 7.1. Sequencing Requirements=0A= =0A= These procedures assume that a transport model, such as [RFC5592],=0A= coordinates session establishment with AAA authentication and=0A= authorization. They rely critically on the receipt by the AAA client=0A= of the RADIUS Management-Policy-Id [RFC5607] Attribute (or its=0A= equivalent) from the RADIUS Access-Accept message (or equivalent).=0A= They also assume that the User-Name [RFC2865] from the RADIUS Access-=0A= Request message (or equivalent) corresponds to an SNMP Security Name=0A= [RFC3411].=0A= =0A= To ensure correct processing of SNMP PDUs, the handling of the=0A= indication of the establishment of a session in accordance with the=0A= elements of procedure below MUST be completed before the=0A= IsAccessAllowed() abstract service interface is invoked for any SNMP=0A= PDUs from that session.=0A= =0A= If a session termination indication occurs before all invocations of=0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 6]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= the IsAccessAllowed() abstract service interface have completed for=0A= all SNMP PDUs from that session, those remaining invocations MAY=0A= result in denial of access.=0A= =0A= 7.2. Actions Upon Session Establishment Indication=0A= =0A= Four pieces of information are needed to process the session=0A= establishment indication:=0A= =0A= o the SnmpSecurityModel [RFC3411] needed as an index into the=0A= vacmSecurityToGroupTable;=0A= =0A= o the RADIUS User-Name Attribute or equivalent;=0A= =0A= o a session identifier, as a unique, definitive identifier of the=0A= session that the AAA authorization is tied to;=0A= =0A= o the RADIUS Management-Policy-Id Attribute or equivalent=0A= =0A= In particular, if either the User-Name or Management-Policy-Id is=0A= absent, invalid, or a zero-length string, no further processing of=0A= the session establishment indication is undertaken.=0A= =0A= 7.2.1. Creation of Entries in vacmAaaSecurityToGroupTable=0A= =0A= Whenever an indication arrives that a new session has been=0A= established, determine whether a corresponding entry exists in the=0A= vacmAaaSecurityToGroupTable. If one does not, create a new row with=0A= the columns populated as follows:=0A= =0A= o vacmAaaSecurityModel =3D value of SnmpSecurityModel corresponding = to=0A= the security model in use=0A= =0A= o vacmAaaSecurityName =3D RADIUS User-Name Attribute or equivalent,=0A= the securityName that will be used in invocations of the=0A= isAccessAllowed() abstract service interface;=0A= =0A= o vacmAaaSessionID =3D unique session identifier=0A= =0A= o vacmAaaGroupName =3D RADIUS Management-Policy-Id Attribute or=0A= equivalent=0A= =0A= Otherwise, if the row already exists, update the vacmAaaGroupName=0A= with the value supplied.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 7]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= 7.2.2. Creation of Entries in vacmSecurityToGroupTable=0A= =0A= Whenever an entry is created in the vacmAaaSecurityToGroupTable, the=0A= vacmSecurityToGroupTable is examined to determine whether a=0A= corresponding entry exists there, using the value of=0A= vacmAaaSecurityModel for vacmSecurityModel, and the value of=0A= vacmAaaSecurityName for vacmSecurityName. If no corresponding entry=0A= exists, create one, using the vacmAaaGroupName of the newly created=0A= entry to fill in vacmGroupName, using a value of "volatile" for=0A= vacmSecurityToGroupStorageType, and a value of "active" for=0A= vacmSecurityToGroupStatus.=0A= =0A= If a corresponding entry already exists in the=0A= vacmSecurityToGroupTable, and the row's StorageType is anything other=0A= than "volatile", or the RowStatus is anything other than "active",=0A= then a role (group) mapping for this user (principal) has already=0A= been put in place on this system, and will not be overridden.=0A= =0A= 7.2.3. Update of vacmGroupName=0A= =0A= Whenever the value of an instance of vacmAaaGroupName is updated, if=0A= a corresponding entry exists in the vacmSecurityToGroupTable, and=0A= vacmSecurityToGroupStorageType is "volatile" and=0A= vacmSecurityToGroupStatus is "active", update the value of=0A= vacmGroupName with the value from vacmAaaGroupName.=0A= =0A= The operational assumption here is that if the row's StorageType is=0A= "volatile", then this entry was probably dynamically created; an=0A= entry created by a security administrator would not normally be given=0A= a StorageType of "volatile". If value being provided by RADIUS (or=0A= other AAA service) is the same as what is already there, this is a=0A= no-op. If the value is different, the new information is understood=0A= as a more recent role (group) assignment for the user, which should=0A= supercede the one currently held there.=0A= =0A= 7.3. Actions Upon Session Termination Indication=0A= =0A= Whenever a RADIUS (or other AAA) authenticated session ends for any=0A= reason, an indication is provided. This indication MUST provide=0A= means of determining the SnmpSecurityModel, and an identifier for the=0A= transport session tied to the AAA authorization. The manner in which=0A= this occurs is implementation dependent.=0A= =0A= 7.3.1. Deletion of Entries from vacmAaaSecurityToGroupTable=0A= =0A= Entries in the vacmAaaSecurityToGroupTable MUST NOT persist across=0A= system reboots.=0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 8]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= When a session has been terminated, the vacmAaaSecurityToGroupTable=0A= is searched for a corresponding entry. A "matching" entry is any=0A= entry for which the SnmpSecurityModel, and session ID match the=0A= information associated with the session termination indication. Any=0A= matching entries are deleted. It is possible that no entries will=0A= match; this is not an error, and no special processing is required in=0A= this case.=0A= =0A= 7.3.2. Deletion of Entries from vacmSecurityToGroupTable=0A= =0A= Whenever the last remaining row bearing a particular=0A= (vacmAaaSecurityModel, vacmAaaSecurityName) pair is deleted from the=0A= vacmAaaSecurityToGroupTable, the vacmSecurityToGroupTable is examined=0A= for a corresponding row. If one exists, and if its StorageType is=0A= "volatile" and its RowStatus is "active", that row MUST be deleted as=0A= well. The mechanism to accomplish this task is implementation=0A= specific.=0A= =0A= =0A= 8. Definitions=0A= =0A= =0A= =0A= SNMP-VACM-AAA-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= mib-2,=0A= Unsigned32 FROM SNMPv2-SMI=0A= SnmpAdminString,=0A= SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB;=0A= =0A= snmpVacmAaaMIB MODULE-IDENTITY=0A= LAST-UPDATED "201007140000Z" -- 14 July, 2010=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-email: isms@ietf.org"=0A= =0A= DESCRIPTION "The management and local datastore information=0A= definitions for the AAA-Enabled View-based Access=0A= Control Model for SNMP.=0A= =0A= Copyright (c) 2010 IETF Trust and the persons=0A= identified as the document authors. All rights=0A= reserved.=0A= =0A= Redistribution and use in source and binary forms,=0A= with or without modification, is permitted pursuant=0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 9]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= to, and subject to the license terms contained in,=0A= the Simplified BSD License set forth in Section=0A= 4.c of the IETF Trust's Legal Provisions Relating=0A= to IETF Documents=0A= (http://trustee.ietf.org/license-info).=0A= =0A= This version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices."=0A= =0A= REVISION "201007140000Z"=0A= DESCRIPTION "Initial version, published as RFC XXXX."=0A= ::=3D { mib-2 XXX }=0A= =0A= vacmAaaMIBObjects OBJECT IDENTIFIER ::=3D { snmpVacmAaaMIB 1 }=0A= =0A= vacmAaaMIBConformance OBJECT IDENTIFIER ::=3D {snmpVacmAaaMIB 2 }=0A= =0A= vacmAaaSecurityToGroupTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF VacmAaaSecurityToGroupEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table provides a listing of all currently active=0A= sessions for which a mapping of the combination of=0A= SnmpSecurityModel and SecurityName into a GroupName has=0A= been provided by an AAA service. The GroupName (in=0A= VACM) in turn identifies an access control policy to be=0A= used for the corresponding principals."=0A= ::=3D { vacmAaaMIBObjects 1 }=0A= =0A= vacmAaaSecurityToGroupEntry OBJECT-TYPE=0A= SYNTAX VacmAaaSecurityToGroupEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An entry in this table maps the combination of a=0A= SnmpSecurityModel and SecurityName into a GroupName for=0A= a particular session.=0A= =0A= Each entry corresponds to a session.=0A= =0A= Entries do not persist across reboots.=0A= =0A= When a session is torn down, disconnected, timed out=0A= (e.g. following the RADIUS Session-Timeout Attribute),=0A= or otherwise terminated for any reason, the=0A= corresponding vacmAaaSecurityToGroupEntry is deleted."=0A= INDEX {=0A= vacmAaaSecurityModel,=0A= vacmAaaSecurityName,=0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 10]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= vacmAaaSessionID=0A= }=0A= ::=3D { vacmAaaSecurityToGroupTable 1 }=0A= =0A= VacmAaaSecurityToGroupEntry ::=3D SEQUENCE=0A= {=0A= vacmAaaSecurityModel SnmpSecurityModel,=0A= vacmAaaSecurityName SnmpAdminString,=0A= vacmAaaSessionID Unsigned32,=0A= vacmAaaGroupName SnmpAdminString=0A= }=0A= =0A= vacmAaaSecurityModel OBJECT-TYPE=0A= SYNTAX SnmpSecurityModel(1..2147483647)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The Security Model associated with the AAA binding=0A= represented by this entry.=0A= =0A= This object cannot take the 'any' (0) value."=0A= ::=3D { vacmAaaSecurityToGroupEntry 1 }=0A= =0A= vacmAaaSecurityName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The Security Name of the principal associated with the=0A= AAA binding represented by this entry. In RADIUS=0A= environments, this corresponds to the User-Name=0A= Attribute."=0A= ::=3D { vacmAaaSecurityToGroupEntry 2 }=0A= =0A= vacmAaaSessionID OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A specific identifier of the session.=0A= =0A= This value MUST be unique among all currently open=0A= sessions of all of this SNMP engine's transport models.=0A= The value has no particular significance other than to=0A= distinguish sessions. Implementations in which=0A= tmSessionID is unique across all transport models MAY=0A= use the tmSessionID value."=0A= ::=3D { vacmAaaSecurityToGroupEntry 3 }=0A= =0A= vacmAaaGroupName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 11]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The name of the group to which this entry is to belong.=0A= In RADIUS environments this comes from the RADIUS=0A= Management-Policy-Id Attribute.=0A= =0A= This group name is used to set the vacmGroupName in the=0A= corresponding vacmSecurityToGroupEntry."=0A= ::=3D { vacmAaaSecurityToGroupEntry 4 }=0A= =0A= =0A= -- Conformance information ******************************************=0A= =0A= vacmAaaMIBCompliances=0A= OBJECT IDENTIFIER ::=3D {vacmAaaMIBConformance 1}=0A= vacmAaaMIBGroups=0A= OBJECT IDENTIFIER ::=3D {vacmAaaMIBConformance 2}=0A= =0A= -- compliance statements=0A= =0A= vacmAaaMIBBasicCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION "The compliance statement for SNMP engines implementing=0A= the AAA-Enabled View-based Access Control Model for=0A= SNMP."=0A= MODULE -- this module=0A= MANDATORY-GROUPS { vacmAaaGroup }=0A= =0A= ::=3D { vacmAaaMIBCompliances 1 }=0A= =0A= -- units of conformance=0A= =0A= vacmAaaGroup OBJECT-GROUP=0A= OBJECTS {=0A= vacmAaaGroupName=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for supporting the use of AAA=0A= services to provide user / group mappings for VACM."=0A= ::=3D { vacmAaaMIBGroups 1 }=0A= =0A= =0A= END=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 12]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= 9. Security Considerations=0A= =0A= The algorithms in this memo make heuristic use of the StorageType of=0A= entries in the vacmSecurityToGroupTable to distinguish those=0A= provisioned by a security administrator (which would presumably not=0A= be configured as "volatile") from those dynamically generated. In=0A= making this distinction, it assumes that those entries explicitly=0A= provisioned by a security administrator and given a non-"volatile"=0A= status are not to be dynamically overridden. Furthermore, it assumes=0A= that any active entries with "volatile" status can be treated as=0A= dynamic, and deleted or updated as needed. Users of this memo need=0A= to be aware of this operational assumption, which, while reasonable,=0A= is not necessarily universally valid. For example, this situation=0A= could also occur if the SNMP security administrator had mistakenly=0A= created these non-volatile entries in error.=0A= =0A= The design of VACM ensures that if an unknown policy (group name) is=0A= used in the vacmSecurityToGroupTable, no access is granted. A=0A= consequence of this is that no matter what information is provided by=0A= the AAA server, no user can gain SNMP access rights not already=0A= granted to some group through the VACM configuration.=0A= =0A= In order to ensure that the access control policy ultimately applied=0A= as a result of the mechanisms described here is indeed the intended=0A= policy for a given principal using a particular security model, care=0A= needs to be applied in the mapping of the authenticated user=0A= (principal) identity to the securityName used to make the access=0A= control decision. Broadly speaking, there are two approaches to=0A= ensure consistency of identity:=0A= =0A= o Entries for the vacmSecurityToGroupTable corresponding to a given=0A= security model are created only through the operation of the=0A= procedures described in this memo. A consequence of this would be=0A= that all such entries would have been created using the RADIUS=0A= User-Name (or other AAA-authenticated identity) and RADIUS=0A= Management-Policy-Id Attribute (or equivalent).=0A= =0A= o Administrative policy allows a matching pre-configured entry to=0A= exist in the vacmSecurityToGroupTable, i.e., an entry with the=0A= corresponding vacmSecurityModel and with a vacmSecurityName=0A= matching the authenticated principal's RADIUS User-Name). In this=0A= case, administrative policy also needs to ensure consistency of=0A= identity between each authenticated principal's RADIUS User-Name=0A= and the administratively configured vacmSecurityName in the=0A= vacmSecurityToGroupTable row entries for that particular security=0A= model.=0A= =0A= In the later case, inconsistent re-use of the same name for different=0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 13]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= entities or individuals (principals) can cause the incorrect access=0A= control policy to be applied for the authenticated principal,=0A= depending on whether the policy configured using SNMP, or the policy=0A= applied using the procedures of this memo, is the intended policy.=0A= This may result in greater or lesser access rights than the=0A= administrative policy intended. Inadvertent mis-identification in=0A= such cases may be undetectable by the SNMP engine or other software=0A= elements of the managed entity.=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= Some of the readable objects in this MIB module (including some=0A= objects with a MAX-ACCESS of not-accessible, whose values are exposed=0A= as a result access to indexed objects) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= =0A= o vacmAaaSecurityToGroupTable - the entire table is potentially=0A= sensitive, since walking the table will reveal user names,=0A= security models in use, session identifiers, and group names.=0A= =0A= o vacmAaaSecurityModel - though not-accessible, this is exposed as=0A= an index of vacmAaaGroupName=0A= =0A= o vacmAaaSecurityName - though not-accessible, this is exposed as an=0A= index of vacmAaaGroupName=0A= =0A= o vacmAaaSessionID - though not-accessible, this is exposed as an=0A= index of vacmAaaGroupName=0A= =0A= o vacmAaaGroupName - since this identifies a security policy and=0A= associates it with a particular user, this is potentially=0A= sensitive.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPsec),=0A= even then, there is no control as to who on the secure network is=0A= allowed to access and GET/SET (read/change/create/delete) the objects=0A= in this MIB module.=0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 14]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410], section 8),=0A= including full support for the SNMPv3 cryptographic mechanisms (for=0A= authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= =0A= 10. IANA Considerations=0A= =0A= The MIB module in this document uses the following IANA-assigned=0A= OBJECT IDENTIFIER value recorded in the SMI Numbers registry:=0A= =0A= =0A= =0A= Descriptor OBJECT IDENTIFIER value=0A= ---------- -----------------------=0A= snmpVacmAaaMIB { mib-2 XXX }=0A= =0A= =0A= Editor's Note (to be removed prior to publication): the IANA is=0A= requested to assign a value for "XXX" under the 'mib-2' subtree and=0A= to record the assignment in the SMI Numbers registry. When the=0A= assignment has been made, the RFC Editor is asked to replace "XXX"=0A= (here and in the MIB module) with the assigned value and to remove=0A= this note.=0A= =0A= =0A= 11. Contributors=0A= =0A= The following participants from the isms working group contributed to=0A= the development of this document:=0A= =0A= o Andrew Donati=0A= =0A= o David Harrington=0A= =0A= o Jeffrey Hutzelman=0A= =0A= o Juergen Schoenwaelder=0A= =0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 15]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= o Tom Petch=0A= =0A= o Wes Hardaker=0A= =0A= =0A= 12. References=0A= =0A= 12.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Structure of Management Information=0A= Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Textual Conventions for SMIv2",=0A= STD 58, RFC 2579, April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,=0A= "Conformance Statements for SMIv2", STD 58, RFC 2580,=0A= April 1999.=0A= =0A= [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,=0A= "Remote Authentication Dial In User Service (RADIUS)",=0A= RFC 2865, June 2000.=0A= =0A= [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=0A= Architecture for Describing Simple Network Management=0A= Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,=0A= December 2002.=0A= =0A= [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based=0A= Access Control Model (VACM) for the Simple Network=0A= Management Protocol (SNMP)", STD 62, RFC 3415,=0A= December 2002.=0A= =0A= [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In=0A= User Service (RADIUS) Authorization for Network Access=0A= Server (NAS) Management", RFC 5607, July 2009.=0A= =0A= [RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In=0A= User Service (RADIUS) Usage for Simple Network Management=0A= Protocol (SNMP) Transport Models", RFC 5608, August 2009.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 16]=0A= =0C=0A= Internet-Draft AAA-Enabled VACM July 2010=0A= =0A= =0A= 12.2. Informative References=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,=0A= "Introduction and Applicability Statements for Internet-=0A= Standard Management Framework", RFC 3410, December 2002.=0A= =0A= [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure=0A= Shell Transport Model for the Simple Network Management=0A= Protocol (SNMP)", RFC 5592, June 2009.=0A= =0A= =0A= Authors' Addresses=0A= =0A= Kaushik Narayan=0A= Cisco Systems, Inc.=0A= 10 West Tasman Drive=0A= San Jose, CA 95134=0A= USA=0A= =0A= Phone: +1 408-526-8168=0A= Email: kaushik_narayan@yahoo.com=0A= =0A= =0A= David Nelson=0A= Elbrys Networks, Inc.=0A= 282 Corporate Drive, Unit #1,=0A= Portsmouth, NH 03801=0A= USA=0A= =0A= Phone: +1 603-570-2636=0A= Email: d.b.nelson@comcast.net=0A= =0A= =0A= Randy Presuhn (editor)=0A= None=0A= San Jose, CA 95120=0A= USA=0A= =0A= Email: randy_presuhn@mindspring.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Narayan, et al. Expires January 16, 2011 [Page 17]=0A= =0C=0A= =0A= ------=_NextPart_000_0009_01CB23A6.AC19B3E0-- From j.schoenwaelder@jacobs-university.de Thu Jul 15 08:47:35 2010 Return-Path: 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 77B5B3A6AC3 for ; Thu, 15 Jul 2010 08:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiG7aK4KJeVA for ; Thu, 15 Jul 2010 08:47:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 554053A6B59 for ; Thu, 15 Jul 2010 08:47:34 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB628C0004; Thu, 15 Jul 2010 17:47:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n17ci5CvPEOT; Thu, 15 Jul 2010 17:47:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72571C0006; Thu, 15 Jul 2010 17:47:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5826513B0444; Thu, 15 Jul 2010 17:47:43 +0200 (CEST) Date: Thu, 15 Jul 2010 17:47:43 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100715154743.GA13814@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <000c01cb23e1$598cbb00$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01cb23e1$598cbb00$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] text of what will be the -09 RADIUS/VACM draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 15:47:35 -0000 On Thu, Jul 15, 2010 at 07:48:26AM +0200, Randy Presuhn wrote: > Hi - > > As requested by Juergen, attached are the results of applying > my understanding of the edits resulting from the discussion > of David Harrington's last call comments, along with a couple > of minor formatting cleanups in the MIB module. There are > numerous small changes, so the probability of error is high. > Please let me know where I got it wrong. Looks all good to me. Two minor editorial nits: RADIUS-Management-Policy-Id -> RADIUS Management-Policy-Id {snmpVacmAaaMIB 2 } -> { snmpVacmAaaMIB 2 } I believe the to be posted -09 version reflects WG concensus and since there were no further WG LC comments, we can proceed as planned. Once ID submission is open again, Randy will post -09 and I will ask our AD to take the document to the IESG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dnelson@elbrys.com Thu Jul 15 11:24:33 2010 Return-Path: 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 C795B3A6902 for ; Thu, 15 Jul 2010 11:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQjrlkrgQM-Y for ; Thu, 15 Jul 2010 11:24:33 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 858ED3A6824 for ; Thu, 15 Jul 2010 11:24:32 -0700 (PDT) Received: from source ([209.85.215.177]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTD9SamCDQKEdXQ64/K8STEOelx2dIXbh@postini.com; Thu, 15 Jul 2010 11:24:43 PDT Received: by eyd10 with SMTP id 10so274713eyd.22 for ; Thu, 15 Jul 2010 11:24:42 -0700 (PDT) Received: by 10.213.28.141 with SMTP id m13mr75555ebc.25.1279218281990; Thu, 15 Jul 2010 11:24:41 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id j28sm5855863qck.11.2010.07.15.11.24.40 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 11:24:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: "David B. Nelson" In-Reply-To: <20100715154743.GA13814@elstar.local> Date: Thu, 15 Jul 2010 14:24:39 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4FF91C9F-743B-4F48-A871-62B3ADDEE52D@elbrys.com> References: <000c01cb23e1$598cbb00$6801a8c0@oemcomputer> <20100715154743.GA13814@elstar.local> To: isms@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [Isms] text of what will be the -09 RADIUS/VACM draft 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: , X-List-Received-Date: Thu, 15 Jul 2010 18:24:33 -0000 On Jul 15, 2010, at 11:47 AM, Juergen Schoenwaelder wrote: > RADIUS-Management-Policy-Id -> RADIUS Management-Policy-Id Also: Management-Policy-ID --> Management-Policy-Id in one section. From randy_presuhn@mindspring.com Thu Jul 15 14:53:34 2010 Return-Path: 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 CC80D3A67F5 for ; Thu, 15 Jul 2010 14:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7qWAug27DIi for ; Thu, 15 Jul 2010 14:53:34 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 042B83A6862 for ; Thu, 15 Jul 2010 14:53:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=e5TUBUZb+TQL630/JYc8wurpOPBvvip0UkHIldvojAm4kjjCNTW97tLQlpCcQ9bl; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.27.162] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OZWND-0005jZ-Uw for isms@ietf.org; Thu, 15 Jul 2010 17:53:44 -0400 Message-ID: <000f01cb2468$8c3874e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000c01cb23e1$598cbb00$6801a8c0@oemcomputer> <20100715154743.GA13814@elstar.local> Date: Thu, 15 Jul 2010 14:56:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035b0578217b79909b34f0a34c2d1ed1350350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.27.162 Subject: Re: [Isms] text of what will be the -09 RADIUS/VACM draft 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: , X-List-Received-Date: Thu, 15 Jul 2010 21:53:34 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, July 15, 2010 8:47 AM > Subject: Re: [Isms] text of what will be the -09 RADIUS/VACM draft ... > Looks all good to me. Two minor editorial nits: > > RADIUS-Management-Policy-Id -> RADIUS Management-Policy-Id Fixed. > {snmpVacmAaaMIB 2 } -> { snmpVacmAaaMIB 2 } Fixed. > I believe the to be posted -09 version reflects WG concensus and since > there were no further WG LC comments, we can proceed as planned. Once > ID submission is open again, Randy will post -09 and I will ask our AD > to take the document to the IESG. Ok. When posted, it will include the two corrections mentioned above. In the meantime, I hope others would scan the text posted to this list and indicate whether they've spotted any problems. Randy From randy_presuhn@mindspring.com Thu Jul 15 14:56:57 2010 Return-Path: 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 6D3103A6B99 for ; Thu, 15 Jul 2010 14:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shwIsCToUYDm for ; Thu, 15 Jul 2010 14:56:56 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 3595E3A67F5 for ; Thu, 15 Jul 2010 14:56:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pOdzG7mXyRAdGDPBRWM1L/qQ/5+Cntt/E1T9oqDZJi7riR4cru55Qu4gKy3EkdFe; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.27.162] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OZWQU-0006lE-NM for isms@ietf.org; Thu, 15 Jul 2010 17:57:07 -0400 Message-ID: <001801cb2469$063cb940$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000c01cb23e1$598cbb00$6801a8c0@oemcomputer><20100715154743.GA13814@elstar.local> <4FF91C9F-743B-4F48-A871-62B3ADDEE52D@elbrys.com> Date: Thu, 15 Jul 2010 14:59:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc720532780359575f9f7fe538d460be749bae350ac3f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.27.162 Subject: Re: [Isms] text of what will be the -09 RADIUS/VACM draft 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: , X-List-Received-Date: Thu, 15 Jul 2010 21:56:57 -0000 Hi - > From: "David B. Nelson" > To: > Sent: Thursday, July 15, 2010 11:24 AM > Subject: Re: [Isms] text of what will be the -09 RADIUS/VACM draft ... > Also: > > Management-Policy-ID --> Management-Policy-Id > > in one section. Thanks, fixed. Randy From luchuk@snmp.com Fri Jul 23 13:22:41 2010 Return-Path: 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 70BC93A6AAD for ; Fri, 23 Jul 2010 13:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_40=-0.185] 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 56UdV46dKC98 for ; Fri, 23 Jul 2010 13:22:39 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 700823A6A10 for ; Fri, 23 Jul 2010 13:22:39 -0700 (PDT) Received: from sol8.snmp.com (sol8.snmp.com [192.147.142.173]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA04521; Fri, 23 Jul 2010 16:22:56 -0400 (EDT) Received: from sol8 (localhost [127.0.0.1]) by sol8.snmp.com (8.11.7p1+Sun/8.11.2/snmpclient.mc-011018) with ESMTP id o6NKMuY09903; Fri, 23 Jul 2010 16:22:56 -0400 (EDT) Message-Id: <201007232022.o6NKMuY09903@sol8.snmp.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 23 Jul 2010 16:22:56 -0400 From: Alan Luchuk Subject: [Isms] SNMP over (D)TLS implementation report 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: , X-List-Received-Date: Fri, 23 Jul 2010 20:22:41 -0000 Hello, My apology for such a late submission. Still, I hope it is helpful for evaluating the SNMP over (D)TLS draft and moving it forward in the standardization process. Regards, --Alan Background ---------- Several of SNMP Research's customers have expressed interest in SNMP over (D)TLS. To respond to the customer demand, we are implementing SNMP over (D)TLS. Much of our development is based upon earlier drafts, but we are implementing the latest available draft, draft-ietf-isms-dtls-tm-14.txt, "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)." We are also implementing related specifications including RFC 5590, "Transport Security Model for the Simple Network Management Protocol" and RFC 5343, "Simple Network Management Protocol (SNMP) Context EngineID Discovery". Implementation Status --------------------- As of this writing, we have added SNMP over (D)TLS support to SNMP Research's agent products and command-line utilities. As the market demands, we anticipate adding SNMP over (D)TLS support to SNMP Research's manager toolkits. We anticipate that most of the code devloped for the agents will be reusable in the manager toolkits Architecturally SNMP Research's implementation resembles the "Transport Subsystem" decribed in RFC 5590, and shown graphically in Section 3.2.1 of RFC 5590. To preserve the agent's reliability, the Transport Subsystem was integrated into the agent with the minimal required changes. We have implemented SNMP get/set operations and SNMP trap operations over (D)TLS. All of these map between X.509 certificates and SNMP security names through the MIB tables specified in the TLS Transport Model draft. Testing ------- We have tested communication between SNMP Research's agent products and SNMP Research's command-line utilities. We also have done preliminary interoperability testing of SNMP get/set operations between SNMP Research's implementation and the Net-SNMP open-source implementation. We have successfully exchanged SNMP get, set, and trap messages with our internal implemenation. We have successfully exchanged SNMP get messages from the Net-SNMP command-line utilities to the SNMP Research agent, and have successfully exchanged SNMP get messages from the SNMP Research command-line utilities to the Net-SNMP agent. Results ------- During development we encountered and resolved problems testing SNMP Research's agent with SNMP Research's command-line tools. During our limited interoperability testing, we encountered and resolved problems that do NOT appear to be inherent flaws in the drafts or specifications. Perhaps the single largest development slowdown occurred from using an open-source (D)TLS implementation. The slowdown was largely due to a shortage of DTLS programming examples and documentation, and also due to programming examples with a different programming model than that of our agent and utilities. Comments -------- Had we implemented SNMP over (D)TLS earlier in the standardization process, there are changes that we believe would have either improved the auditability of the SNMP-TLS-TM-MIB, or simplified the use of SNMP over (D)TLS and its MIBs. However, we find the latest SNMP over (D)TLS draft to be complete, clear, and implementable without changes. Summary ------- We know of market demand for SNMP over (D)TLS. We are implementing SNMP over (D)TLS as specified in draft-ietf-isms-dtls-tm-14.txt, have tested it internally, and have done preliminary interoperability testing with the Net-SNMP implementation. We have found draft-ietf-isms-dtls-tm-14.txt to be implementable and without obvious design flaws. We believe draft-ietf-isms-dtls-tm-14.txt can and should move forward in the standardization process. --- Alan Luchuk SNMP Research, Inc voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From j.schoenwaelder@jacobs-university.de Sat Jul 24 00:58:43 2010 Return-Path: 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 E647C3A6991 for ; Sat, 24 Jul 2010 00:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRbJBFWr47sZ for ; Sat, 24 Jul 2010 00:58:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D348F3A698D for ; Sat, 24 Jul 2010 00:58:42 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DD6FC0004; Sat, 24 Jul 2010 09:59:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 80P7JViWXA9G; Sat, 24 Jul 2010 09:59:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36765C000C; Sat, 24 Jul 2010 09:58:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 550C113D6234; Sat, 24 Jul 2010 09:58:51 +0200 (CEST) Date: Sat, 24 Jul 2010 09:58:51 +0200 From: Juergen Schoenwaelder To: Alan Luchuk Message-ID: <20100724075851.GA48602@elstar.local> Mail-Followup-To: Alan Luchuk , "isms@ietf.org" References: <201007232022.o6NKMuY09903@sol8.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007232022.o6NKMuY09903@sol8.snmp.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] SNMP over (D)TLS implementation report X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 07:58:44 -0000 On Fri, Jul 23, 2010 at 10:22:56PM +0200, Alan Luchuk wrote: > My apology for such a late submission. Still, I hope it is helpful for > evaluating the SNMP over (D)TLS draft and moving it forward in the > standardization process. Alan, thanks for your implementation report - this is greatly appreciated. If there are others implementing some of the ISMS specifications, please feel encouraged to post similar implementation reports. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rajaram_pejaver@cable.comcast.com Mon Jul 26 08:08:19 2010 Return-Path: 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 34E3C3A6BD3 for ; Mon, 26 Jul 2010 08:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 ZE-rXyOjyLjn for ; Mon, 26 Jul 2010 08:08:18 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1D75B3A6AB5 for ; Mon, 26 Jul 2010 08:08:17 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.87399390; Mon, 26 Jul 2010 11:08:35 -0400 Received: from PACDCEXCSMTP04.cable.comcast.com (24.40.15.118) by pacdcexhub03.cable.comcast.com (24.40.55.40) with Microsoft SMTP Server id 14.0.694.0; Mon, 26 Jul 2010 11:08:35 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 11:08:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jul 2010 11:08:07 -0400 Message-ID: <029A504294520A4F84113D5C45B65A5201A66701@pacdcexcmb05.cable.comcast.com> In-Reply-To: <000601cb23d2$c1e66fc0$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Keroberos Security Model for SNMPv3 Thread-Index: Acsj0ojF9Dzo9eTnS1KonAflLLZp7wI/a1kg References: <6C2349C8-5053-47EC-9404-C1E08DF08FF3@cable.comcast.com> <000601cb23d2$c1e66fc0$6801a8c0@oemcomputer> From: "Pejaver, Rajaram" To: Randy Presuhn , X-OriginalArrivalTime: 26 Jul 2010 15:08:30.0732 (UTC) FILETIME=[68741CC0:01CB2CD4] Subject: Re: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Mon, 26 Jul 2010 15:08:19 -0000 > Any thoughts on how this might work with the > AAA/Vacm integration? The proposal suggests similar interpretation of the authorization data returned from AAA/RADIUS. However, the pathway for the authorization data is different. Instead of the managed device talking to a RADIUS server, we suggest that the Kerberos server gets the authorization data from RADIUS (or an equivalent repository) and inserts it securely into a ticket. I can send out an explanation of the differences between the two approaches. Regards Rajaram Pejaver (Was on vacation:=3D=3D Slow response) Comcast, NETO -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Thursday, July 15, 2010 12:04 AM To: Isms@ietf.org Subject: Re: [Isms] Keroberos Security Model for SNMPv3 Hi - > From: "Lee, Yiu" > To: "David Harrington" > Cc: > Sent: Wednesday, July 14, 2010 7:53 PM > Subject: Re: [Isms] Keroberos Security Model for SNMPv3 ... > we also added the centralized authorization. > We think this is useful because Keroberos doesn't > rely on session based transport. Any thoughts on how this might work with the AAA/Vacm integration? > We didn't know the history why the Hornstein's draft wasn't > accepted as WG item. Do you know why? At the time of that draft (last update was in 2001) the isms working group did not yet exist. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From yiu_lee@cable.comcast.com Mon Jul 26 10:41:31 2010 Return-Path: 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 D5AE53A6BBB for ; Mon, 26 Jul 2010 10:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_NUMERIC_HELO=2.067] 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 tfq28urgawnJ for ; Mon, 26 Jul 2010 10:41:31 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 6C2E53A6407 for ; Mon, 26 Jul 2010 10:40:41 -0700 (PDT) Received: from ([147.191.124.13]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.4855800; Mon, 26 Jul 2010 11:44:24 -0600 Received: from PAOAKEXCSMTP01.cable.comcast.com (10.52.116.30) by copdcexhub02.cable.comcast.com (147.191.124.13) with Microsoft SMTP Server id 14.0.702.0; Mon, 26 Jul 2010 11:39:52 -0600 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 13:39:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 87.213.214.66 ([87.213.214.66]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Jul 2010 17:39:15 +0000 MIME-Version: 1.0 Content-Class: urn:content-classes:message Content-Type: multipart/signed; boundary="B_3362996353_1692767"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 26 Jul 2010 13:39:13 -0400 Message-ID: In-Reply-To: <20100726073657.678663A687D@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-pejaver-ismi-kerberos-00 Thread-Index: Acss6XYQ99e4nzJo80SKaGOLoaPnOA== From: "Lee, Yiu" To: X-OriginalArrivalTime: 26 Jul 2010 17:39:16.0265 (UTC) FILETIME=[7802E990:01CB2CE9] Subject: [Isms] FW: New Version Notification for draft-pejaver-ismi-kerberos-00 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: , X-List-Received-Date: Mon, 26 Jul 2010 17:41:32 -0000 --B_3362996353_1692767 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit We posted the draft to the repository. This draft describes how to use Kerberos with SNMP to provide security. Comments and thoughts are welcome. ------ Forwarded Message From: IETF I-D Submission Tool Date: Mon, 26 Jul 2010 00:36:57 -0700 To: Yiu Leung Lee Cc: Subject: New Version Notification for draft-pejaver-ismi-kerberos-00 A new version of I-D, draft-pejaver-ismi-kerberos-00.txt has been successfully submitted by Yiu Lee and posted to the IETF repository. Filename: draft-pejaver-ismi-kerberos Revision: 00 Title: Keroberos Security Model for SNMPv3 Creation_date: 2010-07-26 WG ID: Independent Submission Number_of_pages: 11 Abstract: This memo describes the use of Kerberos [RFC4120] service with Simple Network Management Protocol (SNMP) to authenticate users, authorize them to access specific MIB objects and to encrypt data for confidentiality. User authorization information is securely encapsulated inside the AuthorizationData field in a Kerberos ticket. The recommendations of this memo may be eventually extended to applications other than SNMP. The IETF Secretariat. ------ End of Forwarded Message --B_3362996353_1692767 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBQ+3hOHhGa0uyGwn6BqCtm+w5XMbDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA3MjYxNzM5MTNaMA0GCSqGSIb3DQEBAQUABIIBACq0 eg06nC3kg1u2RXMo/i3aZ1aq8QM7WEQI0NjjhdGFBStXSl2DbXe9d6aoeY4I8xGNnbSK039C Pj42WbiK5SdBlsJUFGzC/ESaW1QAXksS1PztOVqRZddDKZ2elDw24QW0Ppf2TFzV6F+K+Jsm n4d2XViCBacOOhja145WWB6ddUJ52ZcSnwBYSTpanEKHjHlNiKP2BeJKyPUihKMBMwpVJg7R KUZW3jcAOjkKUJ7LMofp0Q3pwHBDTbk9ihUsLjzpGxdwoZiCdAMu54GtXzblU85pzP6rzNYW 9KHErKWRObEW7lFaW3IZ0+XGqQHk4wefnQQ7TjQr62bmrDQefbY= --B_3362996353_1692767-- From jhutz@cmu.edu Mon Jul 26 15:48:13 2010 Return-Path: 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 940943A6847 for ; Mon, 26 Jul 2010 15:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEVgU01yUYJh for ; Mon, 26 Jul 2010 15:48:12 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 82EE63A684E for ; Mon, 26 Jul 2010 15:48:12 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o6QMlV5g015321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jul 2010 18:47:31 -0400 (EDT) Date: Mon, 26 Jul 2010 18:47:31 -0400 From: Jeffrey Hutzelman To: "Pejaver, Rajaram" , Randy Presuhn , Isms@ietf.org Message-ID: <876D9E0BDFDD00D7316369E4@minbar.fac.cs.cmu.edu> In-Reply-To: <24791_1280156923_o6QF8gOf024983_029A504294520A4F84113D5C45B65A5201A66701@pacdcexcmb05.cable.comcast.com> References: <6C2349C8-5053-47EC-9404-C1E08DF08FF3@cable.comcast.com> <000601cb23d2$c1e66fc0$6801a8c0@oemcomputer> <24791_1280156923_o6QF8gOf024983_029A504294520A4F84113D5C45B65A5201A66701@pacdcexcmb05.cable.comcast.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: jhutz@cmu.edu Subject: Re: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Mon, 26 Jul 2010 22:48:13 -0000 --On Monday, July 26, 2010 11:08:07 AM -0400 "Pejaver, Rajaram" wrote: >> Any thoughts on how this might work with the >> AAA/Vacm integration? > > The proposal suggests similar interpretation of the authorization data > returned from AAA/RADIUS. > However, the pathway for the authorization data is different. > Instead of the managed device talking to a RADIUS server, we suggest > that the Kerberos server > gets the authorization data from RADIUS (or an equivalent repository) > and inserts it securely into a ticket. It's certainly possible to do that, but Kerberos has traditionally stayed away from the authorization space, and you might encounter some resistance getting KDC implementors to do something like that. In any case, I am inclined to recommend use of SSHTM with GSS-krb5 keyex and/or userauth, rather than inventing a new SNMPv3 security model for this purpose. An important part of the reason we chose SSH as the basis for the original ISMS work was to leverage its extensibility and wide range of existing authentication mechanisms to allow integration of SNMP with existing infrastructure _without_ developing new security models for every authentication scheme. -- Jeff From wjhns1@hardakers.net Tue Jul 27 00:22:15 2010 Return-Path: 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 536A93A69E5 for ; Tue, 27 Jul 2010 00:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 3Ssw+BMWwNZM for ; Tue, 27 Jul 2010 00:21:45 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id C85A13A69E2 for ; Tue, 27 Jul 2010 00:21:42 -0700 (PDT) Received: from localhost (dhcp-22e8.meeting.ietf.org [130.129.34.232]) by mail.hardakers.net (Postfix) with ESMTPSA id 91B4F981A9; Tue, 27 Jul 2010 00:22:02 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <6C2349C8-5053-47EC-9404-C1E08DF08FF3@cable.comcast.com> <000601cb23d2$c1e66fc0$6801a8c0@oemcomputer> <24791_1280156923_o6QF8gOf024983_029A504294520A4F84113D5C45B65A5201A66701@pacdcexcmb05.cable.comcast.com> <876D9E0BDFDD00D7316369E4@minbar.fac.cs.cmu.edu> Date: Tue, 27 Jul 2010 00:21:59 -0700 In-Reply-To: <876D9E0BDFDD00D7316369E4@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Mon, 26 Jul 2010 18:47:31 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Isms@ietf.org Subject: Re: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Tue, 27 Jul 2010 07:22:15 -0000 >>>>> On Mon, 26 Jul 2010 18:47:31 -0400, Jeffrey Hutzelman said: JH> In any case, I am inclined to recommend use of SSHTM with GSS-krb5 JH> keyex and/or userauth, rather than inventing a new SNMPv3 security JH> model for this purpose. An important part of the reason we chose SSH JH> as the basis for the original ISMS work was to leverage its JH> extensibility and wide range of existing authentication mechanisms to JH> allow integration of SNMP with existing infrastructure _without_ JH> developing new security models for every authentication scheme. The downside of our existing choice to use a transport mechanism is that it greatly ties the usage of the SNMP protocol to the underlying characteristics upon which the transport is based. EG, for SSH this really means TCP which is not always appropriate for SNMP in some environments (especially in lossy networks). The addition of the (D)TLS support helps this by allowing DTLS/UDP as a second alternative on a different "base" protocol (UDP) with different delivery characteristics. But if you recall the long history of the WG, the original proposal I started the BOF with was a proposal that put the authentication inside the SNMP packet so that it didn't tie the security to a particular transport layer protocol. I did this intentionally since Net-SNMP and other stacks support SNMP over much more than just UDP and TCP. Now, we certainly don't need to revisit that discussion as a choice was made, but fundamentally the choice we made very much restricted how SNMP messages can be sent over the wire. When Ken and I did the original KSM draft in 2001 (wow) we also made the security tied only to the SNMPv3 message without requiring it be tied to a particular underlying transport. We also implemented it and have even heard of a few real-world deployments of our original work (very few, but non-zero). I'm sure no one is actually doing KSM over anything but UDP or TCP but in theory it's actually possible to do it over IPX, AAL5PVC or even a unix domain socket. I doubt it, but in theory it should work. Interestingly, one of the stumbling blocks at the time was contextEngineID discovery. Fortunately that's actually been solved now with the creation of RFC5343. In the end, though, we have significant real-world Kerberos use. We have real-world SSH use. We have real-world TLS use. Different people need different forms of authentication and they likely want to use the mechanisms they already have available over the transports they need to use. I'd love to see the KSM work go forward because I think it helps complete the needs of another user base. But, I also believe it shouldn't be tied to the transport mechanism and thus it would be a significant change in direction from the existing ISMS work. -- Wes Hardaker Cobham Analytic Solutions From yiu_lee@cable.comcast.com Tue Jul 27 00:52:04 2010 Return-Path: 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 8A6DA3A69F1 for ; Tue, 27 Jul 2010 00:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.647 X-Spam-Level: X-Spam-Status: No, score=0.647 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_NUMERIC_HELO=2.067, SARE_MILLIONSOF=0.315] 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 dbctDNSFuXuA for ; Tue, 27 Jul 2010 00:52:03 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 498BC3A69DF for ; Tue, 27 Jul 2010 00:52:03 -0700 (PDT) Received: from ([147.191.124.12]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.4912312; Tue, 27 Jul 2010 01:56:49 -0600 Received: from PAOAKEXCSMTP02.cable.comcast.com (10.52.116.31) by copdcexhub01.cable.comcast.com (147.191.124.12) with Microsoft SMTP Server id 14.0.702.0; Tue, 27 Jul 2010 01:52:16 -0600 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 03:52:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 130.129.118.176 ([130.129.118.176]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Jul 2010 07:52:12 +0000 MIME-Version: 1.0 Content-Class: urn:content-classes:message Content-Type: multipart/signed; boundary="B_3363047531_2842631"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 27 Jul 2010 03:52:11 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Isms] Keroberos Security Model for SNMPv3 Thread-Index: AcstYJ6HAYVH7JGmH0WqW6Y5iUPbeA== From: "Lee, Yiu" To: Wes Hardaker , Jeffrey Hutzelman X-OriginalArrivalTime: 27 Jul 2010 07:52:13.0725 (UTC) FILETIME=[A02794D0:01CB2D60] Cc: Isms@ietf.org Subject: Re: [Isms] Keroberos Security Model for SNMPv3 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: , X-List-Received-Date: Tue, 27 Jul 2010 07:52:04 -0000 --B_3363047531_2842631 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Jeff and Wes, We are very much in alignment with Wes. In our network, we managed millions of devices. We heavily rely on snmp to monitor/manage them. If we used ssh-based snmp, it would be a challenge to manage millions of SSH (TCP) sessions in term of scalability. (D)TLS is an alternative. As far as I know, (D)TLS hasn't been widely deployed. We are open to evaluate the possibility but snmp is our core tool, we can't risk to use (D)TLS until the technology is proven and widely supported by the industry. In contrast, Kerberos is mature and we use it in many places in our network. We believe Kerberos is a better choice in our environment. We are open to try any new technology and support the current works in ISMS, but we also hope that ISMS can consider other alternatives based on different use cases and requirements. Thanks, Yiu On 7/27/10 3:21 AM, "Wes Hardaker" wrote: >>>>>> On Mon, 26 Jul 2010 18:47:31 -0400, Jeffrey Hutzelman >>>>>> said: > > JH> In any case, I am inclined to recommend use of SSHTM with GSS-krb5 > JH> keyex and/or userauth, rather than inventing a new SNMPv3 security > JH> model for this purpose. An important part of the reason we chose SSH > JH> as the basis for the original ISMS work was to leverage its > JH> extensibility and wide range of existing authentication mechanisms to > JH> allow integration of SNMP with existing infrastructure _without_ > JH> developing new security models for every authentication scheme. > > The downside of our existing choice to use a transport mechanism is that > it greatly ties the usage of the SNMP protocol to the underlying > characteristics upon which the transport is based. EG, for SSH this > really means TCP which is not always appropriate for SNMP in some > environments (especially in lossy networks). The addition of the (D)TLS > support helps this by allowing DTLS/UDP as a second alternative on a > different "base" protocol (UDP) with different delivery characteristics. > > But if you recall the long history of the WG, the original proposal I > started the BOF with was a proposal that put the authentication inside > the SNMP packet so that it didn't tie the security to a particular > transport layer protocol. I did this intentionally since Net-SNMP and > other stacks support SNMP over much more than just UDP and TCP. Now, we > certainly don't need to revisit that discussion as a choice was made, > but fundamentally the choice we made very much restricted how SNMP > messages can be sent over the wire. > > When Ken and I did the original KSM draft in 2001 (wow) we also made the > security tied only to the SNMPv3 message without requiring it be tied to > a particular underlying transport. We also implemented it and have even > heard of a few real-world deployments of our original work (very few, > but non-zero). I'm sure no one is actually doing KSM over anything but > UDP or TCP but in theory it's actually possible to do it over IPX, > AAL5PVC or even a unix domain socket. I doubt it, but in theory it > should work. > > Interestingly, one of the stumbling blocks at the time was > contextEngineID discovery. Fortunately that's actually been solved now > with the creation of RFC5343. > > In the end, though, we have significant real-world Kerberos use. We > have real-world SSH use. We have real-world TLS use. Different people > need different forms of authentication and they likely want to use the > mechanisms they already have available over the transports they need to > use. I'd love to see the KSM work go forward because I think it > helps complete the needs of another user base. But, I also believe it > shouldn't be tied to the transport mechanism and thus it would be a > significant change in direction from the existing ISMS work. --B_3363047531_2842631 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBSTVcxRqEuqysQOiXc98u8ugvVDuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA3MjcwNzUyMTFaMA0GCSqGSIb3DQEBAQUABIIBAEtu TYj8m8SrF51sjHngLFyhMfPTPcBWy8wbvKmvEiumr+zCmPQQi7OAxyaDtle39Mq6Cco4EZ16 gocUPiCyTuSbqsuIzYufeKsl33pxbDiZU3I1ka5aegG5sc32CvKxDQdphQl1C1VbJxxLJCeI oJ6vRj4KExohJ45UJGCu+fUb2mFi/z5s5dqineK+aYkoHRKvNsjjFQjmL36ArHA8wCBC+OK8 DbvjevA2/6F1x1wtwvJlLkJ0kxK3W5BRJhZyLfZav0oh+wUUXnMUcVUbNUr7E3LLsVxrdhIW ID7r07H4UUJ8k8mj0fNTUel7vUhVJOH/8BTIROWZLxp/27JZ7KQ= --B_3363047531_2842631-- From root@core3.amsl.com Tue Jul 27 21:45:10 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3CBC73A69A4; Tue, 27 Jul 2010 21:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100728044505.3CBC73A69A4@core3.amsl.com> Date: Tue, 27 Jul 2010 21:45:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-09.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: , X-List-Received-Date: Wed, 28 Jul 2010 04:45:11 -0000 --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 : Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-09.txt Pages : 17 Date : 2010-07-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-Based Access Control Model (VACM). Comments are solicited and should be addressed to the working group's mailing list at isms@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-vacm-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-27214153.I-D@ietf.org> --NextPart-- From randy_presuhn@mindspring.com Tue Jul 27 21:54:48 2010 Return-Path: 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 A083D3A6782 for ; Tue, 27 Jul 2010 21:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL61mTw3NP-o for ; Tue, 27 Jul 2010 21:54:47 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id CA93D3A6964 for ; Tue, 27 Jul 2010 21:54:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OCruiWpWx7UTyc8lcK2rvNG+O1HpzUFd0hXuAL5U3OghS+e0dvFi3hKfamQi5AS8; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.93.8] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Odyfe-0001Xk-4k for isms@ietf.org; Wed, 28 Jul 2010 00:55:10 -0400 Message-ID: <004901cb2e11$76bfe3c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000c01cb23e1$598cbb00$6801a8c0@oemcomputer> <20100715154743.GA13814@elstar.local> Date: Tue, 27 Jul 2010 21:58:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fee9e542055ca030fc077cfcf0a0e345bf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.8 Subject: Re: [Isms] text of what will be the -09 RADIUS/VACM draft 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: , X-List-Received-Date: Wed, 28 Jul 2010 04:54:48 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, July 15, 2010 8:47 AM > Subject: Re: [Isms] text of what will be the -09 RADIUS/VACM draft ... > I believe the to be posted -09 version reflects WG concensus and since > there were no further WG LC comments, we can proceed as planned. Once > ID submission is open again, Randy will post -09 and I will ask our AD > to take the document to the IESG. I have posted the updated I-D, incorporating the fixes identified on this list. Randy From j.schoenwaelder@jacobs-university.de Wed Jul 28 03:03:21 2010 Return-Path: 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 29B2928C124; Wed, 28 Jul 2010 03:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+Wz74wFyVYr; Wed, 28 Jul 2010 03:03:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 77AD83A6A1B; Wed, 28 Jul 2010 03:03:19 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E33ADC0016; Wed, 28 Jul 2010 12:03:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mI81l7QhHPhN; Wed, 28 Jul 2010 12:03:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 728D8C0002; Wed, 28 Jul 2010 12:03:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E5A4E13DF9DD; Wed, 28 Jul 2010 12:03:32 +0200 (CEST) Date: Wed, 28 Jul 2010 12:03:32 +0200 From: Juergen Schoenwaelder To: Sean Turner Message-ID: <20100728100332.GA59150@elstar.local> Mail-Followup-To: Sean Turner , Russ Mundy , iesg-secretary@ietf.org, isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: iesg-secretary@ietf.org, isms@ietf.org, Russ Mundy Subject: [Isms] Request to publish draft-ietf-isms-radius-vacm-09.txt as Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 10:03:21 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sean, the ISMS chairs believe that the ISMS WG has reached concensus on draft-ietf-isms-radius-vacm-09.txt and we request publication of this document as Proposed Standard. Please take over the token for this document. I am attaching the document writeup. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-radius-vacm-writeup.txt" Document: draft-ietf-isms-radius-vacm-09.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Schoenwaelder is the document shepherd. I have reviewed the document several times including the latest version and I believe it is ready for forwarding it to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has received WG last call reviews and comments from - Dave Nelson - David Harrington - Juergen Schoenwaelder - Andrew Donati - Jeffrey Hutzelman and I do not have any concerns regarding the level of review for this document, given that the document is also a minor addition to SNMP. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not think the document needs special reviews. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns. No IPR disclosure been filed as far as we know. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG consensus and the WG wants the document to be published as a Proposed Standard. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No-one has threatened with an appeal or expressed extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been checked with idnits 2.12.00. The document contains a MIB module and should go through the MIB doctor review processs. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split in Normative and Informative. All normative documents have been published. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document requests a number of assignment in an existing registry. It does not create any new registries. I believe the IANA instructions are clear. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The MIB module has been checked using smilint for syntactic correctness. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The document describes how to use Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), for access control authorization within the Simple Network Management Protocol (SNMP) framework. A MIB module is provided to dynamically update user-to-group mappings in the View-Based Access Control Model (VACM). Working Group Summary The working group went over several revisions of this document and the document and all WG last call comments have been resolved. There has been strong WG consensus to publish this document as Proposed Standard. Document Quality The chair is not aware of any implementations at this point in time. Dave Harrington has provided significant reviews that helped with the clarity and modularity aspects of the SNMP specifications. --BOKacYhQ+x31HxR3-- From turners@ieca.com Wed Jul 28 04:22:19 2010 Return-Path: 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 6200D28C155 for ; Wed, 28 Jul 2010 04:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuOIjhTHffmJ for ; Wed, 28 Jul 2010 04:22:18 -0700 (PDT) Received: from smtp114.biz.mail.sp1.yahoo.com (smtp114.biz.mail.sp1.yahoo.com [69.147.92.227]) by core3.amsl.com (Postfix) with SMTP id 97BC728C151 for ; Wed, 28 Jul 2010 04:22:18 -0700 (PDT) Received: (qmail 70349 invoked from network); 28 Jul 2010 11:22:39 -0000 Received: from dhcp-26f6.meeting.ietf.org (turners@130.129.38.246 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 28 Jul 2010 04:22:38 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: PMmesQwVM1lTA_UnPWGpwF7wl_eOW1SmZ4U5CKw0mkM9Qt8 iMmkZIpzbU37g0MmHyr3CA9qUamSMiJmzgg5GLqAYIq.HVxE_EgOZUQHkMDI FXtRRR0GCp.u4Yfz8FZ5DCctfyNALlto6qm7Lq6px5QwEiQpd_2nb192xvZW v_Lg0pg1x0vye0M4BVmZ5IejMiYTyxwpqb5fYxOBL2K9SBmsWZLC_aPrPxCY 4YscCAUj8v0RUzRWNEH8RrXKPog6mhN0taIxkb.SQBpr6JwrMtSvy6L5eeRg zJH85ZP7p3jdEhioefm6Qh64- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5012FD.8060207@ieca.com> Date: Wed, 28 Jul 2010 13:22:37 +0200 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Russ Mundy , isms@ietf.org References: <20100728100332.GA59150@elstar.local> In-Reply-To: <20100728100332.GA59150@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Isms] Request to publish draft-ietf-isms-radius-vacm-09.txt as Proposed Standard 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: , X-List-Received-Date: Wed, 28 Jul 2010 11:22:19 -0000 Thanks for this. I will start my review next Wed. spt Juergen Schoenwaelder wrote: > Sean, > > the ISMS chairs believe that the ISMS WG has reached concensus on > draft-ietf-isms-radius-vacm-09.txt and we request publication of this > document as Proposed Standard. > > Please take over the token for this document. I am attaching the > document writeup. > > /js > > From wwwrun@core3.amsl.com Fri Jul 30 01:52:12 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 48C0028C247; Fri, 30 Jul 2010 01:52:00 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100730085208.48C0028C247@core3.amsl.com> Date: Fri, 30 Jul 2010 01:52:00 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] Last Call: (Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 08:52:12 -0000 The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-08-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isms-radius-vacm/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isms-radius-vacm/