Subject: Re: VACM and DISMAN

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 07 Jul 1998 08:05:12 -0400

for my money (and UUNET's), we believe that time-varying
role-based security policy is the only way you deal with
humans, which is very distinct from network elements.

for example, a network operator on duty may have
significant access rights to test and reconfigure a network
element, but when the person goes off-shift, they must lose
those rights.

the only way to do this rationally is to do the mapping of
person-role-time-rights *mostly* in NMS software which sits
between the operator and the network elements.

the machinery in SNMPv3 supports identity-rights mappings,
and that is sufficient given the interposed NMS software
which uses a set of identities instantiated in the network
elements to map a given person performing a specific role
at a certain time into a set of required access rights.
Note that the "time" part is *only* done in the NMS -
that's waaaaay too messy to put in network elements because
of things like time zones, shift changes, etc, etc.

while one can describe all kinds of access control policies,
the question is one of partitioning - how much is supported
directly by the network element and how much by layered NMS
functionality.  

Until proven otherwise, we are proceeding with the firm
belief that what's currently in SNMPv3 is enough mechanism
upon which to build the complex policy machinery we need using
external software, and that making the mechanism inside
the network elements more complex is probably at the point
of diminishing returns, for all the reasons Bert mentioned.

	-mo

---

From: Rob Frye <[email-masked]>
Date: Wed, 15 Jul 1998 13:56:09 -0400

>humans, which is very distinct from network elements.

Agreed, Mike.

Bert Wijnen said:
>I know that SNMpv3 allows me to add/delete users via SNMP.
>Now imagine, that I get a new employee Joe. WHat do I do?
>Do I want to add user Joe to all my SNMP engines (say some 10 or 100
>thousand)? That may take a while before it is complete.
>Then... after a few months, Joe decides to go and work somewhere else.
>Do I then delete user Joe at those 10 or 100 thousand SNMP engines?
>
>I would rather have a NMS that internally uses SNMP-users in the form
>of "operator-role", "networ-admin-role", "senior-role", "junior-role",
>"security-admin-role" and so on. I would then want the NMS to
>let me add a user Joe and tell the NMS that Joe gets to work with
>the "junior-role" for now... maybe later as the "senior-role" once he
>proves he is good and can be trusted.
>between the operator and the network elements.

One problem with relying on the NMS software to translate "joe"
to "junior-role", "operator-role" or "senior-role" is that it
is also doing that for users "fred", "sam", "sally" and the
rest.  Unless the NMS is the only way that these users can
and do access the network elements (not counting your 3rd-level
network gurus who telnet in when all else fails), you have
somewhat of an audit trail problem.  If the agent records
the fact that "senior-role" changed X to Y at time T,
and someone is pulling out their hair trying to figure out
why the network went down at time T, it's awfully hard
to find out it was "joe" rather than "sam".  And for a
"real network-manager" in a BIG company (per Bert), the
ability to know who changed what when is important.

I agree that the NMS needs to handle the time domain aspects,
and that the roles and individuals are known there.  But I
don't like having all users mapped to roles, where only the
role-level security is known to the Agents.  The configuration
complexities have been noted by Juergen, T. Max, Keith and others;
my reading says its a fairly close tradeoff, with more and
more complexity using group mappings in a fluid environment.

-- Rob.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rob Frye ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sr. Network Management Architect   Email:             [email-masked]
MCI Telecommunications Corp.       Phone: +1-703-715-7225/V272-7225
2100 Reston Parkway, Suite 600     Fax:             +1-703-715-7436
Reston, VA  20191                  Pager:           +1-888-270-1537
~~~~~~~~~~~~~~~~~~~~~~~~Procrastinate Later~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Mike O'Dell" <[email-masked]>
Date: Wed, 15 Jul 1998 14:50:03 -0400

if the NMS is doing the authority mapping and not keeping
audit trails, the implementation is deeply defective

	-mo

---

From: Jochen Friedrich <[email-masked]>
Date: Wed, 15 Jul 1998 23:40:00 +0200 (CEST)

> audit trails, the implementation is deeply defective

Sure. But now these NMS audit trails become very important. If they get
lost (either by accident or on purpose), it's no longer possible to trace
back to the original user. 

In the case of the agents doing the mapping, it's much harder to
manipulate all audit trails.

Jochen

---

From: Uri Blumenthal <[email-masked]>
Date: Sun, 19 Jul 1998 22:03:33 -0400 (EDT)

> > audit trails, the implementation is deeply defective

No argument.

> manipulate all audit trails.

It is worse than that. A sound security approach is for the OWNER of (or the
CONTROLLER of the access to) the information to do the logging - otherwise
it's like expecting a rogue banker to keep an audit log of all the cheats
he'd done...
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: Uri Blumenthal <[email-masked]>
Date: Tue, 21 Jul 1998 00:27:37 -0400 (EDT)

Mike O'Dell says:
> humans,

Yes, but are you willing to pay the performance/code-size price
for the privilege of having such a policy? Plus, do you realize
that the only place to keep the "decider" code is in the data
owner, i.e. that "network element" which you refer to below:

> ......... which is very distinct from network elements.

> between the operator and the network elements.

If NMS does the mapping, you (a) may lose the proper audit trail
and (b) may have to restrict management operations to certain
installed NMS.

> at a certain time into a set of required access rights.

This is not a role-based Access Control. It's a role-based NMS.
Now, maybe that's all that is required?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 21 Jul 1998 07:23:15 -0400

no no no no

the network element does NOT need to do the deciding

	-mo

---

From: Uri Blumenthal <[email-masked]>
Date: Tue, 21 Jul 1998 11:34:18 -0400 (EDT)

> the network element does NOT need to do the deciding

In that case your idea of access control has nothing in 
common with that of mine.  To me if the network element
has the data to be accessed,  then the only place where
access control can be done securely is that net.element.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 21 Jul 1998 13:29:13 -0400

of course you are right in the limiting case

however, *all* access control need not be done in the element,
especially if there are rich semantic policies needed.
all you have to do is have an adequate partitioning whereby
enough simple mechanisms exist in the element to allow
implementation with the heavy lifting done elsewhere

	-mo

---

From: Uri Blumenthal <[email-masked]>
Date: Tue, 21 Jul 1998 14:38:42 -0400 (EDT)

> implementation with the heavy lifting done elsewhere

If you have it roughly figured out, why don't you post an outline
of what actions are to be taken and by what entities, when doing
access control? Furnishing as many details as you can?

Because at this point it sounds more like a sales pitch than a technical
proposal  (i.e. "simple enough", "adequate partitioning" etc. are rather
subjective terms and have no meaning until you tell what exactly you
want the things to look like).
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 21 Jul 1998 15:04:07 -0400

i don't need any more mechanism than what's already there.

the management interface maps User X Role -> AccessPartition
based on time, policy, presented credentials, etc.
of course it keeps records of all such mappings granted
as well as all activities performed after the granting.

the network elements have identies for the full set of
AccessPartitions (which is much smaller than User x Role)
and the credentials for access via one of those partition 
identities is maintained *solely* by the management software,
which actually performs the accesses on behalf of the authorized
user in his role.

the management software effectively allows a given user to
take on a given role at a particular time, and all the
mediation required to execute the policy is only in the
management interface software.

the only identities defined in the network elements are the
members of equivalence classes which cover the required rights.

i assume what you believe is a full "role-based model"
involves doing general capability vector algebra.  such
models are frequently operationally incomplete as that they
don't generally support time-varying policy except via
exogenous mediators (which is exactly what i'm proposing),
and they require the maintainence of a large amount of
distributed state which is not required for this purpose.

yes, i understand that what i suggest is not as general,
but that's fine - 
	"You don't need to boil the ocean just to get a poached fish."

so can we please get on with getting done??

	-mo

---

From: Uri Blumenthal <[email-masked]>
Date: Tue, 21 Jul 1998 15:43:49 -0400 (EDT)

> based on time, policy, presented credentials, etc.

So the principal for network elements will be AccessPartition?
OK by me.

> AccessPartitions (which is much smaller than User x Role)

OK here.

> which actually performs the accesses on behalf of the authorized

Management software does not perform any access. It requests the 
operation to be performed (and thus the access to be granted) by
the network element(s).

You want the NMS to authenticate a principal and map him onto the
proper group (privileges-wise, time-wise etc.)? That's doable, of
course.  But it means that you must come in through NMS (and not
via a shell script, for example).  It also means that the data
owner does not have the ability to trace who did what to it.
If you can live with it, so can I.

> members of equivalence classes which cover the required rights.

Fine, in light of the above.

To summarize:

	- The "network elements" have "roles" defined as principals,
	  with the correspondign access rights;

	- the NMS authenticates the users and maps the requests to
	  the appropriate "roles";

	- the network elements authenticate requests issued by the
	  "roles";

	- the NMS logs who (a user) did what, the network elements log 
	  what role did what;

	- the network elements share secrets with the NMS(s) only,
	  not with the users, and thus are accessible only via NMS.

Does it represent accurately what you meant?

What do the others think?

> involves doing general capability vector algebra......

I believe in God and in using correct terminology - no other 
assumption about my beliefs is reliable (:-).

I don't care  whether the accepted approach is a full role-based
model, a partial one, or even a remotely similar. I do care that
all the i's are dotted and all the t's are crossed, when the
model - whatever it is - is specified. That's all.

> so can we please get on with getting done??

Enjoy your poached jellyfish then.  
[Oh, and from my prospective, we *are* done.]
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 21 Jul 1998 17:16:54 -0400

as for what I believe,

	"I believe I'll have another beer."

	cheers
	-mo