From root@core3.amsl.com Mon Jun 1 10:45:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5C2A43A6A8C; Mon, 1 Jun 2009 10:45: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: <20090601174501.5C2A43A6A8C@core3.amsl.com> Date: Mon, 1 Jun 2009 10:45:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-radius-usage-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, 01 Jun 2009 17:45:01 -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 : Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Author(s) : K. Narayan, D. Nelson Filename : draft-ietf-isms-radius-usage-07.txt Pages : 16 Date : 2009-5-31 This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-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-usage-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-6-1103058.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Wed Jun 10 01:23:17 2009 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 1921828C104; Wed, 10 Jun 2009 01:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 kdnzLuXzjAHa; Wed, 10 Jun 2009 01:23:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id E4F7928C0FB; Wed, 10 Jun 2009 01:23:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,339,1241409600"; d="scan'208";a="148144170" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2009 04:23:19 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 10 Jun 2009 04:23:18 -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: Wed, 10 Jun 2009 10:22:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] FW: Recharter: ISMS Thread-Index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAHIwAQA== From: "Romascanu, Dan (Dan)" To: Cc: iesg@ietf.org Subject: [Isms] FW: [MIB-DOCTORS] FW: Recharter: ISMS 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, 10 Jun 2009 08:23:17 -0000 Forwarding comments from David Harrington. A discussion issued on the AAA-Doctors and MIB-Doctors list. I am not sure how to avoid cross-posting on four or five lists - probably best is to continue the discussion on ISMS.=20 Dan -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Tuesday, June 09, 2009 10:48 PM To: Romascanu, Dan (Dan); ops-dir@ietf.org; aaa-doctors@ietf.org; mib-doctors@ietf.org Cc: 'Pasi Eronen'; 'Juergen Schoenwaelder' Subject: RE: [MIB-DOCTORS] FW: Recharter: ISMS Hi, 1) I support this work. I believe the RADIUS support for SNMPv3 authorization is important. I will not be able to participate actively in this work, unfortunately. 2) I think the charter is misworded.=20 "obtaining VACM authorization information via RADIUS" seems to violate the modularity of the RFC3411 architecture. There should be two steps. 1) obtaining authorization information via RADIUS, using "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management". The authorization information should be in an access model independent form, so it can be used with different access control models. 2) applying the RADIUS authorization information to the view-based access control model. I suggest rewording this to read "Applying RADIUS Management Authorization attributes to the view-based access control model (VACM)."=20 3) I think this wording is slightly wrong: "The authorization information will be limited to mapping the authenticated principal to existing access control polices ..." I think the RADIUS authorization could potentially reference policies that do not exist on the managed device yet. I recommend: "The authorization information will be limited to mapping the authenticated principal to access control policies ..." (I personally prefer "named access control policies" or "access control policy names", but that's a nit.) The WG will need to decide whether to install the unrecognized policy as a new policy (groupname) even though it may not be supported by preconfigured group access rights, or to discard the RADIUS authorization attributes for a policy that is not supported locally. RADIUS should NOT need to know whether the corresponding access rights are provisioned on the managed entity. If user/groupname bindings can be installed dynamically, even though the policy (group access) is not provisioned, a new access control model or extension or an implementation might go get the values to dynamically provision the policy details automatically, rather than requiring operators to preconfigure the access rights for groups who may never actually need to manage the device.=20 4) a continuation of point 2) > - Specify a mechanism to support centralization of SNMPv3 Access > Control decisions by means of a RADIUS-provisioned > username-to-groupname dynamic mapping, that would provide a=20 > binding > between a user and preconfigured VACM policies via dynamic=20 > additions > to the securityToGroupname table. Additionally, specify a time=20 > limit > for access decisions, and such a time limit should be used to > garbage collect expired dynamic securityToGroup mappings. I think it is important to recognize that the SNMPv3 WG deliberately made the binding mechanism between a principal and the AC policy the responsibility of the specific AC model. Another AC model might use a different binding mechanism to bind the principal and the RADIUS-provisioned policy name. RADIUS should supply a model-independent policy name, with no RADIUS knowledge of how the binding will occur within an AC model. The VACM extension should apply that RADIUS-provisioned policy name to the authenticated identity using the VACM-specific username-to-groupname mapping table. RADIUS should supply a time limit for the named policy; However, it is the VACM extension that understands this will be enforced by garbage-collecting expired entries in the username-to-groupname table. A different access control model might enforce the time limit for the named policy by using different AC mechanisms. 5) should we be saying AAA rather than RADIUS? 6) in the milestones, should "centralized access" be "VACM extension"? The RADIUS management authorization document already defines the "centralized access" mechanism. ISMS just needs to write the VACM extension to utilize the RADIUS authorization attributes. 7) Should the charter include updating the SNMP-VIEW-BASED-ACM-MIB, if needed? A new MODULE-COMPLIANCE may need to be written. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: mib-doctors-bounces@ietf.org=20 > [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Romascanu,=20 > Dan (Dan) > Sent: Tuesday, June 09, 2009 1:17 PM > To: ops-dir@ietf.org; aaa-doctors@ietf.org; mib-doctors@ietf.org > Subject: [MIB-DOCTORS] FW: Recharter: ISMS >=20 > Please send me your comments and concerns before Wednesday 6/17.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of > Pasi.Eronen@nokia.com > Sent: Tuesday, June 09, 2009 10:55 AM > To: iesg@ietf.org > Subject: Recharter: ISMS >=20 > [Secretariat (Bcc'd), please place this on 2009-06-18 agenda for IETF > review, and send out an internal review announcement] >=20 > ISMS WG has completed its major deliverables for securing=20 > SNMP with SSH, > and is planning to take on new work: obtaining VACM authorization > information via RADIUS, and specifying TLS/DTLS based transport for > SNMP. The proposed charter text is included below. >=20 > Tim and I are still looking for a co-chair (Juergen Schoenwaelder has > indicated that he cannot continue as the only chair, and will not be > able to attend IETF76 and IETF77), but let's review the contents while > Tim and I look for someone... >=20 > Best regards, > Pasi >=20 > --------------------------------------------------------------------- >=20 > Integrated Security Model for SNMP (isms) >=20 > Description of Working Group: >=20 > The Simple Network Management Protocol version 3 (SNMPv3) provides > message security services through the security subsystem. Previously > the ISMS Working Group defined a Transport Subsystem definition, a new > Transport Security Model, and a Secure Shell Transport Model and a > method for authenticating SNMPv3 users via the Remote Authentication > Dial-In User Service (RADIUS). The initial body of work to be tackled > by the working group involved only these pieces. Additional work on > other transport models and other security extensions were to=20 > wait until > the initial transport architecture and defining documents were > completed. >=20 > It is now possible to authenticate SNMPv3 messages via a RADIUS when > those messages are sent over the newly defined SSH transport. > However, it still remains impossible to centrally authorize a=20 > given SNMP > transaction as on-device pre-existing authorization configuration is > still required. In order to leverage a centralized RADIUS service to > its full extent, the access control decision in the Access Control > Subsystem needs to be based on authorization information received from > RADIUS as well. The result will be an extension to the View-based > Access Control Model (VACM), to obtain authorization=20 > information for an > authenticated principal from RADIUS. The authorization=20 > information will > be limited to mapping the authenticated principal to existing access > control polices, defining session timeouts, and similar session > parameters. This mechanism will not provision the detailed access > control rules. >=20 > Additionally, new work will be undertaken to define TLS and DTLS-based > transports that can offer support for environments that prefer > certificate authentication. Certificate based authentication is > desirable for many environments with a centralized authentication > service. DTLS also provides datagram-based transmissions which may be > desired for environments where TCP performance suffers because of > network anomalies (e.g. high packet loss rates). A combination of TLS > and DTLS-based transports offers solutions that addresses=20 > both the need > for certificate-based authentication and for datagram-based delivery. > Operators will be able to chose the transport solution that best meets > their needs. >=20 > The current goal of the ISMS working group is two-fold: to develop a > method for allowing for access control decisions to be based on > information provide by an AAA provisioning service and to develop > TLS-based and DTLS-based Transport Models. >=20 > The new work must not modify any other aspects of SNMPv3 protocol as > defined in STD 62 (e.g., it must not create new PDU types). >=20 > The working group will cover the following work items: >=20 > - Specify a mechanism to support centralization of SNMPv3 Access > Control decisions by means of a RADIUS-provisioned > username-to-groupname dynamic mapping, that would provide=20 > a binding > between a user and preconfigured VACM policies via=20 > dynamic additions > to the securityToGroupname table. Additionally, specify a=20 > time limit > for access decisions, and such a time limit should be used to > garbage collect expired dynamic securityToGroup mappings. >=20 > - Specify TLS and DTLS transport models for SNMP. >=20 > Goals and Milestones: >=20 > Jul 2009 Publish initial documentation on the (D)TLS=20 > transports for SNMP > Jul 2009 Publish initial documentation for the centralized access > control Jan 2010 Submit documentation on the (D)TLS=20 > transports for SNMP > to IESG Jan 2010 Submit documentation for the centralized=20 > access control > to IESG >=20 > --------------------------------------------------------------------- > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors >=20 From dbharrington@comcast.net Wed Jun 10 02:53:54 2009 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 03D1428C0ED for ; Wed, 10 Jun 2009 02:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 LBx1NLOtUiig for ; Wed, 10 Jun 2009 02:53:53 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id DFB5B3A6879 for ; Wed, 10 Jun 2009 02:53:52 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 29nE1c0070QuhwU529u0S5; Wed, 10 Jun 2009 09:54:00 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id 29u01c0040UQ6dC3N9u0ZN; Wed, 10 Jun 2009 09:54:00 +0000 From: "David B Harrington" To: Date: Wed, 10 Jun 2009 05:53:59 -0400 Message-ID: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gAAELMrgAAoxjNA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS 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, 10 Jun 2009 09:53:54 -0000 Hi, Randy Presuhn described it best. The simplest way to approach this problem is to have the RADIUS authorization attributes simply there in the background. Screw the ASIs; we want to finish this within five years. A RADIUS-aware ACM can simply utilize the RADIUS attributes. My concern is maintaining the modularity that was deliberately created by the SNMPv3 WG to allow modular extensibility. This is all about separating who knows what. RADIUS knows about authorization attributes, not about VACM. When the charter says that RADIUS provides VACM username-to-groupname dynamic provisioning, that is wrong. RADIUS provides a policy name. How that translates to VACM access control is dependent on the (extended) VACM access control model. That permits additional access control models to also utilize the RADIUS attributes. dbh > -----Original Message----- > From: Dave Nelson [mailto:d.b.nelson@comcast.net] > Sent: Tuesday, June 09, 2009 11:23 PM > To: 'David B Harrington'; 'Romascanu, Dan (Dan)'; > ops-dir@ietf.org; aaa-doctors@ietf.org; mib-doctors@ietf.org > Cc: 'Juergen Schoenwaelder'; 'Pasi Eronen' > Subject: RE: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS > > David B Harrington writes... > > > "obtaining VACM authorization information via RADIUS" seems to > > violate the modularity of the RFC3411 architecture. > > Well, perhaps it violates the *aspirations* for modularity. > It's clear to > me that the access control decision is encapsulated entirely > in the Access > Control Subsystem. There is no ASI that allows for the ACS > to obtain access > control guidance from any other subsystem. We encountered > that problem in > the work ISMS recently completed. We created a new Transport > Subsystem, and > a "cache" to allow the TS to communicate with the Security > Subsystem without > modifying the existing ASIs. It's pretty clear, in hind > sight, that the > Security Subsystem design was never sufficiently modular to > foresee the > possibility of the security mechanism being provided outside of that > subsystem. Are you suggesting we use the same tactic here? > That we create > a new AAA Subsystem and a "cache" that allows it to > communicate with the > ACS? > > > There should be two steps. > > 1) obtaining authorization information via RADIUS, using "Remote > > Authentication Dial-In User Service (RADIUS) Authorization > for Network > > Access Server (NAS) Management". The authorization > information should > > be in an access model independent form, so it can be used with > > different access control models. > > In other words, we create an AAA Subsystem. > > > If user/groupname bindings can be installed dynamically, even though > > the policy (group access) is not provisioned, a new access control > > model or extension or an implementation might go get the values to > > dynamically provision the policy details automatically, rather than > > requiring operators to preconfigure the access rights for groups who > > may never actually need to manage the device. > > Well, such a thing is possible, of course, but in the absence > of a specific > mechanism, simply providing access by default raises real > security concerns, > whether or not it is a matter of local policy. > > > I think it is important to recognize that the SNMPv3 WG deliberately > > made the binding mechanism between a principal and the AC policy the > > responsibility of the specific AC model. Another AC model > might use a > > different binding mechanism to bind the principal and the > > RADIUS-provisioned policy name. > > By the same logic, as the binding mechanism *is* the > responsibility of a > specific ACM, who's to say it cannot chose to use RADIUS? > What mandates > that the source of access control information be "modular"? > Nothing that I > see in the current definition of the ACS. > > > RADIUS should supply a model-independent policy name, with no RADIUS > > knowledge of how the binding will occur within an AC model. > > Having an AAA Subsystem might be a good thing. My question > is whether it is > a necessary thing, and whether it would be worth the extra > time and effort. > > > The VACM extension should apply that RADIUS-provisioned > policy name to > > the authenticated identity using the VACM-specific > username-to-groupname > > mapping table. > > I think that's exactly what's been proposed. > > > From jhutz@cmu.edu Wed Jun 10 04:42:39 2009 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 29F533A6959 for ; Wed, 10 Jun 2009 04:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 sAyfPiPfwlox for ; Wed, 10 Jun 2009 04:42:38 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by core3.amsl.com (Postfix) with ESMTP id 56FD63A6833 for ; Wed, 10 Jun 2009 04:42:38 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n5ABgex5023040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 07:42:41 -0400 (EDT) Date: Wed, 10 Jun 2009 07:42:40 -0400 From: Jeffrey Hutzelman To: David B Harrington , isms@ietf.org Message-ID: <0DEC4A19AEB7E694AA1AC5FB@minbar.fac.cs.cmu.edu> In-Reply-To: <21008_1244627643_n5A9s2NV001164_01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> References: <21008_1244627643_n5A9s2NV001164_01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.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.201.117 Cc: jhutz@cmu.edu Subject: Re: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS 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, 10 Jun 2009 11:42:39 -0000 --On Wednesday, June 10, 2009 05:53:59 AM -0400 David B Harrington wrote: > Hi, > > Randy Presuhn described it best. The simplest way to approach this > problem is to have the RADIUS authorization attributes simply there in > the background. Screw the ASIs; we want to finish this within five > years. A RADIUS-aware ACM can simply utilize the RADIUS attributes. > > My concern is maintaining the modularity that was deliberately created > by the SNMPv3 WG to allow modular extensibility. This is all about > separating who knows what. RADIUS knows about authorization > attributes, not about VACM. > > When the charter says that RADIUS provides VACM username-to-groupname > dynamic provisioning, that is wrong. RADIUS provides a policy name. > How that translates to VACM access control is dependent on the > (extended) VACM access control model. That permits additional access > control models to also utilize the RADIUS attributes. I thought the plan was to charter work specifically to define a way for _VACM_ to get provisioning data from _RADIUS_. That is... (1) This is an extension to VACM which describes one way it can interact with something outside the scope of SNMP to do its job. It doesn't communicate with the rest of SNMP (except to use information that any ACM already has at its disposal) and it applies only to VACM. (2) By the same token, it relates specifically to RADIUS, via the just-completed NAS management document, and not to any arbitrary AAA protocol. This really shouldn't create a new "AAA subsystem" abstraction for connecting any ACM to any AAA. If we did that, we'd _still_ have to define the interactions between that new abstraction and each of VACM and RADIUS, and we really don't know enough about the possibilities to construct an abstraction for any case other than (VACM->RADIUS). -- Jeff From d.b.nelson@comcast.net Wed Jun 10 05:10:07 2009 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 213AA3A6ACE for ; Wed, 10 Jun 2009 05:10:07 -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 wA3PgiEaPsiz for ; Wed, 10 Jun 2009 05:10:06 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 020863A695B for ; Wed, 10 Jun 2009 05:10:05 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id 2BGt1c0020lTkoCABCAD2V; Wed, 10 Jun 2009 12:10:13 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id 2CAB1c00J4H2mdz8QCACau; Wed, 10 Jun 2009 12:10:13 +0000 From: "Dave Nelson" To: Date: Wed, 10 Jun 2009 08:10:13 -0400 Message-ID: <857AF054FF294FA49A4CDC20F036A27D@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gAAELMrgAA4CjOAAAPAQ0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS 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, 10 Jun 2009 12:10:07 -0000 Forwarding to ISMS WG list. > -----Original Message----- > From: ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On Behalf > Of Dave Nelson > Sent: Wednesday, June 10, 2009 8:04 AM > To: 'David B Harrington'; 'Romascanu, Dan (Dan)'; ops-dir@ietf.org; aaa- > doctors@ietf.org; mib-doctors@ietf.org > Cc: 'Pasi Eronen'; 'Juergen Schoenwaelder' > Subject: Re: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS > > David B Harrington writes... > > > The simplest way to approach this problem is to have the > > RADIUS authorization attributes simply there in the background. > > OK. This was supposed to be a chartering discussion, but it's turning > into > an architecture and design discussion. Maybe going down that path for a > moment will help resolve the charter text issue. I'm not sure. > > So, how do systems typically use RADIUS? Well, you have a device to which > network connections can be made, that is sessions established and service > provided. There is some gatekeeper function that moderates access. That > gatekeeper function can call the RADIUS client module and ask the "Mother, > may I?" question on behalf of the user identity associated with the > connection attempt. RADIUS comes back with a "Yes" or a "No" and perhaps > some modifiers or limitations. The result of that consultation with > RADIUS > does indeed exist in the background. The gatekeeper function typically > keeps it as part of some session state. Or maybe not. It depends on > what's > needed. > > The key point here is that the gatekeeper function calls the RADIUS client > function to ask an access control question. The RADIUS client, after > talking to the RADIUS server, provided an answer. Typically this happens > only once at the point of session establishment. For scalability and > efficiency reasons, it can't happen for every discrete operation. > > All of that comports with the notion that the RADIUS attributes exist in > the > background. What is not accounted for is that doesn't happen by magic. > Something has to call on RADIUS to request that information, and if that > something isn't the Access Control Model, what is it? > > > My concern is maintaining the modularity that was deliberately created > > by the SNMPv3 WG to allow modular extensibility. This is all about > > separating who knows what. RADIUS knows about authorization > > attributes, not about VACM. > > The RADIUS client does not know about VACM. VACM is simply a module (yes > I > mean that, a piece of code) that calls the RADIUS client's API. The > RADIUS > client (asynchronously) calls back with the results of the authentication > / > authorization request. The RADIUS client doesn't know what VACM (the VACM > extension) is going to do with this the information. As a matter of > practicality, the VACM extension will probably dynamically update one of > its > MIB modules with the information obtained from RADIUS. That information > will exist for the duration of the "session". Probably the hardest thing > about this work will be for the VACM extension to figure out when the > "session" is over and when to flush the temporary information from its MIB > module. We've encountered this issue already. > > > When the charter says that RADIUS provides VACM username-to-groupname > > dynamic provisioning, that is wrong. RADIUS provides a policy name. > > Pedantically, you're correct. The RADIUS client provides the VACM > extension > with a policy name that's bound to a username and the VACM extension uses > that information to populate the MIB table. > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir From d.b.nelson@comcast.net Wed Jun 10 05:12:19 2009 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 E6F2C3A695B for ; Wed, 10 Jun 2009 05:12: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=[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 o52H6-xZLsek for ; Wed, 10 Jun 2009 05:12:19 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 159D73A6833 for ; Wed, 10 Jun 2009 05:12:19 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 2Brq1c0050x6nqcA4CCS2Y; Wed, 10 Jun 2009 12:12:26 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id 2CCQ1c0084H2mdz8YCCRFK; Wed, 10 Jun 2009 12:12:26 +0000 From: "Dave Nelson" To: References: <21008_1244627643_n5A9s2NV001164_01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> <0DEC4A19AEB7E694AA1AC5FB@minbar.fac.cs.cmu.edu> Date: Wed, 10 Jun 2009 08:12:26 -0400 Message-ID: <6B8C20A2BD434126A4FBC21F57D4D8DB@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnpwJUGHXoBsRLARgeq2AuQga+dGwAA+fCg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <0DEC4A19AEB7E694AA1AC5FB@minbar.fac.cs.cmu.edu> Subject: Re: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS 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, 10 Jun 2009 12:12:20 -0000 Jeffrey Hutzelman writes... > I thought the plan was to charter work specifically to define a way for > _VACM_ to get provisioning data from _RADIUS_. That is... > > (1) This is an extension to VACM which describes one way it can interact > with something outside the scope of SNMP to do its job. It doesn't > communicate with the rest of SNMP (except to use information that > any ACM already has at its disposal) and it applies only to VACM. > > (2) By the same token, it relates specifically to RADIUS, via the > just-completed NAS management document, and not to any arbitrary > AAA protocol. Yes, that's exactly correct. > This really shouldn't create a new "AAA subsystem" abstraction for > connecting any ACM to any AAA. If we did that, we'd _still_ have to > define the interactions between that new abstraction and each of VACM > and RADIUS, and we really don't know enough about the possibilities > to construct an abstraction for any case other than (VACM->RADIUS). Agreed. From dbharrington@comcast.net Wed Jun 10 05:44:53 2009 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 DD74E3A6ADA for ; Wed, 10 Jun 2009 05:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 9n8avKxTuI8W for ; Wed, 10 Jun 2009 05:44:52 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 68C1C3A6E5C for ; Wed, 10 Jun 2009 05:44:52 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA07.westchester.pa.mail.comcast.net with comcast id 2AJh1c0060Fqzac57CjyGy; Wed, 10 Jun 2009 12:43:58 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 2Ckz1c01n0UQ6dC3UCkzGG; Wed, 10 Jun 2009 12:45:00 +0000 From: "David B Harrington" To: Date: Wed, 10 Jun 2009 08:44:58 -0400 Message-ID: <026801c9e9c9$43ae1430$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gAAELMrgAA4CjOAAAS65wAAA+LQw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] Recharter: ISMS 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, 10 Jun 2009 12:44:54 -0000 Hi, I separated my responses, since one is about charter text and the rest is an architecture and design discussion. > Pedantically, you're correct. The RADIUS client provides the > VACM extension > with a policy name that's bound to a username and the VACM > extension uses > that information to populate the MIB table. Yes. My point is that the charter does not say this. The text is wrong. The charter says a RADIUS-provisioned username-to-groupname dynamic mapping, that would provide a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table. What it should say is what you said: a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. This may seem pedantic to you, but it is more than that to me. It took the SNMPv2/SNMPv3 community ten years, including some very acrimonious times, to get an architecture we could agree to, that was flexible enough to meet the demands of multiple segments of the community. If we want to change the architecture, then we should do so deliberately, not as a side-effect of sloppy design. I strongly object to a WG goal based on the current wording, because it is counter to the intentions of the SNMPv3 WG, and is not compatible with the RFC3411 architecture. I strongly support a WG goal based on the corrected wording. dbh From d.b.nelson@comcast.net Wed Jun 10 06:03:12 2009 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 D131D28C0EC for ; Wed, 10 Jun 2009 06:03:12 -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 O8wdS6uJNty0 for ; Wed, 10 Jun 2009 06:03:12 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 135063A68A0 for ; Wed, 10 Jun 2009 06:03:12 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 2B4R1c0030S2fkCA4D3K1Q; Wed, 10 Jun 2009 13:03:19 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id 2D351c0034H2mdz8VD36UW; Wed, 10 Jun 2009 13:03:19 +0000 From: "Dave Nelson" To: "'David B Harrington'" References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> <01dd01c9e989$de473610$0600a8c0@china.huawei.com> <4F478F94E9C24469AF59E4734E9F7E89@NEWTON603> <026701c9e9c9$03953c20$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 09:03:06 -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: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gAAELMrgAA4CjOAAAS65wAABefJQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <026701c9e9c9$03953c20$0600a8c0@china.huawei.com> Cc: ops-dir@ietf.org, isms@ietf.org, aaa-doctors@ietf.org, 'Pasi Eronen' , mib-doctors@ietf.org Subject: Re: [Isms] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS 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, 10 Jun 2009 13:03:12 -0000 > Yes. My point is that the charter does not say this. The text is > wrong. > The charter says > a RADIUS-provisioned > username-to-groupname dynamic mapping, that would provide a > binding between a user and preconfigured VACM policies via > dynamic additions to the securityToGroupname table. > What it should say is what you said: > a RADIUS-provisioned policy name bound to a username, which > the VACM extension will use to dynamically populate the > securityToGroupname table. Ah, those two sections of text read basically the same to me, not having the context of the "SNMPv3 Wars". :-) I heartily endorse that change in charter text. From wwwrun@core3.amsl.com Wed Jun 10 06:47:10 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 21CD93A6BC3; Wed, 10 Jun 2009 06:47:10 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090610134710.21CD93A6BC3@core3.amsl.com> Date: Wed, 10 Jun 2009 06:47:10 -0700 (PDT) Cc: Internet Architecture Board , isms mailing list , isms chair , RFC Editor Subject: [Isms] Protocol Action: 'Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models' to 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, 10 Jun 2009 13:47:10 -0000 The IESG has approved the following document: - 'Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models ' as a Proposed Standard This document is the product of the Integrated Security Model for SNMP Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-07.txt Technical Summary The document describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. Working Group Summary The document has been stable for several revisions. Most updates reflected changes in the companion document produced by the RADIUS Extensions working group and clarifications to adapt the SNMP terminology. There has been WG consensus on revision 05 of this document. Document Quality There are no known implementations in progress nor are there any known vendor commitments at the moment to implement this specification. Note that this document defines how RADIUS attributes are to be used in the context of secure SNMP Transport Models and bridges between two worlds. The WG last call has been posted to the RADIUS Extensions working group and RADIUS experts have been involved as document editors. Personnel The document shepherd is Juergen Schoenwaelder, and the responsible area director is Pasi Eronen. From randy_presuhn@mindspring.com Wed Jun 10 09:41:03 2009 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 3E9853A6E8D for ; Wed, 10 Jun 2009 09:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 xS6asXBC6caB for ; Wed, 10 Jun 2009 09:41:02 -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 4817E28C1F8 for ; Wed, 10 Jun 2009 09:41:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gZt5rQa2tAxn9pErqtLu+kIXz2zGOmumSTMaARzT8VreQMNF3aLYzwmbHmeYZpX4; 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 [68.166.37.136] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MEQrM-0000b8-Q1 for isms@ietf.org; Wed, 10 Jun 2009 12:41:09 -0400 Message-ID: <002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 09:41:19 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968e014d1f7f600ef106e5d2d814b628287350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.136 Subject: Re: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS 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, 10 Jun 2009 16:41:03 -0000 Hi - > From: "David B Harrington" > To: > Sent: Wednesday, June 10, 2009 2:53 AM > Subject: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS ... > Randy Presuhn described it best. The simplest way to approach this > problem is to have the RADIUS authorization attributes simply there in > the background. Screw the ASIs; we want to finish this within five > years. A RADIUS-aware ACM can simply utilize the RADIUS attributes. ... Lest I be credited with too much, let me re-cap the idea. (I do not claim to be the only person who's thought about it this way!) (1) the RADIUS authorization data includes the name of the group of which this user is an authorized member. (You can call it a policy if you will, but to break out of chicken--egg provisioning problems it must be possible to transform it into a VACM group name without any prior configuration..) (2) if one does not already exist, a corresponding entry is created in the vacmSecurityToGroupTable. (3) processing continues just like it would for any other transaction. Details of step (2): vacmSecurityModel comes from the security model in use for this message vacmSecurityName obvious vacmGroupName comes from the RADIUS authorization data vacmSecurityToGroupStorageType volatile vacmSecurityToGroupStatus active If you really want to get fancy, you could AUGMENT the vacmSecurityToGroupTable with additional column(s) to make entries created in this manner behave like elements in a age-out or LRU cache. I *think* I went through this in more detail in the ancient "miasma" proposal from the days when ISMS was just getting started. The only "architectural" issue is that going through step (2) requires the entity processing the request to be able to act like an SNMP CR application operating on (rather than merely consulting) the VACM MIB (and possibly an extension to that MIB). This does *not* require defining any interfaces that we don't already have. Randy From j.schoenwaelder@jacobs-university.de Wed Jun 10 10:45:47 2009 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 108403A6A1F for ; Wed, 10 Jun 2009 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 8vKqG2d-+qd4 for ; Wed, 10 Jun 2009 10:45:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E57CE3A67EB for ; Wed, 10 Jun 2009 10:45:45 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74C34C001F; Wed, 10 Jun 2009 19:45:51 +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 sk982fmiNcL6; Wed, 10 Jun 2009 19:45:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE0D5C0018; Wed, 10 Jun 2009 19:45:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CC9C5B374D0; Wed, 10 Jun 2009 19:45:48 +0200 (CEST) Date: Wed, 10 Jun 2009 19:45:48 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20090610174548.GA7577@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> <002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] FW: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS 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, 10 Jun 2009 17:45:47 -0000 On Wed, Jun 10, 2009 at 06:41:19PM +0200, Randy Presuhn wrote: > Lest I be credited with too much, let me re-cap the idea. (I do not > claim to be the only person who's thought about it this way!) > > (1) the RADIUS authorization data includes the name of the > group of which this user is an authorized member. (You can > call it a policy if you will, but to break out of chicken--egg > provisioning problems it must be possible to transform it into > a VACM group name without any prior configuration..) > > (2) if one does not already exist, a corresponding entry is created > in the vacmSecurityToGroupTable. > > (3) processing continues just like it would for any other transaction. > > Details of step (2): > vacmSecurityModel comes from the security model in use for this message > vacmSecurityName obvious > vacmGroupName comes from the RADIUS authorization data > vacmSecurityToGroupStorageType volatile > vacmSecurityToGroupStatus active > > If you really want to get fancy, you could AUGMENT the > vacmSecurityToGroupTable with additional column(s) to make entries > created in this manner behave like elements in a age-out or LRU > cache. I personally believe it should be defined what the lifetime of these entries are and how they get eliminated. > I *think* I went through this in more detail in the ancient "miasma" proposal > from the days when ISMS was just getting started. > > The only "architectural" issue is that going through step (2) requires the > entity processing the request to be able to act like an SNMP CR application > operating on (rather than merely consulting) the VACM MIB (and possibly > an extension to that MIB). This does *not* require defining any interfaces > that we don't already have. One way of looking at it. But in general, we do not spell out how our MIB tables are populated; for me this is just more MIB instrumentation and it does not matter how it is implemented. When a new OSPF peer pops up, you also do not expect that an internal SNMP request is being created to change the MIB tables. That said, I believe we kind of all agree on the solution and I also believe it is not really hard to write this up in an initial ID... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Wed Jun 10 11:15:20 2009 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 55F063A6840 for ; Wed, 10 Jun 2009 11:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 8cQrMTirwxpc for ; Wed, 10 Jun 2009 11:15:19 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 68F163A683A for ; Wed, 10 Jun 2009 11:15:18 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id 2JEu1c0061GXsucA5JFSxg; Wed, 10 Jun 2009 18:15:26 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id 2JFQ1c0064H2mdz8TJFRbS; Wed, 10 Jun 2009 18:15:26 +0000 From: "Dave Nelson" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> <002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> Date: Wed, 10 Jun 2009 14:15:26 -0400 Message-ID: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acnp6kQLntCJEWlYRvCj/boKTapkQAAC9KRA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> Subject: [Isms] Moving into some design / architecture issues of Extended VACM 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, 10 Jun 2009 18:15:20 -0000 Randy Presuhn writes... > (1) the RADIUS authorization data includes the name of the > group of which this user is an authorized member. (You can > call it a policy if you will, but to break out of chicken--egg > provisioning problems it must be possible to transform it into > a VACM group name without any prior configuration.) I don't think the "without any prior configuration" part works. A group name or policy name, whatever we call it, is just short-hand for a potentially long list of policy rules or access control rules. There's no practical way that the RADIUS server can know what group names exist on the NAS and what access rights they convey. That has to be pre-arranged by the system administrator. Similarly, there's no way that the NAS can intuit the correct set of policy rules from the name. The name, IMHO, must simply be a label and MUST NOT be encoded with actual access control semantics. > (2) if one does not already exist, a corresponding entry is created > in the vacmSecurityToGroupTable. That, I think, is a potential security hole that you could drive a whole fleet of trucks through. Creating a table entry with some default, null or wildcard set of access control rules seems like a very bad idea. It's good for ease-of-use, but bad for security. From randy_presuhn@mindspring.com Wed Jun 10 11:40:27 2009 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 A54673A6C6F for ; Wed, 10 Jun 2009 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 G4YSfo69-3kf for ; Wed, 10 Jun 2009 11:40:26 -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 BCCEF3A6C4C for ; Wed, 10 Jun 2009 11:40:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Cf16NC2JJctr3Zc5MQC7+jHadfIcvQht5/zuKIhbfr+sRcS17PEVvDyV1Iv+fKLC; 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 [68.166.37.136] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MESiv-0007MM-Cr for isms@ietf.org; Wed, 10 Jun 2009 14:40:33 -0400 Message-ID: <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> Date: Wed, 10 Jun 2009 11:40:44 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69685134bf7f0d329f06560aff869439296b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.136 Subject: Re: [Isms] Moving into some design / architecture issues of ExtendedVACM 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, 10 Jun 2009 18:40:27 -0000 Hi - > From: "Dave Nelson" > To: > Sent: Wednesday, June 10, 2009 11:15 AM > Subject: [Isms] Moving into some design / architecture issues of ExtendedVACM > > Randy Presuhn writes... > > > (1) the RADIUS authorization data includes the name of the > > group of which this user is an authorized member. (You can > > call it a policy if you will, but to break out of chicken--egg > > provisioning problems it must be possible to transform it into > > a VACM group name without any prior configuration.) > > I don't think the "without any prior configuration" part works. A group > name or policy name, whatever we call it, is just short-hand for a > potentially long list of policy rules or access control rules. There's no > practical way that the RADIUS server can know what group names exist on the > NAS and what access rights they convey. That has to be pre-arranged by the > system administrator. Similarly, there's no way that the NAS can intuit the > correct set of policy rules from the name. The name, IMHO, must simply be a > label and MUST NOT be encoded with actual access control semantics. When I talked about "provisioning" I was referring to the SNMP-manageable system. The whole point of this exercise is to push as much as practical (not as much as possible!) into the RADIUS world. This means that the group access rights *will* have to be pre-configured. That's ok. The point of the ISMS work is to cope with user churn, not policy churn. > > (2) if one does not already exist, a corresponding entry is created > > in the vacmSecurityToGroupTable. > > That, I think, is a potential security hole that you could drive a whole > fleet of trucks through. Creating a table entry with some default, null or > wildcard set of access control rules seems like a very bad idea. It's good > for ease-of-use, but bad for security. No, look at what the vacmSecurityToGroupTable *does*. If there is no access control policy in place for a particular group, then no rights are granted. I think we very clearly do *NOT* want this stuff to be messing with anything in VACM other than the vacmSecurityToGroupTable. Practically by definition, we trust the RADIUS server to deliver the correct user->group mapping. If we can't make that assumption, this whole exercise is pointless. Randy From d.b.nelson@comcast.net Wed Jun 10 12:09:18 2009 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 42E203A68C3 for ; Wed, 10 Jun 2009 12:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 1Wrlvn9gLIiK for ; Wed, 10 Jun 2009 12:09:17 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id 56A613A6855 for ; Wed, 10 Jun 2009 12:09:17 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id 2K5P1c00E0mlR8UADK9RfK; Wed, 10 Jun 2009 19:09:25 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id 2K9P1c0034H2mdz8XK9QpV; Wed, 10 Jun 2009 19:09:24 +0000 From: "Dave Nelson" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> Date: Wed, 10 Jun 2009 15:09:25 -0400 Message-ID: <710D8493B4CF44B5848A27680AAEA301@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acnp+vNQEdA12MVfTbSENaCCBc/KoQAAtWrw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> Subject: Re: [Isms] Moving into some design / architecture issues ofExtendedVACM 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, 10 Jun 2009 19:09:18 -0000 Randy Preshun writes... > This means that the group access rights *will* have to be > pre-configured. OK. We're on the same page. > The point of the ISMS work is to cope with user churn, > not policy churn. Exactly. > No, look at what the vacmSecurityToGroupTable *does*. Before dong any drafting of text I *will* need to review the VACM RFC carefully, or rely on my co-editor for that expertise. > If there is no access control policy in place for a > particular group, then no rights are granted. OK. I didn't realize that. > Practically by definition, we trust the RADIUS server to > deliver the correct user->group mapping. Yes, but the NAS's VACM MIB tables and the RADIUS server's database are configured by human system administrators who can make mistakes. Sometimes as simple as a typo error. If RADIUS authorizes an unknown group name, that has to be considered a configuration error and the NAS needs to handle it predictably and securely. > If we can't make that assumption, this whole exercise > is pointless. We can assume that when the system is properly configured. We also design the system to detect and correctly handle mis-configurations. From ietfdbh@comcast.net Wed Jun 10 12:16:43 2009 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 29C3A3A6B22 for ; Wed, 10 Jun 2009 12:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 IrUQEOadEjNZ for ; Wed, 10 Jun 2009 12:16:42 -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 D8BD73A69A1 for ; Wed, 10 Jun 2009 12:16:41 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 2K9X1c00517dt5G55KGpef; Wed, 10 Jun 2009 19:16:49 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 2KGo1c00V0UQ6dC3ZKGotF; Wed, 10 Jun 2009 19:16:49 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> Date: Wed, 10 Jun 2009 15:16:48 -0400 Message-ID: <000601c9ea00$00795120$0600a8c0@china.huawei.com> 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.3198 Thread-Index: Acnp+vNQGLDebVoRQmKuBzSv2EzFXAAAMnhw In-Reply-To: <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> Subject: Re: [Isms] Moving into some design / architecture issues ofExtendedVACM 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, 10 Jun 2009 19:16:43 -0000 Hi, I agree with (what I believe to be) Randy's assessment. VACM has two major parts: 1) a binding of user to policy/group 2) the detailed access controls for a group (views, permissions, etc.) I think it is fine for RADIUS to provide a user/policy, and for VACM to translate that into user/groupname even if there are no entries specifying the views and permissions for the groupname. The isAccessAllowed() will simply say "no" for any group for which no views/permissions are defined. Nobody is talking about providing agent-supplied defaults that grant default permissions to an unrecognized groupname. So installing the user/group binding alone should be fine. No security hole that I see. -- As Randy says, ISMS is trying to address user churn, not policy churn. The configuration of the policy details within the VACM model can be done using SNMP (or CLI or netconf or startup files or ...). Once installed, the policy usually remains unchanged. The WG will need to deal with mid-session changes to user/policy assignments and/or policy configuration changes. Maybe we assume sessions will short-lived enough not to worry about it, but given the sensitivity of management access, I think we will need to address this. IIRC, RADIUS servers can specify "interrupts" - hey, client, I need to revoke the current access-accept and force you to ask me again, because some things have changed. Hopefully, we will not need to deal with a user changing their group's permissions in a way that denies them access to the view and permissions tables they are changing ;-) dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Wednesday, June 10, 2009 2:41 PM > To: isms@ietf.org > Subject: Re: [Isms] Moving into some design / architecture > issues ofExtendedVACM > > Hi - > > > From: "Dave Nelson" > > To: > > Sent: Wednesday, June 10, 2009 11:15 AM > > Subject: [Isms] Moving into some design / architecture > issues of ExtendedVACM > > > > Randy Presuhn writes... > > > > > (1) the RADIUS authorization data includes the name of the > > > group of which this user is an authorized member. (You can > > > call it a policy if you will, but to break out of chicken--egg > > > provisioning problems it must be possible to transform it into > > > a VACM group name without any prior configuration.) > > > > I don't think the "without any prior configuration" part > works. A group > > name or policy name, whatever we call it, is just short-hand for a > > potentially long list of policy rules or access control > rules. There's no > > practical way that the RADIUS server can know what group > names exist on the > > NAS and what access rights they convey. That has to be > pre-arranged by the > > system administrator. Similarly, there's no way that the > NAS can intuit the > > correct set of policy rules from the name. The name, IMHO, > must simply be a > > label and MUST NOT be encoded with actual access control semantics. > > When I talked about "provisioning" I was referring to the > SNMP-manageable > system. The whole point of this exercise is to push as much > as practical > (not as much as possible!) into the RADIUS world. This means that the > group access rights *will* have to be pre-configured. That's ok. > > The point of the ISMS work is to cope with user churn, not > policy churn. > > > > (2) if one does not already exist, a corresponding entry > is created > > > in the vacmSecurityToGroupTable. > > > > That, I think, is a potential security hole that you could > drive a whole > > fleet of trucks through. Creating a table entry with some > default, null or > > wildcard set of access control rules seems like a very bad > idea. It's good > > for ease-of-use, but bad for security. > > No, look at what the vacmSecurityToGroupTable *does*. > If there is no access control policy in place for a particular group, > then no rights are granted. I think we very clearly do *NOT* > want this > stuff to be messing with anything in VACM other than the > vacmSecurityToGroupTable. Practically by definition, we trust > the RADIUS server to deliver the correct user->group mapping. > If we can't make that assumption, this whole exercise is pointless. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From ietfdbh@comcast.net Wed Jun 10 12:31:12 2009 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 52A273A67B2 for ; Wed, 10 Jun 2009 12:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 QkLxZHAr38P1 for ; Wed, 10 Jun 2009 12:31:11 -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 358D23A6855 for ; Wed, 10 Jun 2009 12:31:10 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 2K6v1c0020mv7h055KXJ63; Wed, 10 Jun 2009 19:31:18 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 2KXJ1c00C0UQ6dC3XKXJlE; Wed, 10 Jun 2009 19:31:18 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer> <710D8493B4CF44B5848A27680AAEA301@NEWTON603> Date: Wed, 10 Jun 2009 15:31:19 -0400 Message-ID: <000701c9ea02$07a07440$0600a8c0@china.huawei.com> 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.3198 Thread-Index: Acnp+vNQEdA12MVfTbSENaCCBc/KoQAAtWrwAACexVA= In-Reply-To: <710D8493B4CF44B5848A27680AAEA301@NEWTON603> Subject: Re: [Isms] Moving into some design / architecture issuesofExtendedVACM 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, 10 Jun 2009 19:31:12 -0000 Hi, Installing a groupname when there are no corresponding views and permissions entries is not a misconfiguration. From RFC3415: vacmGroupName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the group to which this entry (e.g., the combination of securityModel and securityName) belongs. This groupName is used as index into the vacmAccessTable to select an access control policy. However, a value in this table does not imply that an instance with the value exists in table vacmAccesTable. " ::= { vacmSecurityToGroupEntry 3 } (oh my! we have a misspelling in RFC3415!). dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Wednesday, June 10, 2009 3:09 PM > To: isms@ietf.org > Subject: Re: [Isms] Moving into some design / architecture > issuesofExtendedVACM > > Randy Preshun writes... > > > This means that the group access rights *will* have to be > > pre-configured. > > OK. We're on the same page. > > > The point of the ISMS work is to cope with user churn, > > not policy churn. > > Exactly. > > > No, look at what the vacmSecurityToGroupTable *does*. > > Before dong any drafting of text I *will* need to review the VACM RFC > carefully, or rely on my co-editor for that expertise. > > > If there is no access control policy in place for a > > particular group, then no rights are granted. > > OK. I didn't realize that. > > > Practically by definition, we trust the RADIUS server to > > deliver the correct user->group mapping. > > Yes, but the NAS's VACM MIB tables and the RADIUS server's > database are > configured by human system administrators who can make > mistakes. Sometimes > as simple as a typo error. If RADIUS authorizes an unknown > group name, that > has to be considered a configuration error and the NAS needs > to handle it > predictably and securely. > > > If we can't make that assumption, this whole exercise > > is pointless. > > We can assume that when the system is properly configured. > We also design > the system to detect and correctly handle mis-configurations. > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From d.b.nelson@comcast.net Wed Jun 10 12:38:10 2009 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 3264D3A697E for ; Wed, 10 Jun 2009 12:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 6+6z1TYnw1h2 for ; Wed, 10 Jun 2009 12:38:09 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 5C0E23A67B2 for ; Wed, 10 Jun 2009 12:38:09 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 2K8B1c00A0b6N64A4KeHf9; Wed, 10 Jun 2009 19:38:17 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id 2KeF1c0074H2mdz8PKeFRV; Wed, 10 Jun 2009 19:38:16 +0000 From: "Dave Nelson" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer> <000601c9ea00$00795120$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 15:38:17 -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: Acnp+vNQGLDebVoRQmKuBzSv2EzFXAAAMnhwAAFdP7A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <000601c9ea00$00795120$0600a8c0@china.huawei.com> Subject: Re: [Isms] Moving into some design / architecture issuesofExtendedVACM 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, 10 Jun 2009 19:38:10 -0000 David Harrington writes... > I think it is fine for RADIUS to provide a user/policy, > and for VACM to translate... Are we contemplating something other than the "identity transform" here? If not, why use the word "translate"? If so, how is domain-wide correctness guaranteed? > ... that into user/groupname even if there are no entries > specifying the views and permissions for the groupname. The > isAccessAllowed() will simply say "no" for any group for which no > views/permissions are defined. Yes, I see that. As the default for a new group entry is no access, there is no security risk. OTOH, what's the operational advantage of populating the tables with useless / erroneous group names? Conversely, what's the disadvantage of simply ignoring any non-existing group names, and dismissing them as a mis-configuration? You many, of course, want a counter of these someplace. > The WG will need to deal with mid-session changes to user/policy > assignments and/or policy configuration changes. This can be tricky. One possible solution is for a "significant' have of policy definition in the NAS to trigger a RADIUS re-authentication request. > IIRC, RADIUS servers can specify "interrupts" - hey, client, I > need to revoke the current access-accept and force you to ask me > again, because some things have changed. You're thinking of Dynamic RADIUS, which allows for changes of authorization, initiated by the RADIUS server. Of course, the RADIUS server isn't likely to be aware of changes in MIB values on the NAS. From d.b.nelson@comcast.net Wed Jun 10 12:45:13 2009 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 139483A6B47 for ; Wed, 10 Jun 2009 12:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 MMn1jTlu38Kg for ; Wed, 10 Jun 2009 12:45:12 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 4238F3A69A1 for ; Wed, 10 Jun 2009 12:45:11 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id 2K7V1c0090x6nqcABKlKJs; Wed, 10 Jun 2009 19:45:19 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id 2KlH1c0024H2mdz8YKlHKg; Wed, 10 Jun 2009 19:45:18 +0000 From: "Dave Nelson" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer> <710D8493B4CF44B5848A27680AAEA301@NEWTON603> <000701c9ea02$07a07440$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 15:45:19 -0400 Message-ID: <8A6E391F9358412D953F3BC532495630@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acnp+vNQEdA12MVfTbSENaCCBc/KoQAAtWrwAACexVAAAL1z4A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <000701c9ea02$07a07440$0600a8c0@china.huawei.com> Subject: Re: [Isms] Moving into some design / architecture issuesofExtendedVACM 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, 10 Jun 2009 19:45:13 -0000 David Harrington writes... > Installing a groupname when there are no corresponding views and > permissions entries is not a misconfiguration. OK, so "null pointers" in VACM are *not* a mis-configuration. I wouldn't have guessed that. :-) I suppose it make sense in terms of populating a MIB Module. Operationally it seems kind of pointless, though. Well, no matter. It's not of significance to the design, AFAICT. From ietfdbh@comcast.net Wed Jun 10 14:03:08 2009 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 3E18F3A67BD for ; Wed, 10 Jun 2009 14:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 KD+Z+N1QVKpD for ; Wed, 10 Jun 2009 14:03:02 -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 89BDD3A6AFE for ; Wed, 10 Jun 2009 14:03:01 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 2K501c0031GhbT859M394G; Wed, 10 Jun 2009 21:03:09 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id 2M381c00M0UQ6dC3TM3861; Wed, 10 Jun 2009 21:03:09 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 17:03:04 -0400 Message-ID: <001101c9ea0e$d987fee0$0600a8c0@china.huawei.com> 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.3198 Thread-Index: Acnp+vNQGLDebVoRQmKuBzSv2EzFXAAAMnhwAAFdP7AAAv2JUA== In-Reply-To: Subject: Re: [Isms] Moving into some design / architectureissuesofExtendedVACM 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, 10 Jun 2009 21:03:08 -0000 Hi, > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Wednesday, June 10, 2009 3:38 PM > To: isms@ietf.org > Subject: Re: [Isms] Moving into some design / > architectureissuesofExtendedVACM > > David Harrington writes... > > > I think it is fine for RADIUS to provide a user/policy, > > and for VACM to translate... > > Are we contemplating something other than the "identity > transform" here? If > not, why use the word "translate"? If so, how is domain-wide > correctness > guaranteed? I just meant "translate" from attribute format to MIB format, using the identity transform. > > > ... that into user/groupname even if there are no entries > > specifying the views and permissions for the groupname. The > > isAccessAllowed() will simply say "no" for any group for which no > > views/permissions are defined. > > Yes, I see that. As the default for a new group entry is no > access, there > is no security risk. OTOH, what's the operational advantage > of populating > the tables with useless / erroneous group names? Conversely, > what's the > disadvantage of simply ignoring any non-existing group names, > and dismissing > them as a mis-configuration? You many, of course, want a > counter of these > someplace. I think the reasoning was simply that some admins might prefer to install user/group mappings before they actually do the accesstable. Some might prefer to do the accessTable first and then the user/group mapping. Note that the accessTable also can be populated before the user-to-groupname entry is defined, even though groupname is part of the index. vacmAccessEntry OBJECT-TYPE SYNTAX VacmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An access right configured in the Local Configuration Datastore (LCD) authorizing access to an SNMP context. Entries in this table can use an instance value for object vacmGroupName even if no entry in table vacmAccessSecurityToGroupTable has a corresponding value for object vacmGroupName. " INDEX { vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel, vacmAccessSecurityLevel } ::= { vacmAccessTable 1 } > > > The WG will need to deal with mid-session changes to user/policy > > assignments and/or policy configuration changes. > > This can be tricky. One possible solution is for a > "significant' have of > policy definition in the NAS to trigger a RADIUS > re-authentication request. Hopefully we won't need to deal with that too much. > > > IIRC, RADIUS servers can specify "interrupts" - hey, client, I > > need to revoke the current access-accept and force you to ask me > > again, because some things have changed. > > You're thinking of Dynamic RADIUS, which allows for changes of > authorization, initiated by the RADIUS server. Of course, > the RADIUS server > isn't likely to be aware of changes in MIB values on the NAS. True, but the server might be aware of admin changes for the user/group assignments. > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From randy_presuhn@mindspring.com Wed Jun 10 18:58:44 2009 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 C46A63A69B2 for ; Wed, 10 Jun 2009 18:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSWsCEvnMCUD for ; Wed, 10 Jun 2009 18:58:44 -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 DF4D63A688C for ; Wed, 10 Jun 2009 18:58:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=W6gXURL5A7Pg1gFM3Wnxldee3+dTR4sRSooJA+WFOASxvp5sxc8SfZb/QBGegmRi; 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 [68.166.37.136] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MEZZ4-00042s-Nk for isms@ietf.org; Wed, 10 Jun 2009 21:58:50 -0400 Message-ID: <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 18:59:00 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69684ebbd052a46fa5a7763d3a56062f2e66350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.37.136 Subject: Re: [Isms] Moving into some design / architectureissuesofExtendedVACM 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, 11 Jun 2009 01:58:44 -0000 Hi - > From: "Dave Nelson" > To: > Sent: Wednesday, June 10, 2009 12:38 PM > Subject: Re: [Isms] Moving into some design / architectureissuesofExtendedVACM ... > Yes, I see that. As the default for a new group entry is no access, there > is no security risk. OTOH, what's the operational advantage of populating > the tables with useless / erroneous group names? Conversely, what's the > disadvantage of simply ignoring any non-existing group names, and dismissing > them as a mis-configuration? You many, of course, want a counter of these > someplace. I think the disadvantage is that of introducing yet another special case. There is no way to tell the difference between "useless," "eroneous," and "I got there before the configuration updated was pushed to that particular node." (Operationally, the user-group mapping will go out before there is any guarantee that all nodes for which that policy will be relevant have been updated to include that policy in their repertoire.) If we distinguish this case with special handling and counters, do we want to propagate an error back to RADIUS-land? (We have no mechanism for delivering any special indication to the SNMP conversation partner.) What is the recovery strategy upon receipt of this error, and is it any different from any other access-denied situation? Randy From d.b.nelson@comcast.net Thu Jun 11 06:28:24 2009 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 EB6E53A6C47 for ; Thu, 11 Jun 2009 06:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 1ZpGpji-IRPs for ; Thu, 11 Jun 2009 06:28:23 -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 BC32A3A6ACE for ; Thu, 11 Jun 2009 06:28:22 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 2aKl1c0030xGWP851dUDip; Thu, 11 Jun 2009 13:28:13 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 2dUW1c00S4H2mdz3YdUWeb; Thu, 11 Jun 2009 13:28:30 +0000 From: "Dave Nelson" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com> <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> Date: Thu, 11 Jun 2009 09:28:34 -0400 Message-ID: <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnqOC2M5DkwrcdOTN2rIwhVupb3TwAX5NQg Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM 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, 11 Jun 2009 13:28:24 -0000 Randy Presuhn writes... > I think the disadvantage is that of introducing yet another special case. > There is no way to tell the difference between "useless," "eroneous," > and "I got there before the configuration updated was pushed to that > particular node." (Operationally, the user-group mapping will go out > before there is any guarantee that all nodes for which that policy will > be relevant have been updated to include that policy in their repertoire.) > > If we distinguish this case with special handling and counters, do we want > to propagate an error back to RADIUS-land? (We have no mechanism for > delivering any special indication to the SNMP conversation partner.) What > is the recovery strategy upon receipt of this error, and is it any > different from any other access-denied situation? All good questions. We do need to define behavior for all the corner cases as part of this effort. If there is a mismatch in policy/group names between the RADIUS server and the network devices, users will get authenticated, an SNMP session will start, e.g. over SSH, but the VACM will not provide any access to MIB objects. Is there an SNMP-level error message that will inform the user where the problem lies? From j.schoenwaelder@jacobs-university.de Thu Jun 11 07:05:42 2009 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 D19553A690F for ; Thu, 11 Jun 2009 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 zoT+iAtSHHMQ for ; Thu, 11 Jun 2009 07:05:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9B3193A6907 for ; Thu, 11 Jun 2009 07:05:41 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63C0EC0016; Thu, 11 Jun 2009 16:05:48 +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 sHyFNloeqJC2; Thu, 11 Jun 2009 16:05:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75A5EC000B; Thu, 11 Jun 2009 16:05:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 468A0B398B2; Thu, 11 Jun 2009 16:05:45 +0200 (CEST) Date: Thu, 11 Jun 2009 16:05:45 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090611140545.GA9442@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> <002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> <000601c9ea00$00795120$0600a8c0@china.huawei.com> <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM 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, 11 Jun 2009 14:05:42 -0000 On Thu, Jun 11, 2009 at 03:28:34PM +0200, Dave Nelson wrote: > Randy Presuhn writes... > > > I think the disadvantage is that of introducing yet another special case. > > There is no way to tell the difference between "useless," "eroneous," > > and "I got there before the configuration updated was pushed to that > > particular node." (Operationally, the user-group mapping will go out > > before there is any guarantee that all nodes for which that policy will > > be relevant have been updated to include that policy in their repertoire.) > > > > If we distinguish this case with special handling and counters, do we want > > to propagate an error back to RADIUS-land? (We have no mechanism for > > delivering any special indication to the SNMP conversation partner.) What > > is the recovery strategy upon receipt of this error, and is it any > > different from any other access-denied situation? > > All good questions. We do need to define behavior for all the corner cases > as part of this effort. No, the behaviour is already defined in VACM. Just be happy with what it does and the lets move on. ;-) > If there is a mismatch in policy/group names between the RADIUS server and > the network devices, users will get authenticated, an SNMP session will > start, e.g. over SSH, but the VACM will not provide any access to MIB > objects. Is there an SNMP-level error message that will inform the user > where the problem lies? According to RFC 3413 section 3.2. (page 11), I think this should result in an authorizationError. But more important: SNMP has defined ways to handle this situation, which can occur due to manual mis-configuration of VACM tables. It should not make any difference whether the "broken" group name was manually configured or installed by a RADIUS client. But there are some interesting questions to work out: What is the behaviour if a RADIUS client receives a policy attributes but the vacmSecurityToGroupTable has already a (different) entry for the (securityModel, securityName) tuple? Who wins in this situation - or does this even cause the authentication of the incoming request to fail? What happens if no new entries can be created anymore due to resource limitations? These are examples of new error situations that we have to deal with. /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 Thu Jun 11 09:23:35 2009 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 28A933A689D for ; Thu, 11 Jun 2009 09:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 fvKvrOvJcgKd for ; Thu, 11 Jun 2009 09:23:34 -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 EDAE03A67AA for ; Thu, 11 Jun 2009 09:23:33 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 2a841c0061HzFnQ53gPi5Q; Thu, 11 Jun 2009 16:23:42 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id 2gPh1c00G0UQ6dC3agPh5K; Thu, 11 Jun 2009 16:23:42 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Dave Nelson'" References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> Date: Thu, 11 Jun 2009 12:23:40 -0400 Message-ID: <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> 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.3198 Thread-Index: Acnqnbx/lBzv6ICfRjiWGKdUHP6k9gAEoieg In-Reply-To: <20090611140545.GA9442@elstar.local> Cc: isms@ietf.org Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM 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, 11 Jun 2009 16:23:35 -0000 Hi, > No, the behaviour is already defined in VACM. Just be happy with what > it does and the lets move on. ;-) > [...] > But more important: SNMP has defined ways to handle this situation, > which can occur due to manual mis-configuration of VACM tables. It > should not make any difference whether the "broken" group name was > manually configured or installed by a RADIUS client. agreed. > > But there are some interesting questions to work out: What is the > behaviour if a RADIUS client receives a policy attributes but the > vacmSecurityToGroupTable has already a (different) entry for the > (securityModel, securityName) tuple? If we tried to do this with a SET what would happen? If it would fail as a SET, then it should fail as a dynamic creation. You might want to use a different counter for the dynamic creation failure. > Who wins in this situation - or > does this even cause the authentication of the incoming request to > fail? If the row contains a RowStatus, would that make a difference? > What happens if no new entries can be created anymore due to > resource limitations? If we tried to do this with a SET, what would happen? we should be consistent, although we have no way of sending back an error RESPONSE message. These are examples of new error situations > that we have to deal with. agreed. > > /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 j.schoenwaelder@jacobs-university.de Thu Jun 11 10:14:09 2009 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 D67B728C0D7 for ; Thu, 11 Jun 2009 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 rmEP1kdvINVO for ; Thu, 11 Jun 2009 10:14:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 649593A6D93 for ; Thu, 11 Jun 2009 10:14:08 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87C6DC0016; Thu, 11 Jun 2009 19:14:15 +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 9F3ucfwK3rwT; Thu, 11 Jun 2009 19:14:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5CF5C000B; Thu, 11 Jun 2009 19:14:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3CB1FB3B9B1; Thu, 11 Jun 2009 19:14:11 +0200 (CEST) Date: Thu, 11 Jun 2009 19:14:11 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090611171411.GA388@elstar.local> Mail-Followup-To: David Harrington , 'Dave Nelson' , "isms@ietf.org" References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> <002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> <000601c9ea00$00795120$0600a8c0@china.huawei.com> <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM 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, 11 Jun 2009 17:14:09 -0000 On Thu, Jun 11, 2009 at 06:23:40PM +0200, David Harrington wrote: > agreed. > > > > > But there are some interesting questions to work out: What is the > > behaviour if a RADIUS client receives a policy attributes but the > > vacmSecurityToGroupTable has already a (different) entry for the > > (securityModel, securityName) tuple? > > If we tried to do this with a SET what would happen? If it would fail > as a SET, then it should fail as a dynamic creation. You might want to > use a different counter for the dynamic creation failure. > > > Who wins in this situation - or > > does this even cause the authentication of the incoming request to > > fail? > > If the row contains a RowStatus, would that make a difference? The table has a RowStatus and a StorageType column and thus there are quite a number of possible failure modes... > > What happens if no new entries can be created anymore due to > > resource limitations? > > If we tried to do this with a SET, what would happen? we should be > consistent, although we have no way of sending back an error RESPONSE > message. My point is that have to define what the RADIUS client does in case the attempt to push something into the vacmSecurityToGroupTable fails - and depending on how long we want to work on this, we might go into all the details of distinguishing different failure modes. It will sure get complicated if we make it complicated. But the minimum we have to do is to specify what the RADIUS client does if the creation fails. And I think we should avoid making this really more complicated. /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 Thu Jun 11 10:25:57 2009 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 3B4583A6DB5 for ; Thu, 11 Jun 2009 10:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 FHgH2+-LYRe6 for ; Thu, 11 Jun 2009 10:25:55 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 87AB33A69BF for ; Thu, 11 Jun 2009 10:25:55 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 2gul1c00R0EZKEL54hS3oT; Thu, 11 Jun 2009 17:26:03 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 2hRi1c00g0UQ6dC3MhRiT8; Thu, 11 Jun 2009 17:25:43 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com> <002201c9e9ea$488a1dc0$6801a8c0@oemcomputer> <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> <000601c9ea00$00795120$0600a8c0@china.huawei.com> <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> <20090611171411.GA388@elstar.local> Date: Thu, 11 Jun 2009 13:26:01 -0400 Message-ID: <008601c9eab9$b15ab150$0600a8c0@china.huawei.com> 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.3198 Thread-Index: AcnquA40mmiN69sfRgyXI5Tq2P4ZGAAAZ2KA In-Reply-To: <20090611171411.GA388@elstar.local> Cc: isms@ietf.org Subject: Re: [Isms] Moving into some design/architectureissuesofExtendedVACM 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, 11 Jun 2009 17:25:57 -0000 +1 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, June 11, 2009 1:14 PM > To: David Harrington > Cc: 'Dave Nelson'; isms@ietf.org > Subject: Re: [Isms] Moving into some > design/architectureissuesofExtendedVACM > > On Thu, Jun 11, 2009 at 06:23:40PM +0200, David Harrington wrote: > > > agreed. > > > > > > > > But there are some interesting questions to work out: What is the > > > behaviour if a RADIUS client receives a policy attributes but the > > > vacmSecurityToGroupTable has already a (different) entry for the > > > (securityModel, securityName) tuple? > > > > If we tried to do this with a SET what would happen? If it > would fail > > as a SET, then it should fail as a dynamic creation. You > might want to > > use a different counter for the dynamic creation failure. > > > > > Who wins in this situation - or > > > does this even cause the authentication of the incoming request to > > > fail? > > > > If the row contains a RowStatus, would that make a difference? > > The table has a RowStatus and a StorageType column and thus there are > quite a number of possible failure modes... > > > > What happens if no new entries can be created anymore due to > > > resource limitations? > > > > If we tried to do this with a SET, what would happen? we should be > > consistent, although we have no way of sending back an > error RESPONSE > > message. > > My point is that have to define what the RADIUS client does in case > the attempt to push something into the vacmSecurityToGroupTable fails > - and depending on how long we want to work on this, we might go into > all the details of distinguishing different failure modes. It will > sure get complicated if we make it complicated. > > But the minimum we have to do is to specify what the RADIUS client > does if the creation fails. And I think we should avoid making this > really more complicated. > > /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 Thu Jun 11 12:37:02 2009 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 491763A6BEE for ; Thu, 11 Jun 2009 12:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 F38A5Dw2ExNL for ; Thu, 11 Jun 2009 12:37:01 -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 9560B3A6A70 for ; Thu, 11 Jun 2009 12:37:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=R0lSUJUfHWMPORhxhL4vEIpaGxxIofKz1+lL7gx7YLsmoT/DB35r/X29/pmqGVnx; 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 [68.166.188.22] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MEq5D-0004sZ-OK for isms@ietf.org; Thu, 11 Jun 2009 15:37:08 -0400 Message-ID: <004101c9eacc$0916ffe0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> Date: Thu, 11 Jun 2009 12:37:19 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696830e155673273170ba99f2eece04de6b9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.22 Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM 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, 11 Jun 2009 19:37:02 -0000 Hi - > From: "Dave Nelson" > To: > Sent: Thursday, June 11, 2009 6:28 AM > Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM ... > If there is a mismatch in policy/group names between the RADIUS server and > the network devices, users will get authenticated, an SNMP session will > start, e.g. over SSH, but the VACM will not provide any access to MIB > objects. Is there an SNMP-level error message that will inform the user > where the problem lies? It depends. Assuming the group is created automatically, in response to an SNMP operation you might get "noSuchName", which would be indistinguishable from "the data doesn't exist", or you might get "authorizationError", which lets you know that the access- control system kept you away from the information. If the group were *not* created automatically (except when there is something, such as corresponding entries in vacmAccessTable, to indicate that the group is "intended" to exist) then you're guaranteed "authorizationError" in SNMPv3 by the procedures on page 12 of RFC 3413. Even in this latter case, the operation *might* suceed if tried again later. Consider this scenario: while the security administrator is in the process of pushing the updates to the vacmAccessTable in accordance with the procedures spelled out in that table's DESCRIPTION, the rights granted to members of that group will only stay the same or increase with each update, so that members of that group can be assumed to have been granted their full rights on that system only after *all* the relevant entries to the vacmAccessTable have been successfully pushed. I think the upshot of this is that carving out an exception doesn't actually make anything easier here. Randy From randy_presuhn@mindspring.com Thu Jun 11 13:39:35 2009 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 C83983A6AA2 for ; Thu, 11 Jun 2009 13:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 YlYX-L4iHE7w for ; Thu, 11 Jun 2009 13:39:33 -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 6BA763A6A62 for ; Thu, 11 Jun 2009 13:39:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jEidDm5HyNprfI/95WzNtlmpAF13fRDA7m3dE/dMRWIXm+mvRulIdHZPtS0kFDgZ; 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 [68.166.188.22] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MEr3j-0007cB-N1 for isms@ietf.org; Thu, 11 Jun 2009 16:39:40 -0400 Message-ID: <003001c9ead4$c60d5a60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> Date: Thu, 11 Jun 2009 13:39:52 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69682981d7cb44a5c6a1b7809c4bfe5b47bd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.22 Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM 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, 11 Jun 2009 20:39:36 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Dave Nelson" > Cc: > Sent: Thursday, June 11, 2009 7:05 AM > Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM .... > But more important: SNMP has defined ways to handle this situation, > which can occur due to manual mis-configuration of VACM tables. It > should not make any difference whether the "broken" group name was > manually configured or installed by a RADIUS client. Adopting this philosophy helps answer the questions that follow... > But there are some interesting questions to work out: What is the > behaviour if a RADIUS client receives a policy attributes but the > vacmSecurityToGroupTable has already a (different) entry for the > (securityModel, securityName) tuple? Who wins in this situation - or > does this even cause the authentication of the incoming request to > fail? If the row for (securityModel, securityName) already exists, then if the value of vacmSecurityToGroupStorageType is "readOnly", then the "policy attribute" would have to be ignored. For any other value of vacmSecurityToGroupStorageType, the "policy attribute" would result in an update of vacmGroupName, and (potentially) vacmSecurityToGroupStatus set to "active". > What happens if no new entries can be created anymore due to > resource limitations? Then no entry is created. This is no different from the case where a security administrator tries to create a new entry. > These are examples of new error situations > that we have to deal with. Yup. Fortunately, none of them so far seems very complicated or scary, as long as we don't try to change the fundamental design. Randy From randy_presuhn@mindspring.com Thu Jun 11 13:54:50 2009 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 9C5843A6A3E for ; Thu, 11 Jun 2009 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 h7cB03MwPNiU for ; Thu, 11 Jun 2009 13:54:49 -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 ADE2E3A693A for ; Thu, 11 Jun 2009 13:54:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=US/V7AhcVJMy9mGhZNk82z4TXCgKq8Dnz8LYnOiYQXR66rFd4z43Y4ZpP+KuH7Y3; 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 [68.166.188.22] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MErIX-0005Ck-2a for isms@ietf.org; Thu, 11 Jun 2009 16:54:57 -0400 Message-ID: <003b01c9ead6$e8e08920$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com> <20090611171411.GA388@elstar.local> Date: Thu, 11 Jun 2009 13:55:09 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69681d0579face4f9de60acdb406a51d2b26350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.22 Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM 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, 11 Jun 2009 20:54:50 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "David Harrington" > Cc: > Sent: Thursday, June 11, 2009 10:14 AM > Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM ... > My point is that have to define what the RADIUS client does in case > the attempt to push something into the vacmSecurityToGroupTable fails > - and depending on how long we want to work on this, we might go into > all the details of distinguishing different failure modes. It will > sure get complicated if we make it complicated. There are actually relatively few - I spelled them out in an earlier message. > But the minimum we have to do is to specify what the RADIUS client > does if the creation fails. Yup, and I think the answer is "nothing." There's no channel for signalling back the failure. From an implementation perspective, if there aren't resources to create/update a vacmSecurityToGroupEntry, then I'd be wary of trying to do things like queue up special-purpose notifications for the security administrator, who'd be the one who'd have to figure out a recovery strategy. At an operational level, the user might notice that it was granted different access rights than it expected. The user might check its vacmSecurityToGroupEntry (if it has permission to see it), or leave that job to the security administrator. (There would either be no entry, or the group name specified in that entry would be the "old" one.) In either case, figuring out a recovery strategy would still be up to the security administrator, and would be no different from dealing with a system that ran out of resources while a security policy update was being pushed to it. But I think we're off in the extreme corner cases here. A system that runs out of memory under these circumstances has a more serious problem on its hands. :-) > And I think we should avoid making this > really more complicated. Agreed. Randy From kaushik@cisco.com Thu Jun 11 15:27:41 2009 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 5C3233A6DDF for ; Thu, 11 Jun 2009 15:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 D4Rcbvb0YezU for ; Thu, 11 Jun 2009 15:27:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8544B3A6DDB for ; Thu, 11 Jun 2009 15:27:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,204,1243814400"; d="scan'208";a="321690175" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2009 22:27:42 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5BMRgt0006990; Thu, 11 Jun 2009 15:27:42 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5BMRfng017408; Thu, 11 Jun 2009 22:27:42 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 15:27:42 -0700 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Jun 2009 22:27:41 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 11 Jun 2009 15:27:32 -0700 From: kaushik To: Dave Nelson , Message-ID: Thread-Topic: [Isms] Moving into some design / architecture issues of Extended VACM Thread-Index: Acnp6kQLntCJEWlYRvCj/boKTapkQAAC9KRAADtuRmg= In-Reply-To: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jun 2009 22:27:42.0031 (UTC) FILETIME=[D5AFBDF0:01C9EAE3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1017; t=1244759262; x=1245623262; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Isms]=20Moving=20into=20some=20design= 20/=20architecture=20issues=20of=20Extended=0A=20VACM |Sender:=20; bh=E6+FOnuSSs3vwOv4RYjxiWyhJDP1cjXtm5qkHAftAi4=; b=ed0I8XM8cbOE2j01aHE8IZ5scK+j6oIACcCNpgG3bLxeH6gLqcMNNAQYV8 bsdpCBqFXhJ7G33aeB+HnrwWy4mGQhwhzGyTFoxTkaJr06PdfqRo3w7tCWek ccJM3JUhEP; Authentication-Results: sj-dkim-3; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Isms] Moving into some design / architecture issues of Extended VACM 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, 11 Jun 2009 22:27:41 -0000 Hi Randy, Please find my reply inline. >> (2) if one does not already exist, a corresponding entry is created >> in the vacmSecurityToGroupTable. > > That, I think, is a potential security hole that you could drive a whole > fleet of trucks through. Creating a table entry with some default, null or > wildcard set of access control rules seems like a very bad idea. It's good > for ease-of-use, but bad for security. > > The issue I have with this model is that we are using the RADIUS user-to-group mapping which is a temporal association valid for the duration of the session and provisioning a persistent piece of configuration on the SNMP engine. I am not sure the semantics match and this could create potential problems around whether the RADIUS server or SNMP engine is authoritative source for user-to-group mapping since entries can be added to the vacmSecurityToGroupTable without knowledge of the RADIUS server. Regards, kaushik From j.schoenwaelder@jacobs-university.de Thu Jun 11 15:57:30 2009 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 3470D3A6E0B for ; Thu, 11 Jun 2009 15:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.033, 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 a0plmsKJzL+z for ; Thu, 11 Jun 2009 15:57:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F33B73A6A37 for ; Thu, 11 Jun 2009 15:57:28 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36058C0029; Fri, 12 Jun 2009 00:57:36 +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 D2w7TbYXX0kI; Fri, 12 Jun 2009 00:57:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C053C0037; Fri, 12 Jun 2009 00:57:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 00D78B3C06C; Fri, 12 Jun 2009 00:57:32 +0200 (CEST) Date: Fri, 12 Jun 2009 00:57:32 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20090611225732.GA840@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> <000601c9ea00$00795120$0600a8c0@china.huawei.com> <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> <20090611171411.GA388@elstar.local> <003b01c9ead6$e8e08920$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003b01c9ead6$e8e08920$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM 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, 11 Jun 2009 22:57:30 -0000 On Thu, Jun 11, 2009 at 10:55:09PM +0200, Randy Presuhn wrote: > > But the minimum we have to do is to specify what the RADIUS client > > does if the creation fails. > > Yup, and I think the answer is "nothing." There's no channel for > signalling back the failure. From an implementation perspective, > if there aren't resources to create/update a vacmSecurityToGroupEntry, > then I'd be wary of trying to do things like queue up special-purpose > notifications for the security administrator, who'd be the one who'd have > to figure out a recovery strategy. I am talking in general about a failure to install the requested policy / name to group mapping - not just about the resource shortage case. Suppose the RADIUS server tells the RADIUS client that "joe" using "TSM" is authorized for the management policy "restricted" but the attempt of the RADIUS client to install this policy fails since for some reason (e.g., there exists an entry for "joe" using "TSM" using group "poweruser" that for whatever reason can't be modified). Is it OK to ignore the failure and to let "joe" now use the "poweruser" rights? Or should the RADIUS client do something like deny authentication of joe's session if it can't install the management policy, or kill joe's session if it is already there (likely a challenge to write down due to the architectural model we have, but likely easy to implement ;-). My understanding is that RADIUS decisions are of the kind "here is exactly what you do or you deny service" (RADIUS folks, please correct me if I am wrong). If this is the case, simply ignoring a failure to install the requested policy sounds kind of wrong. /js PS: Does the RADIUS client have the "rights" to modify any existing writable matching table entries? Will it revert the changes when the session dies? -- 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 Thu Jun 11 17:13:42 2009 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 BD3A43A69AD for ; Thu, 11 Jun 2009 17:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 J0xT8b0-f25R for ; Thu, 11 Jun 2009 17:13:42 -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 CEC8D3A6886 for ; Thu, 11 Jun 2009 17:13:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QH9ODEFVUJr6Kj24VedOjt529qysrSWa+XyV3Dcc50z2TRed3Ltw01I4nGLbr3mT; 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 [68.166.188.167] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MEuOz-0005mL-I1 for isms@ietf.org; Thu, 11 Jun 2009 20:13:49 -0400 Message-ID: <000901c9eaf2$b0d98380$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <00e901c9e9fa$f7642100$6801a8c0@oemcomputer> <000601c9ea00$00795120$0600a8c0@china.huawei.com> <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> <20090611171411.GA388@elstar.local> <003b01c9ead6$e8e08920$6801a8c0@oemcomputer> <20090611225732.GA840@elstar.local> Date: Thu, 11 Jun 2009 17:14:00 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696815884395b9ede06dc1bf4a8f2c26f76f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.167 Subject: Re: [Isms] Moving into some design/architectureissuesofExtendedVACM 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, 12 Jun 2009 00:13:42 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, June 11, 2009 3:57 PM > Subject: Re: [Isms] Moving into some design/architectureissuesofExtendedVACM > > On Thu, Jun 11, 2009 at 10:55:09PM +0200, Randy Presuhn wrote: > > > > But the minimum we have to do is to specify what the RADIUS client > > > does if the creation fails. > > > > Yup, and I think the answer is "nothing." There's no channel for > > signalling back the failure. From an implementation perspective, > > if there aren't resources to create/update a vacmSecurityToGroupEntry, > > then I'd be wary of trying to do things like queue up special-purpose > > notifications for the security administrator, who'd be the one who'd have > > to figure out a recovery strategy. > > I am talking in general about a failure to install the requested > policy / name to group mapping - not just about the resource shortage > case. > > Suppose the RADIUS server tells the RADIUS client that "joe" using > "TSM" is authorized for the management policy "restricted" but the > attempt of the RADIUS client to install this policy fails since for > some reason (e.g., there exists an entry for "joe" using "TSM" using > group "poweruser" that for whatever reason can't be modified). Is it > OK to ignore the failure and to let "joe" now use the "poweruser" > rights? Yes, since that's exactly what would happen if another security administrator tried to create/update the entry and failed. > Or should the RADIUS client do something like deny > authentication of joe's session if it can't install the management > policy, or kill joe's session if it is already there (likely a > challenge to write down due to the architectural model we have, but > likely easy to implement ;-). I see no value whatsoever to doing so. If the system is already configured to treat that user as a member of a particular group, and (for whatever reason) is unable to honor the group membership asserted by RADIUS, then it makes perfect sense for it to use the policy it already has in place. After all, that's exactly what it would do today. > My understanding is that RADIUS decisions are of the kind "here is > exactly what you do or you deny service" (RADIUS folks, please correct > me if I am wrong). If this is the case, simply ignoring a failure to > install the requested policy sounds kind of wrong. I think in our case it makes more sense to view this information as being provided by a security administrator, since it is being used to update the access control configuration of the system, and is *not* directly an access-allowed/access-denied decision. > PS: Does the RADIUS client have the "rights" to modify any existing > writable matching table entries? If we take the stance that this should be treated like an update from a security administrator, then yes, when vacmSecurityToGroupStorageType is not 'readOnly', it would need to be able to update vacmGroupName and vacmSecurityToGroupStatus (if not already 'active'). > Will it revert the changes when > the session dies? Again, if we take as our model that the RADIUS information is configuration data, treated as if coming from an authorized security administrator, then it does not make sense to revert the changes. Randy From dnelson@elbrysnetworks.com Thu Jun 11 17:51:16 2009 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 97A473A6A00 for ; Thu, 11 Jun 2009 17:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C3x1ZggvBbO for ; Thu, 11 Jun 2009 17:51:15 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 978553A6A6C for ; Thu, 11 Jun 2009 17:51:15 -0700 (PDT) Received: (qmail 4255 invoked from network); 11 Jun 2009 13:39:20 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 11 Jun 2009 13:39:20 -0400 From: "David B. Nelson" To: "'David Harrington'" , "'Juergen Schoenwaelder'" References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local> <008601c9eab9$b15ab150$0600a8c0@china.huawei.com> Date: Thu, 11 Jun 2009 13:39:23 -0400 Organization: Elbrys Networks, Inc. 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: AcnquA40mmiN69sfRgyXI5Tq2P4ZGAAAZ2KAAABoC9A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <008601c9eab9$b15ab150$0600a8c0@china.huawei.com> Cc: isms@ietf.org Subject: Re: [Isms] Moving into some design/architectureissuesofExtendedVACM 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, 12 Jun 2009 00:51:16 -0000 I've sent other responses in this thread this morning, but the Elbrys Networks DNS servers don't seem to like the ietf.org domain and my outgoing mail often languishes. Sigh. From ietfdbh@comcast.net Thu Jun 11 19:32:31 2009 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 68AF728C14C for ; Thu, 11 Jun 2009 19:32:31 -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 BEllIaxcOecS for ; Thu, 11 Jun 2009 19:32:30 -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 745B128C192 for ; Thu, 11 Jun 2009 19:32:30 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 2mMQ1c00817dt5G51qYMRu; Fri, 12 Jun 2009 02:32:21 +0000 Received: from Harrington73653 ([69.24.4.68]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 2qYS1c00S1U2xWl3ZqYUGZ; Fri, 12 Jun 2009 02:32:37 +0000 From: "David Harrington" To: "'kaushik'" , "'Dave Nelson'" , References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> Date: Thu, 11 Jun 2009 22:32:25 -0400 Message-ID: <00e701c9eb06$0c1147c0$0600a8c0@china.huawei.com> 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.3198 Thread-Index: Acnp6kQLntCJEWlYRvCj/boKTapkQAAC9KRAADtuRmgACHpogA== In-Reply-To: Subject: Re: [Isms] Moving into some design / architecture issues of Extended VACM 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, 12 Jun 2009 02:32:31 -0000 Hi, I think the MIB should be augmented with a column to identify how it was installed, and a time limit specified by RADIUS. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of kaushik > Sent: Thursday, June 11, 2009 6:28 PM > To: Dave Nelson; isms@ietf.org > Subject: Re: [Isms] Moving into some design / architecture > issues of Extended VACM > > Hi Randy, > > Please find my reply inline. > > > > >> (2) if one does not already exist, a corresponding entry is created > >> in the vacmSecurityToGroupTable. > > > > That, I think, is a potential security hole that you could > drive a whole > > fleet of trucks through. Creating a table entry with some > default, null or > > wildcard set of access control rules seems like a very bad > idea. It's good > > for ease-of-use, but bad for security. > > > > > > > > The issue I have with this model is that we are using the RADIUS > user-to-group mapping which is a temporal association valid > for the duration > of the session and provisioning a persistent piece of > configuration on the > SNMP engine. I am not sure the semantics match and this could create > potential problems around whether the RADIUS server or SNMP engine is > authoritative source for user-to-group mapping since entries > can be added to > the vacmSecurityToGroupTable without knowledge of the RADIUS server. > > Regards, > kaushik > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From dnelson@elbrysnetworks.com Thu Jun 11 19:44:52 2009 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 4D5D43A6CF6 for ; Thu, 11 Jun 2009 19:44:52 -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 X11LlUE-GENX for ; Thu, 11 Jun 2009 19:44:51 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 5A65C3A6C32 for ; Thu, 11 Jun 2009 19:44:51 -0700 (PDT) Received: (qmail 598 invoked from network); 11 Jun 2009 11:38:12 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 11 Jun 2009 11:38:12 -0400 From: "David B. Nelson" To: References: <01fe01c9e9b1$607f52d0$0600a8c0@china.huawei.com><002201c9e9ea$488a1dc0$6801a8c0@oemcomputer><7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> Date: Thu, 11 Jun 2009 11:38:16 -0400 Organization: Elbrys Networks, Inc. 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: AcnqnbtOXXrbntFTSz+zwFdQproEEwAC7GBQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20090611140545.GA9442@elstar.local> Subject: Re: [Isms] Moving into some design/architecture issues of ExtendedVACM 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, 12 Jun 2009 02:44:52 -0000 Juergen Schoenwaelder writes... > Just be happy with what it does and the lets move on. Perhaps. My operating assumption is that VACM tables are not manually updated frequently; in fact probably very infrequently. Once the mistakes in configuration ad detected, the Help Desk calls placed, and the error rectified, things remain stable for a relatively long time. All is goodness. Once the user to group mapping becomes dynamic, it seems to me that that opportunity arises for much more frequent mismatches, with the resultant user confusion and Help Desk calls. Anyway, that's my current think on this issue. I could be mistaken. > But there are some interesting questions to work out: What is the > behaviour if a RADIUS client receives a policy attributes but the > vacmSecurityToGroupTable has already a (different) entry for the > (securityModel, securityName) tuple? This is not unique to VACM. There are other use cases where the NAS needs to have a well defined precedence relationship for RADIUS-provisioned vs. locally-stored session properties. Sometimes this is a user configurable parameter. > What happens if no new entries can be created anymore due to > resource limitations? Good question. From d.b.nelson@comcast.net Thu Jun 11 20:54:30 2009 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 796AF3A6BED for ; Thu, 11 Jun 2009 20:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 AXpcby3NwaSN for ; Thu, 11 Jun 2009 20:54:29 -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 58A993A6B83 for ; Thu, 11 Jun 2009 20:54:28 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 2mKC1c00E0Fqzac58rudWB; Fri, 12 Jun 2009 03:54:37 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 2ruc1c0094H2mdz3UrudLk; Fri, 12 Jun 2009 03:54:37 +0000 From: "Dave Nelson" To: References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer> <20090611225732.GA840@elstar.local> Date: Thu, 11 Jun 2009 23:54:41 -0400 Message-ID: <0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090611225732.GA840@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acnq6AclnFO7JUMoRPC3ScXNF1x7jAAJkLOA Subject: Re: [Isms] Moving into some design/architecture issues of ExtendedVACM 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, 12 Jun 2009 03:54:30 -0000 Juergen Schoenwaelder writes... > Suppose the RADIUS server tells the RADIUS client that "joe" using > "TSM" is authorized for the management policy "restricted" but the > attempt of the RADIUS client to install this policy fails since for > some reason (e.g., there exists an entry for "joe" using "TSM" using > group "poweruser" that for whatever reason can't be modified). Is it > OK to ignore the failure and to let "joe" now use the "poweruser" > rights? I guess the question can be rephrased to ask whether you really want two different repositories (the RADIUS server's database and the locally stored VACM MIB entries) to be equally authoritative for authorization, especially when they conflict. I would think, in general, that's not a good idea. In a carefully managed environment, many things are acceptable that would not be acceptable in the more general case. For example, if you assume that the "joe" that RADIUS has authenticated is the same "joe" that is found configured in the VACM MIB Module, it *might* in some circumstances be OK to let the VACM data take precedence over the RADIUS data. OTOH, if it's possible that there are two *different* users with the username "joe" one in RADIUS and another in VACM, then it may be a very bad idea. Generally speaking when a feature is taken under RADIUS control, RADIUS is considered to be the primary authority, and local data does not override the access provisioned by RADIUS. I feel quite uncomfortable with proposing that behavior for use with the VACM extension. Local data can use used with RADIUS, but typically only in a fall-back use case, for example when RADIUS is unavailable because of network problems or a server crash. > Or should the RADIUS client do something like deny > authentication of joe's session if it can't install the management > policy, or kill joe's session if it is already there (likely a > challenge to write down due to the architectural model we have, but > likely easy to implement ;-). With the caveat that this behavior could be overridden by local policy configuration, this is exactly the behavior that I would recommend. Let me quote a portion of Section 6.3 of draft-ietf-radext-management-authorization-07.txt, now in the RFC Editor Queue: The management access policy named in this attribute, received in an Access-Accept packet, MUST be applied to the session authorized by the Access-Accept. If the NAS supports this attribute, but the policy name is unknown, or if the RADIUS client is able to determine that the policy rules are incorrectly formatted, the NAS MUST treat the Access-Accept packet as if it had been an Access-Reject. This indicates to me that when present in RADIUS authorization information the policy (group name) specified in the Management-Policy-ID attribute MUST be applied faithfully, or access MUST be rejected. > My understanding is that RADIUS decisions are of the kind "here is > exactly what you do or you deny service" (RADIUS folks, please correct > me if I am wrong). You are correct. > If this is the case, simply ignoring a failure to install the > requested policy sounds kind of wrong. Agreed. > PS: Does the RADIUS client have the "rights" to modify any existing > writable matching table entries? Will it revert the changes when > the session dies? I think it needs to revert, yes. While we talk loosely of the RADIUS authorization information being used to update the VACM MIB Module in the same sense that the SNMP engine would do in response to an SNMP SET, we may be taking this too literally. I think that the RADIUS information kept by the VACM Extension should be transient, with a lifetime limited to that of the secure transport session. From d.b.nelson@comcast.net Thu Jun 11 21:22:56 2009 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 6FE4A3A6BE8 for ; Thu, 11 Jun 2009 21:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 HKxFpmlEzFHp for ; Thu, 11 Jun 2009 21:22:55 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 8C2763A6A88 for ; Thu, 11 Jun 2009 21:22:55 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA07.westchester.pa.mail.comcast.net with comcast id 2sCA1c0010ldTLk57sMz9m; Fri, 12 Jun 2009 04:21:59 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA04.westchester.pa.mail.comcast.net with comcast id 2sP31c00U4H2mdz3QsP3Ty; Fri, 12 Jun 2009 04:23:03 +0000 From: "Dave Nelson" To: References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> Date: Fri, 12 Jun 2009 00:23:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acnp6kQLntCJEWlYRvCj/boKTapkQAAC9KRAADtuRmgADApy4A== Subject: Re: [Isms] Moving into some design / architecture issues of Extended VACM 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, 12 Jun 2009 04:22:56 -0000 Kaushik writes... > The issue I have with this model is that we are using the RADIUS > user-to-group mapping which is a temporal association valid for > the duration of the session and provisioning a persistent piece of > configuration on the SNMP engine. I have the same concern. The simplicity of this concept -- populating the vacmSecurityToGroupTable with data from RADIUS -- is alluring, to be sure. It's useful for implementation, in that access control decision requests are processed using existing code, and the table's contents can be used externally for real time debugging of user access problems. I think that one implementation "trick" that could be used to have the best of both worlds would be to have a "shadow" copy of the vacmSecurityToGroupTable that appears whenever RADIUS is "in play" and disappears, revealing the statically and permanently stored version, when RADIUS is "not in play". The SNMP engine need not be concerned with which copy of the table it was accessing at any given moment. All the behaviors would be the same either way. The only difference is that we would not be mixing statically configured user-to-group information with dynamically configured user-to-group information. This may sound like an odd idea at first blush, but I think it worthy of serious consideration. From randy_presuhn@mindspring.com Fri Jun 12 00:08:52 2009 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 C0EBC3A6B81 for ; Fri, 12 Jun 2009 00:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 Fo2eVJpfoc1M for ; Fri, 12 Jun 2009 00:08:51 -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 A7BAA3A6B75 for ; Fri, 12 Jun 2009 00:08:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KSyuQtZYwDFKb/smIN2Wivb4RdaZSdFdC8I32Qj8Lv6nhKlYhopdjgrJiczyQy0E; 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 [66.167.204.148] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MF0sl-0004ZE-B0 for isms@ietf.org; Fri, 12 Jun 2009 03:08:59 -0400 Message-ID: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Fri, 12 Jun 2009 00:04:28 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968bffd4eedfad0569f37bd357c31df8469350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.204.148 Subject: Re: [Isms] Moving into some design / architecture issues of Extended VACM 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, 12 Jun 2009 07:08:52 -0000 Hi - > From: "kaushik" > To: "Dave Nelson" ; > Sent: Thursday, June 11, 2009 3:27 PM > Subject: Re: [Isms] Moving into some design / architecture issues of Extended VACM ... > The issue I have with this model is that we are using the RADIUS > user-to-group mapping which is a temporal association valid for the duration > of the session and provisioning a persistent piece of configuration on the > SNMP engine. I am not sure the semantics match and this could create > potential problems around whether the RADIUS server or SNMP engine is > authoritative source for user-to-group mapping since entries can be added to > the vacmSecurityToGroupTable without knowledge of the RADIUS server. "Authoritative source"? Whoever has the necessary access rights to update the vacmSecurityToGroupTable is authoritative, as far as VACM is concerned, and whatever the current configuration of VACM is will govern who can do what to anything via SNMP. The persistance of the information is governed by vacmSecurityToGroupStorageType. If the entry already exists, that's already been configured. If a new entry needs to be created, 'volatile' is the only type that makes sense. Forcing persistence does not make sense. I think the crucial point is whether the information coming from the RADIUS server is trusted as much as information coming from a security administrator. If it is, then updating vacmGroupName with the most recently received information makes sense. If the RADIUS server is not trusted as much as a security administrator, then information from it should not be used for making user/group mapping decisions. It does *not* make sense for the value of vacmGroupName to "revert" upon termination of the session or some other condition. Consider the operational scenario where the update of the RADIUS server is slightly out-of-phase with a VACM access control policy push. Simple update of vacmGroupName will produce the correct answer. Doing a "revert" will result in vacmGroupName being *temporarily* updated via RADIUS to the correct value, the SNMP push will walk on by, and then the "revert" will restore it to a now obsolete value. Not good, so to fix *that* you'd have to add additional state and require the push application to write to objects that would appear to already have the correct value. Yuck! This isn't netconf. This is SNMP. Let's remember what the "S" is supposed to stand for. Randy From d.b.nelson@comcast.net Fri Jun 12 03:36:52 2009 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 246093A68D5 for ; Fri, 12 Jun 2009 03:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 KzF446+PzF+8 for ; Fri, 12 Jun 2009 03:36:51 -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 F25333A6403 for ; Fri, 12 Jun 2009 03:36:50 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 2xvp1c0050QuhwU56yczD8; Fri, 12 Jun 2009 10:36:59 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA02.westchester.pa.mail.comcast.net with comcast id 2ycz1c0014H2mdz3NyczNB; Fri, 12 Jun 2009 10:36:59 +0000 From: "Dave Nelson" To: References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> Date: Fri, 12 Jun 2009 06:37:04 -0400 Message-ID: <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnrLKvJ/OBMkCbvRQup/M3drhPl+AAGbJ2g Subject: Re: [Isms] Moving into some design / architecture issues ofExtended VACM 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, 12 Jun 2009 10:36:52 -0000 Randy Presuhn writes... > "Authoritative source"? Whoever has the necessary access rights > to update the vacmSecurityToGroupTable is authoritative, as far > as VACM is concerned... That's today's model. It's not at all clear to me it should be the model going forward in a RADIUS-enabled extended VACM. > ...and whatever the current configuration of VACM is will govern > who can do what to anything via SNMP. Correct. > I think the crucial point is whether the information coming > from the RADIUS server is trusted as much as information coming > from a security administrator. Right. The use case we're talking about is one in which the "security administrator" has been effectively replaced by the RADIUS server. The notion that RADIUS authorization information is considered advisory and secondary to locally configured data is contrary to the way RADIUS is intended to be used. Local data can be used to place certain limitations on the services provisioned by RADIUS, but that's almost always in the form of limitations on the consumption of NAS resources. RADIUS servers are, generally speaking, unaware of such resource limitations in the NAS. > If the RADIUS server is not trusted as much as a security > administrator, then information from it should not be used > for making user/group mapping decisions. I'd go further. If the RADIUS server is not trusted more than the security administrator, then the I-D were talking about here is simply not applicable to the use case. Let's all go home. > Consider the operational scenario where the update of the RADIUS > server is slightly out-of-phase with a VACM access control policy > push. RADIUS needs to be in control of the user-to-group mapping. SNMP is in charge of the group-to-access-rights mapping. Neither should attempt to mind the other's business. Yes, they do need to work in concert, such that the set of group is commonly understood. Having commonly understood group names is REQUIRED to be able to use RADIUS in this fashion. From ietfdbh@comcast.net Fri Jun 12 08:38:26 2009 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 152883A6DD9 for ; Fri, 12 Jun 2009 08:38:26 -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 hTaspx8-F1Ac for ; Fri, 12 Jun 2009 08:38:25 -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 1CAD03A69FD for ; Fri, 12 Jun 2009 08:38:24 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 2xkj1c0060ldTLk553eZh9; Fri, 12 Jun 2009 15:38:33 +0000 Received: from Harrington73653 ([69.24.4.68]) by OMTA04.westchester.pa.mail.comcast.net with comcast id 33eN1c00S1U2xWl3Q3eRzh; Fri, 12 Jun 2009 15:38:31 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> Date: Fri, 12 Jun 2009 11:38:21 -0400 Message-ID: <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> 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.3198 Thread-Index: AcnrLKvJ/OBMkCbvRQup/M3drhPl+AAGbJ2gAAs9+SA= In-Reply-To: <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> Subject: Re: [Isms] Moving into some design / architecture issues ofExtendedVACM 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, 12 Jun 2009 15:38:26 -0000 > > "Authoritative source"? Whoever has the necessary access rights > > to update the vacmSecurityToGroupTable is authoritative, as far > > as VACM is concerned... > > That's today's model. It's not at all clear to me it should > be the model > going forward in a RADIUS-enabled extended VACM. > [...] > RADIUS needs to be in control of the user-to-group mapping. > SNMP is in > charge of the group-to-access-rights mapping. Neither should > attempt to > mind the other's business. Yes, they do need to work in > concert, such that > the set of group is commonly understood. Having commonly > understood group > names is REQUIRED to be able to use RADIUS in this fashion. I strongly object to a "VACM extension" that works this way. That is a totally different access control model, with different assumptions, and it shoulkd use its own MIB module. That way VACM and RADIUS-ACM models can coexust. And THAT is a key tenet of SNMPv3. dbh From d.b.nelson@comcast.net Sat Jun 13 06:40:17 2009 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 1B2873A6B7E for ; Sat, 13 Jun 2009 06:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=-0.843, 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 r-3DsyeAe3AO for ; Sat, 13 Jun 2009 06:40:16 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 39F8C3A6B78 for ; Sat, 13 Jun 2009 06:40:15 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 3RAd1c0060QuhwU5BRgRw9; Sat, 13 Jun 2009 13:40:25 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA02.westchester.pa.mail.comcast.net with comcast id 3RgR1c0024H2mdz3NRgRRZ; Sat, 13 Jun 2009 13:40:25 +0000 From: "Dave Nelson" To: References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> Date: Sat, 13 Jun 2009 09:40:32 -0400 Message-ID: <4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnrLKvJ/OBMkCbvRQup/M3drhPl+AAGbJ2gAAs9+SAALhHm8A== Subject: Re: [Isms] Moving into some design / architecture issues of ExtendedVACM 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: Sat, 13 Jun 2009 13:40:17 -0000 (This me be a duplicate reply.) David Harrington writes... > I strongly object to a "VACM extension" that works this way. > That is a totally different access control model, with different > assumptions, and it shoulkd use its own MIB module. > > That way VACM and RADIUS-ACM models can coexust. > And THAT is a key tenet of SNMPv3. Didn't we previously consider creating a completely new ACM for usage with RADIUS and then dismiss that option, because of an "issue" with the architecture that precludes a practical method of selecting an ACM at run time? I could probably find that thread if I searched through the archives. As I recall, some asserted that adding another ACM would require us to perform some "maintenance" on the SNMPv3 and/or ASIs such that the ACM could be selected on a per packet basis. From j.schoenwaelder@jacobs-university.de Sat Jun 13 07:24:01 2009 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 ACF4B3A6B99 for ; Sat, 13 Jun 2009 07:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.032, 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 e6JwIRp9XuQh for ; Sat, 13 Jun 2009 07:24:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7CE593A6BAB for ; Sat, 13 Jun 2009 07:24:00 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90F44C005A; Sat, 13 Jun 2009 16:24:08 +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 H8baO1Oj9z8h; Sat, 13 Jun 2009 16:24:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6745CC0065; Sat, 13 Jun 2009 16:24:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E013B41045; Sat, 13 Jun 2009 16:24:05 +0200 (CEST) Date: Sat, 13 Jun 2009 16:24:05 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090613142405.GA3493@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> <4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design / architecture issues of ExtendedVACM 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, 13 Jun 2009 14:24:01 -0000 On Sat, Jun 13, 2009 at 03:40:32PM +0200, Dave Nelson wrote: > (This me be a duplicate reply.) > > David Harrington writes... > > > I strongly object to a "VACM extension" that works this way. > > That is a totally different access control model, with different > > assumptions, and it shoulkd use its own MIB module. > > > > That way VACM and RADIUS-ACM models can coexust. > > And THAT is a key tenet of SNMPv3. > > Didn't we previously consider creating a completely new ACM for usage with > RADIUS and then dismiss that option, because of an "issue" with the > architecture that precludes a practical method of selecting an ACM at run > time? Indeed, the SNMPv3 specs do not define a way to select the ACM responsible for a given message. Since so far has only been one ACM (VACM), we all live happily with this. From this perspective, it is attractive to use VACM unmodified. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Sat Jun 13 09:30:49 2009 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 3815A3A6C01 for ; Sat, 13 Jun 2009 09:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 1D0QcDgr9BNJ for ; Sat, 13 Jun 2009 09:30:48 -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 3E4B93A63EC for ; Sat, 13 Jun 2009 09:30:47 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA10.westchester.pa.mail.comcast.net with comcast id 3SFA1c0020SCNGk5AUWw1c; Sat, 13 Jun 2009 16:30:56 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 3UWw1c0044H2mdz3VUWwpX; Sat, 13 Jun 2009 16:30:56 +0000 From: "Dave Nelson" To: References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> <4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603> <20090613142405.GA3493@elstar.local> Date: Sat, 13 Jun 2009 12:31:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090613142405.GA3493@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnsMqD5U10RrXcLRWSy7BFOIJrFRwADqWgg Subject: Re: [Isms] Moving into some design / architecture issues ofExtendedVACM 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: Sat, 13 Jun 2009 16:30:49 -0000 Juergen Schoenwaelder writes... > Indeed, the SNMPv3 specs do not define a way to select the ACM > responsible for a given message. Since so far has only been one ACM > (VACM), we all live happily with this. From this perspective, it is > attractive to use VACM unmodified. Well, yes, but adding new functionality and refraining from modification are often incompatible goals. :-) I suppose, one could posit an architecture in which some glue code is added, in the form of a local SNMP application that has an interface to RADIUS and has write access to the VACM's MIB tables. RADIUS then looks like an odd form of system administrator, tinkering with the security objects. The problem, as I see it, is that some of the rules for VACM MIB object usage conflict with traditional RADIUS service provisioning practice. I don't want to offend any of the long time SNMP experts, but this seems to me just one more case where the RFC 3114 SNMP architecture is modular as long as you never consider options that weren't considered during its formulation, such as providing SNMP packet security outside of the Security Subsystem. This may be another case where we need to be willing to think "outside the box". I agree that we seem to be limited to two options: (a) Extend VACM so that it's RADIUS (or generically AAA) aware. (b) Add a new SNMP application that takes counsel from RADIUS and modifies the VACM's MIB objects, as if it were an external security administrator. I'm concerned that if we take the (b) approach, we'll have an interesting time addressing (or blithely ignoring) corner cases and security risks. This approach is vastly simple on one level -- it does not touch existing VACM code. However it's highly complex on another level -- the RADIUS provisioning model seems to have conflicts with the VACM provisioning model. One issue that we need to resolve is "Who's in charge?". It is reasonable to use authorization information on a mix-and-match basis from two distinct, and perhaps non-coordinated, entities? I've previously posted my reasoning, based in the RADIUS NAS-Management I-D text, why it's simply unacceptable for RADIUS-provisioned access control to be ignored, e.g. because of a locally configured user-to-group that conflicts. I would characterize RADIUS as an "It's my way or the highway." type of protocol. If the NAS can't faithfully provision service as RADIUS has specified it, the NAS must reject access altogether. From j.schoenwaelder@jacobs-university.de Sat Jun 13 10:13:46 2009 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 CF4B73A6C1A for ; Sat, 13 Jun 2009 10:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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 C68htS2iBoiY for ; Sat, 13 Jun 2009 10:13:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id DCCA33A6BE6 for ; Sat, 13 Jun 2009 10:13:45 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89B4EC0067; Sat, 13 Jun 2009 19:13:54 +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 OR3s-7jAMOcE; Sat, 13 Jun 2009 19:13:53 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61F3AC0065; Sat, 13 Jun 2009 19:13:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 25470B4127C; Sat, 13 Jun 2009 19:13:52 +0200 (CEST) Date: Sat, 13 Jun 2009 19:13:52 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090613171352.GA3610@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> <4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603> <20090613142405.GA3493@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design / architecture issues ofExtendedVACM 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, 13 Jun 2009 17:13:46 -0000 On Sat, Jun 13, 2009 at 06:31:03PM +0200, Dave Nelson wrote: > I agree that we seem to be limited to two options: > > (a) Extend VACM so that it's RADIUS (or generically AAA) aware. > > (b) Add a new SNMP application that takes counsel from RADIUS and modifies > the VACM's MIB objects, as if it were an external security administrator. Well, (b) is not really an option - as long as you mean "application" in the RFC3411 sense. What we have as an option is this: (c) Fix the RFC3411 architecture so that is supports multiple access control models and then write a RADIUS access control model. My concern is that we won't get this done easily and it will take one year longer than we are planning this WG to continue. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Sat Jun 13 10:19:59 2009 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 6D9B83A690C for ; Sat, 13 Jun 2009 10:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=-1.093, 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 2-QEx0o9isve for ; Sat, 13 Jun 2009 10:19:58 -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 D3A1E3A6807 for ; Sat, 13 Jun 2009 10:19:55 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 3UET1c0020vyq2s59VL5eU; Sat, 13 Jun 2009 17:20:05 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA05.westchester.pa.mail.comcast.net with comcast id 3VL51c00B4H2mdz3RVL55T; Sat, 13 Jun 2009 17:20:05 +0000 From: "Dave Nelson" To: References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer><438E7CA1B8E64074865BDD873BD0ED30@NEWTON603><012e01c9eb73$d61b0070$0600a8c0@china.huawei.com><4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603><20090613142405.GA3493@elstar.local> Date: Sat, 13 Jun 2009 13:20:12 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnsMqD5U10RrXcLRWSy7BFOIJrFRwADqWggAAJheiA= Subject: Re: [Isms] Moving into some design / architecture issues of ExtendedVACM 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: Sat, 13 Jun 2009 17:19:59 -0000 Or course, there *are* some models of disparate authentication systems used in a precedence relationship. For example, consider NIS and /etc/passed as used for UNIX login. The key is that there *is* a precedence relation, and you won't find NIS populating /etc/passwd with user entries. From d.b.nelson@comcast.net Sat Jun 13 10:25:02 2009 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 D376C3A6B11 for ; Sat, 13 Jun 2009 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 axdaQ4vKb4eI for ; Sat, 13 Jun 2009 10:25:02 -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 D38553A690C for ; Sat, 13 Jun 2009 10:25:01 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 3Q3l1c00217dt5G55VRBuo; Sat, 13 Jun 2009 17:25:11 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 3VRA1c00H4H2mdz3ZVRBFF; Sat, 13 Jun 2009 17:25:11 +0000 From: "Dave Nelson" To: References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> <4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603> <20090613142405.GA3493@elstar.local> <20090613171352.GA3610@elstar.local> Date: Sat, 13 Jun 2009 13:25:17 -0400 Message-ID: <122206154B8C4697BE2F966801EB29EF@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090613171352.GA3610@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnsSlaE8IzlEwoBTni0EpVAY/nNuAAAQtqw Subject: Re: [Isms] Moving into some design / architecture issuesofExtendedVACM 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: Sat, 13 Jun 2009 17:25:02 -0000 Juergen Schoenwaelder writes... > Well, (b) is not really an option - as long as you mean "application" > in the RFC3411 sense. You're probably right. An SNMP application won't have the right hooks into the "session creation" process. > What we have as an option is this: > > (c) Fix the RFC3411 architecture so that is supports multiple access > control models and then write a RADIUS access control model. > > My concern is that we won't get this done easily and it will take one > year longer than we are planning this WG to continue. Yeah. That would be the "right thing" to do. The question is whether there is support in the Internet community to undertake that effort and whether the result would be worth the effort. I'm thinking that quick is good. So, is option (a) still on the table? From d.b.nelson@comcast.net Sat Jun 13 11:30:01 2009 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 C3D233A6C27 for ; Sat, 13 Jun 2009 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 CuZdwrysg+nt for ; Sat, 13 Jun 2009 11:30:01 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id BDCCB3A6BC7 for ; Sat, 13 Jun 2009 11:30:00 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 3SRv1c00617dt5G54WWAwe; Sat, 13 Jun 2009 18:30:10 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 3WW91c00X4H2mdz3ZWWAMm; Sat, 13 Jun 2009 18:30:10 +0000 From: "Dave Nelson" To: Date: Sat, 13 Jun 2009 14:30:16 -0400 Message-ID: <05F78AE1AAD94D7186CD6228374C3998@NEWTON603> 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.5579 Thread-Index: AcnsVP+iNx72aX+oQyygiWTlJvbHNg== Subject: [Isms] Further ACM design discussions 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: Sat, 13 Jun 2009 18:30:01 -0000 While we're wrestling with modularity issues, I need to bring up an old discussion regarding modularity vs. identity bindings. We want the Access Control Subsystem to be independent of all other subsystems, except for the information passed explicitly in ASIs or implicitly via "caches". Very good. The question I want to pose is what's the relationship between the authenticated identity associated with the Transport Subsystem's protected session, and the securityName passed into the Access Control Subsystem? We had a debate about whether an authorization service ought to be separate from an authentication service -- Jeff -- but we know that RADIUS was not designed with that separation in mind. In fact, RADIUS authorization is always tied to RADIUS authentication, either directly or indirectly. How does the RADIUS data access control information, e.g. Management-Policy-ID, get to the place where it's needed? Does the RADIUS client pass that information up through PAM to the SSH server and hence to SSHTM, which stashes it in a "cache" that some VACM-related function can later access? Or do we expect that the ACM will somehow cause a second RADIUS exchange to occur? What happens if there is a name-mapping that occurs between the time a Username Attribute is sent in a RADIUS Access-Request message and securityName is presented to an Access Control Model? It seems to me that the data access control information provided by RADIUS is bound to the Username in the Access-Request, and for correct operation the securityName presented to the ACM must be similarly bound to the RADIUS-authenticated identity. I need to go back and read our I-Ds, now in the RFC Editor Queue, to refresh my memory, but I recall all sorts of debate on this list about name mappings and translations that might occur between what happens in RADIUS and what happens in ACM. From dnelson@elbrysnetworks.com Sat Jun 13 14:04:32 2009 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 F11373A6C0E for ; Sat, 13 Jun 2009 14:04:32 -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 TU46XQjvBuzy for ; Sat, 13 Jun 2009 14:04:32 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 159FD3A6A31 for ; Sat, 13 Jun 2009 14:04:31 -0700 (PDT) Received: (qmail 3225 invoked from network); 12 Jun 2009 12:37:58 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 12 Jun 2009 12:37:58 -0400 From: "David B. Nelson" To: References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer><438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> Date: Fri, 12 Jun 2009 12:38:01 -0400 Organization: Elbrys Networks, Inc. Message-ID: <90BD8933312E42D8AAB617B16B1BA580@xpsuperdvd2> 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.5579 Thread-Index: AcnrLKvJ/OBMkCbvRQup/M3drhPl+AAGbJ2gAAs9+SAAAgYlIA== In-Reply-To: <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> Subject: Re: [Isms] Moving into some design / architecture issues of ExtendedVACM 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: Sat, 13 Jun 2009 21:04:33 -0000 David Harrington writes... > I strongly object to a "VACM extension" that works this way. > That is a totally different access control model, with different > assumptions, and it should use its own MIB module. > > That way VACM and RADIUS-ACM models can coexist. > And THAT is a key tenet of SNMPv3. Didn't we already consider having a completely new ACM for RADIUS usage and dismiss that option because of some "issue" with the architecture that precludes a practical run-time selection mechanism for the ACM? (This message probably won't make it to the mailing list until late tonight or early tomorrow. We're still having mail server issues.) From randy_presuhn@mindspring.com Sat Jun 13 21:53:23 2009 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 302BD3A6BFB for ; Sat, 13 Jun 2009 21:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 e5HhzQPPqrEM for ; Sat, 13 Jun 2009 21:53:22 -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 DD6C23A68EE for ; Sat, 13 Jun 2009 21:53:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SsHkqyY/OsH3iamHO+v1cY5dSbN5wSb+cCaV+UdTjFR/MtQmZ37OcV36GyvLrRhP; 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 [68.166.189.204] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MFhik-00057R-Rq for isms@ietf.org; Sun, 14 Jun 2009 00:53:31 -0400 Message-ID: <002401c9ecac$1b128b60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer><438E7CA1B8E64074865BDD873BD0ED30@NEWTON603><012e01c9eb73$d61b0070$0600a8c0@china.huawei.com><4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603><20090613142405.GA3493@elstar.local> Date: Sat, 13 Jun 2009 21:53:47 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696850c83f394c0989ae268833322caaa1b1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.204 Subject: Re: [Isms] Moving into some design / architecture issuesofExtendedVACM 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: Sun, 14 Jun 2009 04:53:23 -0000 Hi - > From: "Dave Nelson" > To: > Sent: Saturday, June 13, 2009 9:31 AM > Subject: Re: [Isms] Moving into some design / architecture issuesofExtendedVACM ... > I agree that we seem to be limited to two options: > > (a) Extend VACM so that it's RADIUS (or generically AAA) aware. > > (b) Add a new SNMP application that takes counsel from RADIUS and modifies > the VACM's MIB objects, as if it were an external security administrator. In my opinion, (b) will bring completion with the least risk and the greatest degree of operational interoperability with deployed management systems. > I'm concerned that if we take the (b) approach, we'll have an interesting > time addressing (or blithely ignoring) corner cases and security risks. So far, even the corner cases look incredibly straightforward. It's only when people try to get fancy (ignore the "S" in SNMP) that it looks like they'll wrap themselves around the axle. I'd argue that the "corner cases" in (b) will be much easier to enumerate and analyze that if we create something brand new that operates differently in any way from classic VACM. > This approach is vastly simple on one level -- it does not touch existing > VACM code. However it's highly complex on another level -- the RADIUS > provisioning model seems to have conflicts with the VACM provisioning model. Perhaps, but i think that if it look at it from one level above that, the level of the enterprise-wide security administrator, those "conflicts" are only transients that result when the push of a security policy update gets slightly out-of-phase with RADIUS. The good news is that the situation is self-healing, *if* you take the simple approach and don't try to make things fancy. > One issue that we need to resolve is "Who's in charge?". It is reasonable > to use authorization information on a mix-and-match basis from two distinct, > and perhaps non-coordinated, entities? It depends on how you read "non-coordinated." If you mean "not necessarily operating in lock step as policy updates are propagated", I think you have to take it as a given, and it's not a problem if you handle the updates as I've outlined earlier in this thread. If you mean "not converging to the same security policy", then you've got a much bigger problem, since you've granted both of them access rights to change the security policy on the managed device. > I've previously posted my reasoning, based in the RADIUS NAS-Management I-D > text, why it's simply unacceptable for RADIUS-provisioned access control to > be ignored, e.g. because of a locally configured user-to-group that > conflicts. I don't think anyone is arguing for that. The sole case I can see in which the RADIUS-supplied user-to-group mapping should be ignored is when the value of the corresponding vacmSecurityToGroupStorageType is 'readOnly', meaning it's in ROM and would not be changeable under any circumstances by any security administrator. > I would characterize RADIUS as an "It's my way or the highway." > type of protocol. If the NAS can't faithfully provision service as RADIUS > has specified it, the NAS must reject access altogether. Perhaps, though handling this corner case in this way would mean that if your network had a mix of systems with dynamic and "ROMmed" entries for some user (e.g. "root"), and they did not all have the same ROM group name for this user, then you would have to turn RADIUS off in order to access the systems for which that user had a ROM entry. To me, that cure sounds substantially worse than the disease. Randy From randy_presuhn@mindspring.com Sat Jun 13 21:59:01 2009 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 86A943A6BED for ; Sat, 13 Jun 2009 21:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 4HMPikflFwSf for ; Sat, 13 Jun 2009 21:59:00 -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 A7AB93A684C for ; Sat, 13 Jun 2009 21:59:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DLcPQXnG035yqj+XEJla930fvqFNhasZGyyu36K3KzTGtocyDn8AuVpD5xyzCInz; 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 [68.166.188.72] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MFhoD-0004Ag-W8 for isms@ietf.org; Sun, 14 Jun 2009 00:59:10 -0400 Message-ID: <002d01c9ecac$e5fc0a40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer><438E7CA1B8E64074865BDD873BD0ED30@NEWTON603><012e01c9eb73$d61b0070$0600a8c0@china.huawei.com><4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603><20090613142405.GA3493@elstar.local> <20090613171352.GA3610@elstar.local> Date: Sat, 13 Jun 2009 21:58:15 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69689c7cbb938550475997f6500cfb929a9a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.72 Subject: Re: [Isms] Moving into some design / architectureissues ofExtendedVACM 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: Sun, 14 Jun 2009 04:59:01 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Dave Nelson" > Cc: > Sent: Saturday, June 13, 2009 10:13 AM > Subject: Re: [Isms] Moving into some design / architectureissues ofExtendedVACM ... > > (b) Add a new SNMP application that takes counsel from RADIUS and modifies > > the VACM's MIB objects, as if it were an external security administrator. > > Well, (b) is not really an option - as long as you mean "application" > in the RFC3411 sense. Of course, I'm using it in a *much* looser sense. One *could* think of it as using the ASIs to access the corresponding instrumentation, or as reaching into the vacmSecurityToGroupTable directly. The important part is the understanding that it's acting on behalf of the security administrator. Randy From j.schoenwaelder@jacobs-university.de Sun Jun 14 06:12:27 2009 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 06B453A6C95 for ; Sun, 14 Jun 2009 06:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 g42eIyh1zYCH for ; Sun, 14 Jun 2009 06:12:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E63113A6C93 for ; Sun, 14 Jun 2009 06:12:25 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E564C005D; Sun, 14 Jun 2009 15:12:34 +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 eISWG0A+WEYP; Sun, 14 Jun 2009 15:12:33 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F143C005A; Sun, 14 Jun 2009 15:12:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A7FF9B41A25; Sun, 14 Jun 2009 15:12:31 +0200 (CEST) Date: Sun, 14 Jun 2009 15:12:31 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090614131231.GD4106@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> <438E7CA1B8E64074865BDD873BD0ED30@NEWTON603> <012e01c9eb73$d61b0070$0600a8c0@china.huawei.com> <4BF4B32A4D874F37A7FA2F68643F2322@NEWTON603> <20090613142405.GA3493@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design / architecture issues of ExtendedVACM 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, 14 Jun 2009 13:12:27 -0000 On Sat, Jun 13, 2009 at 07:20:12PM +0200, Dave Nelson wrote: > Or course, there *are* some models of disparate authentication systems used > in a precedence relationship. For example, consider NIS and /etc/passed as > used for UNIX login. The key is that there *is* a precedence relation, and > you won't find NIS populating /etc/passwd with user entries. SNMPv3 currently does not have this for authentication and it does not have this for authorization. To fix the multiple ACM issue, one would have to extend the SNMPv3 infrastructure with a table that controls how multiple ACMs each implementing the isAccessAllowed() ASI would work together. One option is of course to have priorities. If we would have something like this, we could have a RADIUS VACM MIB module which provides a security name to group name mapping based on RADIUS policy information and otherwise reuse VACM access rules. Then the new ACM control table would allow me to specify whether RADIUS takes precedence or not and I can have my fallback config in the VACM MIB that is being used when RADIUS fails. This might be the cleanest solution. But getting this right does require some great deal of help of some SNMPv3 seniors... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kaushik@cisco.com Mon Jun 15 17:33:24 2009 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 CAF7A3A6D30 for ; Mon, 15 Jun 2009 17:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 yEIW7h2e8-HN for ; Mon, 15 Jun 2009 17:33:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 070473A6D2C for ; Mon, 15 Jun 2009 17:33:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,225,1243814400"; d="scan'208";a="176631337" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2009 00:33:34 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5G0XYMU032082; Mon, 15 Jun 2009 17:33:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5G0XYJi024863; Tue, 16 Jun 2009 00:33:34 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 17:33:34 -0700 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Jun 2009 00:33:34 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 15 Jun 2009 17:33:25 -0700 From: kaushik To: Juergen Schoenwaelder , Dave Nelson Message-ID: Thread-Topic: [Isms] Moving into some design / architecture issues of ExtendedVACM Thread-Index: AcnuGg9MJxczCLBev0uf3kKaeOlnYQ== In-Reply-To: <20090614131231.GD4106@elstar.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 00:33:34.0634 (UTC) FILETIME=[150A80A0:01C9EE1A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1594; t=1245112414; x=1245976414; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Isms]=20Moving=20into=20some=20design= 20/=20architecture=20issues=20of=0A=20ExtendedVACM |Sender:=20; bh=x5rmNwB4ob/ccuKmE6p16rx7WMdKvY30lPnc/EMwgpI=; b=drw1NiupskKCCmYNt+LHyGu2I31jZV2ReiZp4FHAnr4FRjWEwheI8WpgtR a5dPdiGwexFFUvR6390deKNiMlbaoRMm/Ff9m4SP+E0PIltFCNDHrrrRMWMa OEiDPGdXJA; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design / architecture issues of ExtendedVACM 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, 16 Jun 2009 00:33:24 -0000 Hi Juergen, I like the approach you have proposed to have the RADIUS user-to-group mappings and VACM user-to-group mappings in separate tables and have a control table to decide precedence. Regards, kaushik On 6/14/09 6:12 AM, "Juergen Schoenwaelder" wrote: > On Sat, Jun 13, 2009 at 07:20:12PM +0200, Dave Nelson wrote: > >> Or course, there *are* some models of disparate authentication systems used >> in a precedence relationship. For example, consider NIS and /etc/passed as >> used for UNIX login. The key is that there *is* a precedence relation, and >> you won't find NIS populating /etc/passwd with user entries. > > SNMPv3 currently does not have this for authentication and it does not > have this for authorization. To fix the multiple ACM issue, one would > have to extend the SNMPv3 infrastructure with a table that controls > how multiple ACMs each implementing the isAccessAllowed() ASI would > work together. One option is of course to have priorities. If we would > have something like this, we could have a RADIUS VACM MIB module which > provides a security name to group name mapping based on RADIUS policy > information and otherwise reuse VACM access rules. Then the new ACM > control table would allow me to specify whether RADIUS takes > precedence or not and I can have my fallback config in the VACM MIB > that is being used when RADIUS fails. > > This might be the cleanest solution. But getting this right does > require some great deal of help of some SNMPv3 seniors... > > /js From randy_presuhn@mindspring.com Mon Jun 15 17:42:58 2009 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 724CD3A6A44 for ; Mon, 15 Jun 2009 17:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 MryAoZqXGfKl for ; Mon, 15 Jun 2009 17:42:57 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 9A23E3A6A3B for ; Mon, 15 Jun 2009 17:42:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JfzrlyJp+4N6RZSd54+Z/9Ad4RGdWqvCkhao5Q/tQ7IKrPkmeuIK29vcuohG8oOh; 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.5.20] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MGMlI-0001Ki-Sp for isms@ietf.org; Mon, 15 Jun 2009 20:42:53 -0400 Message-ID: <002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local> <0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603> Date: Mon, 15 Jun 2009 17:43:14 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968d1758664fa8a0200be2bebbd591fc9f2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.20 Subject: Re: [Isms] Moving into some design/architecture issues ofExtendedVACM 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, 16 Jun 2009 00:42:58 -0000 Hi - > From: "Dave Nelson" > To: > Sent: Thursday, June 11, 2009 8:54 PM > Subject: Re: [Isms] Moving into some design/architecture issues ofExtendedVACM ... > > PS: Does the RADIUS client have the "rights" to modify any existing > > writable matching table entries? Will it revert the changes when > > the session dies? > > I think it needs to revert, yes. > > While we talk loosely of the RADIUS authorization information being used to > update the VACM MIB Module in the same sense that the SNMP engine would do > in response to an SNMP SET, we may be taking this too literally. I think > that the RADIUS information kept by the VACM Extension should be transient, > with a lifetime limited to that of the secure transport session. ... Repeating myself: this would interact badly with security policy updates. It is much safer for changes to vacmGroupName in a vacmSecurityToGroupEntry to behave just like they would if they had been set. If they can "revert", then an entry which appeared to be up-to-date when inspected by a security administrator could silently become not-up-to-date because a secure transport session ended. This would make a hash of security policy configuration management. Simple really is preferable here. It's less work for the implementor, both of management applications and in the guts of the SNMP implementation. It's less work for the security administrator. And it would be a lot simpler for this WG. Randy From randy_presuhn@mindspring.com Mon Jun 15 17:53:24 2009 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 5374C3A6A01 for ; Mon, 15 Jun 2009 17:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 8F6XhjSEGflW for ; Mon, 15 Jun 2009 17:53:23 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 556213A6A0D for ; Mon, 15 Jun 2009 17:53:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HS+4yF0cJtQqQiHSBbdTxXkdgB5nCe1ScB56YfMVTgC3DrV6+ofoar8NbSuW7l6A; 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.5.20] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MGMvd-00058C-Rl for isms@ietf.org; Mon, 15 Jun 2009 20:53:34 -0400 Message-ID: <002a01c9ee1c$eeb36900$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> Date: Mon, 15 Jun 2009 17:53:57 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696876e36843e4a0b387b4b58eb1f6701b5a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.20 Subject: Re: [Isms] Moving into some design / architecture issues ofExtended VACM 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, 16 Jun 2009 00:53:24 -0000 Hi - > From: "Dave Nelson" > To: > Sent: Thursday, June 11, 2009 9:23 PM > Subject: Re: [Isms] Moving into some design / architecture issues ofExtended VACM > > Kaushik writes... > > > The issue I have with this model is that we are using the RADIUS > > user-to-group mapping which is a temporal association valid for > > the duration of the session and provisioning a persistent piece of > > configuration on the SNMP engine. > > I have the same concern. The simplicity of this concept -- populating the > vacmSecurityToGroupTable with data from RADIUS -- is alluring, to be sure. > It's useful for implementation, in that access control decision requests are > processed using existing code, and the table's contents can be used > externally for real time debugging of user access problems. > > I think that one implementation "trick" that could be used to have the best > of both worlds would be to have a "shadow" copy of the > vacmSecurityToGroupTable that appears whenever RADIUS is "in play" and > disappears, revealing the statically and permanently stored version, when > RADIUS is "not in play". The SNMP engine need not be concerned with which > copy of the table it was accessing at any given moment. All the behaviors > would be the same either way. The only difference is that we would not be > mixing statically configured user-to-group information with dynamically > configured user-to-group information. > > This may sound like an odd idea at first blush, but I think it worthy of > serious consideration. I think it has a real problem from the perspective of security configuration management. A security administrator should be able to find out how a system's security policy is configured, regardless of whether RADIUS is in use. This means the "shadow" table would need to be visible to management. However, the security administrator should also be able to configure and update the "real" VACM configuration whether RADIUS is in use at the moment or not. This means that "write" operations would need to affect both the shadow and the "real" configuration. However, to determine whether the "real" configuration is in need of update, it must be possible for the administrator to retrieve it. This conflict is irreconcilable. To kluge around it, I think you'd have to use a separate SNMP context for the shadow. This is just too ugly and convoluted a thing to do for no real benefit, particularly since it would require standardizing a context name for this kluge. Randy From d.b.nelson@comcast.net Mon Jun 15 20:26:46 2009 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 36CAA3A6D19 for ; Mon, 15 Jun 2009 20:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 orS2T9ERNhv3 for ; Mon, 15 Jun 2009 20:26:45 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id D4CCC3A6AD1 for ; Mon, 15 Jun 2009 20:26:44 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 4R1c1c0050mlR8UA2TSvVH; Tue, 16 Jun 2009 03:26:55 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id 4TSu1c0014H2mdz8XTSuzR; Tue, 16 Jun 2009 03:26:55 +0000 From: "Dave Nelson" To: References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603> <002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> Date: Mon, 15 Jun 2009 23:26:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnuG23GZ8w81WbZRj6nrWVsXARJnwAFUYcg Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 03:26:46 -0000 Randy Presuhn writes... > Repeating myself: this would interact badly with security policy > updates. It is much safer for changes to vacmGroupName in a > vacmSecurityToGroupEntry to behave just like they would if they > had been set. I think we're talking at cross purposes. You seem to be talking about maintaining consistency between RADIUS usage and manual security administration. IIRC, the whole premise of the ISMS work is that many operators feel that SNMPv3 security is simply too complicated to deploy. So they don't. They want something ties into their existing infrastructure. We're talking about two different audiences, those who like SNMPv3 security and use it as defined today and those who don't. The ISMS work address the "those who don't" audience. I think, by definition, there aren't any operational conflicts to be resolved. Beyond that, I think you need to seriously consider other examples of how local, static authentication and authorization is integrated with remote, dynamic authentication and authorization. There are precedents. The UNIX login usage (NIS vs. /etc/passed file) is just one. I too am repeating myself, and it seems that we simply look at this problem very differently. From j.schoenwaelder@jacobs-university.de Mon Jun 15 22:01:49 2009 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 8CFD13A6A05 for ; Mon, 15 Jun 2009 22:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.026, 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 gWBzd0FyzZGi for ; Mon, 15 Jun 2009 22:01:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6067B3A6805 for ; Mon, 15 Jun 2009 22:01:48 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B201AC007E; Tue, 16 Jun 2009 07:01:58 +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 mLuNCzeuHNBf; Tue, 16 Jun 2009 07:01:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 591C6C0003; Tue, 16 Jun 2009 07:01:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4A01AB43920; Tue, 16 Jun 2009 07:01:56 +0200 (CEST) Date: Tue, 16 Jun 2009 07:01:56 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20090616050156.GA6629@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> <20090611171411.GA388@elstar.local> <003b01c9ead6$e8e08920$6801a8c0@oemcomputer> <20090611225732.GA840@elstar.local> <0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603> <002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design/architecture issues ofExtendedVACM 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, 16 Jun 2009 05:01:49 -0000 On Tue, Jun 16, 2009 at 02:43:14AM +0200, Randy Presuhn wrote: > Hi - > > > From: "Dave Nelson" > > To: > > Sent: Thursday, June 11, 2009 8:54 PM > > Subject: Re: [Isms] Moving into some design/architecture issues ofExtendedVACM > ... > > > PS: Does the RADIUS client have the "rights" to modify any existing > > > writable matching table entries? Will it revert the changes when > > > the session dies? > > > > I think it needs to revert, yes. > > > > While we talk loosely of the RADIUS authorization information being used to > > update the VACM MIB Module in the same sense that the SNMP engine would do > > in response to an SNMP SET, we may be taking this too literally. I think > > that the RADIUS information kept by the VACM Extension should be transient, > > with a lifetime limited to that of the secure transport session. > ... > > Repeating myself: this would interact badly with security policy updates. > It is much safer for changes to vacmGroupName in a vacmSecurityToGroupEntry > to behave just like they would if they had been set. If they can "revert", then an entry > which appeared to be up-to-date when inspected by a security administrator could > silently become not-up-to-date because a secure transport session ended. > This would make a hash of security policy configuration management. > > Simple really is preferable here. It's less work for the implementor, > both of management applications and in the guts of the SNMP implementation. > It's less work for the security administrator. And it would be a lot simpler > for this WG. Randy, you have the same probem if I as the security administrator change the VACM table and then RADIUS comes in and simply changes what I have carefully configured. I tend to agree with Dave Nelson that having a single table modified by two different entities is likely asking for trouble. You might argue that the problem is really the conflict between RADIUS policy and the security administrator's policy. My counter argument to that is that if both would be in fine synchrony, we would not need the RADIUS interface in the first place. /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 Mon Jun 15 22:07:07 2009 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 929E93A6830 for ; Mon, 15 Jun 2009 22:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.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 Eak4Mei142uh for ; Mon, 15 Jun 2009 22:07:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 77A833A6805 for ; Mon, 15 Jun 2009 22:07:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC4A4C007E; Tue, 16 Jun 2009 07:07:16 +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 6kDMIlLzL67W; Tue, 16 Jun 2009 07:07:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC257C0003; Tue, 16 Jun 2009 07:07:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BFBA0B43968; Tue, 16 Jun 2009 07:07:14 +0200 (CEST) Date: Tue, 16 Jun 2009 07:07:14 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20090616050714.GB6629@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <002a01c9ee1c$eeb36900$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002a01c9ee1c$eeb36900$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design / architecture issues ofExtended VACM 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, 16 Jun 2009 05:07:07 -0000 On Tue, Jun 16, 2009 at 02:53:57AM +0200, Randy Presuhn wrote: > > I think it has a real problem from the perspective of security configuration > management. A security administrator should be able to find out how > a system's security policy is configured, regardless of whether RADIUS > is in use. This means the "shadow" table would need to be visible to > management. However, the security administrator should also be able > to configure and update the "real" VACM configuration whether RADIUS > is in use at the moment or not. This means that "write" operations > would need to affect both the shadow and the "real" configuration. > However, to determine whether the "real" configuration is in need of > update, it must be possible for the administrator to retrieve it. This > conflict is irreconcilable. > > To kluge around it, I think you'd have to use a separate SNMP context for the > shadow. This is just too ugly and convoluted a thing to do for no real > benefit, particularly since it would require standardizing a context name > for this kluge. I do not think you need to mess around with contexts. If we can make multiple ACMs to work, the problem has a solution. /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 Jun 15 22:33:59 2009 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 1E13B3A685F for ; Mon, 15 Jun 2009 22:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uwgqXPVhySJh for ; Mon, 15 Jun 2009 22:33:58 -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 264693A6830 for ; Mon, 15 Jun 2009 22:33:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gMPem0caebT3enkl5nbWiThnsgUnm5YlohkoF8Rpq/Jt6hz+ukkmffx3pli18bVC; 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.190] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MGRJA-00043v-N6 for isms@ietf.org; Tue, 16 Jun 2009 01:34:08 -0400 Message-ID: <000401c9ee44$1f2d0240$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer> <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> <20090611171411.GA388@elstar.local> <003b01c9ead6$e8e08920$6801a8c0@oemcomputer> <20090611225732.GA840@elstar.local> <0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603> <002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> <20090616050156.GA6629@elstar.local> Date: Mon, 15 Jun 2009 22:34:27 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696855b20de6474c32d7ba178f9bae3148aa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.190 Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 05:33:59 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Monday, June 15, 2009 10:01 PM > Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM ... > you have the same probem if I as the security administrator change the > VACM table and then RADIUS comes in and simply changes what I have > carefully configured. I don't think this is operationally a problem. As a matter of sanity, we have to assume that what the security administrator tells RADIUS to do is the same as what he wants the SNMP-alone policy to be. If they're at odds, he's got a bigger problem than we can solve here. So the cases we need to worry about are those where SNMP and RADIUS policy updates get out of phase. The case you describe is the worst case that can happen with a sane adminstrator, so it's worth exploring. Consider what a security administrator needs to do to effect a policy change: (1) he needs to tell the RADIUS servers about the change (2) he needs to tell the SNMP management infrastructure about the change (1) is going to generally propagate faster than (2), particularly since (2) isn't complete until ever single managed device in the administrative domain has been updated. Even in the case that (2) happens for some node before the RADIUS servers are notified of the policy change, it will "heal" when the RADIUS server is finally updated and that user needs access again. Furthermore, this behaviour is in line with the "RADIUS is always definitive" philosophy folks have been arguing for. This worst-case scenario is still more desirable than the failure mode I described with the proposed "revert" behaviour. > I tend to agree with Dave Nelson that having a > single table modified by two different entities is likely asking for > trouble. You might argue that the problem is really the conflict > between RADIUS policy and the security administrator's policy. My > counter argument to that is that if both would be in fine synchrony, > we would not need the RADIUS interface in the first place. No, demanding synchronization is unrealistic. We need to assume they'll be out of sync at least some of the time, but we also should assume that it's operationally desirable for them to converge. Consequently, the "dueling manager" scenarios fall under the general rubric of "don't do that", and we only need to check through the cases where things are temporarily out of sync to understand the implications. In those cases, as far as I can tell, nothing worse happens than would occur if updates were slow to be propageted to the RADIUS servers in the absence of SNMP-based policy updates. Randy From randy_presuhn@mindspring.com Mon Jun 15 22:56:50 2009 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 556EA3A68E0 for ; Mon, 15 Jun 2009 22:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PHxqAlE8pI9X for ; Mon, 15 Jun 2009 22:56:49 -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 25FB23A685D for ; Mon, 15 Jun 2009 22:56:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=L4E4i4O9aGputSUMJ0jbfckWfnKdZGZ9LBqK5sLFczlN3/KbM0CtDY1i1rvL/dhe; 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.190] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MGRfF-0002d8-QK for isms@ietf.org; Tue, 16 Jun 2009 01:56:58 -0400 Message-ID: <000901c9ee47$511b4480$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <002a01c9ee1c$eeb36900$6801a8c0@oemcomputer> <20090616050714.GB6629@elstar.local> Date: Mon, 15 Jun 2009 22:57:21 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69687288d85e03898389601e5ada92dc1d89350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.190 Subject: Re: [Isms] Moving into some design / architecture issuesofExtended VACM 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, 16 Jun 2009 05:56:50 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Monday, June 15, 2009 10:07 PM > Subject: Re: [Isms] Moving into some design / architecture issuesofExtended VACM ... > I do not think you need to mess around with contexts. If we can make > multiple ACMs to work, the problem has a solution. ... Multiple ACMs would be a wonderful theoretical Pandora's box project to give to some grad student to play with. Be careful what you wish for, especially when it comes time to send notifications. For the implementations with which I am familiar, having multiple ACMs would be *very* tricky. Don't forget the extent to which isAccessAllowed is involved in the conceptual processing of GetNext, GetBulk, and notifications, and that a real implementation, rather than relying on the ASI abstraction, may look directly into the heart of VACM in order to optimize subagent subtree queries during GetNext and GetBulk. Having the possibility of a different access control model could throw a monkey wrench into those algorithms. Folks think having VACM to deal with is difficult. Just wait until folks start putting in ACMs of their own in order to "simplify" things. But it will give the WG, implementors, and operators a lot more to do, so I suppose some might consider that a win. Randy From j.schoenwaelder@jacobs-university.de Tue Jun 16 00:40:52 2009 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 CD1D83A659C for ; Tue, 16 Jun 2009 00:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.024, 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 z2V+8RPnH0-2 for ; Tue, 16 Jun 2009 00:40:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3CF923A6890 for ; Tue, 16 Jun 2009 00:40:50 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C887C0082; Tue, 16 Jun 2009 09:29:04 +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 bN1dXVI4wwlq; Tue, 16 Jun 2009 09:29:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C871C008A; Tue, 16 Jun 2009 09:29:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 67C78B43B82; Tue, 16 Jun 2009 09:29:02 +0200 (CEST) Date: Tue, 16 Jun 2009 09:29:02 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20090616072902.GB6719@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603> <20090611140545.GA9442@elstar.local> <007601c9eab0$fb7da930$0600a8c0@china.huawei.com> <20090611171411.GA388@elstar.local> <003b01c9ead6$e8e08920$6801a8c0@oemcomputer> <20090611225732.GA840@elstar.local> <0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603> <002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> <20090616050156.GA6629@elstar.local> <000401c9ee44$1f2d0240$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c9ee44$1f2d0240$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 07:40:52 -0000 On Tue, Jun 16, 2009 at 07:34:27AM +0200, Randy Presuhn wrote: > As a matter of sanity, we have to assume that what the security > administrator tells RADIUS to do is the same as what he wants the > SNMP-alone policy to be. If they're at odds, he's got a bigger > problem than we can solve here. If we make this assumption, why then have RADIUS at all? I am familiar with envrionments where the SNMP configuration is rather static and never changed unless really really really necessary. In particular, nobody wants to configure a number of SNMP agents just because a single user needs to be added/removed. But people are much more happy to do this via a centralized (RADIUS) mechanism. In other words, in such environemnts, the SNMP static access policy is by definition different from the RADIUS access policy. For these environments, making the assumption that the RADIUS and static SNMP access policy are essentially the same except during transitional update periods is a non starter since I still have to update a number of SNMP agents - so there is really no win in having RADIUS involved. /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 Tue Jun 16 05:35:22 2009 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 61E3F3A6D12 for ; Tue, 16 Jun 2009 05:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 cz2w4ZDy0CS5 for ; Tue, 16 Jun 2009 05:35:21 -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 5498D3A689E for ; Tue, 16 Jun 2009 05:35:20 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 4aVs1c0050QuhwU53cVYBm; Tue, 16 Jun 2009 12:29:32 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id 4cVY1c0060UQ6dC3NcVYw6; Tue, 16 Jun 2009 12:29:32 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> Date: Tue, 16 Jun 2009 08:29:30 -0400 Message-ID: <013701c9ee7e$1934a3e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnuG23GZ8w81WbZRj6nrWVsXARJnwAFUYcgABL3i1A= Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 12:35:22 -0000 Hi, At the risk of repeating myself ;-) ... If you design an ACM that operates with a totally different set of assumptions, then you are designing a new ACM, not extending an existing one. If you want an ACM that operates following RADIUS, rather than SNMPv3, assumptions, then I think you need to design a new ACM and that means you need to address the issue that the SNMPv3 WG did not provide an ACM selector. That will take significantly more time to address than simnply adding some RADIUS attributes to allow dynamically provisioning the existing VACM models. I expect there would be other significant problems to solve besides the selector to get RADIUS-like assumptions built into SNMPv3; The SNMPv3 WG **deliberately** split authorization from authentication, using only the ASIs for bindings. I think you will effectively be trying to design a new SNMP architecture based on AAA assumptions if we follow your reasoning here. The RADIUS and SNMP architectures do not match, and ISMS has not been authorized to totally redesign SNMP and its assumptions. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Monday, June 15, 2009 11:27 PM > To: isms@ietf.org > Subject: Re: [Isms] Moving into some design/architecture > issuesofExtendedVACM > > Randy Presuhn writes... > > > Repeating myself: this would interact badly with security policy > > updates. It is much safer for changes to vacmGroupName in a > > vacmSecurityToGroupEntry to behave just like they would if they > > had been set. > > I think we're talking at cross purposes. > > You seem to be talking about maintaining consistency between > RADIUS usage > and manual security administration. IIRC, the whole premise > of the ISMS > work is that many operators feel that SNMPv3 security is simply too > complicated to deploy. So they don't. They want something > ties into their > existing infrastructure. > > We're talking about two different audiences, those who like > SNMPv3 security > and use it as defined today and those who don't. The ISMS > work address the > "those who don't" audience. I think, by definition, there aren't any > operational conflicts to be resolved. > > Beyond that, I think you need to seriously consider other > examples of how > local, static authentication and authorization is integrated > with remote, > dynamic authentication and authorization. There are > precedents. The UNIX > login usage (NIS vs. /etc/passed file) is just one. > > I too am repeating myself, and it seems that we simply look > at this problem > very differently. > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From d.b.nelson@comcast.net Tue Jun 16 05:39:23 2009 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 A94443A68C8 for ; Tue, 16 Jun 2009 05:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 9A1vMr3fwO+e for ; Tue, 16 Jun 2009 05:39:23 -0700 (PDT) Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id D0FFC3A69CF for ; Tue, 16 Jun 2009 05:39:22 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id 4b611c0031GXsucAFcekvX; Tue, 16 Jun 2009 12:38:44 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id 4cei1c00U4H2mdz8TcejRo; Tue, 16 Jun 2009 12:38:44 +0000 From: "Dave Nelson" To: References: <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer><20090616050156.GA6629@elstar.local><000401c9ee44$1f2d0240$6801a8c0@oemcomputer> <20090616072902.GB6719@elstar.local> Date: Tue, 16 Jun 2009 08:38:42 -0400 Message-ID: <8E09C8E7F7AC41298C1AAF0979A538C9@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090616072902.GB6719@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnuVc8Kl8jIjfqYTvK3HWeWZgSWPAAJ319Q Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 12:39:23 -0000 Juergen Schoenwaelder writes... > I am familiar with envrionments where the SNMP configuration > is rather static and never changed unless really really really > necessary. I suspect that this broadly applies to the access control rules and the "roles" that are defined by the collections of rules, i.e. the "groups". I think that "roles" change very infrequently, once initially debugged and tuned, unless something in the organization changes, such as a different division of responsibilities or some new type of equipment with new management challenges is introduced. I think it's fair to say that the group definitions are semi-static, and managed by traditional SNMP access. These definitions are certainly *not* managed by RADIUS. I also think it's fair to say that most organizations have only a handful of roles / groups. What changes most frequently is the assignment of people to roles. From all the postings to date, I believe we have rough consensus on that much. What seems to be in contention is *how* the dynamic information from RADIUS is applied. The issue that seems to be most contentions is whether the securityName to groupName binding provided by RADIUS is persistent in the NAS after the session has ended. While this is the way SNMP works it is not the way RADIUS works. This is the root of the disagreement -- very different persistence models between RADIUS provisioning and SNMP provisioning. Each camp naturally views the issues from their own experience base and comfort zone. How do we resolve this? From d.b.nelson@comcast.net Tue Jun 16 05:46:03 2009 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 EFBFC3A698B for ; Tue, 16 Jun 2009 05:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 cVEbb035sG4H for ; Tue, 16 Jun 2009 05:46:02 -0700 (PDT) Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 35D583A68AE for ; Tue, 16 Jun 2009 05:46:01 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id 4c321c0031GXsucAFckcaT; Tue, 16 Jun 2009 12:44:36 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id 4ckb1c0054H2mdz8TckcVW; Tue, 16 Jun 2009 12:44:36 +0000 From: "Dave Nelson" To: References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603><00e901c9e9fa$f7642100$6801a8c0@oemcomputer><000601c9ea00$00795120$0600a8c0@china.huawei.com><006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> <013701c9ee7e$1934a3e0$0600a8c0@china.huawei.com> Date: Tue, 16 Jun 2009 08:44:35 -0400 Message-ID: <8127B745735840BBB886F86AAA5A6CE4@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <013701c9ee7e$1934a3e0$0600a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnuG23GZ8w81WbZRj6nrWVsXARJnwAFUYcgABL3i1AAAMAwkA== Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 12:46:03 -0000 David Harrington writes... > The RADIUS and SNMP architectures do not match, and ISMS > has not been authorized to totally redesign SNMP and its > assumptions. Nor has the WG been authorized to totally redesign RADIUS and its assumptions. :-) Clearly there's an impedance mismatch between the operational models. If we're to proceed, we need to find a way to mitigate those issues. I don't think that misapplying RADIUS to the problem in an attempt preserve SNMP architectural integrity is the answer. From ietfdbh@comcast.net Tue Jun 16 05:54:10 2009 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 55B623A6AA4 for ; Tue, 16 Jun 2009 05:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 5-V9jpNj+6-T for ; Tue, 16 Jun 2009 05:54:09 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 3374B3A698B for ; Tue, 16 Jun 2009 05:54:09 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 4bxf1c00716LCl054cttei; Tue, 16 Jun 2009 12:53:53 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 4cts1c00U0UQ6dC3Scts7z; Tue, 16 Jun 2009 12:53:53 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer> <20090616050156.GA6629@elstar.local> Date: Tue, 16 Jun 2009 08:53:51 -0400 Message-ID: <013801c9ee81$80023530$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090616050156.GA6629@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnuP5b4EWBhftc3T8mMoQt9O0jstAAPqNJQ Cc: isms@ietf.org Subject: Re: [Isms] Moving into some design/architectureissues ofExtendedVACM 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, 16 Jun 2009 12:54:10 -0000 Hi, SNMP is built with the assumption that one or more managers have access to the MIB residing in an agent. That includes the VACM tables, unless the access controls themselves prevent access. So it has long been a basic assumption in the SNMPv3 design that the access control tables can be modified by more than one administrator or management application. While the SNMPv3 WG punted on designing an ACM selector field in the message, or some other mechanism, it was always the consensus of the SNMPv3 WG that multiple ACMs could exist and operate simultaneously. COPS-PR was a no-go in the IETF because it demanded that if COPS-PR was enabled, then COPS-PR and only COPS-PR, controlled the policy decisions for a managed device. For operators to use a different NM interface, they needed to disable COPS-PR. Operators said "no way!" For me, this argument that when RADIUS is in use, it must be the only access control in play follows a similar vein of thinking, and I think this is a no-go. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, June 16, 2009 1:02 AM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] Moving into some > design/architectureissues ofExtendedVACM > > On Tue, Jun 16, 2009 at 02:43:14AM +0200, Randy Presuhn wrote: > > Hi - > > > > > From: "Dave Nelson" > > > To: > > > Sent: Thursday, June 11, 2009 8:54 PM > > > Subject: Re: [Isms] Moving into some design/architecture > issues ofExtendedVACM > > ... > > > > PS: Does the RADIUS client have the "rights" to modify > any existing > > > > writable matching table entries? Will it revert the > changes when > > > > the session dies? > > > > > > I think it needs to revert, yes. > > > > > > While we talk loosely of the RADIUS authorization > information being used to > > > update the VACM MIB Module in the same sense that the > SNMP engine would do > > > in response to an SNMP SET, we may be taking this too > literally. I think > > > that the RADIUS information kept by the VACM Extension > should be transient, > > > with a lifetime limited to that of the secure transport session. > > ... > > > > Repeating myself: this would interact badly with security > policy updates. > > It is much safer for changes to vacmGroupName in a > vacmSecurityToGroupEntry > > to behave just like they would if they had been set. If > they can "revert", then an entry > > which appeared to be up-to-date when inspected by a > security administrator could > > silently become not-up-to-date because a secure transport > session ended. > > This would make a hash of security policy configuration management. > > > > Simple really is preferable here. It's less work for the > implementor, > > both of management applications and in the guts of the SNMP > implementation. > > It's less work for the security administrator. And it > would be a lot simpler > > for this WG. > > Randy, > > you have the same probem if I as the security administrator change the > VACM table and then RADIUS comes in and simply changes what I have > carefully configured. I tend to agree with Dave Nelson that having a > single table modified by two different entities is likely asking for > trouble. You might argue that the problem is really the conflict > between RADIUS policy and the security administrator's policy. My > counter argument to that is that if both would be in fine synchrony, > we would not need the RADIUS interface in the first place. > > /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 ietfdbh@comcast.net Tue Jun 16 06:03:29 2009 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 0A8863A6D74 for ; Tue, 16 Jun 2009 06:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 va3494QKqU2d for ; Tue, 16 Jun 2009 06:03:28 -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 CE4B03A689E for ; Tue, 16 Jun 2009 06:03:27 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 4ZWq1c0040cZkys51d2fRf; Tue, 16 Jun 2009 13:02:39 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id 4d311c00G0UQ6dC3Wd31bi; Tue, 16 Jun 2009 13:03:01 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603><002a01c9ee1c$eeb36900$6801a8c0@oemcomputer> <20090616050714.GB6629@elstar.local> Date: Tue, 16 Jun 2009 09:03:00 -0400 Message-ID: <013901c9ee82$c6d13b90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090616050714.GB6629@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnuQFSDvzhgJK2LRtmkwMtDYTdIvQAQU4WA Cc: isms@ietf.org Subject: Re: [Isms] Moving into some design / architecture issues ofExtendedVACM 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, 16 Jun 2009 13:03:29 -0000 Hi, I think Juergen's suggestion of a precedence table in a MIB might make sense. That keeps the system SNMP-manageable, allows the administrator the choice of precedence, and allows us to have a separate MIB module and associated elements of procedure for RADIUS ACM support. Effectively, we can design a new RADIUS ACM, and use the precedence table as the selector mechanism. I assume the ACM precedence table must be preconfigured, just as the policies are. I do think there will be plenty of problems forcing one ACM to always have precedence, and I can envision admins wanting one system to have precedence for some users (e.g., the IT staff, in case of the need to override RADIUS), while other users should always be controlled under the RADIUS approach. But setting precedence by user would require preconfiguration of the users. ACM Precedence probably needs to be by group. Setting precedence might be able to be added for a user/group mapping by adding an ACM selector to the RADIUS attributes. That might not work for the it-group, though. I think the precedence table needs to be similar to a capabilities negotiation; an admin can configure the table to say "RADIUS takes precedence for this group if it is available; otherwise USM MAY be used by this group." For non-emergency uses, RADIUS could specify the precedece order for a group, but somehow, the security admin needs to be able to say that "this group needs authorization to override a RADIUS rejection". dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, June 16, 2009 1:07 AM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] Moving into some design / architecture > issues ofExtendedVACM > > On Tue, Jun 16, 2009 at 02:53:57AM +0200, Randy Presuhn wrote: > > > > I think it has a real problem from the perspective of > security configuration > > management. A security administrator should be able to find out how > > a system's security policy is configured, regardless of > whether RADIUS > > is in use. This means the "shadow" table would need to be > visible to > > management. However, the security administrator should also be able > > to configure and update the "real" VACM configuration whether RADIUS > > is in use at the moment or not. This means that "write" operations > > would need to affect both the shadow and the "real" configuration. > > However, to determine whether the "real" configuration is in need of > > update, it must be possible for the administrator to > retrieve it. This > > conflict is irreconcilable. > > > > To kluge around it, I think you'd have to use a separate > SNMP context for the > > shadow. This is just too ugly and convoluted a thing to do > for no real > > benefit, particularly since it would require standardizing > a context name > > for this kluge. > > I do not think you need to mess around with contexts. If we can make > multiple ACMs to work, the problem has a solution. > > /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 d.b.nelson@comcast.net Tue Jun 16 06:20:25 2009 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 510B33A6B73 for ; Tue, 16 Jun 2009 06:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 9C-hQIQvn9x9 for ; Tue, 16 Jun 2009 06:20:24 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 727ED3A6B5D for ; Tue, 16 Jun 2009 06:20:24 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id 4bc91c0061HpZEsA7dLcfA; Tue, 16 Jun 2009 13:20:36 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id 4dLa1c00D4H2mdz8adLbYA; Tue, 16 Jun 2009 13:20:35 +0000 From: "Dave Nelson" To: References: <006e01c9ea38$30aeccc0$6801a8c0@oemcomputer><657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer><20090616050156.GA6629@elstar.local> <013801c9ee81$80023530$0600a8c0@china.huawei.com> Date: Tue, 16 Jun 2009 09:20:34 -0400 Message-ID: <4F99FCF8A028407DADD2FF4CBA442993@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <013801c9ee81$80023530$0600a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnuP5b4EWBhftc3T8mMoQt9O0jstAAPqNJQAAFivPA= Subject: Re: [Isms] Moving into some design/architectureissuesofExtendedVACM 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, 16 Jun 2009 13:20:25 -0000 David Harrington writes... > While the SNMPv3 WG punted on designing an ACM selector field > in the message, or some other mechanism, it was always the consensus > of the SNMPv3 WG that multiple ACMs could exist and operate > simultaneously. In other words, you're all pretty much in a state of denial. :-) > COPS-PR was a no-go in the IETF because it demanded that if COPS-PR > was enabled, then COPS-PR and only COPS-PR, controlled the policy > decisions for a managed device An interesting sidelight on IETF network management protocol history, but not directly relevant to the current debate, I think. > For me, this argument that when RADIUS is in use, it must > be the only access control in play follows a similar vein of > thinking, and I think this is a no-go. Except that no one has ever said that. What I have said is that the "multiple writers" problem for AAA should be solved in an organized way, following accepted principles of precedence -- primary and fallback -- and not in the simple "last change takes precedence" fashion traditional to SNMP. The use of RADIUS does not preclude the use of statically configured user-to-group data in the NAS, any more than the use of NIS for UNIX login precludes the use of the /etc/passwd file. Sometimes in order to obtain new functionality, you need to be open to change. All I'm asking is that the RADIUS provisioning operation model not be violated, and that RADIUS provisioned access control information has a lifetime limited to that of the underlying session. From ietfdbh@comcast.net Tue Jun 16 06:24:41 2009 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 998773A6AEC for ; Tue, 16 Jun 2009 06:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpEJtbuMX1g4 for ; Tue, 16 Jun 2009 06:24:40 -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 957083A69C3 for ; Tue, 16 Jun 2009 06:24:40 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 4bBM1c0050mv7h051dQKM1; Tue, 16 Jun 2009 13:24:19 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 4dQg1c00S0UQ6dC3XdQg5e; Tue, 16 Jun 2009 13:24:41 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer><20090616050156.GA6629@elstar.local><000401c9ee44$1f2d0240$6801a8c0@oemcomputer><20090616072902.GB6719@elstar.local> <8E09C8E7F7AC41298C1AAF0979A538C9@NEWTON603> Date: Tue, 16 Jun 2009 09:24:39 -0400 Message-ID: <013b01c9ee85$cd6fff60$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8E09C8E7F7AC41298C1AAF0979A538C9@NEWTON603> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnuVc8Kl8jIjfqYTvK3HWeWZgSWPAAJ319QAAIHONA= Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 13:24:41 -0000 Hi, I think we actually have consensus about persistence. I think everybody expects that the user-to-group mapping should go away when the radius-authorized session ends; we just need to figure how to do that without redesigning snmpv3 and the rfc3411 architecture. I do not think we have consensus on reverting. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Tuesday, June 16, 2009 8:39 AM > To: isms@ietf.org > Subject: Re: [Isms] Moving into some design/architecture > issuesofExtendedVACM > > Juergen Schoenwaelder writes... > > > I am familiar with envrionments where the SNMP configuration > > is rather static and never changed unless really really really > > necessary. > > I suspect that this broadly applies to the access control > rules and the > "roles" that are defined by the collections of rules, i.e. > the "groups". I > think that "roles" change very infrequently, once initially > debugged and > tuned, unless something in the organization changes, such as > a different > division of responsibilities or some new type of equipment with new > management challenges is introduced. > > I think it's fair to say that the group definitions are > semi-static, and > managed by traditional SNMP access. These definitions are > certainly *not* > managed by RADIUS. > > I also think it's fair to say that most organizations have > only a handful of > roles / groups. What changes most frequently is the > assignment of people to > roles. From all the postings to date, I believe we have > rough consensus on > that much. > > What seems to be in contention is *how* the dynamic > information from RADIUS > is applied. > > The issue that seems to be most contentions is whether the > securityName to > groupName binding provided by RADIUS is persistent in the NAS > after the > session has ended. While this is the way SNMP works it is not the way > RADIUS works. This is the root of the disagreement -- very different > persistence models between RADIUS provisioning and SNMP > provisioning. Each > camp naturally views the issues from their own experience > base and comfort > zone. > > How do we resolve this? > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From d.b.nelson@comcast.net Tue Jun 16 06:30:12 2009 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 800B03A6A76 for ; Tue, 16 Jun 2009 06:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 pC-JuyWnpOvg for ; Tue, 16 Jun 2009 06:30:10 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id 362F53A6AA4 for ; Tue, 16 Jun 2009 06:30:10 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id 4cpG1c0040lTkoCACdVv6M; Tue, 16 Jun 2009 13:29:55 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id 4dVt1c00V4H2mdz8QdVuJ9; Tue, 16 Jun 2009 13:29:55 +0000 From: "Dave Nelson" To: "'David Harrington'" , "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603><002a01c9ee1c$eeb36900$6801a8c0@oemcomputer><20090616050714.GB6629@elstar.local> <013901c9ee82$c6d13b90$0600a8c0@china.huawei.com> Date: Tue, 16 Jun 2009 09:29:54 -0400 Message-ID: <39CFB8825E134C5F917280271348DDC9@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <013901c9ee82$c6d13b90$0600a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnuQFSDvzhgJK2LRtmkwMtDYTdIvQAQU4WAAADw9fA= Cc: isms@ietf.org Subject: Re: [Isms] Moving into some design / architectureissues ofExtendedVACM 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, 16 Jun 2009 13:30:12 -0000 David Harrington writes... > For non-emergency uses, RADIUS could specify the precedence > order for a group, but somehow, the security admin needs to be > able to say that "this group needs authorization to override > a RADIUS rejection". I think you're making this *way* too complicated. First, I don't believe there is a real market requirement for fine-granularity precedence of AAA sources. One can posit hypothetical scenarios where it could be useful, but I think that's outside the 80-percent problem. Second, no one should *ever* be able to override a RADIUS reject. If there is a problem with the RADIUS service, then a good design is to have one (or a very small number) of locally configured user identities that bypass RADIUS altogether -- the analog of the "root" account in the /etc/passwd file. Having a simple selection mechanism to choose between using RADIUS or local data is sufficient, and that could be as simple as "root" is always a local account. Once you get into the business of second guessing the authoritative AAA service, as to access control decisions, "Abandon Hope All Ye Who Enter Here". From d.b.nelson@comcast.net Tue Jun 16 06:46:44 2009 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 B5AA83A6A2E for ; Tue, 16 Jun 2009 06:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 gcIeAENYJtlX for ; Tue, 16 Jun 2009 06:46:44 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id E953E28C17C for ; Tue, 16 Jun 2009 06:46:43 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 4c5C1c0010EPchoA4dmK6t; Tue, 16 Jun 2009 13:46:19 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id 4dmJ1c0024H2mdz8MdmJBJ; Tue, 16 Jun 2009 13:46:19 +0000 From: "Dave Nelson" To: References: <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer><20090616050156.GA6629@elstar.local><000401c9ee44$1f2d0240$6801a8c0@oemcomputer><20090616072902.GB6719@elstar.local> <8E09C8E7F7AC41298C1AAF0979A538C9@NEWTON603> <013b01c9ee85$cd6fff60$0600a8c0@china.huawei.com> Date: Tue, 16 Jun 2009 09:46:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <013b01c9ee85$cd6fff60$0600a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnuVc8Kl8jIjfqYTvK3HWeWZgSWPAAJ319QAAIHONAAAMr/sA== Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 13:46:44 -0000 David Harrington writes... > I think we actually have consensus about persistence. > > I think everybody expects that the user-to-group mapping should go > away when the radius-authorized session ends; ... Excellent! > ... we just need to figure how to do that without redesigning > snmpv3 and the rfc3411 architecture. I eagerly await suggestions, as I have (temporarily) run out of ideas. From j.schoenwaelder@jacobs-university.de Tue Jun 16 08:07:11 2009 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 EE0243A6AD8 for ; Tue, 16 Jun 2009 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.023, 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 dFRGxQZenF1F for ; Tue, 16 Jun 2009 08:07:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 57D313A6AEC for ; Tue, 16 Jun 2009 08:07:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C858CC0035; Tue, 16 Jun 2009 17:05:45 +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 sb13ePPks5mn; Tue, 16 Jun 2009 17:05:44 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1A2CC0003; Tue, 16 Jun 2009 17:05:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 93A77B441DE; Tue, 16 Jun 2009 17:05:42 +0200 (CEST) Date: Tue, 16 Jun 2009 17:05:42 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090616150542.GB6910@elstar.local> Mail-Followup-To: David Harrington , 'Randy Presuhn' , "isms@ietf.org" References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <002a01c9ee1c$eeb36900$6801a8c0@oemcomputer> <20090616050714.GB6629@elstar.local> <013901c9ee82$c6d13b90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013901c9ee82$c6d13b90$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] Moving into some design / architecture issues ofExtendedVACM 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, 16 Jun 2009 15:07:12 -0000 On Tue, Jun 16, 2009 at 03:03:00PM +0200, David Harrington wrote: > I assume the ACM precedence table must be preconfigured, just as the > policies are. I do think there will be plenty of problems forcing one > ACM to always have precedence, and I can envision admins wanting one > system to have precedence for some users (e.g., the IT staff, in case > of the need to override RADIUS), while other users should always be > controlled under the RADIUS approach. But setting precedence by user > would require preconfiguration of the users. ACM Precedence probably > needs to be by group. Setting precedence might be able to be added for > a user/group mapping by adding an ACM selector to the RADIUS > attributes. That might not work for the it-group, though. I think the > precedence table needs to be similar to a capabilities negotiation; an > admin can configure the table to say "RADIUS takes precedence for this > group if it is available; otherwise USM MAY be used by this group." > For non-emergency uses, RADIUS could specify the precedece order for a > group, but somehow, the security admin needs to be able to say that > "this group needs authorization to override a RADIUS rejection". Way too complex if you ask me. Such an ACM precedence table should be as minimal as we can make it - and Randy believes even that is way too complicated because of ACM optimizations some SNMP toolkits do for performance reasons. For me, the minimal solution is a table consisting of a priority column and an ACM identification column. If I would have a configured precedence like try first RVACM (Radius VACM) and then VACM, then RVACM might return a statusInformation of the isAccessAllowed() allowed that tells my code to 'continue' with the next ACM. However, VACM does not have such a continue return code defined (RFC 3415 page 7) so I would assume that a VACM decision is always final (access/failure). In other words, the precedence VACM and then RVACM would never reach RVACM. Here is what this exercise boils down to: a) A control table needs to be defined that specifies the precedence order in which ACMs are consulted. b) A very slight change to the isAccessAllowed() ASI since the statusInformation would be "success or errorIndication or continue" for new ACMs. c) Updates would be needed to section 3.2 of RFC 3413 step (5) where isAccessAllowed() is called from Command Responder applications d) Updates would be needed to section 3.3 of RFC 3413 step (2) and (3) where isAccessAllowed() is called from Notification Originator applications Putting my chair hat on, the question is whether ISMS is chartered to do such a piece of work that affects several core SNMPv3 documents. So far, work on new access control models was clearly out of scope for this WG. The proposed new charter text also talks pretty clearly about "a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table." So if this charter gets approved, I believe the work outlined above falls out of the charter and we have to come up with some other sensible ways to deal with conflicts that can happen if RADIUS is asked to overwrite existing table entries. /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 Tue Jun 16 09:56:17 2009 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 F3D153A6C05 for ; Tue, 16 Jun 2009 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 595o5NiVVklx for ; Tue, 16 Jun 2009 09:56:16 -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 E9FA83A6BB8 for ; Tue, 16 Jun 2009 09:56:15 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA10.westchester.pa.mail.comcast.net with comcast id 4cvr1c00A1GhbT85AgwLE7; Tue, 16 Jun 2009 16:56:20 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id 4gwK1c00h0UQ6dC3TgwLWt; Tue, 16 Jun 2009 16:56:20 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603><002a01c9ee1c$eeb36900$6801a8c0@oemcomputer> <20090616050714.GB6629@elstar.local> Date: Tue, 16 Jun 2009 12:56:18 -0400 Message-ID: <017501c9eea3$5ecb46f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090616050714.GB6629@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnuQFSDvzhgJK2LRtmkwMtDYTdIvQAYv/1A Cc: isms@ietf.org Subject: Re: [Isms] Moving into some design / architecture issues ofExtendedVACM 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, 16 Jun 2009 16:56:17 -0000 I prefer to avoid using contexts to solve this issue. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, June 16, 2009 1:07 AM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] Moving into some design / architecture > issues ofExtendedVACM > > On Tue, Jun 16, 2009 at 02:53:57AM +0200, Randy Presuhn wrote: > > > > I think it has a real problem from the perspective of > security configuration > > management. A security administrator should be able to find out how > > a system's security policy is configured, regardless of > whether RADIUS > > is in use. This means the "shadow" table would need to be > visible to > > management. However, the security administrator should also be able > > to configure and update the "real" VACM configuration whether RADIUS > > is in use at the moment or not. This means that "write" operations > > would need to affect both the shadow and the "real" configuration. > > However, to determine whether the "real" configuration is in need of > > update, it must be possible for the administrator to > retrieve it. This > > conflict is irreconcilable. > > > > To kluge around it, I think you'd have to use a separate > SNMP context for the > > shadow. This is just too ugly and convoluted a thing to do > for no real > > benefit, particularly since it would require standardizing > a context name > > for this kluge. > > I do not think you need to mess around with contexts. If we can make > multiple ACMs to work, the problem has a solution. > > /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 Jun 16 10:38:52 2009 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 84CD63A6DA0 for ; Tue, 16 Jun 2009 10:38:52 -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 IdfAYzQQTqMk for ; Tue, 16 Jun 2009 10:38:51 -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 56DEC3A6AA6 for ; Tue, 16 Jun 2009 10:38:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sQ3Vmb55yXAnvSPfwhOC/pE6IM68GM8wbz+hWZ1DJCVAegZnjOrMVlSKWB+InMzB; 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 [76.254.53.210] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MGcby-0002gR-NK for isms@ietf.org; Tue, 16 Jun 2009 13:38:18 -0400 Message-ID: <002301c9eea9$4b34b940$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer><20090616050156.GA6629@elstar.local><000401c9ee44$1f2d0240$6801a8c0@oemcomputer><20090616072902.GB6719@elstar.local> <8E09C8E7F7AC41298C1AAF0979A538C9@NEWTON603> Date: Tue, 16 Jun 2009 10:38:42 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696870b0493a80cefc70c8e57ef26ec086db350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.53.210 Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 17:38:52 -0000 Hi - > From: "Dave Nelson" > To: > Sent: Tuesday, June 16, 2009 5:38 AM > Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM ... > The issue that seems to be most contentions is whether the securityName to > groupName binding provided by RADIUS is persistent in the NAS after the > session has ended. While this is the way SNMP works it is not the way > RADIUS works. This is the root of the disagreement -- very different > persistence models between RADIUS provisioning and SNMP provisioning. Each > camp naturally views the issues from their own experience base and comfort > zone. > > How do we resolve this? I think it's helpful to break it down into the specific cases: (1) a matching entry (identified by user name and security model) already exists when the data from RADIUS arrives. This is the case that's been getting most of the attention in this discussion. It occurs when something gets provisioned both through SNMP and through radius. I believe that in this case, the persistence should be in accordance with the row's StorageType, and that the most recently supplied group mapping should "win", with no mystical "reverting" of values. (2) No matching entry exists when the data from RADIUS arrives. I think it is quite reasonable for such entries to have a very limited lifetime, and that upon expiration of that lifetime, they should evaporate, unless in the meantime a manager has stepped in and changed the StorageType from 'volatile' to something more permanent. Now, I *think* a reasonable compromise is possible. Under normal operational conditions, it doesn't make much sense to provision vacmSecurityToGroupStorageType to be volatile. After all, the security administrator creating the entry would almost certainly like it to survive the next reboot! So, consider the following: When the data arrives from RADIUS, check for a matching vacmSecurityToGroupEntry. If it exists and vacmSecurityToGroupStorageType is not readOnly: Then update vacmGroupName with the data received from RADIUS Else create an appropriate entry: using the supplied data for vacmSecurityName, vacmSecurityModel, and vacmGroupName; 'volatile' for vacmSecurityToGroupStorageType, and 'active' for 'vacmSecurityToGroupStatus' When the user's last session goes away (there may be multiple, overlapping sessions, right?): If there is a matching vacmSecurityToGroupEntry (it's possible that creation failed due to system resource exhaustion, but that is a pathological corner case) Then if the entry's vacmSecurityToGroupStorageType is 'volatile' Then set vacmSecurityToGroupStatus to 'destroy' I think this satisfies fairly well everyone's requirements, doesn't change VACM one bit, produces no "surprising" results and is really really simple. Randy From ietfdbh@comcast.net Tue Jun 16 14:32:10 2009 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 2471F3A6D71 for ; Tue, 16 Jun 2009 14:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 OELjmZfTfyat for ; Tue, 16 Jun 2009 14:32:08 -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 37A183A67B2 for ; Tue, 16 Jun 2009 14:32:07 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 4cNV1c00C17dt5G55lWdJY; Tue, 16 Jun 2009 21:30:37 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 4lWd1c0080UQ6dC3ZlWdYH; Tue, 16 Jun 2009 21:30:37 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" References: <7D5B6351B90B4B7FB309277995E141F9@NEWTON603> <002a01c9ee1c$eeb36900$6801a8c0@oemcomputer> <20090616050714.GB6629@elstar.local> <013901c9ee82$c6d13b90$0600a8c0@china.huawei.com> <20090616150542.GB6910@elstar.local> Date: Tue, 16 Jun 2009 17:30:34 -0400 Message-ID: <018501c9eec9$af842500$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090616150542.GB6910@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acnuk+/y6rJ11yzhRlm1umjAYj2lggALfjVQ Cc: isms@ietf.org Subject: Re: [Isms] Moving into some design / architecture issuesofExtendedVACM 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, 16 Jun 2009 21:32:10 -0000 Hi, OK. We can simplify this if we do not change the assumptions in the basic VACM model. We need to allow RADIUS to provision the VACM user-to-group table, or to provision a second table for user-to-group mapping, with an admin-configured precedance table. I think the simplest approach is to treat thia as a VACM extension, and that means it happens between the isAccessAllowed() interface and the VACM elements of procedure. We add a second mapping table, and a precedence table, and some EOP that immediately check the precedence table to determine which mapping table to use. The only thing the precedence table decides is which user-to-group mapping table to use. Once we have the correct table, then VACM elements of procedure work as designed. We can choose to not support a fallback approach; if RADIUS-authz fails, well, it fails. An operator can try a different username, such as root, to connect if RADIUS is not available. In this way, we do not need to add a "continue" option to isAccessAllowed, and we are not changing any of the existing RFCs, or any ASIs. We are merely developing an optional augmenting MIB module for VACM with associated elements of procedure. How an access control model decides to map users to policies has always been considered the purview of the specific access control model. All we are doing is adding some flexibility to VACM's decision mechanism. If we want to ensure there are no competing admins, but help admins understand what is happening regarding authorization, we can make the RADIUS mapping table into a read-only MIB module; only RADIUS can alter it. I think the ACM precedence should be assigned per group. So you might have most operators assigned groups in the RADIUS table, while a select few operators (superusers) are configured to use statically configured VACM. So it is a manual fallback design. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, June 16, 2009 11:06 AM > To: David Harrington > Cc: 'Randy Presuhn'; isms@ietf.org > Subject: Re: [Isms] Moving into some design / architecture > issuesofExtendedVACM > > On Tue, Jun 16, 2009 at 03:03:00PM +0200, David Harrington wrote: > > > I assume the ACM precedence table must be preconfigured, just as the > > policies are. I do think there will be plenty of problems > forcing one > > ACM to always have precedence, and I can envision admins wanting one > > system to have precedence for some users (e.g., the IT > staff, in case > > of the need to override RADIUS), while other users should always be > > controlled under the RADIUS approach. But setting precedence by user > > would require preconfiguration of the users. ACM Precedence probably > > needs to be by group. Setting precedence might be able to > be added for > > a user/group mapping by adding an ACM selector to the RADIUS > > attributes. That might not work for the it-group, though. I > think the > > precedence table needs to be similar to a capabilities > negotiation; an > > admin can configure the table to say "RADIUS takes > precedence for this > > group if it is available; otherwise USM MAY be used by this group." > > For non-emergency uses, RADIUS could specify the precedece > order for a > > group, but somehow, the security admin needs to be able to say that > > "this group needs authorization to override a RADIUS rejection". > > Way too complex if you ask me. Such an ACM precedence table should be > as minimal as we can make it - and Randy believes even that is way too > complicated because of ACM optimizations some SNMP toolkits do for > performance reasons. For me, the minimal solution is a table > consisting of a priority column and an ACM identification column. > > If I would have a configured precedence like try first RVACM (Radius > VACM) and then VACM, then RVACM might return a statusInformation of > the isAccessAllowed() allowed that tells my code to 'continue' with > the next ACM. However, VACM does not have such a continue return code > defined (RFC 3415 page 7) so I would assume that a VACM decision is > always final (access/failure). In other words, the precedence VACM and > then RVACM would never reach RVACM. > > Here is what this exercise boils down to: > > a) A control table needs to be defined that specifies the precedence > order in which ACMs are consulted. > > b) A very slight change to the isAccessAllowed() ASI since the > statusInformation would be "success or errorIndication or continue" > for new ACMs. > > c) Updates would be needed to section 3.2 of RFC 3413 step (5) where > isAccessAllowed() is called from Command Responder applications > > d) Updates would be needed to section 3.3 of RFC 3413 step (2) and (3) > where isAccessAllowed() is called from Notification Originator > applications > > Putting my chair hat on, the question is whether ISMS is chartered to > do such a piece of work that affects several core SNMPv3 documents. > So far, work on new access control models was clearly out of scope for > this WG. The proposed new charter text also talks pretty clearly about > "a binding between a user and preconfigured VACM policies via dynamic > additions to the securityToGroupname table." So if this charter gets > approved, I believe the work outlined above falls out of the charter > and we have to come up with some other sensible ways to deal with > conflicts that can happen if RADIUS is asked to overwrite existing > table entries. > > /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 Tue Jun 16 15:19:50 2009 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 33D0228C1C3 for ; Tue, 16 Jun 2009 15:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yzNgVcoA63X for ; Tue, 16 Jun 2009 15:19:49 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 4056328C123 for ; Tue, 16 Jun 2009 15:19:49 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 4amL1c0020cZkys52mL12S; Tue, 16 Jun 2009 22:20:01 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id 4mL11c0040UQ6dC3WmL1cd; Tue, 16 Jun 2009 22:20:01 +0000 From: "David Harrington" To: "'Dave Nelson'" , References: <657B1423308A4454B0CE8A9BC3B92D41@NEWTON603><20090611140545.GA9442@elstar.local><007601c9eab0$fb7da930$0600a8c0@china.huawei.com><20090611171411.GA388@elstar.local><003b01c9ead6$e8e08920$6801a8c0@oemcomputer><20090611225732.GA840@elstar.local><0801A762ABE34A88B3FAF6D09192F5BC@NEWTON603><002501c9ee1b$6f5f1600$6801a8c0@oemcomputer><20090616050156.GA6629@elstar.local><000401c9ee44$1f2d0240$6801a8c0@oemcomputer><20090616072902.GB6719@elstar.local><8E09C8E7F7AC41298C1AAF0979A538C9@NEWTON603><013b01c9ee85$cd6fff60$0600a8c0@china.huawei.com> Date: Tue, 16 Jun 2009 18:20:00 -0400 Message-ID: <018f01c9eed0$96a95da0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnuVc8Kl8jIjfqYTvK3HWeWZgSWPAAJ319QAAIHONAAAMr/sAAAc85w Subject: Re: [Isms] Moving into some design/architecture issuesofExtendedVACM 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, 16 Jun 2009 22:19:50 -0000 Hi, I suggest the RADIUS attributes be stored and associated with a RADIUS-authorized session. When the session goes down, the attributes and the session authorization are deleted. The VACM-RADIUS extension should check whether RADIUS authorization attributes are present and valid or not, much as SSHTM checks whether we have a present-and-valid tmStateRefreence. If the session is closed there will be no authorization attributes available. Representing this in a MIB or an ASI construct helps to standardize this, including the terminology, so we can better check whether independent implementations will have interoperable assumptions. This also makes the job for the WG harder. But this may also make the IESG more comfortable that we have an interoperable solution. An operators might want to be able to see what is happening regarding RADIUS authorizations. I think limiting the MIB-ified part to the VACM user-to-group table, and augmenting the table using standard MIB things, like lifetime objects and RowStatus to indicate/manipulate the entries, as Juergen suggested, could be fairly simple. We might want some type of "void pointer" in the table to the implementation-dependent session-associated authorization information. We already have a "void pointer" tmSessionID in the tmStateReference with which the attributes could be associated in an implementation-dependent manner. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Tuesday, June 16, 2009 9:46 AM > To: isms@ietf.org > Subject: Re: [Isms] Moving into some design/architecture > issuesofExtendedVACM > > David Harrington writes... > > > I think we actually have consensus about persistence. > > > > I think everybody expects that the user-to-group mapping should go > > away when the radius-authorized session ends; ... > > Excellent! > > > ... we just need to figure how to do that without redesigning > > snmpv3 and the rfc3411 architecture. > > I eagerly await suggestions, as I have (temporarily) run out of ideas. > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From cfinss@dial.pipex.com Wed Jun 17 07:06:18 2009 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 3A7843A6BD6 for ; Wed, 17 Jun 2009 07:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 AVra7OMC1EJ9 for ; Wed, 17 Jun 2009 07:06:17 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 0020828C275 for ; Wed, 17 Jun 2009 07:06:15 -0700 (PDT) X-Trace: 258166668/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.79/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.79 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAJ+VOEo+vGlP/2dsb2JhbACDKjyLa7UgB5ApCII1gUsF X-IronPort-AV: E=Sophos;i="4.42,236,1243810800"; d="scan'208";a="258166668" X-IP-Direction: IN Received: from 1cust79.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.79]) by smtp.pipex.tiscali.co.uk with SMTP; 17 Jun 2009 15:06:25 +0100 Message-ID: <000e01c9ef4c$3bba7c40$0601a8c0@allison> From: "tom.petch" To: "Dave Nelson" , References: <05F78AE1AAD94D7186CD6228374C3998@NEWTON603> Date: Wed, 17 Jun 2009 15:02:27 +0200 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] Further ACM design discussions X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:06:18 -0000 ----- Original Message ----- From: "Dave Nelson" To: Sent: Saturday, June 13, 2009 8:30 PM Subject: [Isms] Further ACM design discussions > While we're wrestling with modularity issues, I need to bring up an old > discussion regarding modularity vs. identity bindings. > > We want the Access Control Subsystem to be independent of all other > subsystems, except for the information passed explicitly in ASIs or > implicitly via "caches". Very good. > > The question I want to pose is what's the relationship between the > authenticated identity associated with the Transport Subsystem's protected > session, and the securityName passed into the Access Control Subsystem? > Not sure where you got to with this, but securityName is the name that is used by the application and ASIs throughout the engine, the principal on whose behalf the transaction is performed. Except that we introduced an ASI bypass in the shape of transportAddress which, when in the 'e-mail address' format, can be used by the application to pass another identifier to ssh for use in authentication. A technique that could be used elsewhere to bypass awkward architectural restrictions:-) Tom Petch > We had a debate about whether an authorization service ought to be separate > from an authentication service -- Jeff -- but we know that RADIUS was not > designed with that separation in mind. In fact, RADIUS authorization is > always tied to RADIUS authentication, either directly or indirectly. > > How does the RADIUS data access control information, e.g. > Management-Policy-ID, get to the place where it's needed? Does the RADIUS > client pass that information up through PAM to the SSH server and hence to > SSHTM, which stashes it in a "cache" that some VACM-related function can > later access? Or do we expect that the ACM will somehow cause a second > RADIUS exchange to occur? > > What happens if there is a name-mapping that occurs between the time a > Username Attribute is sent in a RADIUS Access-Request message and > securityName is presented to an Access Control Model? It seems to me that > the data access control information provided by RADIUS is bound to the > Username in the Access-Request, and for correct operation the securityName > presented to the ACM must be similarly bound to the RADIUS-authenticated > identity. > > I need to go back and read our I-Ds, now in the RFC Editor Queue, to refresh > my memory, but I recall all sorts of debate on this list about name mappings > and translations that might occur between what happens in RADIUS and what > happens in ACM. > > From kaushik@cisco.com Wed Jun 17 15:21:56 2009 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 3A9F528C2DF for ; Wed, 17 Jun 2009 15:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 cCigEt5Q1+O3 for ; Wed, 17 Jun 2009 15:21:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 51A9228C1B2 for ; Wed, 17 Jun 2009 15:21:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,239,1243814400"; d="scan'208";a="201641013" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Jun 2009 22:22:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5HMM7cH004198; Wed, 17 Jun 2009 15:22:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5HMM7re013058; Wed, 17 Jun 2009 22:22:07 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 15:22:07 -0700 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Jun 2009 22:22:06 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 17 Jun 2009 15:21:57 -0700 From: kaushik To: Randy Presuhn , Message-ID: Thread-Topic: [Isms] Moving into some design / architecture issues of Extended VACM Thread-Index: AcnvmgaCuKa7ILYDfEKqiUyxMtXIPQ== In-Reply-To: <004201c9eb2c$b09c6e20$6801a8c0@oemcomputer> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jun 2009 22:22:07.0304 (UTC) FILETIME=[0CA6F480:01C9EF9A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3632; t=1245277327; x=1246141327; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Isms]=20Moving=20into=20some=20design= 20/=20architecture=20issues=20of=20Extended=0A=20VACM |Sender:=20; bh=cUuL5U9RmnjoozaCHjWe8BhT3WCrfRI5NoFhYvQ9FSM=; b=yX99fwJRq/wfORWYVadCeOzrTEVopC0RJaZ9T7mlNwOVjfjjh+2Rpazqzs hkYQRpBq3TRcPxHfEzHBVimJT29VnHM5S24oHyZ+ZgKn5pv6OGF11m5ruAWu ivmrLOsG8C; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Isms] Moving into some design / architecture issues of Extended VACM 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, 17 Jun 2009 22:21:56 -0000 Hi Randy, Sorry for the delayed response. I was referring to notion of "authoritative source" really at a system level. A typical environment will have some form of Identity management system, for e.g. An LDAP server, as an authoritative source of user identities and group mappings. RADIUS servers will typically acquire attributes on a per session basis to evaluate network access policies and I was hoping that a similar model could flow down to VACM wherein the group mapping provided by the RADIUS server had the semantics of a temporal read-only attribute. This is probably in line with the model Juergen suggested where we have a separate RADIUS VACM table that store user-to-group mappings received from RADIUS. Regards, kaushik On 6/12/09 12:04 AM, "Randy Presuhn" wrote: > Hi - > >> From: "kaushik" >> To: "Dave Nelson" ; >> Sent: Thursday, June 11, 2009 3:27 PM >> Subject: Re: [Isms] Moving into some design / architecture issues of Extended >> VACM > ... >> The issue I have with this model is that we are using the RADIUS >> user-to-group mapping which is a temporal association valid for the duration >> of the session and provisioning a persistent piece of configuration on the >> SNMP engine. I am not sure the semantics match and this could create >> potential problems around whether the RADIUS server or SNMP engine is >> authoritative source for user-to-group mapping since entries can be added to >> the vacmSecurityToGroupTable without knowledge of the RADIUS server. > > "Authoritative source"? Whoever has the necessary access rights to update > the vacmSecurityToGroupTable is authoritative, as far as VACM is concerned, > and whatever the current configuration of VACM is will govern who can do what > to anything via SNMP. > > The persistance of the information is governed by > vacmSecurityToGroupStorageType. > If the entry already exists, that's already been configured. If a new entry > needs to > be created, 'volatile' is the only type that makes sense. Forcing persistence > does > not make sense. > > I think the crucial point is whether the information coming from the RADIUS > server > is trusted as much as information coming from a security administrator. If it > is, then > updating vacmGroupName with the most recently received information makes > sense. > If the RADIUS server is not trusted as much as a security administrator, then > information > from it should not be used for making user/group mapping decisions. > > It does *not* make sense for the value of vacmGroupName to "revert" upon > termination > of the session or some other condition. Consider the operational scenario > where the > update of the RADIUS server is slightly out-of-phase with a VACM access > control policy push. > Simple update of vacmGroupName will produce the correct answer. Doing a > "revert" > will result in vacmGroupName being *temporarily* updated via RADIUS to the > correct value, > the SNMP push will walk on by, and then the "revert" will restore it to a now > obsolete value. Not good, > so to fix *that* you'd have to add additional state and require the push > application to > write to objects that would appear to already have the correct value. Yuck! > > This isn't netconf. This is SNMP. Let's remember what the "S" is supposed to > stand for. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From Pasi.Eronen@nokia.com Thu Jun 18 11:24:36 2009 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 DE2313A6931 for ; Thu, 18 Jun 2009 11:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 uxi9z7AYEFg7 for ; Thu, 18 Jun 2009 11:24:35 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7D5653A6860 for ; Thu, 18 Jun 2009 11:24:35 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5IIOKGI020979 for ; Thu, 18 Jun 2009 21:24:30 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 21:23:24 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 21:23:20 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 18 Jun 2009 20:23:19 +0200 From: To: Date: Thu, 18 Jun 2009 20:23:17 +0200 Thread-Topic: ISMS recharter, status update Thread-Index: AcnwQdoe3yRtt+s+S82cZo7Tuvkfdg== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6B137953@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jun 2009 18:23:20.0042 (UTC) FILETIME=[DB5A04A0:01C9F041] X-Nokia-AV: Clean Subject: [Isms] ISMS recharter, status update 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, 18 Jun 2009 18:24:37 -0000 The ISMS charter has resulted in significant amount of discussion on multiple lists (isms, ops-dir, aaa-doctors, mib-doctors -- BTW, the archives of the latter two are public if you missed those). As far as I can tell, most of the emails have been about details that do not need to be in the charter, but rather need to be discussed and decided in the WG during the work. I made couple of minor edits to the text based on those emails (current version below), and today the IESG OK'd sending this for=20 IETF review (meaning ietf-announce etc.). If you think further edits=20 need to be made (or the ones I made were wrong), please comment=20 on the ISMS WG list. I will be mostly off-line starting today until July 20. If there are no significant comments, this could be approved by IESG on the July 2 telechat (even though I won't be there). Anyway, this charter text can be used as the current working assumption when preparing for IETF75. In particular, it would be nice to have individual draft(s) for the RADIUS work submitted before the deadlines (July 6 for -00) so it might be possible to approve them as starting points for further WG work in Stockholm. So technical work should not wait for this recharter process to complete. =20 Best regards, Pasi ---------- Integrated Security Model for SNMP (isms) Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the (D)TLS transports for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG ---------- From ietfdbh@comcast.net Thu Jun 18 11:51:09 2009 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 50F943A68DE for ; Thu, 18 Jun 2009 11:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 beaI5fuM8G34 for ; Thu, 18 Jun 2009 11:51:08 -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 07D2E3A68CE for ; Thu, 18 Jun 2009 11:51:07 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 5SNH1c0020mv7h058WrM7k; Thu, 18 Jun 2009 18:51:21 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 5WrL1c00j0UQ6dC3XWrL6U; Thu, 18 Jun 2009 18:51:21 +0000 From: "David Harrington" To: , References: <808FD6E27AD4884E94820BC333B2DB773A6B137953@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 18 Jun 2009 14:51:17 -0400 Message-ID: <00a701c9f045$c33c2c00$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6B137953@NOK-EUMSG-01.mgdnok.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnwQdoe3yRtt+s+S82cZo7TuvkfdgAA7C+g Subject: Re: [Isms] ISMS recharter, status update 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, 18 Jun 2009 18:51:09 -0000 Hi, I am satisfied with this text, with the understanding that the WG might choose to design this as two separate user-to-policy-name tables and a selector table, rather than overloading the existing table. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Thursday, June 18, 2009 2:23 PM > To: isms@ietf.org > Subject: [Isms] ISMS recharter, status update > > The ISMS charter has resulted in significant amount of discussion on > multiple lists (isms, ops-dir, aaa-doctors, mib-doctors -- BTW, > the archives of the latter two are public if you missed those). > > As far as I can tell, most of the emails have been about details that > do not need to be in the charter, but rather need to be discussed and > decided in the WG during the work. > > I made couple of minor edits to the text based on those emails > (current version below), and today the IESG OK'd sending this for > IETF review (meaning ietf-announce etc.). If you think further edits > need to be made (or the ones I made were wrong), please comment > on the ISMS WG list. > > I will be mostly off-line starting today until July 20. If there are > no significant comments, this could be approved by IESG on the July 2 > telechat (even though I won't be there). Anyway, this charter text can > be used as the current working assumption when preparing for IETF75. > > In particular, it would be nice to have individual draft(s) for the > RADIUS work submitted before the deadlines (July 6 for -00) so it > might be possible to approve them as starting points for further WG > work in Stockholm. So technical work should not wait for this > recharter process to complete. > > Best regards, > Pasi > > ---------- > > Integrated Security Model for SNMP (isms) > > Description of Working Group: > > The Simple Network Management Protocol version 3 (SNMPv3) provides > message security services through the security subsystem. Previously > the ISMS Working Group defined a Transport Subsystem definition, a new > Transport Security Model, and a Secure Shell Transport Model and a > method for authenticating SNMPv3 users via the Remote Authentication > Dial-In User Service (RADIUS). The initial body of work to be tackled > by the working group involved only these pieces. Additional work on > other transport models and other security extensions were to wait > until the initial transport architecture and defining documents were > completed. > > It is now possible to authenticate SNMPv3 messages via a RADIUS when > those messages are sent over the newly defined SSH transport. > However, it still remains impossible to centrally authorize a given > SNMP transaction as on-device pre-existing authorization configuration > is still required. In order to leverage a centralized RADIUS service > to its full extent, the access control decision in the Access Control > Subsystem needs to be based on authorization information received from > RADIUS as well. The result will be an extension to obtain > authorization information for an authenticated principal from RADIUS. > The authorization information will be limited to mapping the > authenticated principal to existing named access control policies, > defining session timeouts, and similar session parameters. This > mechanism will not provision the detailed access control rules. > > Additionally, new work will be undertaken to define TLS and DTLS-based > transports that can offer support for environments that prefer > certificate authentication. Certificate based authentication is > desirable for many environments with a centralized authentication > service. DTLS also provides datagram-based transmissions which may be > desired for environments where TCP performance suffers because of > network anomalies (e.g. high packet loss rates). A combination of TLS > and DTLS-based transports offers solutions that addresses both the > need for certificate-based authentication and for datagram-based > delivery. Operators will be able to chose the transport solution that > best meets their needs. > > The current goal of the ISMS working group is two-fold: to develop a > method for allowing for access control decisions to be based on > information provide by an AAA provisioning service and to develop > TLS-based and DTLS-based Transport Models. > > The new work must not modify any other aspects of SNMPv3 protocol as > defined in STD 62 (e.g., it must not create new PDU types). > > The working group will cover the following work items: > > - Specify a mechanism to support centralization of SNMPv3 Access > Control decisions by means of a RADIUS-provisioned policy name > bound to a username, which the VACM extension will use to > dynamically populate the securityToGroupname table. Additionally, > specify a time limit for access decisions, and such a time limit > should be used to garbage collect expired dynamic securityToGroup > mappings. > > - Specify TLS and DTLS transport models for SNMP. > > Goals and Milestones: > > Jul 2009 Publish initial documentation on the (D)TLS > transports for SNMP > Jul 2009 Publish initial documentation for the centralized > access control > Jan 2010 Submit documentation on the (D)TLS transports for > SNMP to IESG > Jan 2010 Submit documentation for the centralized access > control to IESG > > ---------- > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Thu Jun 18 11:54:56 2009 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 8BBC228C2E0 for ; Thu, 18 Jun 2009 11:54:56 -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 b0TFapOkQcZI for ; Thu, 18 Jun 2009 11:54:56 -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 C35093A6981 for ; Thu, 18 Jun 2009 11:54:55 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 875D598180; Thu, 18 Jun 2009 11:55:05 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 56C49399CAA; Thu, 18 Jun 2009 11:55:04 -0700 (PDT) From: Wes Hardaker To: Organization: Sparta References: <808FD6E27AD4884E94820BC333B2DB773A6B137953@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 18 Jun 2009 11:55:03 -0700 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6B137953@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Thu, 18 Jun 2009 20:23:17 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsISMS recharter, status update 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, 18 Jun 2009 18:54:56 -0000 >>>>> On Thu, 18 Jun 2009 20:23:17 +0200, said: PE> I made couple of minor edits to the text based on those emails PE> (current version below), and today the IESG OK'd sending this for PE> IETF review (meaning ietf-announce etc.). Pasi, Thanks for the good news and for pushing forward on it. I'm glad to see progress so that we can try and make the charter deadlines ;-) -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Sat Jun 20 01:10:51 2009 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 9AD3C3A68AF for ; Sat, 20 Jun 2009 01:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_MLH_Stock1=0.87] 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 ULW1UfknUaDv for ; Sat, 20 Jun 2009 01:10:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9A6FE3A67EF for ; Sat, 20 Jun 2009 01:10:50 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7C55C0008 for ; Sat, 20 Jun 2009 10:11:03 +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 MBl+7uLkpibp; Sat, 20 Jun 2009 10:11:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28FB5C0015; Sat, 20 Jun 2009 10:11:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3A9AFB4A457; Sat, 20 Jun 2009 10:11:02 +0200 (CEST) Date: Sat, 20 Jun 2009 10:11:02 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090620081102.GA15326@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] isms meeting at the stockholm ietf 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, 20 Jun 2009 08:10:51 -0000 Hi, I requested a two-hour WG meeting slot for the Stockholm IETF. The ISMS WG meeting is currently scheduled for Monday July 27th in the late afternoon session, 17:40-19:40. The goal of the meeting is to work on the following two items: a) DTLS/TLS transport model(s) We have as starting point for the discussion. Wes, do you plan to submit a revised version by the deadline (July 13th)? b) RADIUS / VACM management policy integration I like to encourage people to submit individual draft(s) that can be discussed during the meeting. The proposals should be in scope with the new ISMS charter currently being reviewed. The deadline for new IDs is July 6th. The meeting should focus on working out and answering the fundamental questions so that afterwards we can concentrate on getting the documents say the right things with the right words - something that can be done reasonably well via the mailing list. Assuming the rechartering process has been completed by the Stockholm IETF meeting, we can have initial WG documents shortly after (or even during) the IETF week. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Sat Jun 20 07:08:37 2009 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 5BFA528C166 for ; Sat, 20 Jun 2009 07:08:37 -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.316, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 ghBR0G8Y8DTI for ; Sat, 20 Jun 2009 07:08:36 -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 5F41928C0DB for ; Sat, 20 Jun 2009 07:08:35 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 6BfY1c00317dt5G55E8qiN; Sat, 20 Jun 2009 14:08:50 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 6E8q1c0054H2mdz3ZE8qin; Sat, 20 Jun 2009 14:08:50 +0000 From: "Dave Nelson" To: References: <20090620081102.GA15326@elstar.local> Date: Sat, 20 Jun 2009 10:08:57 -0400 Message-ID: <7724A4AA898840DC90D44D19605A8239@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090620081102.GA15326@elstar.local> Thread-Index: AcnxfqrFD5plCSW8SGiKVKIYNi/bZgAMMMQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Isms] isms meeting at the stockholm ietf 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: Sat, 20 Jun 2009 14:08:37 -0000 Juergen Schoenwaelder writes... > b) RADIUS / VACM management policy integration > > I like to encourage people to submit individual draft(s) that can > be discussed during the meeting. The proposals should be in scope > with the new ISMS charter currently being reviewed. The deadline > for new IDs is July 6th. It seems possible to do that -- now. I've resisted doing that heretofore for two reasons (a) it would be waste of my time if the revised charter isn't accepted and, more importantly (b) it hasn't been clear the WG has a rough consensus on a design approach. The lengthy debate on the list this past two weeks demonstrates that. In fact, many design details are yet to be worked out. It seems fruitless to write an I-D that's going to be 80% wrong, just to stimulate debate. :-) > The meeting should focus on working out and answering the fundamental > questions so that afterwards we can concentrate on getting the > documents say the right things with the right words - something that > can be done reasonably well via the mailing list. I will not be in attendance at IETF 75 because of schedule and travel limitations. From wjhns1@hardakers.net Sat Jun 20 09:14:07 2009 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 301603A6932 for ; Sat, 20 Jun 2009 09:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 hyHc3Bw1hQjD for ; Sat, 20 Jun 2009 09:14:06 -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 2C39628C12C for ; Sat, 20 Jun 2009 09:13:45 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 3DA34980AA for ; Sat, 20 Jun 2009 09:13:58 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 1A639399CAA for ; Sat, 20 Jun 2009 09:13:57 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20090620081102.GA15326@elstar.local> Date: Sat, 20 Jun 2009 09:13:56 -0700 In-Reply-To: <20090620081102.GA15326@elstar.local> (Juergen Schoenwaelder's message of "Sat, 20 Jun 2009 10:11:02 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismsisms meeting at the stockholm ietf 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: Sat, 20 Jun 2009 16:14:07 -0000 >>>>> On Sat, 20 Jun 2009 10:11:02 +0200, Juergen Schoenwaelder said: JS> a) DTLS/TLS transport model(s) JS> We have as starting point for JS> the discussion. Wes, do you plan to submit a revised version by the JS> deadline (July 13th)? I do have a revised version that I'll likely publish next week that takes into account incorporating TLS. I have a few questions that should accompany it to the working group and would like to use some of the time at the meeting to discuss the certificate to/from securityName mapping. I won't need a full hour, though, so that should give plenty of time to the radius/VACM work which is more contentious at this point. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Jun 24 09:29:56 2009 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 0558F3A6FB6 for ; Wed, 24 Jun 2009 09:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 tplUNudEVNbd for ; Wed, 24 Jun 2009 09:29:55 -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 1D1D53A6FB3 for ; Wed, 24 Jun 2009 09:29:55 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 36DE19810B for ; Wed, 24 Jun 2009 09:30:07 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 812D6399B1B for ; Wed, 24 Jun 2009 09:30:05 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 24 Jun 2009 09:30:05 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] draft-hardaker-isms-dtls-tm-05 submitted 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, 24 Jun 2009 16:29:56 -0000 I've just posted an updated version of my DTLS draft. I've left the name the same until it becomes a WG document after the charter is approved, at which point I'll drop the 'd' in the draft title so it's just '-tls'. The biggest change in this version of the draft is the incorporation of the straight TLS transport in addition to the DTLS transport previously described. Most of the text changes are very straight forward as the text was fairly generically pointed to TLS related features in the first place. In a few places, however, TLS or DTLS are specifically called out. http://www.ietf.org/internet-drafts/draft-hardaker-isms-dtls-tm-05.txt -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Wed Jun 24 10:34:38 2009 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 63C473A6CC8 for ; Wed, 24 Jun 2009 10:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 QtkwV1dh2uYv for ; Wed, 24 Jun 2009 10:34:37 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id E5F873A6CC6 for ; Wed, 24 Jun 2009 10:34:36 -0700 (PDT) X-Trace: 226128027/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.252/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.252 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFALP/QUo+vGn8/2dsb2JhbABEgmc8i2+zfQeQeQmCO4FHBYE0 X-IronPort-AV: E=Sophos;i="4.42,284,1243810800"; d="scan'208";a="226128027" X-IP-Direction: IN Received: from 1cust252.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.252]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Jun 2009 18:33:10 +0100 Message-ID: <000501c9f4e9$40c55000$0601a8c0@allison> From: "tom.petch" To: , References: <808FD6E27AD4884E94820BC333B2DB773A6B137953@NOK-EUMSG-01.mgdnok.nokia.com> Date: Wed, 24 Jun 2009 14:02:56 +0200 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] ISMS recharter, status update X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 17:34:38 -0000 For those who don't track the ssh list, it looks like there is about to be a draft for certificates with ssh, which would give another option for certificate users besides (D)TLS. Tom Petch ----- Original Message ----- From: To: Sent: Thursday, June 18, 2009 8:23 PM Subject: [Isms] ISMS recharter, status update > The ISMS charter has resulted in significant amount of discussion on > multiple lists (isms, ops-dir, aaa-doctors, mib-doctors -- BTW, > the archives of the latter two are public if you missed those). > > As far as I can tell, most of the emails have been about details that > do not need to be in the charter, but rather need to be discussed and > decided in the WG during the work. > > I made couple of minor edits to the text based on those emails > (current version below), and today the IESG OK'd sending this for > IETF review (meaning ietf-announce etc.). If you think further edits > need to be made (or the ones I made were wrong), please comment > on the ISMS WG list. > > I will be mostly off-line starting today until July 20. If there are > no significant comments, this could be approved by IESG on the July 2 > telechat (even though I won't be there). Anyway, this charter text can > be used as the current working assumption when preparing for IETF75. > > In particular, it would be nice to have individual draft(s) for the > RADIUS work submitted before the deadlines (July 6 for -00) so it > might be possible to approve them as starting points for further WG > work in Stockholm. So technical work should not wait for this > recharter process to complete. > > Best regards, > Pasi > > ---------- > > Integrated Security Model for SNMP (isms) > > Description of Working Group: > > The Simple Network Management Protocol version 3 (SNMPv3) provides > message security services through the security subsystem. Previously > the ISMS Working Group defined a Transport Subsystem definition, a new > Transport Security Model, and a Secure Shell Transport Model and a > method for authenticating SNMPv3 users via the Remote Authentication > Dial-In User Service (RADIUS). The initial body of work to be tackled > by the working group involved only these pieces. Additional work on > other transport models and other security extensions were to wait > until the initial transport architecture and defining documents were > completed. > > It is now possible to authenticate SNMPv3 messages via a RADIUS when > those messages are sent over the newly defined SSH transport. > However, it still remains impossible to centrally authorize a given > SNMP transaction as on-device pre-existing authorization configuration > is still required. In order to leverage a centralized RADIUS service > to its full extent, the access control decision in the Access Control > Subsystem needs to be based on authorization information received from > RADIUS as well. The result will be an extension to obtain > authorization information for an authenticated principal from RADIUS. > The authorization information will be limited to mapping the > authenticated principal to existing named access control policies, > defining session timeouts, and similar session parameters. This > mechanism will not provision the detailed access control rules. > > Additionally, new work will be undertaken to define TLS and DTLS-based > transports that can offer support for environments that prefer > certificate authentication. Certificate based authentication is > desirable for many environments with a centralized authentication > service. DTLS also provides datagram-based transmissions which may be > desired for environments where TCP performance suffers because of > network anomalies (e.g. high packet loss rates). A combination of TLS > and DTLS-based transports offers solutions that addresses both the > need for certificate-based authentication and for datagram-based > delivery. Operators will be able to chose the transport solution that > best meets their needs. > > The current goal of the ISMS working group is two-fold: to develop a > method for allowing for access control decisions to be based on > information provide by an AAA provisioning service and to develop > TLS-based and DTLS-based Transport Models. > > The new work must not modify any other aspects of SNMPv3 protocol as > defined in STD 62 (e.g., it must not create new PDU types). > > The working group will cover the following work items: > > - Specify a mechanism to support centralization of SNMPv3 Access > Control decisions by means of a RADIUS-provisioned policy name > bound to a username, which the VACM extension will use to > dynamically populate the securityToGroupname table. Additionally, > specify a time limit for access decisions, and such a time limit > should be used to garbage collect expired dynamic securityToGroup > mappings. > > - Specify TLS and DTLS transport models for SNMP. > > Goals and Milestones: > > Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP > Jul 2009 Publish initial documentation for the centralized access control > Jan 2010 Submit documentation on the (D)TLS transports for SNMP to IESG > Jan 2010 Submit documentation for the centralized access control to IESG > > ---------- > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From j.schoenwaelder@jacobs-university.de Thu Jun 25 01:33:11 2009 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 AA9833A6AEF for ; Thu, 25 Jun 2009 01:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 l1JrVrhKrAVt for ; Thu, 25 Jun 2009 01:33:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4FA663A6ADD for ; Thu, 25 Jun 2009 01:33:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E599C00F2 for ; Thu, 25 Jun 2009 10:29:28 +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 7UutEIPL3DPm for ; Thu, 25 Jun 2009 10:29:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73761C0008 for ; Thu, 25 Jun 2009 10:29:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CB6A6B4FAEC; Wed, 24 Jun 2009 23:52:36 +0200 (CEST) Date: Wed, 24 Jun 2009 23:52:36 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090624215236.GC21229@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted 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, 25 Jun 2009 08:33:11 -0000 On Wed, Jun 24, 2009 at 06:30:05PM +0200, Wes Hardaker wrote: > > I've just posted an updated version of my DTLS draft. I've left the > name the same until it becomes a WG document after the charter is > approved, at which point I'll drop the 'd' in the draft title so it's > just '-tls'. > > The biggest change in this version of the draft is the incorporation of > the straight TLS transport in addition to the DTLS transport previously > described. Most of the text changes are very straight forward as the > text was fairly generically pointed to TLS related features in the first > place. In a few places, however, TLS or DTLS are specifically called > out. > > http://www.ietf.org/internet-drafts/draft-hardaker-isms-dtls-tm-05.txt Thanks for getting this update out. It will be very good if people take a serious look at this document so that we can identify any technical issues to be discussed and resolved at the next IETF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Thu Jun 25 15:30:02 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CCD373A68A4; Thu, 25 Jun 2009 15:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090625223002.CCD373A68A4@core3.amsl.com> Date: Thu, 25 Jun 2009 15:30:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] WG Review: Recharter of Integrated Security Model for SNMP (isms) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@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: Thu, 25 Jun 2009 22:30:03 -0000 A modified charter has been submitted for the Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, July 2, 2009. Integrated Security Model for SNMP (isms) ========================================= Last Modified: 2009-06-18 Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the (D)TLS transports for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG From wjhns1@hardakers.net Tue Jun 30 16:20:27 2009 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 084F03A68AA for ; Tue, 30 Jun 2009 16:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 t1jv8WYlrYMq for ; Tue, 30 Jun 2009 16:20:26 -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 8FFCE3A6987 for ; Tue, 30 Jun 2009 16:20:25 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 3BAFA980F1 for ; Tue, 30 Jun 2009 16:20:45 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id DDBC1399B49 for ; Tue, 30 Jun 2009 16:20:44 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 30 Jun 2009 16:20:43 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] (D)TLS question (#1): selecting a client certificate to use 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, 30 Jun 2009 23:20:27 -0000 Background: I have a few questions about supporting (D)TLS that I'd like to solicit feedback for on the list. I was going to describe them at the IETF too, but I figure starting on the list is probably better as it'll help the discussion process move along more rapidly. So question #1 deals with selecting a client-side certificate for outgoing connections (eg, for notifications originated by a notification generator). Right now client side configuration exists in the SNMP-TARGET-MIB for configuring which remote server to connect to: snmpTargetAddrTable: details about the address to connect to (address, port, timeout, retry, ...) (this table also points to the snmpTargetParamsTable) snmpTargetParamsTable: details about SNMP protocol usage (security model, security name, security level, ...) To open a (D)TLS connection, however, we need to know which X.509 certificate to present to the server in order to authenticate us and (help) secure the connection. For SSH we assumed infrastructure was in place to do client identification certificate selection. For (D)TLS there isn't really a deployed base that has a pre-assigned and pseudo-standardized user-name to certificate mapping database on each system (IE, there is no ~/.ssh/identity.pub file). To solve this problem, the current (D)TLS draft has the following SNMP-TARGET-MIB augmentation table in it (this is obviously abbreviated; please look at the draft for the full MIB definition): tlstmParamsEntry OBJECT-TYPE SYNTAX TlstmParamsEntry AUGMENTS { snmpTargetParamsEntry } TlstmParamsEntry ::= SEQUENCE { tlstmParamsHashType X509IdentifierHashType, tlstmParamsHashValue X509IdentifierHash, tlstmParamsStorageType StorageType, tlstmParamsRowStatus RowStatus } Where X509IdentifierHashType is just a enum of common (current) hashing algorithms (which will probably discussion of which to include and eventually require IANA maintenance). X509IdentifierHash is just a hash of a given certificate to use. IE, the hash is really just a look-up key into an implementation dependent certificate store. [FYI, I asked a number of PKIX folks about the best way to remotely refer to certificates, and they all agreed that a hash lookup is the best way to do it]. I don't think defining a certificate store (and associated upload mechanism!) is within scope of the WG and even if we wanted to do it. (It would fall into the scope of the PKIX WG not ISMS). But we do need a method to perform a lookup given an outgoing connection, which is all this table is trying to do. What do people think of this solution as defined above? The other potential solution I think is possible is a securityName to certificate mapping table rather than augmenting the snmpTargetParamsTable. The USM MIB's user table is an example of how credentials are looked up based on snmpTargetParamsTable data. But, one aspect of using a securityName to certificate mapping table that needs to be dealt with is how to handle the situation where two different connections require two different certificates but the same securityName. This is handled within USM by the securityEngineID being part of the index to the USM User table, but we don't have a securityEngineID available in the ISMS transport solutions. If you like multiple choice style questions, the options are: A) Use the AUGMENTS mechanism as summarized above and defined in the current draft B) Create a securityName to certificate mapping table and solve the single securityName to multiple certificate issue discussed above C) Don't provide any sort of mapping and assume it's implementation-dependent Obviously, because I wrote the draft that way, I think A) is more straight forward. My second choice is B), but I don't like the problem with multiple securityName/certificate combinations. I don't like the idea of C) at all. -- Wes Hardaker Cobham Analytic Solutions From rfc-editor@rfc-editor.org Tue Jun 30 16:57:18 2009 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 D910A3A6ED6; Tue, 30 Jun 2009 16:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.939 X-Spam-Level: X-Spam-Status: No, score=-16.939 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 gZB8+EkPzIdT; Tue, 30 Jun 2009 16:57:18 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 0A0153A6ED5; Tue, 30 Jun 2009 16:57:18 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id CF29C2E057F; Tue, 30 Jun 2009 16:55:07 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090630235507.CF29C2E057F@bosco.isi.edu> Date: Tue, 30 Jun 2009 16:55:07 -0700 (PDT) Cc: isms@ietf.org, rfc-editor@rfc-editor.org Subject: [Isms] RFC 5590 on Transport Subsystem for the Simple Network Management Protocol (SNMP) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 23:57:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5590 Title: Transport Subsystem for the Simple Network Management Protocol (SNMP) Author: D. Harrington, J. Schoenwaelder Status: Standards Track Date: June 2009 Mailbox: ietfdbh@comcast.net, j.schoenwaelder@jacobs-university.de Pages: 34 Characters: 84513 Updates: RFC3411, RFC3412, RFC3414, RFC3417 I-D Tag: draft-ietf-isms-tmsm-18.txt URL: http://www.rfc-editor.org/rfc/rfc5590.txt This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS TRACK] This document is a product of the Integrated Security Model for SNMP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Jun 30 16:57:23 2009 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 12FD03A6EF0; Tue, 30 Jun 2009 16:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.94 X-Spam-Level: X-Spam-Status: No, score=-16.94 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 LWumxvAn7CNr; Tue, 30 Jun 2009 16:57:22 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 5E1F83A6EF5; Tue, 30 Jun 2009 16:57:21 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id A7E552E0581; Tue, 30 Jun 2009 16:55:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090630235513.A7E552E0581@bosco.isi.edu> Date: Tue, 30 Jun 2009 16:55:13 -0700 (PDT) Cc: isms@ietf.org, rfc-editor@rfc-editor.org Subject: [Isms] RFC 5591 on Transport Security Model for the Simple Network Management Protocol (SNMP) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 23:57:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5591 Title: Transport Security Model for the Simple Network Management Protocol (SNMP) Author: D. Harrington, W. Hardaker Status: Standards Track Date: June 2009 Mailbox: ietfdbh@comcast.net, ietf@hardakers.net Pages: 28 Characters: 61747 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-isms-transport-security-model-14.txt URL: http://www.rfc-editor.org/rfc/rfc5591.txt This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP). This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS TRACK] This document is a product of the Integrated Security Model for SNMP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Jun 30 16:57:55 2009 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 97DA83A6EF0; Tue, 30 Jun 2009 16:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.941 X-Spam-Level: X-Spam-Status: No, score=-16.941 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 r-Fu+qmWogHj; Tue, 30 Jun 2009 16:57:54 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id E389F3A6EA2; Tue, 30 Jun 2009 16:57:54 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id B7C072E0583; Tue, 30 Jun 2009 16:55:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090630235533.B7C072E0583@bosco.isi.edu> Date: Tue, 30 Jun 2009 16:55:33 -0700 (PDT) Cc: isms@ietf.org, rfc-editor@rfc-editor.org Subject: [Isms] RFC 5592 on Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 23:57:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5592 Title: Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) Author: D. Harrington, J. Salowey, W. Hardaker Status: Standards Track Date: June 2009 Mailbox: ietfdbh@comcast.net, jsalowey@cisco.com, ietf@hardakers.net Pages: 36 Characters: 82822 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-isms-secshell-18.txt URL: http://www.rfc-editor.org/rfc/rfc5592.txt This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS TRACK] This document is a product of the Integrated Security Model for SNMP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From adonati@motorola.com Tue Jun 30 20:25:39 2009 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 70BB73A6E81 for ; Tue, 30 Jun 2009 20:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 FKQk4dyz1B+v for ; Tue, 30 Jun 2009 20:25:38 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 163183A6E7C for ; Tue, 30 Jun 2009 20:25:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1246418750!36104833!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 16590 invoked from network); 1 Jul 2009 03:25:51 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2009 03:25:51 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n613Po0e004324 for ; Tue, 30 Jun 2009 20:25:50 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n613PnhW002146 for ; Tue, 30 Jun 2009 22:25:49 -0500 (CDT) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n613Pn8k002129 for ; Tue, 30 Jun 2009 22:25:49 -0500 (CDT) 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: Tue, 30 Jun 2009 23:25:26 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] (D)TLS question (#1): selecting a client certificate to use Thread-Index: Acn52WwPgbdQNMFKTJmaQO/ZpuKXPQAH3njw References: From: "Donati Andrew-MGIA0477" To: "Wes Hardaker" , X-CFilter-Loop: Reflected Subject: Re: [Isms] (D)TLS question (#1): selecting a client certificate to use 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, 01 Jul 2009 03:25:39 -0000 Wes, Option A sounds like a good solution. Here are a few observations on option A. =20 -- Since RowStatus and StorageType are already present the snmpTargetParams table, it may be conflicting to have these columns duplicated in the augmenting tlstmParams table. =20 -- If tlstmParamsRowStatus is not used, the modification rules based on the setting of snmpTargetParamsRowStatus for tlstmParams objects may need to be clarified in their respective description clauses. Note that the tlstmParamsRowStatus description states that "The value of this object has no effect on whether other objects in this conceptual row can be modified" and the values for objects in the snmpTargetParams table cannot be set if the RowStatus is active. -- The tlstmParamsHashValue object may need to have a default value defined. =20 Andy Donati Motorola HN&M -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Wes Hardaker Sent: Tuesday, June 30, 2009 7:21 PM To: isms@ietf.org Subject: [Isms] (D)TLS question (#1): selecting a client certificate to use Background: I have a few questions about supporting (D)TLS that I'd like to solicit feedback for on the list. I was going to describe them at the IETF too, but I figure starting on the list is probably better as it'll help the discussion process move along more rapidly. So question #1 deals with selecting a client-side certificate for outgoing connections (eg, for notifications originated by a notification generator). Right now client side configuration exists in the SNMP-TARGET-MIB for configuring which remote server to connect to: snmpTargetAddrTable: details about the address to connect to (address, port, timeout, retry, ...) (this table also points to the snmpTargetParamsTable) snmpTargetParamsTable: details about SNMP protocol usage (security model, security name, security level, ...) To open a (D)TLS connection, however, we need to know which X.509 certificate to present to the server in order to authenticate us and (help) secure the connection. For SSH we assumed infrastructure was in place to do client identification certificate selection. For (D)TLS there isn't really a deployed base that has a pre-assigned and pseudo-standardized user-name to certificate mapping database on each system (IE, there is no ~/.ssh/identity.pub file). To solve this problem, the current (D)TLS draft has the following SNMP-TARGET-MIB augmentation table in it (this is obviously abbreviated; please look at the draft for the full MIB definition): tlstmParamsEntry OBJECT-TYPE SYNTAX TlstmParamsEntry AUGMENTS { snmpTargetParamsEntry } TlstmParamsEntry ::=3D SEQUENCE { tlstmParamsHashType X509IdentifierHashType, tlstmParamsHashValue X509IdentifierHash, tlstmParamsStorageType StorageType, tlstmParamsRowStatus RowStatus } Where X509IdentifierHashType is just a enum of common (current) hashing algorithms (which will probably discussion of which to include and eventually require IANA maintenance). X509IdentifierHash is just a hash of a given certificate to use. IE, the hash is really just a look-up key into an implementation dependent certificate store. [FYI, I asked a number of PKIX folks about the best way to remotely refer to certificates, and they all agreed that a hash lookup is the best way to do it]. I don't think defining a certificate store (and associated upload mechanism!) is within scope of the WG and even if we wanted to do it. (It would fall into the scope of the PKIX WG not ISMS). But we do need a method to perform a lookup given an outgoing connection, which is all this table is trying to do. What do people think of this solution as defined above? The other potential solution I think is possible is a securityName to certificate mapping table rather than augmenting the snmpTargetParamsTable. The USM MIB's user table is an example of how credentials are looked up based on snmpTargetParamsTable data. But, one aspect of using a securityName to certificate mapping table that needs to be dealt with is how to handle the situation where two different connections require two different certificates but the same securityName. This is handled within USM by the securityEngineID being part of the index to the USM User table, but we don't have a securityEngineID available in the ISMS transport solutions. If you like multiple choice style questions, the options are: A) Use the AUGMENTS mechanism as summarized above and defined in the current draft B) Create a securityName to certificate mapping table and solve the single securityName to multiple certificate issue discussed above C) Don't provide any sort of mapping and assume it's implementation-dependent=20 Obviously, because I wrote the draft that way, I think A) is more straight forward. My second choice is B), but I don't like the problem with multiple securityName/certificate combinations. I don't like the idea of C) at all. -- Wes Hardaker Cobham Analytic Solutions _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms