Grid Security

1
Grid Security

• Laura Pearlman
• USC Information Sciences Institute
• (and other members of the Globus Project team)

2
Outline

• The Grid Security Problem
• Background Public Key Encryption and
  Certificate-Based Authentication
• Grid Security Infrastructure
• Authorization

3
The Grid Security Problem (1)

• Resources are located in multiple distinct
  administrative domains (sites).
• A single application may use resources from
  multiple sites.
• Each site has its own pre-existing security
  requirements, policies, and enforcement
  mechanisms.

4
The Grid Security Problem (2)

• Virtual Organizations (VOs) have their own
  security requirements and policies.
• A single user or resource may be in several VOs
• The sets of users, resources, and sites in a VO
  may be large, dynamic, and unpredictable.
• It is often difficult to establish site-wide
  trust relationships.

5
Grid Security User Requirements

• Ease of use (e.g., single sign-on)
• Ability to run applications that use resources
  throughout the VO
• User-based trust model
• Proxies / agents

6
Site Requirements

• Adherence to site policies (specifically
  regarding authorization, auditing, accounting)
• Interoperability with local security mechanisms
• Understandable, verifiable policies and mechanisms

7
VO Requirements

• Adherence to VO policies (specifically regarding
  authorization, auditing, accounting)
• Understandable, verifiable policies and
  mechanisms
• Mechanisms that scale to many sites.

8
Some Security Operations

• Authentication
• Authorization
• Revocation
• Message protection
• Message integrity
• Message confidentiality
• Delegation
• Auditing and Accounting
• Non-repudiation

9
Authentication

• Verification of identity.
• Many mechanisms exist
• Username/password
• Kerberos
• Public key mechanisms
• Biometrics

10
Authorization

• Verification of rights
• Many mechanisms exist for specification and
  enforcement
• By operating system (e.g., unix file permissions)
• By application (e.g., permissions within a DBMS)
• Usually requires authentication, but doesnt
  always.

11
Revocation

• Invalidating an authentication credential, or
  removing an authorization.
• Revocation mechanisms depend on the corresponding
  authentication / authorization mechanisms.
• Major issue how long does it take for a
  revocation to take effect?

12
Message Protection

• Integrity
• Authenticate the message, and
• Verify that the message received is the same
  message that was sent.
• A signature is a message integrity mechanism that
  can be verified even if the sender is offline.
• Confidentiality
• Ensure that no one but the sender and recipient
  can read the message

13
Delegation

• Delegation is the act of granting some or all of
  ones rights to another entity
• For example, a user may run a process on a remote
  host that requires access to resources on a third
  host.

User Host
Server Host
File Server
14
Auditing and Accounting

• Auditing
• Who did what to what resource?
• Requires authentication
• Accounting
• Who used how much of what resource?

15
Non-Repudiation

• Problem how to verify a signed message when the
  credential used to sign it is no longer valid.
• The credential may have been revoked
• The credential may have expired
• The authentication mechanism used in the
  signature may have been broken.
• Non-repudiation services are third-party services
  that timestamp and sign a signed message.

16
Outline

• The Grid Security Problem
• Background Public Key Encryption and
  Certificate-Based Authentication
• Grid Security Infrastructure
• Authorization

17
Public Key Encryption

• Encryption function E takes a key (k) and a
  message (m) and returns an encrypted message
  E(k, mplain) mcypher
• Public and private keys are inverses
• E(kpublic, E(kprivate, m)) m and
• E(kprivate, E(kpublic, m)) m.
• Knowing kpublic does not make it easy to guess
  kprivate.

18
Public Key Signatures

• The signer uses a well-known hash function (h) to
  compute a hash of the message to be sent and
  encrypts the hash with the private key
• Hplain h(m)
• Hcypher E(kprivate, Hplain)
• thus
• h(m) E(kpublic, Hcypher)
• The signer sends the original message (m) plus
  the encrypted hash (Hcypher).
