Subject: Re: Proposed Update to Netconf Charter

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Jun 2005 12:44:11 -0700

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: <[email-masked]>; "Sharon Chisholm" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 30, 2005 9:27 AM
> Subject: RE: Proposed Update to Netconf Charter
...
> I agree with Juergen on this. In an ideal world I would see the issue of
> access control being dealt with in a common framework with isms, but I
> am quite uncertain right now about where isms is - even with respect to
> its initial goals.
...

The only bits to worry about from isms are whether the identification of
principals and security levels will be compatible with existing SNMP security
models, along with whatever configuration data is needed to support the
use of the new security model(s).

I'm increasingly doubtful that we'll ever see vendor-neutral mappings
between SNMP contexts and OID regions to things in netconf-land, much
less a way of ensuring that netconf security policies and, for example, VACM
policies are logically consistent.  To make this practical, we'd need an
an algorithmic way to relate arbitrary vendor-specific chunks of XML to
constellations of SMI objects.  Even if fancy XSLTs might do the job,
who would actually write these things?

However, those aren't specifically isms issues.  The current isms charter
makes a point of not addressing access control.  Short of starting a new
WG, the place to do the netconf access control work is here in netconf,
unless we just leave it to the vendors as a means of product differentiation.

Randy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Mazumdar, Subrata \(Subrata\)" <[email-masked]>
Date: Wed, 6 Jul 2005 08:33:32 -0400

Hi!,
I think that Andy's proposal for two tier security is very much similar 
to Deployment Descriptor based (read XML) J2EE (declarative) security model 
for Web and EJB container. 
J2EE security model is role-based and defined in XML.  
(For more info, see Chapter 32 in J2EE http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html)

The Web-container security model allows patterns in URLs as target resources 
and permission can be customized for individual operation (GET/POST etc). 
The EJB security model allows method (getter/setter for attribute) based 
target definition for access control and it is completely meta-data driven.
I believe that the J2EE declarative 
security model really fits your need for simple model to start with. 

I believe that it is not going to be very difficult to map the SNMP VACM to RBAC 
so that netconf AC is compatible with SNMP v3 VACM. 

--
Subrata 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, July 06, 2005 5:55 AM
To: Vincent Cridlig
Cc: [email-masked]; [email-masked]; Radu State
Subject: Re: Proposed Update to Netconf Charter

On Wed, Jul 06, 2005 at 11:36:13AM +0200, Vincent Cridlig wrote:
> Let me give more details about what I proposed.
> 
> The prefix concept is well defined in the XPath recommendation. I didn't 
> invent this concept and I don't want to change XPath.
> 
> Using XPath prefix needs a namespace declaration. This is why I 
> suggested to add some namespace declaration along with the Netconf request.
> In fact, I might be wrong but I think it is not possible to fully 
> support XPath without making it possible to send these declarations. 
> These declarations are needed to build the expression context as 
> described in the XPath recommendation.
> If a manager sends an XPath request which contains prefixes, I don't 
> know how an agent could guess the related (real) namespace URI.

Thanks for this clarification. This now sounds much more reasonable.
I guess I have to go back to the XPath specs.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany