Towards a Flexible Access Control Mechanism for E-Transactions Vishwas Patil vtp@tifr.res.in vishwas...

Post on 28-Dec-2015

219 views 0 download

Transcript of Towards a Flexible Access Control Mechanism for E-Transactions Vishwas Patil vtp@tifr.res.in vishwas...

Towards a Flexible Access Control Mechanism for E-Transactions

Vishwas Patilvtp@tifr.res.in

http://www.tcs.tifr.res.in/~vishwas

School of Technology and Computer Science

Tata Institute of Fundamental Research, Mumbai.

R. K. Shyamasundar, Fellow IEEEshyam@tifr.res.in

http://www.tcs.tifr.res.in/~shyam

The 2004 ACM/IEEE International Conference on E-Business and Telecommunication Networks (ICETE-04)

2 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Outline● Need for Access Control● Present approaches: what more is required?● Background● Modeling security requirements for access control● Modeling dynamic security requirements● flexi-ACL● Conclusions● Future Directions

3 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Need for Access Control

● Irresistible advantages of using Internet

● More and more resources are coming over Internet

● Restrict the access to intended users

● Access Control: distinguish between Authorized and un-Authorized users

4 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Mechanisms: Simple/Complex?● What is the nature of the security controls?

Do we require complexity or assurance?

● Simple security mechanismseasy to maintain unlikely to be configured incorrectlyeasy to prove implementation of security meets policy requirements may not support all requirements of security policy

● Complex security mechanisms

difficult to maintain likely to be configured incorrectly difficult to prove implementation of security meets policy requirementssupport a wide variety of security features

5 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Issues● Secure access● Protection against misuse of authorizations ● Manageability● Fault-tolerance● On-line vs. Off-line trade-off● Emergency access measures● Granular access● Dynamic aspects in distributed environment● Sequential access: Layered security approach● Privacy issues● Trust management

Author
We will judge our approach with other schemes based on following parameters.mention few parameters.....AT the end of this slide: "Only doing authorizations is not enough, at the end of this presentation we shall also see the aspect of TRUST involved"

6 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

● Various proposals exist MAC/DAC PKI PKI-based: PolicyMaker/KeyNote, RBAC et. al. Capability-based

● How to do it in a better way? flexi-ACL

Approaches

7 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Early days of Access Control● Butler Lampson proposed “Access Control Matrix”

(extended by HRU)

8 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Access Control Matrix● A request can be regarded as a triple (s, o, a)

s is a subject o is an object a is an access operation

● A request is granted (by the reference monitor) if a belongs to the access matrix entry corresponding to subject s and

object o

Authorization

Database

SubjectReference

MonitorObject

9 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Access Control Matrix● The matrix is likely to be extremely sparse and therefore

implementation is inefficient

● Management of the matrix is likely to be extremely difficult if there are 0000s of files and 00s of users (resulting in 000000s of matrix entries)

● The administration of access control structures is extremely time-consuming, complicated and error-prone

● Such kind of approach is suitable in OS, where the state transition is internal to system and readily available during decision making process, also security is not a concern.

10 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Plain Authentications over the Internet● Distributed computing and the Internet have caused a paradigm

shift in computing security

● Security threats Data confidentiality, integrity Re-play attack Non-repudiation Identity theft, privacy, etc.

● man-in-middle attack

● Cryptography has a role to play in secure Access Control, especially in distributed environment like Internet.

11 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Role of Cryptography● Properties provided by cryptography (symmetric/asymmetric),

Data confidentiality Data integrity Authentication, Authorization Non-repudiation These properties can be realized in distributed environment using

digital certificates

● PKI comes into picture X.509 (centralized framework), SPKI/SDSI (de-centralized)

● Only integration of PKI with applications may not suffice! Other Access Control Issues

12 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Access Control Issues● How is security to be managed?

Do we centralize or decentralize? A security policy should be implemented consistently