• The recipient calculates the message hash
  directly and decrypts the encrypted hash, and
  verifies that the two values are equal.

19
Public Key Authentication

• If Alice wants to verify Bobs identity, she
  first sends him a challenge message (m).
• Bob encrypts the challenge message with his
  private key, and sends Alice the result
• m E(kprivate, m)
• Alice decrypts Bobs message with his public key
  and verifies that its the same as the original
  challenge
• M E(kpublic, m)

20
Using Public Key Encryption for Confidentiality

• If Alice wants to send Bob a confidential
  message, she encrypts the message with his public
  key he can then read it using his private key.
• Sometimes this is combined with authentication
  Alice can encrypt a message with her private key
  and then encrypt the result with Bobs public
  key.

21
In Real Life

• Because public-key encryption is computationally
  expensive, systems such as SSL/TLS use secret-key
  encryption (using a new, randomly-generated
  session key) for most operations. They use
  public-key encryption only for authentication and
  key exchange during session initiation.

22
Key Management

• PEM model central registry of user/key mappings
• PGP model (also used by ssh) each person keeps
  track of the keys of each person they want to
  talk to.
• Certificate model each person keeps track of
  the keys of a small number of trusted Certificate
  Authorities (CAs) these CAs sign certificates
  binding keys to names.

23
Advantages/Disadvantages of Certificate Approach

• Advantages
• Third-party authentication, but the third party
  does not have to be online for authentication to
  work
• Trust is decided by individuals.
• Individuals retain complete control over their
  credentials.
• Disadvantages
• Revocation can be a slow process
• Site administrators often do not trust users to
  manage certificates wisely

24
X.509 Certificates

• An X.509 Certificate is a statement, signed by
  the issuer, binding a key to a name. It consists
  of
• A base structure containing
• A subject name
• A public key
• A validity time
• The issuers subject name
• A CA flag
• and other information
• Plus the issuers signature of the base structure
  defined above
• The certificate can be made public the
  associated private key must be kept private.

25
Certificate Extensions

• Critical extensions may not be ignored
• Non-critical extensions may be ignored

26
Getting an X.509 Certificate

• Typically, an individual (an end entity)
  generates a public/private key pair, and puts the
  public key into a certificate request, which is
  sent to the CA.
• The CA decides whether or not to honor the
  request if so, the CA creates a signed
  certificate and returns it to the end entity.
• No one but the end entity ever sees the private
  key.

27
CA Responsibilities

• Issuing certificates
• Revoking certificates
• Renewing certificates that are about to expire
• Replacing certificates for users who forgot their
  passwords
• Authenticating/authorizing requests for all of
  the above
• Maintaining certificate policy and certificate
  practice statements.

28
Deciding to Trust a CA

• Some factors to be considered
• Physical and operational security of CA site
• CA policies about certificate issuance (who can
  get one, what kind of identification is required,
  etc.).
• CA policies about certificate lifetime,
  revocation, renewal, etc.
• To help evaluate these factors, a CA typically
  publishes statements about its policies and
  practices.
• Mechanics of trusting a CA relying party must do
  some (minor) configuration on each host.

29
Typical Workflow for a Small CA

• User sends certificate request
• CA authenticates request (e.g., talks to user in
  person to verify that the request came from that
  user, and checks id), and verifies that the user
  was authorized to make the request. This step
  may be delegated to a separate Registration
  Authority (RA)
• CA issues certificate and sends it to the user.

30
Other Ways to Generate and Manage Certificates

• Large CA with distributed RA
• Gateways to other authentication systems
• Kx509 generates certificates based on kerberos
  authentication
• Certificate repositories
• Hold user credentials (certificates and private
  keys)
• Typically use username/password authentication

31
Authenticating with an X.509 Certificate

• Validate the certificate (see next slide)
• Verify that the remote entity knows the private
  key associated with the public key in the
  certificate.
