The 2004 ACM IEEE International Conference on E-Business and

The 2004 ACM/IEEE International Conference on E-Business and Telecommunication Networks (ICETE-04) Towards a Flexible Access Control Mechanism for E-Transactions School of Technology and Computer Science Tata Institute of Fundamental Research, Mumbai.

Outline 2

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 3

Mechanisms: Simple/Complex? 4

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 5

Approaches ● Various proposals exist MAC/DAC PKI-based: Policy. Maker/Key. Note, RBAC et. al. Capability-based ● How to do it in a better way? flexi-ACL 6

Early days of Access Control ● Butler Lampson proposed “Access Control Matrix” (extended by HRU) 7

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 Subject Reference Monitor Object Authorization Database 8

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 0000 s of files and 00 s of users (resulting in 000000 s 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. 9

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. 10

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 11

Access Control Issues 12

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) 13

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 14

PKI 15

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 16

Scenario 0 Underlying security framework: X. 509 17

Scenario 1 ● Is it possible to delegate authorizations and restrict the number of authorized users? Underlying security framework: SPKI/SDSI 18

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

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 welldefined fixed set of rights. 20

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 21

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 22

● 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 policyis then obtained through a merger of global and local policies. 23

Challenge: Access Control Rule Response: Certificate Chain as proof + 24

25

Challenge: Access Control Rule Response: Certificate Chain as proof + 26

Challenge: Access Control Rule Response: Certificate Chain as proof + 27

Challenge: Access Control Rule Response: Certificate Chain as proof + 28

Challenge: Access Control Rule Response: Certificate Chain as proof + 29

30

Challenge Response + 31

32

33

Possession of credentials Proof of evidence Reputation or Reference 34

1. 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. 35

36

Comprehensive Scenario: [Layered Security Infra. ] 37

Conclusions 38

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 39

Future Directions 40

Contact & References Your Questions We will reply before lunch-break 41