1. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE CS582: Distributed Systems Lecture 10, 11 – October 1, 8 2003 Security Dr. Shahab Baqai LUMS

2. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Security Goals Protection –Enforced by hardware –Depends on trusted kernel Authentication –Determining identity of principal Integrity –Authenticity of document –That it hasn’t changes Privacy –That inappropriate information is not disclosed

3. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Security Policy Access Matrix –implemented as: ▪Capabilities or ▪Access Control list

4. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Access Control Lists Advantages –Easy to see who has access –Easy to change/revoke access Disadvantages –Time consuming to check access Extensions to ease management –Groups –EACLs

5. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Extended Access Control Lists Conditional authorization –Implemented as restrictions on ACL entries and embedded as restrictions in authentication and authorization credentials

6. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Capabilities Advantages –Easy and efficient to check access –Easily propagated Disadvantages –Hard to protect capabilities –Easily propagated –Hard to revoke Hybrid approach –EACL’s/proxies

7. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Protecting capabilities Stored in TCB –Only protected calls manipulate Limitations ? –Works in centralized systems Distributed Systems –Tokens with random or special coding –Possibly protect through encryption –How does Amoeba do it? (claimed)

8. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Basic Security Services Authentication Authorization Accounting Audit Assurance Payment Protection Policy Privacy Confidentiality

9. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Network Threats –Spurious association initiation –Denial of use –Traffic analysis Attacks may be –Active or passive –Unauthorized release of data –Unauthorized modification of data –Impersonation

10. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Network Threats –Unauthorized release of data –Unauthorized modification of data –Spurious association initiation ▪Impersonation –Denial of use –Traffic analysis Attacks may be –Active or passive

11. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Likely points of attack (location)

12. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Likely points of attack (module) Against the protocols –Sniffing for passwords and credit card numbers –Interception of data returned to user –Hijacking of connections Against the server –The commerce protocol is not the only way in –Once an attacker is in, all bets are off Against the client’s system –You have little control over the client’s system

13. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Network Attacks Eavesdropping Listening for passwords or credit card numbers Message stream modification Changing links and data returned by server Hijacking Killing client and taking over connection CS Attacker

14. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Network Attack Countermeasures Don’t send anything important Not everything needs to be protected Encryption For everything else Mechanism limited by client side software CS Attacker

15. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Encryption for confidentiality and integrity Encryption used to scramble data PLAINTEXT CIPHERTEXT ENCRYPTION (KEY) DECRYPTION (KEY) ++

16. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Authentication Proving knowledge of encryption key –Nonce = Non repeating value {Nonce or timestamp}K c CS

17. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Today’s security deployment Most of the deployment of security services today handles the easy stuff, implementing security at a single point in the network, or at a single layer in the protocol stack: –Firewalls, VPN’s –IPSec –SSL Unfortunately, security isn’t that easy. It must be better integrated with the application. –At the level at which it must ultimately be specified, security policies pertain to application level objects, and identify application level entities (users).

18. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Conclusion: Integration is hard to do The majority of applications were not being modified to use security services. –In fact, the only widespread interoperable integration of security services with applications was SSL integration with the web, and SSL is used primarily as a confidentiality mechanism and only rarely for user authentication.

19. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Conclusion: Integration is hard to do The reason –Integration with applications involved many changes: ▪Multiple calls to GSS-API or other authentication interfaces ▪Calls to decide what the user is authorized to do –Home grown policy databases or protocol extensions requiring even more calls to complete. ▪Custom integration with other security services –Confidentiality, integrity, payment, audit

20. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Focus on Authorization Focusing on authorization and the management of policies used in the authorization decision. –Not really new - this is a reference monitor. –Applications shouldn’t care about authentication or identity. ▪Separate policy from mechanism –Authorization may be easier to integrate with applications. –Hide the calls to the key management and authentication functions.

21. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Generic Authorization and Access-control API Allows applications to use the security infrastructure to implement security policies. gaa_get_object_eacl function called before other GAA API routines which require a handle to object EACL to identify EACLs on which to operate. Can interpret existing policy databases. gaa_check_authorization function tells application whether requested operation is authorized, or if additional application specific checks are required Application GAA API input output gaa_get_ object_eacl gaa_check_ authorization Yes,no,maybe SC,obj_id,op

22. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Credential transport (needed) The GAA-API gets user & connection info from Security Context: Evaluated and unevaluated credentials Delegated authority Cross-calls to transport to retrieve additional creds The security context is provided as: –Output from GSS-API (requires many calls) –Credentials from transport or session protocols –SSL, ARDP –Other extensions are needed: –IPSec, pulled from Kernel, other extensions

23. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Evaluation of credentials POLICY gaa_get_object_eacl gaa_check_authorization GAA API App EACL... GAA API Security Context GSS-API LIBRARY Transport Mechanism 23 14 4a 6a 5 6 7 5a 6b

24. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Integrating security services The GAA-API calls must be made by applications. –This is a major undertaking, but one which must be done no matter how one chooses to do authorization. These calls are at the control points in the app –They occur at auditable events, and this is where records should be generated for ID systems –They occur at the places where one needs to consider dynamic network threat conditions. –Adaptive policies use such information from ID systems. –They occur at the right point for billable events.

25. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Electronic commerce Some authorization policies do not require user authentication at all - just that an item is paid for. –Policy specifies required payment. –Cross call to credential transport retrieves payment credentials and grants access. –If application used GAA-API, no change to the application is necessary, simply specify the payment policy instead of a more traditional identity based policy.

26. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE ID and Audit relation to GAA-API SECURITY AUDIT RECORDS THREAT CONDITION UNDER ATTACK POLICY gaa_get_object_eacl gaa_check_authorization GAA API App EACL... GAA API Security Context GSS-API LIBRARY Transport Mechanism 23 14 4a 6a 5 6 7 5a 6b

27. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Application based ID Without the GAA-API –Convince each application developer to add calls to audit functions in addition to all the other security calls they make (good luck). Of course it needs to do authentication too. With the GAA-API –Get developers to use the GAA for authorization decisions instead of making multiple calls to implement their own authorization database. –Create module for GAA implementation that generates audit records according to policy. –Write policy (inc. adaptive or credential based) that says when to generate audit records.

28. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Key distribution Conventional cryptography –Single key shared by both parties Public Key cryptography –Public key published to world –Private key known only by owner Third party certifies or distributes keys –Certification infrastructure –Authentication

29. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Authentication w/ Conventional Crypto Kerberos 2 3 1 or Needham Schroeder,4,5 KDC C S

30. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Authentication w/ PK Crypto Based on public key certificates 1 DS S C 3 2

31. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Kerberos Third-party authentication service –Distributes session keys for authentication, confidentiality, and integrity TGS 4. Ts+{Reply}Kt 3. TgsReq KDC 1. Req 2. T+{Reply}Kc CS 5. Ts + {ts}Kcs

32. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Public Key Cryptography (revisited) Key Distribution –Confidentiality not needed for public key –Solves n 2 problem Performance –Slower than conventional cryptography –Implementations use for key distribution, then use conventional crypto for data encryption Trusted third party still needed –To certify public key –To manage revocation –In some cases, third party may be off-line

33. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Certificate-Based Authentication Certification authorities issue signed certificates –Banks, companies, & organizations like Verisign act as CA’s –Certificates bind a public key to the name of a user –Public key of CA certified by higher-level CA’s –Root CA public keys configured in browsers & other software –Certificates provide key distribution

34. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Certificate-Based Authentication (2) Authentication steps –Verifier provides nonce, or a timestamp is used instead. –Principal selects session key and sends it to verifier with nonce, encrypted with principal’s private key and verifier’s public key, and possibly with principal’s certificate –Verifier checks signature on nonce, and validates certificate.

35. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Secure Sockets Layer (and TLS) Encryption support provided between Browser and web server - below HTTP layer Client checks server certificate Works as long as client starts with the correct URL Key distribution supported through cert steps Authentication provided by verify steps C S Attacker Hello Hello + Cert S {PMKey}K s [Cert C + Verify C ] Verify S

36. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Trust models for certification X.509 Hierarchical –Single root (original plan) –Multi-root (better accepted) –SET has banks as CA’s and common SET root PGP Model –“Friends and Family approach” - S. Kent Other representations for certifications No certificates at all –Out of band key distribution –SSH

37. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Global Authentication Service Pair-wise trust in hierarchy –Name is derived from path followed –Shortcuts allowed, but changes name –Exposure of path is important for security Compared to Kerberos –Transited field in Kerberos - doesn’t change name Compared with X.509 –X.509 has single path from root –X.509 is for public key systems Compared with PGP –PGP evaluates path at end, but may have name conflicts

38. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Capability Based Systems - Amoeba “Authentication not an end in itself” Theft of capabilities an issue –Claims about no direct access to network –Replay an issue Modification of capabilities a problem –One way functions provide a good solution Where to store capabilities for convenience –In the user-level naming system/directory –3 columns Where is authentication in Amoeba –To obtain initial capability

39. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Capability Directories in Amoeba

40. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Security Architectures DSSA –Delegation is the important issue ▪Workstation can act as user ▪Software can act as workstation - if given key ▪Software can act as developer - if checksum validated –Complete chain needed to assume authority –Roles provide limits on authority - new sub-principal Proxies - Also based on delegation –Limits on authority explicitly embedded in proxy –Works well with access control lists

41. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Distributed Authorization It must be possible to maintain authorization information separate from the end servers –Less duplication of authorization database –Less need for specific prior arrangement –Simplified management Based on restricted proxies which support –Authorization servers –Group Servers –Capabilities –Delegation

42. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Proxies A proxy allows a second principal to operate with the rights and privileges of the principal that issued the proxy –Existing authentication credentials –Too much privilege and too easily propagated Restricted Proxies –By placing conditions on the use of proxies, they form the basis of a flexible authorization mechanism

43. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Restricted Proxies Two Kinds of proxies –Proxy key needed to exercise bearer proxy –Restrictions limit use of a delegate proxy Restrictions limit authorized operations –Individual objects –Additional conditions + Proxy Conditions: Use between 9AM and 5PM Grantee is user X, Netmask is 128.9.x.x, must be able to read this fine print, can you PROXY CERTIFICATE Grantor

44. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Authorization and Group Services 1. Authenticated authorization request (operation X) 2. [operation X only]R, {Kproxy} Ksession 3. [operation X only]R, authentication using Kproxy R 2 SC 3 1

45. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Central Authorization Authorization server uses extended ACLs –Conditions are not evaluated, but instead attached to credentials Groups implemented by auth server –Server grants right to assert group membership Application servers configured to use authorization server –Minimal local ACL –Can use multiple Authorization servers

46. Copyright © 1995-2003 Clifford Neuman - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE Applied Security Electronic commerce –SSL Applies authentication and encryption –NetCheque applies proxies –SET applies certification –End system security a major issue What we have today –Firewalls –Web passwords, encryption, certificates –Windows 2000 uses Kerberos