• Verify that the issuer is a certificate authority
  that you trust.

32
Authentication Validating an X.509 Certificate

• Build a certificate chain
• May be short
• CA1 a trust anchor, an already-known and
  trusted CA cert
• an end entity certificate signed by CA1.
• May be longer
• CA1 a trust anchor, an already-known and
  trusted CA cert
• CA2 a CA cert signed by CA1
• N. CAN A CA cert signed by CAN-1
• N1. EEC An end-entity cert signed by CAN
• Validate each certificate in the chain
• Check signatures, validity times, etc.

33
Authentication Proof of Possession (signature)

• Several standard protocols exist to validate
  proof of possession of a private key
• Signature-based protocols, such as xml-signature,
  specify signature formats for certain types of
  messages using certificates.

34
Authentication Proof of Possession
(challenge/response)

• Protocols such as SSL/TLS use a
  challenge-response mechanism
• User sends certificate over the wire
• Relying party sends user a challenge string
• User encrypts the challenge string with the
  private key
• Relying party uses the public key to decrypt the
  encrypted challenge. If it comes out unchanged,
  the user knows the private key.

35
Authentication Validating the CA

• Authentication is valid only if its based on a
  credential issued by an authority that you trust.
• For certificate-based authentication, this means
  that you must decide which CAs you trust and
  acquire copies of their certificates.
• In validating a certificate chain, one of the CAs
  that appears in the chain must be the one of your
  trusted CAs.

36
Revoking an X.509 Certificate

• Certificate Revocation Lists (CRLs)
• The CA issues CRLs, listing certificates that
  theyve granted and later revoked.
• CRL format is standardized and can be parsed by
  software.
• Relying parties use their discretion in deciding
  how often to check CRLs.
• Online Certificate Status Protocol (OCSP)
• The CA runs an OCSP server, which relying parties
  can query for certificate status.

37
Outline

• The Grid Security Problem
• Background Public Key Encryption and
  Certificate-Based Authentication
• Grid Security Infrastructure
• Authorization

38
Grid Security Infrastructure

• Provides
• Authentication (one-way or mutual)
• Message integrity and confidentiality
• Delegation
• Extends the X.509 certificate standard to include
  proxy certificates for delegation and
  single-sign-on
• Two modes of operation transport-level and
  message-level security.
• GSI was developed as part of the Globus Toolkit

39
GSI with Transport-Level Security

• Original GSI Implementation
• Uses SSL/TLS, extended for single-sign-on and
  delegation
• Assumes a connection-based transport (e.g., tcp).
• Uses X.509 certificates for authentication and to
  establish session keys.

40
GSI with Message-Level Security

• Newer GSI Implementation
• Uses WS-Security, XML-Signature, and related
  protocols
• Provides both session-based security (which
  assumes a connection-based transport and involves
  session keys) and per-message security (which
  does not require a connection-based transport).

41
X.509 Proxy Certificates

• Issued by an end entity certificate (or another
  proxy certificate), not a CA
• Has (effectively) the same subject name as its
  issuer
• Has a different public/private key than its
  issuer.
• Allows the bearer (of the certificate and
  associated private key) to impersonate the
  issuer, subject to restrictions
• Usually a much shorter validity time
• Limited proxy flag
• flexible authorization restrictions
• Used for single sign on and delegation

42
Authentication using X.509 Proxy Certificates

• Similar to authentication using regular
  (end-entity) X.509 certificates, except that the
  certificate path is longer
• CA1 a trust anchor, an already-known and
  trusted CA cert
• N1. EEC an end-entity cert signed by CAN
• N2. PC1 a proxy cert signed by EEC
• N3. PC2 a proxy cert signed by PC1
• Extension to the X.509 syntax not recognized by
  non-GSI software (currently an Internet Draft in
  IETF).

43
Single Sign On

• A user may want to do many operations that
  require authentication during a day.
  Traditionally, this would require
