RE: [xacml] Comments on BSR INCITS 359 - Role Based Access Control - DRAFT 4/4/2003

["John Hughes" <john.hughes@entegrity.com>]

Barbara,

you can if you wish - although its basically the same as I originally
submitted to you.


John

-----Original Message-----
From: Bennett, Barbara [mailto:bbennett@itic.org]
Sent: 19 June 2003 16:56
To: John Hughes
Cc: Rick Kuhn (E-mail); David Ferraiolo (E-mail) (E-mail); Hal Lockhart
(E-mail); Ramaswamy Chandramouli (E-mail); John Barkley (E-mail);
rbac-info@nist.gov; XACML TC (E-mail); alicia clay (E-mail); Hogan, Mike
Subject: RE: [xacml] Comments on BSR INCITS 359 - Role Based Access
Control - DRAFT 4/4/2003


Dear John,

Should this response to Hal be treated as Late comments submitted on the
public review of INCITS 359?  The public review period was extended from 45
days to 60 days and ended on June 17, 2003.

Please advise.

Barbara Bennett
Associate Manager, Standards Operations, INCITS
Tel: 202.626.5743; Fax:  202.638.4922
Email: mailto:bbennett@itic.org
http://www.incits.org



> ----------
> From: 	John Hughes
> Sent: 	Thursday, June 19, 2003 3:55 AM
> To: 	Hal Lockhart; Bennett, Barbara
> Cc: 	Rick Kuhn; David Ferraiolo; Ramaswamy Chandramouli; John Barkley;
rbac-info@nist.gov; XACML TC
> Subject: 	RE: [xacml] Comments on BSR INCITS 359 - Role Based Access
Control - DRAFT 4/4/2003
>
> Hal,
>
> I agree with your comments - and in my separate submission to Barbara I
have
> stated that RBAC should be extended to be "Policy Based Access Control" -
> PBAC.  In the document I provided I argue that PBAC is a superset of RBAC
> and illustrates how the RBAC model is extended to become PBAC.
>
> If any one is interested we have a white paper on the subject on our web
> site, or just email me and I will provide a copy.
>
> John
>
>
> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: 18 June 2003 22:45
> To: Barbara Bennett
> Cc: Rick Kuhn; David Ferraiolo; Ramaswamy Chandramouli; John Barkley;
> rbac-info@nist.gov; XACML TC
> Subject: [xacml] Comments on BSR INCITS 359 - Role Based Access Control
> - DRAFT 4/4/2003
>
>
> I applaud NIST and ANSI efforts to promote Role Based Access Control. I
> agree that specifying Access Control rules in terms of attributes that
> aggregate individual users is essential to building effective security
> solutions for large-scale environments. However, I have some concerns with
> the specification as it exists today. Two of them concern technical
aspects
> of the specification and one applies more generally.
>
> 1. The RBAC model presented in this specification is a limited one that
does
> not meet all the requirements of modern Access Control Policies. For
> example, it is necessary to be able to specify access control policies
based
> on environmental conditions, such as the date, time or day of the week or
> the network location from which the access request is being made. Further,
> while this RBAC model considers the Roles of the entity making the access
> request, it is frequently necessary to consider the attributes of other
> participants in the interaction. For example, in a healthcare environment,
a
> patient may request that his or her medical records be transmitted to a
> specialist physician. The decision to grant the request in this case may
> depend on both the attributes of the requester (patient) and the recipient
> (specialist) of the data. Another example is controlled delegation, where
> both the attributes of the original requester and the attributes of the
> delegated intermediary must be considered in making an access control
> decision.
>
> 2. This specification seems to be envisioned for small scale, homogenous
> environments. It seems to ignore many of the requirements of large-scale
> environments, however it is exactly these environments in which an RBAC
> model is most useful.
>
> For example, the administrative APIs specify creating roles and users, but
> large-scale environments typically contain a federation of repositories
> based on different technologies, vendor products and administrative
> interfaces. It seems unrealistic to believe that all roles and users can
be
> created by the same simple interface. Similarly, the environment will
> contain a variety of operating environments. It seems unrealistic that a
> single simple interface can be used to enable session roles across many
> different environments.
>
> A second example is the use of nested roles. In large-scale, federated
> environments, information about role membership is likely to be widely>
> distributed and managed by autonomous organizations. The performance
> implications of multiple distributed accesses in order to resolve nested
> role membership, not to mention the issues of detecting cycles in the
> definitions would seem to make this kind of functionality impractical,
> unless some arbitrary restrictions are imposed on the generality of nested
> roles.
>
> A third example is the user permissions and role permissions APIs. In a
> large scale environment an individual or role might have millions of
> permissions that could only be determined by polling thousands of servers.
> While determining whether a particular access should be allowed could be
> done efficiently, determining all the permissions available to a given
user
> or role would take an impractical amount of time, typically so long that
> some of the permissions would most likely have changed before the
> information could be compiled. Here again it would seem necessary to
impose
> arbitrary constraints on the request to make it practical.
>
> 3. My most important concern is about the plan for standardization. It is
my
> understanding that the intention is to make the current specification an
> ANSI standard, but not to further develop the specification. But
information
> technology standards today are generally understood to enable either
> interoperability or portability or both. A standard should allow testing
> which makes it possible to unambiguously determine if an implementation
> conforms to the specification or not.
>
> However, this specification does not provide for interoperability or
> portability. The specification talks about conformance, but I do not see
any
> objective way of determining whether a piece of software complies with the
> specification or not. My concern is that if this specification becomes an
> ANSI standard, compliance to it will be designated as a mandatory
criterion
> for procurement both by federal agencies and private corporations. In this
> event, vendors will be forced to develop their own proprietary
> implementations, which perforce will not interoperate. Once these
> implementations have been developed, vendors will be reluctant to abandon
> them, particularly since their proprietary nature will act as a barrier to
> entry to competitors. If this occurs it will be against the interests of
the
> government and the industry in general.
>
> In my opinion, it would be far preferable to choose one of two alternative
> approaches. Either change the term describing this specification from
> Standard, to some more neutral term, such as Recommendation or Model and
> remove the misleading references to conformance. Or alternatively, submit
> the specification to some standards organization, which is open to
> participation by the IT industry and press forward to define
> interoperability standards, so that products can be developed which can
work
> together in large-scale environments, rather than encouraging the
> development of proprietary solutions which conform to the abstract model.
>
> Harold W. Lockhart
> Principal Engineering Technologist
> Architecture & Standards Group
> BEA Systems, Inc.
>
>
> You may leave a Technical Committee at any time by visiting
>
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p
> hp
>
>
>