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

Noon 2PM 4PM 6PM 8PM

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

Grid Computing Model

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

Grid Security Infrastructure Based on X.509 certificates International efforts coordinated by several security working groups in the Global Grid Forum (

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 …

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

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

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

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/ keys to remote machines & leave them cannotUser managed keys cannot be trusted

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

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

IETF Information Internet-Drafts: –Securely Available Credentials - Credential Server Framework 02.txt 02.txt –Securely Available Credentials Protocol 00.txt 00.txt –PKI Enrollment Information 00.txt 00.txt Request For Comments: –Securely Available Credentials - Requirements (RFC 3157)

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

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

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)

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.

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

Kerberos IETF RFC 1510 National Science Foundation project to support KX.509 / KCA extensions for Grid applications R1/1/KX509KCA/

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

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.

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

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

Virtual Smart Card (vsc) Premise: Physical smart cards (psc) in software –vsc’s have a 1-to-1 concept correspondence to psc’s ConceptPhysicalVirtual ProcurementPurchase/downlo ad Request/generat e PossessionPhysicalAuthentication OperationsIndirect Tamper protection Self-destructRestricted access Theft protectionSettable pinSettable password

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

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

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

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

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

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

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)

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