• Typing the private key password many times, or
• Keeping the private key unencrypted on disk, or
• Doing all operations that require authentication
  from one instance of a program, or
• Using specialized authentication hardware.

44
Using X.509 Proxy Certificates for Single Sign On

• The user
• Creates a short-lived proxy certificate
• Keeps it and its private key unencrypted on local
  storage
• Uses it instead of the users permanent
  certificate to authenticate
• Destroys the proxy explicitly, or simply lets it
  expire.
• There is a risk that the proxy private key will
  be compromised, but the amount of damage that can
  be done is mitigated somewhat by the short
  lifetime.

45
Using X.509 Proxy Certificates for Delegation

• Assume a user process on host A wants to delegate
  to a server process on host B, which needs to
  access resources on host C.
• The server process generates a key pair and sends
  a request (with the public key) to the user
  process.
• The user process uses its local proxy certificate
  (PCA) to sign a new proxy certificate (PCB) in
  response to the servers request
• The server process on host B then uses PCB (and
  the private key it generated in step 1) to
  authenticate to host C.
• No private key is ever sent over the network.

46
Delegation Example
User process
Users Job
File Server
Machine 1
Machine 2
Machine 3
47
Delegation Non-Example
Web Browser
Web Portal
Resource
Machine 1
Machine 2
Machine 3
48
Other Uses of Proxy Certificates

• Restricted Proxy certificate includes an
  embedded policy restricting how the certificate
  may be used
• Independent proxy certificate does not convey
  any rights (rights must be granted/delegated to
  it explicitly).

49
Outline

• The Grid Security Problem
• Background Public Key Encryption and
  Certificate-Based Authentication
• Grid Security Infrastructure
• Authorization

50
Grid Authorization Goals

• Compatible with existing site security policies.
• Compatible with VO security policies.
• Easy to understand and verify.
• Easy to administer.
• Compatible with existing site security mechanisms.

51
Grid Authorization Methods

• Classic Authorization Methods
• Identity mapping
• Self and service authorization
• Direct authorization
• Other Authorization Methods
• Community Authorization Service
• Akenti
• PERMIS

52
Classic Grid Authorization

• Identity mapping maps a grid identity (that is,
  the Distinguished Name from a users X.509
  certificate) to a local identity, then lets the
  operating system enforce access control.
• Self authorization allows access only if the
  remote identity is the same as the current
  identity.
• Service authorization uses an algorithm based
  on host and service name to determine whether the
  remote identity is one that was expected.

53
Authorization Example FTP and GridFTP
USER laura PASS xxxx
ftpd
setuid(laura)
ftpd
/CNLaura Pearlman
/CNLaura Pearlman laura
gridftpd
/CNhost/myhost.edu
setuid(laura)
gridftpd
54
Authorization (and delegation) Example GRAM
/CNLaura Pearlman laura
/CNLaura Pearlman
Gatekeeper
/CNhost/myhost.edu
setuid(laura)
/CNLaura Pearlman
Job Manager
/CNLaura Pearlman
Job
/CNLaura Pearlman
/CNLaura Pearlman
55
MJMFS
Grid-mapfile
User
FactoryAccount
UserProxy
HostCreds
SetuidStarter
LJMFS
GRIM
UserAccount
Creds
MJS
Job
Resource
56
Characteristics of Identity Mapping

• Easy to understand and implement for services
  that have an existing authorization model based
  on local identity.
• Site administrators retain local control.
• Requires root access at site to add or delete a
  user, and in some cases to grant permissions.
• Set of permissions that can be granted depends on
  site-specific implementation.

57
Direct Authorization

• Just use a services pre-existing
  subject-name-based access control mechanism
• Only works for services that have one
• but very simple to implement for those that do.
• Typically implementation-dependent
• Set of permissions that can be granted depends on
  implementation
• May require site administrators intervention to
  grant/revoke permissions

