Re: Configuring Community Names

["Aleksey Y. Romanov" <[e-mail]>]

> 
> The original message on this thread was a about configuring community
> strings, a V1 concept.  Hence my principle text was how one might do
> some V2 things in V1.
> ...
>
> 			--karl--
> 

I would like to explore the inverse of this idea; that is, how to make
V1-like things under V2. The general idea is to define a subset of 
the V2 security/authentication mechanism which is the functional 
equivalent of V1 as to both (1) requirements on the underlying 
agent and (2) community-based security.

IMHO, it seems to me that it is worth while at least to check how 
feasible it is. So, do not beat up on me too much if it is wrongheaded.

Let us consider the agent with IP address a.b.c.d. I will denote
the party identified by initialPartyId.a.b.c.d.n as party.n,
context identified by initialContexId.a.b.c.d.n as context n, and
the collection of view entries with viewIndex equal to n as view.n

Let us assume that there is a reserved set of parties, contexts, acls and
views.

This reserved set consists of:

party.n    n=10, 11, ..., 41   partyAuthProtocol is v2md5AuthProtocol,
partyIndex is n

context.n  n=10, 12, ..., 40   contextViewIndex is n (*), contextIndex is n

view.n     n=10, 12, ..., 40

There is an appropriate set of acls.
This set of acls is providing read level privileges to:
    aclTarget    --   n
    aclSubject   --   4
    aclResources --   n
  
and read write level privileges to:
    aclTarget    --   n+1
    aclSubject   --   4
    aclResources --   n

and response level privileges to
    aclTarget    --   4
    aclSubject   --   n
    aclResources --   n

and response level privileges to
    aclTarget    --   4
    aclSubject   --   n+1
    aclResources --   n
 
n = 10, 12, ..., 40 


There is a choice of several levels of implementation.

1. Parties, contexts, views and acls are restricted to iniitial set
   and reserved set. The reserved set is set up upon startup of the agent
   and cannot be changed. This is in my view a very close mapping of
   V1 functionality on V2. It will not require too much from agent
   to support this type of security. The partyAuthPrivate is playing
   the role of community string in the case. So for each NMS, three
   secrets will define its maximum level of read-only and 
   read-write access to the agent and its possibility to authenticate
   responses from this agent. It is possible to make it look very 
   close to community based approach if parties.n residing in the 
   several agents have the same secret value assigned to each of them.
   As in case of V1 it requires sneakernet for secret distribution
   and changing.

2. The same as level (1) + party.3 can change partyAuthPrivate values.

3. The same as level (2) + party.3 can delete and create reserved
   entries. IMHO, this level is simple enough to handle but flexible
   enough to satisfy 90 percent of real-world cases.

4. The agent compliant with full blown partyNoPrivacyCompliance.

...


IMHO, It is reasonable to establish some restrictions on
the contexts and views wich can be used as a reserved entries.

Context limitations: no local entities, and no proxies because of (*)
above.

Let us call the viewEntry a simple viewEntry if its viewMask element is
''H (means no wild cards) and its viewType is included. Let us
call view a simple view if it consists of simple viewEntries.

It seems reasonable to me to restrict views in the reserved set to
simple views.

Aleksey