Re: Configuring Community Names

[Keith McCloghrie <[e-mail]>]

> "by assertion" Could we please leave this kind of negative language
> out of this discussion?
 
You might find it interesting to reread some of your own messages :-)
 
> 	  I think I mentioned that the V2 mechanism for
> 	  authentication, i.e. the authenticaiton wrapper, is better
> 	  than using MIB variables.  If I didn't, then I should have.
 
Thanks.

> 	- The variable based authentication mechanisms *can* be used
> 	  for GET/GETNEXT as well as for SET.  They are just clumsy.
> 	  Again, all I'm pointing out is that it was *possible* in V1.
 
Maybe you have a neat idea which has not occurred to me, but I don't
think this is true.  However, since you are happy with the V2
mechanisms, it's not worth us arguing the point (but see below).

> > As you yourself have pointed out on many occasions, products which
> > employ encryption may be export controlled, and it is illegal to
> > send encrypted data across some country boundaries.  That's why
> > encryption is not used for the protection of SNMPv2 secrets.  
> 
> I don't agree with your point that the V2 xor mechanism is not
> encryption and is hence not controlled.
> 
> I do not see why the x-or mechanism is any less subject to export
> controls or transboarder data flow rules than DES (indeed, being
> closer to a one-time pad, it may even more controlled than DES.)
 
I claim that the value of partyAuthPrivate (or partyPrivPrivate) are
not an encrypted version of a secret, but rather a specification of 
a requested change in a value which happens to be a secret.

Consider, if we added a new PDU type, called the Increment-PDU, which
would only accept read-write INTEGER objects in its var-bind-list, and
which had the semantics that the values in the var-bind-list were to be
ignored, but that every object named in the var-bind-list was to have
its value incremented by one, would that be an encryption ?  I think not.

Or even if the varbind-values were not ignored, but rather specified
on a per-varbind basis, by how much that object was to be incremented.
I still think this is not encryption.  I claim that the definition of
partyAuthPrivate and partyPrivPrivate are equivalent in terms of
non-encryption to my hypothetical Increment-PDU.

Note that I couldn't (or at least, it would be harder) to make this
claim if retrieval was done as the xor of the current value with some
other value, which in V2's case it is not.  (This is the basis of my
Get/GetNext disagreement above.)

>  > Also, I believe that the manual distribution of secrets will be the
>  > biggest burden of security.  Any reduction (small or not) in the need
>  > for sneakernet can only be an advantage.
> 
> That is a very major point.  ...
> 
> You have focused on two of the mechanisms, which in my mind are some
> of the most positive secure/administrative improvements suggested by
> V2.  The new packet format, with it's authentication wrapper is a
> major improvement over V1.  The party and clock mechanism is almost
> certainly going to be proven universally necessary.  The X-or trick
> is a great idea.
 
I believe I focused on the two specific points for which you raised 
"complexity" questions in your last message.

> But that leaves a large amout of administratave MIB that may or may
> not be worth the cost.  
 
Ok, so now, apart from wanting to see some implementation experience of
clocks (which is fine by me), you take back all your previous comments
about the "complexity of V2" except for two points: 

1.
>                    ...  The questions really revolve around the need
> to dynamically create views and parties and access lists and proxies
> and such.

2.
> And there is the open issue whether the conformance guidelines are
> adequate to allow pruning.
 
I think your second point is correct.  One of the purposes of adding
the xxxStorageType objects was to allow 'permanent' entries, in the
viewTable in particular, and thus an agent shouldn't be required to
provide write access to the viewTable.  So, the conformance macros in
RFC 1447 are too simple - instead of specifying partyMibGroup as a
MANDATORY-GROUP, they should specify it as GROUP and specify which
objects do not need to be writeable, e.g., the viewTable objects.
Some aspects of the contextTable fall into the same category, e.g.,
I suggest the only value which needs to be writeable for contextLocalTime
is currentTime.

As for dynamically creating parties, I claim that while it's not useful 
to dynamically create parties for an unSecurableCompliance agent (and
thus, that conformance macro is also wrong), it *is* useful to create
parties for any agent implementing MD5, specifically for the purpose of
reducing the need for sneakernet (which you agreed above is "a very
major point").  In particular, for an agent with multiple managers
(would you agree that every agent shoudl support multiple managers ?),
the secrets for the first authenticated party-pair can be setup using
sneakernet, and subsequent party-pair(s) for subsequent managers can
be setup by dynamically creating the parties.  (For aclTable entries,
the need or not to create entries follows directly from the need or
not to create parties.)

The proxy stuff is also optional.  People were confused in V1 as to 
how to do proxy.  V2 is very explicit on this, and it is *essential*
that it be defined, specifically because it's one of the mechanisms
specified for co-existence and transition from V1 to V2.

So, that leaves "access lists" as the last on the list of items you 
raised.  Given our need to have noAuth/noPriv as well as authenticated
requestors, then we have to be able to specify what the noAuth/noPriv
can and can't do.  So, we obviously need some kind of access lists.
There are two aspects to specifying access: the type of operation, and
the objects which can be accessed.  Unless you're willing to say that
all noAuth/noPriv managers have read access to everything, then we need
both.  [As an aside, I recently saw a message from the NSFnet backbone
people saying they had reduced what can be read via the public
community-string, so there's obviously an opertional need.]

So, our exchange has been worthwhile, and for that I thank you.  You
have pointed out that the conformance macros for the Party MIB are
broken.  Would you like to suggest what they should be, or shall I do
that ?

Keith.