Development of an open network Hierarchical Identity-Based Access Control System

1. By Jyh-haw yeh Department of Computer Science Boise State University Development of an open network Hierarchical Identity-Based Access Control System

2. Access Control Controlling data accesses within a networked enterprise, based on security needs. • Define access control policy • User authentication • Policy enforcement mechanisms • Data transmission through networks

3. Identity-Based Access Control (IBAC) • Authentication is based on user’s identity, rather than network connection port. • User identity/job duty, time and location of connection – define a set of security groups • Different groups have different access privileges on objects. • Each object has an access control list (ACL) as an enforcing mechanism.

4. Deficiency Observation of IBAC • Security groups have no relationship among them – require duplicate administrative work (See Figure 1) • Use different keys for authentication (master key) and authorization (session key). • Require a new session key for each access session. • Session key generation and distribution may slow down performance.

5. Administrative Work Figure 1: HIBAC versus IBAC (a) Privilege assignment (b) User assignment (c) ACL for an Object IBAC HIBAC P U G1 G1 P U G2 G2 P U G3 G3 U G1 G1 G2 G2 P G3 G3

6. Hierarchical Identity-Based Access Control (HIBAC) • Define Security groups to have a hierarchical privilege-inheritance relationship. • A group Ainherits privileges from a group B if A is located higher than B in the hierarchy. • A single mechanism, hierarchical key assignment, for authentication and authorization.

7. HIBAC, continue… Why hierarchical? • Reduce administrative work. • Simplify authentication and authorization logics – single hierarchical key V.S. master & session keys • The hierarchical key can also be used for data encryption during transmission.

8. A Walk through Example • A xyz company defines 6 security groups, based on job duty, time and location of network connection. • CEO, Finance (FIN), Human Resource (HR), Employee (E), Employee Restricted (ER) and Guest (G). • Table 1 specifies the access right assignment. • Form a hierarchical policy (See Figure 2).

9. A Walk through Example Table 1: Access right assignment in a xyz company

10. A Walk through Example Figure 2: Hierarchical policy and it’s hierarchical key assignment CEO: K1 / \ FIN: K2 HR: K3 \ / E: K4 | ER: K5 | G: K6

11. A Walk through Example Authentication: • Alice has it’s own hierarchical key, say K2. • Alice login networks through an authentication (AE) server. Challenge-and-response between Alice’s machine and AE server. • Alice uses K2 (or K5, if public location) to encrypt response to server – prove the security group FIN (or ER) she belongs to.

12. A Walk through Example Authentication: • After authentication, AE server create a signed proof P to Alice and authorization (AO) server. • The proof P may contain

13. A Walk through Example Authorization: • Alice makes an access request to AO server, with P attached. • AO server verifies P and thus authenticate Alice. • Based on P, AO server either grants or denies the access.

14. A Walk through Example Data transmission: • If AO server grants access to Alice, AO server can use either K2 or K5 to encrypt data and transmits it to Alice. • Upon receiving data, Alice uses either K2 or K5 to decrypt data.

15. Research Challenges • Design issues:  Guidelines for defining a hierarchical policy  session key vs. hierarchical key  Minimum contents of P  Prevent the re-use of P – freshness data, revocation of P • Figure 1 shows the advantage of reducing administrative work in HIBAC – need quantitative measurement.

16. Research Challenges • The walk through example show the simple logic for authentication and authorization processes in HIBAC – need an event-driven simulation to measure the system performance, in terms of increased control messages and storage. • Investigate any unnoticed security vulnerability of the new system.