Grid Security - PowerPoint PPT Presentation


PPT – Grid Security PowerPoint presentation | free to download - id: 7ba85-NzBiY


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Grid Security


Background: Public Key Encryption and Certificate-Based Authentication ... Hold user credentials (certificates and private keys) ... – PowerPoint PPT presentation

Number of Views:76
Avg rating:3.0/5.0
Slides: 71
Provided by: laurape9
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Grid Security

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

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

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

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.

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

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

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

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

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

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

  • 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?

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

  • 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

User Host
Server Host
File Server
Auditing and Accounting
  • Auditing
  • Who did what to what resource?
  • Requires authentication
  • Accounting
  • Who used how much of what resource?

  • 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.

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

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

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.

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
  • M E(kpublic, m)

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

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.

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.

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

X.509 Certificates
  • An X.509 Certificate is a statement, signed by
    the issuer, binding a key to a name. It consists
  • 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.

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

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

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

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,
  • CA policies about certificate lifetime,
    revocation, renewal, etc.
  • To help evaluate these factors, a CA typically
    publishes statements about its policies and
  • Mechanics of trusting a CA relying party must do
    some (minor) configuration on each host.

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.

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

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
  • Verify that the issuer is a certificate authority
    that you trust.

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.

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.

Authentication Proof of Possession
  • 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.

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.

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
  • 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.

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

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
  • Two modes of operation transport-level and
    message-level security.
  • GSI was developed as part of the Globus Toolkit

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

GSI with Message-Level Security
  • Newer GSI Implementation
  • Uses WS-Security, XML-Signature, and related
  • 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).

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
  • Has a different public/private key than its
  • 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

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

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.

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
  • Uses it instead of the users permanent
    certificate to authenticate
  • Destroys the proxy explicitly, or simply lets it
  • 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

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
  • 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.

Delegation Example
User process
Users Job
File Server
Machine 1
Machine 2
Machine 3
Delegation Non-Example
Web Browser
Web Portal
Machine 1
Machine 2
Machine 3
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).

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

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.

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

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
  • Service authorization uses an algorithm based
    on host and service name to determine whether the
    remote identity is one that was expected.

Authorization Example FTP and GridFTP
USER laura PASS xxxx
/CNLaura Pearlman
/CNLaura Pearlman laura
Authorization (and delegation) Example GRAM
/CNLaura Pearlman laura
/CNLaura Pearlman
/CNLaura Pearlman
Job Manager
/CNLaura Pearlman
/CNLaura Pearlman
/CNLaura Pearlman
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.

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
  • May require site administrators intervention to
    grant/revoke permissions

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

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.

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.

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)
A Typical CAS Request

CAS Server

CAS-maintained community policy database
User proxy

What rights does the community grant to this

Resource Server

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?

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)
  • 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

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
  • Because use-conditions may be marked critical, it
    is necessary to consider all use-condition
    certificates for a resource when making access
    control decisions.

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).

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).

  • 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

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

For More Information
  • Globus Security http//
  • Akenti http//
  • Global Grid Forum security area