Credential Repositories in an Interprise Environment

1. Credential Repositories in an Interprise Environment Bob Cowles Stanford Linear Accelerator Center 27 January 2003 Work supported by U. S. Department of Energy contract DE-AC03-76SF00515

2. Noon 2PM 4PM 6PM 8PM http://average.matrix.net

3. India China Japan Korea Australia 8AM 10AM Noon 2PM

4. Grid Computing Model

5. Grid Vision • Location independent access to computing resources similar to access to the electrical grid • User authenticates using PKI-based application • Request job to be run • Scheduler determines where job runs • Data and computational resources brought together • Results are stored or returned

6. Grid Security Infrastructure • Based on X.509 certificates • International efforts coordinated by several security working groups in the Global Grid Forum (www.gridforum.org)

7. Statement of the Problem • Provide trusted authentication and authorization checking across security and trust domains • Risk model is difficult to determine • What are threats and vulnerabilities? • Protect but not interfere (too much) • Balanced to reduce over/underprotection • On the edge of chaos …

8. “Logging on” to the Grid • Authenticate: % grid-proxy-init Enter PEM pass phrase: ****** • Creates temporary, short-lived proxy credential

9. Proxy Credentials • Proxy credentials are short-lived credentials created by user • Short term binding of user’s identity to alternate private (and public) key • Stored unencrypted for easy repeated access • Short lifetime in case of theft • Enables user to authenticate once then perform multiple actions without reauthenticating

10. Proxy Delegation • Delegation = remote creation of a (second level) proxy credential • New key pair generated remotely on server • Proxy cert and public key sent to client via SSL • Client signs proxy cert and returns it • Note: no private key movement across network • Allows remote process to authenticate on behalf of the user • Remote process “impersonates” the user

11. Private Key Problems • Private keys and users don’t mix • No guarantee of good or any password choice • No guarantee of secure private key location • E.g., users store keys in network based file systems • No guarantee how private key was handled • E.g., users copy/e-mail keys to remote machines & leave them • User managed keys cannot be trusted

12. Solitary Private Keys • Never give a user their private key • Can’t mishandle something you don’t have • Provide a stronger security guarantee • Signed cert as secure as institution’s accounts • Must provide agent-based key handling • E.g., smart cards

13. SACRED • IETF RFC 3157 • SACRED is concerned with the secure use of credentials in roaming or mobile environment with: desktop or laptop, mobile phone, PDA, etc. • (thanks to Yuri Demchenko demch@terena.nl )

14. IETF Information • Internet-Drafts: • Securely Available Credentials - Credential Server Frameworkhttp://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-02.txt • Securely Available Credentials Protocolhttp://www.ietf.org/internet-drafts/draft-ietf-sacred-protocol-bss-00.txt • PKI Enrollment Informationhttp://www.ietf.org/internet-drafts/draft-ietf-sacred-pkienrollinfo-00.txt • Request For Comments: • Securely Available Credentials - Requirements (RFC 3157)http://www.ietf.org/rfc/rfc3157.txt

15. SACRED Motivation • Support user mobility by allowing roaming user to retrieve / use credentials • Allow to use the same credentials for/from different user network appliances • Secure user credentials by storing credentials on Credential Server

16. SACRED Principles I • Credentials MUST not be sent in the clear during network transmission and SHOULD not be in the clear when stored on an end user device • Secured credentials are defined for SACRED: opaque (and partially privacy and integrity protected) data object that can be used by network device

17. SACRED Principles II • Clients should be able to recover their credentials from opaque object • Credential formats SHOULD provide privacy and integrity protection • Credentials MUST be protected with a second layer of encryption prior to network transmission (using client/server negotiated keys)

18. SACRED Framework • The framework MUST support both "credential server" and "direct" solutions. • The "credential server" and "direct" solutions SHOULD use the same technology as far as possible. • The framework MUST allow for protocols which support different user authentication schemes • The details of the actual credential type or format MUST be opaque to the protocol, though not to processing within the protocol's peers. The protocol MUST NOT depend on the internal structure of any credential type or format.

19. SACRED and Grid • General issues: • Traditional systems are client/server centric • Grid computing is data centric • Traditional systems: • Protect system from users • Protect data of single user • In Grid systems: • Protect applications and data from the execution system • Stronger/mutual authentication needed to ensure resources and data not provided by a attacker • Different admin domains/Security policies

20. Kerberos • IETF RFC 1510 • National Science Foundation project to support KX.509 / KCA extensions for Grid applications http://www.nsf-middleware.org/documentation/NMI-R1/1/KX509KCA/

21. KCA • Acts (nearly) as root Certificate Authority • Signs a certificate for user based on Kerberos authentication ticket • All resource providers must agree to accept KCA signed certificates

22. KX.509 • Client side of protocol • Generates key pair and sends certificate containing public key to KCA for signing • Resulting credentials can be used like a GSI proxy certificate.

23. KX.509/KCA Drawbacks • Site specific installation (based on KDC) • Lacks scaling • Requires multi-site trust (potentially) • Grid projects (virtual organizations) have to perform site-by-site negotiation of trust

24. Virtual Smart Card Andrew Hanushevsky Robert Cowles Stanford Linear Accelerator Center Work supported by U. S. Department of Energy contract DE-AC03-76SF00515

25. Virtual Smart Card (vsc) • Premise: Physical smart cards (psc) in software • vsc’s have a 1-to-1 concept correspondence to psc’s

26. VSC Conceptualization • A vsc is implemented using a secure, access restricted server • One server holds many user’s private keys • Hence, one server instantiates many vsc’s • Can be well secured • Restricted physical access • Cages, keyed room, etc. • Restricted logical access • Only three access protocols needed: dns, ntp, and vsc • Keys can be encrypted via user-supplied passwords

27. CA 3.E-mail cert url 4.Download CA signed public cert* 2.Generate keys and send cert request 1.Ask for a cert vsc *When available on 1st request or automatic poll. VSC Procurement User never sees the private key!

28. 1.Get public cert 3.Sign proxy cert vsc VSC Operation (vsc-proxy) Externally authenticated(e.g., Kerberos) 2.Generate proxy public/private key Private key never sees the network!

29. 2.Send encrypted key-string vsc VSC Theft Protection Externally authenticated(e.g., Kerberos) 1.Generate key-string from a strong user password 3.Encrypt user’s x509 private key and discard key-string User must now supply key-string for vsc to use private key

30. VSC Advantages I • Simple and effective • Models well-known physical object -- smart card • Initial certificate request is trivial • Private keys never exposed • Can be further encrypted by user • Can get proxy cert anywhere in the world • No need to copy public/private keys

31. VSC Advantages II • Can provide special always-on services • Perhaps proxy cert revalidation • Can provide stronger security guarantee • Signed cert as secure as institution’s accounts

32. VSC Disadvantages • Private keys are concentrated • Can be user-encrypted • Similar problem in Kerberos • May violate current CA CP/CPS • Political vs. practical reality • No more secure than external authentication • Need good authentication (e.g., K5)

33. Conclusion • Virtual Smart Cards effective • Simple, relatively transparent, secure • Provides a path to more stringent security • Physical smart cards • Simplify user’s lives • Ease of use reduces security lapses