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 users 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 dont 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
• Cant mishandle something you dont have
• Provide a stronger security guarantee
• Signed cert as secure as institutions 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_at_terena.nl )

14
IETF Information

• Internet-Drafts
• Securely Available Credentials - Credential
  Server Frameworkhttp//www.ietf.org/internet-draf
  ts/draft-ietf-sacred-framework-02.txt
• Securely Available Credentials Protocolhttp//www
  .ietf.org/internet-drafts/draft-ietf-sacred-protoc
  ol-bss-00.txt
• PKI Enrollment Informationhttp//www.ietf.org/int
  ernet-drafts/draft-ietf-sacred-pkienrollinfo-00.tx
  t
• 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-R
  1/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
• vscs have a 1-to-1 concept correspondence to
  pscs

Concept Physical Virtual
Procurement Purchase/download Request/generate
Possession Physical Authentication
Operations Indirect Indirect
Tamper protection Self-destruct Restricted access
Theft protection Settable pin Settable password
26
VSC Conceptualization

• A vsc is implemented using a secure, access
  restricted server
• One server holds many users private keys
• Hence, one server instantiates many vscs
• 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
VSC Procurement
User never sees the private key!
28
VSC Operation (vsc-proxy)
Externally authenticated (e.g., Kerberos)
2. Generate proxy public/private key
Private key never sees the network!
29
VSC Theft Protection
Externally authenticated (e.g., Kerberos)
1. Generate key-string from a strong user password
3. Encrypt users 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 institutions 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 users lives
• Ease of use reduces security lapses