● Single point of controlPolicy likely to implemented consistently throughout May be performance bottleneck

● Multiple control points Implementation of policy more likely to be inconsistentPerformance likely to be improvedFlexible and natural policies

13 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

PKI● X.509

Centralized architecture Global “root” CA are responsible for proper functionality of setup Sub-ordinate CAs help in management, but delegation is limited Single digital-certificate is used for name and authorization binding Trust accumulates at CA, loss of flexibility Key management is costly and cumbersome for large setup (CRL)

14 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

PKI● SPKI/SDSI

Decentralized architecture Separate name and authorization certificates (privacy) Each principal can independently issue certificates (local name space) Principals can also make name and authorization bindings on names

(defined in local name space or in someone else’s name space) rather than on exact keys (extended names)

Global CAs can be accommodated in the setup Principals can delegate acquired authorizations to others (if allowed) The onus of generating proof of some authorization is left on requester

rather than on resource controller

15 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

PKI

16 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Modeling Security Requirements for AC

● For today's complex applications over the Internet, the security requirements cannot be met merely by PKI based frameworks

● Let us see with the help of few simple scenarios what are the requirements of a generic access control mechanism

● We shall also see how these requirements can or cannot be met in existing frameworks

17 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Scenario 0

Underlying security framework: X.509

18 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Scenario 1● Is it possible to delegate authorizations and restrict the number

of authorized users?

Underlying security framework: SPKI/SDSI

19 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Scenario 2● Is it possible to restrict the depth of authorization delegation?

20 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Scenario 3● Can each user have different accessing rights on the resource?

A typical approach is to categorize users into different roles and authorize them against the rights honored against respective roles.

This way resource controller has to maintain less info. in a manageable way (work-flow systems, RBAC etc.)

Another approach could be to include all the permissions into user’s certificate itself, but this leads to revelation of information that is not necessary while performing a particular authorization

This is suitable for setup where users exercise rights from a well-defined fixed set of rights.

21 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Scenario 4● Is it possible to restrict an authorized user from acting as a

service proxy for others? In communications that are not face-to-face, remote lending cannot be

prevented, regardless of whether privacy-protecting certificates or fully traceable identity certificates are used. Indeed, the “lender” might as well perform the entire showing protocol execution and simply relay the provided service or goods to the “borrower” [Stefan Brands].

Case 1: auction robots – acting on behalf of its owner Case 2: laundry service – if authorization credentials does not tightly

bind the recipient of the service, users may run the laundry service Case 3: privacy violation – if authorization credentials bind lot of user

information with it- Reduces the scope of the underlying certification scheme or- Possess privacy threats

22 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Modeling Dynamic Security Requirements● We have argued that the existing frameworks do not support

the following features:

Constraints & flexibilities required for specifying proxies by users,

Variable access rights for the users,

Emergency access requirements, and

Robustness/fault-tolerance and immediate revocation of authority

23 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL● Every access request is a negotiation between resource

controller and the requester● We should have a judicious mix of certificates and on-line

schemes (authentications), based on the requirement trade-offs

● Our approach addresses the modeled requirements through the following abstractions Abstract out the core access control across scenarios as a global

policy specification that can and will be handled through certificates Specify refinements that may require on-line schemes as local policy The overall policy is then obtained through a merger of global and

local policies.

24 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL [Typical “controller-requester” Interaction]

+

Challenge: Access Control Rule Response: Certificate Chain as proof

25 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

AIntersect() Function [Derive Actual perms.]

26 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL: Scenario-1

+

Challenge: Access Control Rule Response: Certificate Chain as proof

Stop the service to members of my-group defined in the ACL

Remove this rule from acl

27 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL: Scenario-2

+

Challenge: Access Control Rule Response: Certificate Chain as proof

Disable write perm on ftptemporarily

Remove write fromthe (tag ) field

28 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL: Scenario-3

+

