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

http://average.matrix.net

8AM 10AM Noon 2PM

Australia

JapanKorea

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 (www.gridforum.org)

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/e-mail keys to remote machines &

leave them

• User managed keys cannotcannot be trusted

Solitary Private Keys

• Never give a user their private key– Can’t mishandle something you don’t have

• Provide a strongerstronger 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 demch@terena.nl )

IETF Information

• Internet-Drafts: – Securely Available Credentials - Credential Server Framework

http://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

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 applicationshttp://www.nsf-middleware.org/documentation/NMI-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 CowlesStanford 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

Concept Physical VirtualProcurement Purchase/

downloadRequest/generate

Possession Physical Authentication

Operations Indirect Indirect

Tamper protection

Self-destruct Restricted access

Theft protection Settable pin Settable 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. E-mail cert url

User never sees the private key!

CACA

4. Download CA signed public cert*

*When available on 1st request or automatic poll.

VSC Operation (vsc-proxy)

2. Generate proxy public/private key

3. Sign proxy certSign proxy cert

Private key never sees the network!

1. Get public certGet public cert

Externally authenticatedExternally authenticated (e.g., Kerberos)

VSC Theft Protection

1. Generatekey-string from a

strong user password

2. Send encrypted key-stringSend encrypted key-string

Externally authenticatedExternally 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

• Can provide strongerstronger 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