58
Community Authorization Service (CAS)

• Sites perform course-grained access control,
  granting rights to large blocks of resources to
  Virtual Organizations (VOs)
• VOs use CAS to perform fine-grained access
  control, granting rights to individual resources
  to individual users.
• Resource servers running at sites enforce both
  the site policy and the VO policy.
• Developed by the Globus Project

59
CAS Policy Management

• Sites maintain site policies using existing
  methods (e.g., gridmap files and unix accounts).
• Community policies are maintained using the CAS
  server and CAS administrative protocol.
• Sites are not required to manage policy for
  individual community users or groups.

60
Community Authorization Service (CAS)

• VO administrators use the CAS administrative
  interface to enter VO policy
• Users contact the CAS server to obtain signed
  policy assertions stating what they are allowed
  to do (based on VO policy)
• Users present these signed assertions (along with
  their own identity credentials) to resource
  servers when authenticating.

61
Signed Authorization Assertions
Subject /OGrid/CNLaura Valid 3/25/03 1100
3/26/03 1100
The authorization assertion is signed by the VOs
CAS server. It delegates a subset of the VOs
rights to a user, during a validity time.
AuthorizationAssertion (non-critical
extension) Target Subject /OGrid/CNLaura Valid
3/25/03 1300 1500 These actions are
allowed Read gridftp//myhost/mydir/ Signature
(of assertion, by the VO CAS server)
It is only valid when used along with the target
users authentication credentials.
Signature (of all above, by the user)
62
A Typical CAS Request

CAS Server



CAS-maintained community policy database
User proxy

What rights does the community grant to this
user?






Resource Server
Client



What local policy applies to this user?

User proxy
Local policy information

Policy statement
Does the policy statement authorize the request?
Community Signature


Is this request authorized for the community?


63
Effective Policy in CAS
Access Granted by site To community
Access Granted by community To user
Effective Access
Maximum Access Granted by site To user (e.g., via
blacklists, whitelists)
64
Akenti

• Authorization system developed at LBNL
• Designed to allow multiple stakeholders provide
  access-control information.
• Uses policy files, use-condition certificates,
  and attribute certificates.
• Resource owners create policy files that say
  where to look for, and whos authorized to
  create, use-condition certificates and attribute
  certificates.

65
Akenti Use-Condition Certificates

• Signed certificates that define conditions of use
  of a resource (e.g., anyone with attibute X may
  read file A).
• May be marked critical, indicating that this
  condition MUST be met for the access to be
  granted.
• Because use-conditions may be marked critical, it
  is necessary to consider all use-condition
  certificates for a resource when making access
  control decisions.

66
Akenti Attribute Certificates

• Signed certificates that associate attributes
  with identities
• Having an attribute never restricts a users
  rights (e.g., there are never any use-condition
  certificates that say No one with attribute X
  may read file A).
• It is not necessary to have all of a users
  attribute certificates to make an access control
  decision (but a missing attribute certificate may
  result in fewer privileges).

67
Role-Based Access Control (RBAC)

• Roles are sets of permissions on objects.
• Users are associated with roles.
• Role definitions (which roles are permitted to
  take which actions on which objects) are
  maintained separately from role membership
  information (which users are in which roles).

68
PERMIS

• Role-based authorization system developed at
  University of Salford
• Uses policy certificates (what roles can do what
  to which resources) and role certificates (who is
  in which role).
• Currently, the PERMIS API fetches the appropriate
  policy and role certificates from LDAP servers to
  make authorization decisions

69
Other Work on Authorization

• Standardization efforts in GGF OGSA-Authz group
• Authorization service (policy decision point)
• Policy language
• Attribute assertion language

70
For More Information

• Globus Security http//www.globus.org/security
• Akenti http//www-itg.lbl.gov/Akenti/homepage.htm
  l
• PERMIS www.permis.org
• Global Grid Forum security area
  https//forge.gridforum.org/projects/sec