Challenge: Access Control Rule Response: Certificate Chain as proof

Introduce a new perm foo on ftp

foo

Add foo to the (tag ) field

*

29 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL: Scenario-4

+

Challenge: Access Control Rule Response: Certificate Chain as proof

Restrict access of ftp to themembers of my-group only

foo

Remove the (delegate)flag*

30 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL [Modified (tag) field of SPKI/SDSI]

● SPKI/SDSI allows application developers to define the structure of (tag) filed present in ACL rules and authorization certificates

● Instead of (tag (resource (permissions))) in ACL / authorization certificates,

● We have adapted following modification: for ACL

(tag (resource (*)(permissions-dynamic))) for authorization certificates

(tag (resource (permissions-static)(*)))● So that the resultant intersection will produce a combination of

overall global policy (prescribed in certs) + local policy (prescribed in ACL)

31 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL [Introduction of positional * operator in (tag)]

+

Challenge Response

32 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL: Typical Structure

33 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL [rule types supported]

● flexi-ACL allows integration of a priori defined authentication mechanisms (standard/proprietary) as rule types for a given setup

● For example; spki pamd RSA SecurID biometric TCP/IP wrapper token et. al.

34 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL [rule type examples]

Possession ofcredentials

Reputation orReference

Proof ofevidence

35 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL: Scenarios1. Stop providing service to non-conforming users

The Resource Administrator has control over one of the a priori defined authentication mechanisms integrated with flexi-ACL

Administrator simply revokes the non-conforming user from the authentication mechanism, though the user is satisfying global policy, it is not satisfying the local policy and hence denied access

2. A particular user U should not access the resource more than “n” times

For such requirements of tracking the state of user’s access to the resource, the administrator may integrate a suitable authentication mechanism into the rules-set.

For example, one-time-passwords, or a mechanism integrated with database, to keep track of number of accesses already made.

36 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

flexi-ACL: Scenarios3. Provide more permissions to the users who can satisfy

additional policy requirementsAdministrator can put the additional policy requirements in

conjunctions with the necessary e-authentication mechanisms as a conformance check.

4. Introduce a new permission foo over the resource only to certain users

Administrator will create a new rule inside the acl-block, in which permission foo is introduced as a new permission under local policy but availed to the users who can authenticate themselves against the newly integrated e-authentication mechanism integrated with the rule using AND operator.

37 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Comprehensive Scenario: [Layered Security Infra.]

38 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Conclusions● We have argued the need for a hybrid of digital certificates and

other state-based schemes to arrive at flexible distributed access control specification (flexi-ACL)

● Inclusion of external authentication mechanisms into the underlying PKI framework empowers the resource controller to provide fine-grained access control

● The ability of resource controller to enforce local access control policies helps the resource owner in granting discretionary auxiliary rights to the users

● Such an approach is also helpful in achieving properties like; “rights amplification”, “fault-tolerance”, “instant authority revocation”, and better trust management!

39 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Future Directions● How do we “do” access control if we can’t identify subjects?

Mobile code e-Commerce customers

● How do we control the access of untrusted code running on our machine? Sandboxes Code signing

● Notion of incomplete contracts Trust is an important ingredient for execution of incomplete contracts

40 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Future Directions

41 / 41ICETE-04/EGCDMAS-04 Vishwas Patil and R.K. Shyamasundar. TIFR.

Contact & References

Vishwas PatilScientific Officervtp@tifr.res.in

http://www.tcs.tifr.res.in/~vishwas

Prof. R. K. Shyamasundar Dean, School of Technology and Comp. Science

shyam@tifr.res.in

http://www.tcs.tifr.res.in/~shyam

● http://www.tcs.tifr.res.in/~vishwas/pub/tm/tm.pdf

● http://www.tcs.tifr.res.in/~vishwas/pub/flexiacl/flexiacl-2.pdf

YourQuestions

We will reply before lunch-break