Subject: Re: [Isms] Evaluation status [and more]

From: Wes Hardaker <[email-masked]>
Date: Tue, 01 Feb 2005 07:08:17 -0800

>>>>> On Mon, 31 Jan 2005 18:35:15 -0500, "Nelson, David" <[email-masked]> said:

David> I believe that authorization *needs* to be strongly bound to
David> authentication, to be robust and trustworthy.

I think we've hashed this argument enough before and the different
viewpoints on the subject are already known.  Everyone does agree with
the above statement to the extend that it must be possible for the
authorization system to trust the authentication system to (securely)
hand it information about how a request/response was authenticated and
using what security mechanisms.  Everyone is in agreement there.

>> I would not mind, personally, if the charter were updated to 
>> include such future work as well but right now we haven't 
>> actually accomplished the immediate goals of determining an 
>> architectural direction to solve the current problem.

David> Agreed.  We need to keep the pressure on to complete current
David> goals. That doesn't mean that authorization is unimportant,
David> however.

And there!

-- 
Wes Hardaker
Sparta

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 1 Feb 2005 10:23:50 -0800

Wherever I turn I keep bumping into requirements such as "separation of
duties with least privilege" or "security zones" (e.g., subdomains
within a deployment with more stringent (or unique) security
requirements) which are increasingly being met by techniques such as
Role Based Access Control (RBAC) technologies. "Public", "private" and
"superuser" can be viewed as possible RBAC roles. 

Regardless, the point I want to make is that the system we are devising
is more powerful -- and more useful -- if it is easily extended to
support arbitrary (from the ISMS perspective) RBAC authentication and
access control groupings, leveraging one or more of the deployments'
existing authentication systems. I do not think that the system should
presume or require RBAC. I rather believe that a possible requirement is
that it should be configurable to be able to operate in RBAC
environments when needed.

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Monday, January 31, 2005 5:10 AM
To: 'Wijnen, Bert (Bert)'; 'Martin Soukup'; 'David T. Perkins'
Cc: [email-masked]
Subject: RE: [Isms] Evaluation status [and more]

<snip>

People who have always managed their networks using communities need to
change their mindset to think in terms of views and contexts and groups.
Think about the large number of people who run using the current
defaults of "public", "private" and "superuser" communities because the
vendors didn't make it easy to change the community names on their
devices, or because SNMP security hasn't been their highest priority
because there are so many other security problems they need to work on.
And if you get the migration from communities to context, views, and
groups wrong, they could endanger the security or the manageability of
the network. And you expect them to just "grok" VACM from the examples
in the appendix of RFC3415?

<snip>