griglie computazionaligrid security services1 [email protected] infn – cnaf corso di...

Griglie Computazionali Grid Security Services 1

Grid Security Services

[email protected] – CNAF

Corso di Laurea specialistica in InformaticaAnno Acc. 2004/2005

Slide sources:Grid Security Infrastructure Tutorial, Von Welch, Uni. Of Chicago and ANL;

Grid Security Infrastructure, The Globus Project and R.Buyya;Security Mechanisms – Tutorial, the European DataGrid Team, Torino, Dic 2002

Grid Security, Laura Pearlman, USC Information Sciences Institute and Globus TeamSecurity, Antonia Ghiselli, Corso di Sistemi Distribuiti, A/A 2003-2004


Outline

• PART I: Introduction

• PART II: Privacy, Integrity and Authentication

• PART III: Secure Socket Layer (SSL)

• PART IV: Grid Security Infrastructure

• PART V: Authorization

• References


PART IIntroduction


Security Needs

• Confidentiality (privacy)– a third party cannot understand the communication

• Integrity– data is not modified during communication

• Non-repudiation– the sender cannot claim he didn’t send the data

• Authentication– establish the identity of an entity (user, process, host, service, ...)

• Authorization– establish the rights of the entity


Privacy

• Only the sender and the receiver should be able to understand the conversation. If someone eavesdrops on the communication, the eavesdropper should be unable to make any sense out of it. This is generally achieved by encryption/decryption algorithms.

• Example: imagine we want to transmit the message "INVOKE METHOD ADD", and we want to make sure that, if a third party intercepts that message (e.g. using a network sniffer), they won't be able to understand that message. We could use a trivial encryption algorithm which simply changes each letter for the next one in the alphabet. The encrypted message would be "JOWPLFANFUIPEABEE" (let's suppose 'A' comes after the whitespace character). On the other hand, the receiving end would know the decryption algorithm beforehand (change each letter for the previous one in the alphabet) and would therefore be able to understand the message. Of course, this method is trivial, and encryption algorithms nowadays are much more sophisticated.


Integrity

• The receiving end must be able to know for sure that the message he is receiving is exactly the one that the transmitting end sent him.

• Traditional encryption algorithms don't protect against these kind of attacks. For example, consider the simple algorithm we've just seen. If a third party used a network sniffer to change the encrypted message to "JAMJAMJAMJAMJAMJA", the receiving end would apply the decryption algorithm and think the message is "I LI LI LI LI LI ".

• Although the malicious third party might have no idea what the message contains, he is nonetheless able to modify it (this is relatively easy to do with certain network sniffing tools). This confuses the receiving end, which would think there has been an error in the communication.

• Public-key encryption algorithms do protect against this kind of attacks (the receiving end has a way of knowing if the message it received is, in fact, the one the transmitting end sent and, therefore, not modified).


Authentication and Authorization

• We should be protected from malicious users who try to impersonate one of the parties in the secure conversation. Again, this is relatively easy to do with some network sniffing tools. However, modern encryption algorithms also protect against this kind of attacks.

• Authorization refers to mechanisms that decide when a user is authorized to perform a certain task. Authorization is related to authentication because we generally need to make sure that a user is who he claims to be (authentication) before we can make a decision on whether he can (or cannot) perform a certain task (authorization).


PART II(a) Privacy


Cryptography (1/2)

• Cryptography is "the art of writing in secret characters".

• Most modern algorithms are key-based.– A key-based algorithm uses an encryption key to encrypt the message. This

means that the encrypted message is generated using not only the message, but also using a 'key':

– The receiver can then use a decryption key to decrypt the message. Again, this means that the decryption algorithm doesn't rely only on the encrypted message. It also needs a 'key':

– Some algorithms use the same key to encrypt and decrypt, and some do not.

• It is absolutely necessary to have the decryption key to recover the original message.

• Keys are at least 128 bits long.


Cryptography (2/2)

• Mathematical tool that provides some important building blocks for the implementation of a security infrastructure

• Terminology– Plaintext: M

• If the algorithm operates on the plaintex one bit (or byte) at a time it is called stream cipher, if it operates on blocks of bits, it is called block cipher.

– Cyphertext: C

– Encryption with key K1 : E K1(M) = C

– Decryption with key K2 : D K2(C) = M

• Algorithms

– Symmetric: K1 = K2

– Public Key (asymmetric): K1 ≠ K2

K2K1

EncryptionEncryption DecryptionDecryptionM C M


Symmetric Algorithms• The same key is used for encryption

and decryption– Benefits:

• Fast

• Easy to implement

– Drawbacks:• how to distribute the keys?

• they only guarantee privacy (integrity and authentication would have the be done some other way).

• the number of keys is O(n2)

• Examples:– DES

– 3DES

– Rijndael (AES)

– Blowfish

A B

ciao

3$r ciao

A B

ciao

3$r ciao

3$r

3$r


Example (symmetric algorithms )

• Message to encrypt: 1 2 3 4 5 6 5 4 3 2 1 • Key is "4232". To encrypt the message, we'll repeat the key as many times as

necessary to 'cover' the whole message:

– 1 2 3 4 5 6 5 4 3 2 1 4 2 3 2 4 2 3 2 4 2 3 The encrypted message is created by adding both numbers:– 1 2 3 4 5 6 5 4 3 2 1 + 4 2 3 2 4 2 3 2 4 2 3 ------------------------- 5 4 6 6 9 8 8 6 7 4 4

We can decrypt following the inverse process: Repeating the key as many time as necessary to cover the message, and then subtract the key character by character:

– 5 4 6 6 9 8 8 6 7 4 4 – 4 2 3 2 4 2 3 2 4 2 3 ------------------------- 1 2 3 4 5 6 5 4 3 2 1

Original message

Encrypted message

Decrypted message


Asymmetric algorithms

• Asymmetric algorithms: a different key is used to encrypt and decrypt the message.


Public Key Cryptography (1/3)

• In public-key cryptography, the two keys are called the private key and the public key

– Private key: This key must be know only by its owner.

– Public key: This key is known to everyone (it is public)

– Relation between both keys: What one key encrypts, the other one decrypts, and vice versa. That means that if you encrypt something with my public key (which you would know, because it's public), I would need my private key to decrypt the message.


Public Key Cryptography (2/3)• Every user has two keys: one private

and one public:– it is practically impossible to derive

the private key from the public one;– a message encrypted by one key can

be decripted only by the other one.– the sender cyphers using the public

key of the receiver;– the receiver decripts using his

private key;– if someone wants to receive an

encrypted message, the sender only needs to know the receiver's public key

• Examples:– Diffie-Helmann (1977)– RSA (1978)

B’s keys

public private

A’s keys

public private

A B

ciao

3$r ciao

A B

ciao

cy7 ciao

3$r

cy7


Public Key Cryptography (3/3)

• Benefits– unlike symmetric algorithms, public-key systems can guarantee privacy, integrity and

authentication. The basic communication seen above only guarantees privacy. We will shortly see how integrity and authentication fit into public-key systems.

– publishing the public key in no way compromises the key– the number of keys is O(n)– very hard to compute the private key from the public key (which is the one everyone

knows). In fact, some algorithms need several months (and even years) of constant computation to obtain the private key from the public key.

• Drawbacks– not as fast as symmetric algorithms: keys are 512 bits (insecure) to 2048 bits


PART II(b) Message Integrity


Digital Signatures: Integrity in Public-Key Systems (1/2)• Digital signature: a piece of data which is attached to a message and which can

be used to find out if the message was tampered with during the conversation (e.g. through the intervention of a malicious user)

• The digital signature for a message is generated in two steps:– 1) A message digest is generated. A message digest is a 'summary' of the

message we are going to transmit, and has two important properties: (1) It is always smaller than the message itself and (2) Even the slightest change in the message produces a different digest. The message digest is generated using a set of hashing algorithms.

– 2) The message digest is encrypted using the sender's private key. The resulting encrypted message digest is the digital signature.

– The digital signature is attached to the message, and sent to the receiver. • The receiver then does the following:

– Using the sender's public key, decrypts the digital signature to obtain the message digest generated by the sender.

– Uses the same message digest algorithm used by the sender to generate a message digest of the received message.

– Compares both message digests (the one sent by the sender as a digital signature, and the one generated by the receiver).


Digital Signatures: Integrity in Public-Key Systems (2/2)

• If they are not exactly the same, – the message has been tampered with by a third party. We can be

sure that the digital signature was sent by the sender (and not by a malicious user) because only the sender's public key can decrypt the digital signature (which was encrypted by the sender's private key; remember that what one key encrypts, the other one decrypts, and vice versa).

– If decrypting using the public key renders a faulty message digest, this means that either the message or the message digest are not exactly what the sender sent.


One-Way Hash Functions

• Functions (H) that given as input a variable-length message (M) produce as output a string of fixed length (h)– the length of h must be at least 128 bits (to avoid birthday attacks)

1. given M, it must be easy to calculate H(M) = h

2. given h, it must be difficult to calculateM = H-1(h)

3. given M, it must be difficult to find M’ such that H(M) = H(M’)

• Examples:– SNEFRU: hash of 128 or 256 bits;

– MD4/MD5: hash of 128 bits;

– SHA (Standard FIPS): hash of 160 bits.


Example (1/2)


Example (2/2)• INTEGRITY

– Using public-key cryptography in this manner ensures integrity, because we have a way of knowing if the message we received is exactly what was sent by the sender.

• PRIVACY – The above example guarantees only integrity. The message itself is sent

unencrypted. (Note: in some cases we might not be interested in keeping the data private, we simply want to make sure it isn't tampered with. To add privacy to this conversation, we would simply need to encrypt the message).

• AUTHORIZATION – The above example does guarantee, to a certain extent, the authenticity of the

sender. Since only the sender's public key can decrypt the digital signature (encrypted with the sender's private key).

– However, the only thing this guarantees is that whoever sent the message has the private key corresponding to the public key we used to decrypt the digital signature. Although this public key might have been advertised as belonging to the sender, how can we be absolutely certain? Maybe the sender isn't really who he claims to be, but just someone impersonating the sender.

– Some security scenarios might consider that the 'weak authentication' shown in the previous example is sufficient. However, other scenarios might require that there is absolutely no doubt about a user's identity. This is achieved with digital certificates.


PART II(c) Authentication


Authentication in public-key systems

• A’s digital signature is safe if:1. A’s private key is not compromised

2. B knows A’s public key

• But: how can B be sure that A’s public key is really A’s public key and not someone else’s?– A third party guarantees the correspondence between public key and

owner’s identity, by signing a document which contains the owner’s identity and his public key (Digital Certificate)

– Both A and B must trust this third party

• Two models:– PGP: “web of trust”

– X.509: hierarchical organization


PGP “web of trust”

A

B

C

D

E

F

• F knows D and E, who knows A and C, who knows A and B.

• F is reasonably sure that the key from A is really from A.


Digital signature

• A digital certificate is a digital document that certifies that a certain public key is owned by a particular user.

• This document is signed by a third party called the certificate authority (or CA). – Of course, the certificate is encoded in a digital format and is signed by a

third party (the certificate authority) which does not itself take place in the secure conversation.

– The signature is actually a digital signature generated with the CA's private key. Therefore, we can verify the integrity of the certificate using the CA's public key.

• If you digitally sign your message with your private key, and send the receiver a copy of your certificate, he can know for sure that the message was sent by you (because only your public key can decrypt the digital signature and the certificate assures that the public key the receiver uses is yours and no one else's)


Trust

• The CA that signs the certificate needs to be trusted. – There are no specific algorithms to decide when a CA is trustworthy, each

specific user has to decide whether to trust or don't trust a CA.

– The public-key system generally has a list of 'trusted CAs', which includes the digital certificates of those trusted CAs (each of these certificates, in turn, include the CA's public key, so that the digital signatures can be verified).

• Some CAs are so well known that they are included by default in many public-key systems (for example, web browsers usually include VeriSign and GlobalSign certificates, because many websites use certificates issued by those companies to authenticate themselves to web browsers).

• Other CAs can be added to the 'trusted list'. For example, if a local department sets up a CA, and it is trusted, then it can be added to the list.


X.509 Certificates (1/2)

• The “third party” is called Certification Authority (CA).

• An X.509 Certificate contains:– Subject: identity of the owner (It is encoded as a distinguished name);

– Time of validity;

– Subject’s public key: owner’s public key, this includes not only the key itself, but information such as the algorithm used to generate the public key

– Issuer's Subject: CA's distinguished name;

– Info on the Certification Authority;

– Digital signature of the CA: the certificate includes a digital signature of all the information in the certificate. This digital signature is generated using the CA's private key. To verify the digital signature, we need the CA's public key (which can be found in the CA's certificate).


X.509 Certificates (2/2)

• Certificates are published in a directory (e.g. LDAP or WWW) managed by the CA

• CA’s periodically publish a list of compromised certificates

– Certificate Revocation Lists (CRL):• The CA issues CRLs, listing certificates that they’ve 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.


Distinguished names

• Names in X.509 certificates are not encoded simply as 'common names', such as “Mario Rossi", or "Certificate Authority XYZ", or "Systems Administrator". They are encoded as distinguished names, which are a comma-separated list of name-value pairs. For example, the following could be my distinguished name:– O=University of Pisa, OU=Department of Software Engineering, CN=Mario

Rossi

– A distinguished name can have several different attributes, and the most common are the following:

• O: Organization

• OU: Organizational Unit

• CN: Common Name (generally, the user's name)

• C: Country


CA Hierarchies (1/3)

• Who signs the CA's certificate? Another CA! – This allows for hierarchies

of CAs to be created.

– Although a CA is not explicitly trusted (because it's not in the user’s list), it may happen that the higher-level CA that signed its certificate is trusted. This makes the lower-level CA trustworthy.

Root ofhierarchy

Leaf ofhierarchy


CA Hierarchies (2/3)

• The user’s certificate is signed by Certificate Authority FOO.

• Certificate Authority FOO's certificate is, in turn, signed by Certificate Authority BAR. Finally, BAR's certificate is signed by itself.

• If you receive the user’s certificate, and don't explicitly trust CA FOO (the issuer of the user’s certificate), this doesn't automatically mean the user’s certificate isn't trustworthy. You might check to see if CA FOO's certificate was issued by a CA you do trust. If it turns out that CA BAR is in your 'trusted list', then that means that my certificate is trustworthy.

• The higher-level CA (BAR) has signed its own certificate. This is not uncommon, and is called a self-signed certificate. A CA with a self-signed certificate is called a root CA, because there's 'no one above it'. To trust a certificate signed by this CA, it must necessarily be in the list of trusted CAs.


Authentication: Validating an X.509 Certificate (3/3)

• Build a certificate chain– May be short:

1. CA1: a “trust anchor”, an already-known and trusted CA cert

2. an end entity certificate signed by CA1.

– May be longer:1. CA1: a “trust anchor”, an already-known and trusted CA cert

2. CA2: a CA cert signed by CA1

…

N. CAN: A CA cert signed by CAN-1

N+1. EEC: An end-entity cert signed by CAN

• Validate each certificate in the chain– Check signatures, validity times, etc.


Requesting a Certificate• To request a certificate a user starts by

generating a key pair (public and private)• The user then signs their own public key to

form what is called a Certificate RequestIn particular, in case of Globus:• The program grid-cert-request is used to

create a public/private key pair and unsigned certificate in ~/.globus/:

– Certificate request file: usercert_request.pem: unsigned certificate request file

– Private key: userkey.pem, encrypted private key file, readable only by the owner

• Mail usercert_request.pem to [email protected]

• Receive a Globus-signed certificatePlace in ~/.globus/usercert.pem

• Other organizations may use their own CA

Sign

CertificateRequest

Public Key

Public key

Private key


Registration Authority (RA)

• The user then takes the certificate to a Registration Authority (RA)

• A RA’s responsibility is to verify the user’s name

• The user’s name needs to be unique within the scope of a CA

• Often the RA coexists with the CA and is not apparent to the user

CertificateRequest

Public KeyID


Certificate Issuance

• The CA then takes the identity from the RA and the public key from the certificate request

• It then creates, signs and issues a certificate for the user

CertificateRequest

Public Key

NameIssuerPublic KeySignature

Name


Files for Server Authentication

• /etc/grid-security– hostcert.pem: certificate used by the server in mutual authentication

– hostkey.pem: private key corresponding to the server’s certificate (read-only by root)

– grid-mapfile: maps grid subject names to local user accounts

• /etc/grid-security/certificates– CA certificates: CA certificates that are trusted when validating

certificates, and thus needn’t be verified

– ca-signing-policy.conf: defines the subject names that can be signed by each CA


Files for User Authentication

• $HOME/.globus– usercert.pem: User’s certificate (subject name, public key, CA signature)

– userkey.pem: User’s private key (encrypted using the user’s pass phrase)

• /tmp– Proxy file(s): Temporary file(s) containing unencrypted proxy private key

and certificate (readable only by user’s account)


Secure Services• A simple authenitcation mechanism can be based on the mapping between the

distinguished names of the authorized Grid users to local credentials (for example, usernames in a Unix system).

• This simple approach is for example used by the gatekeeper (Globus), which is responsible of

– performing mutual authentication by means of files in /etc/grid-security

– mapping the certificate subjects (they are distinguished names) to local users via the gridmap file.

– gridmap file example:

# Distinguished name Local username#

/O=INFNGrid/O=INFN/OU=CNAF/CN=Tiziana Ferrari tferrari"/C=US/O=Globus/O=NPACI/OU=SDSC/CN=Richard Frost” frost"/C=US/O=Globus/O=USC/OU=ISI/CN=Carl Kesselman” u14543"/C=US/O=Globus/O=ANL/OU=MCS/CN=Ian Foster” itf


Gatekeeper: Secure Job Submission

key

cert

gatekeeperclient

1. Exchange certificates, authenticate, delegate

2. Check gridmap file

3. Lookup service

4. Run service program (e.g. jobmanager)

jobmanager

key

cert

1.

2.

map

4.

services3.


PART IIISecurity Sockets Layer (SSL)


Overview

• SSL is a protocol that involves two entities: a client and a server. It allows:– Server authentication to one client

– Client authentication to one server

– a couple client/server to establish an encrypted connection

• The SSL protocol specification is by Netscape

• It is based on TCP/IP and can be used by application-layer protocols such as:– HyperText Transport Protocol (HTTP)

– Lightweight Directory Access Protocol (LDAP)

– Internet Messaging Acces Protocol (IMAP)

– Grid Security Infrastructure (GSI, see following slides)

– Etc.


SSL features

• The specification includes two protocol definitions:– SSL Record Protocol:

• guarantees data integrity• Based on symmetric cryptography (e.g. DES, RC4, etc.): Keys are

generated uniquely for each connection because public-key encryption is computationally expensive, systems such as SSL/TLS use symmetric cryptography (using a new, randomly-generated session key) for most operations. They use public-key encryption only for authentication and key exchange during session initiation.

– SSL Handshake Protocol• It uses the SSL Record Protocol for integrity• Allows the client and server to authenticate to each other• Authentication is based on public key cryptography (e.g. RSA, DSS etc.)• Allows the client and server to negotiate the encryption algorithm

(cypher) used for authentication– SSL Alert Protocol


SSL Records and Alert Protocols

• SSL Records: this protocol provides a common format to frame all Alert, ChangeCipherSpec, Handshake, and application protocol messages.– SSL records consist of:

• encapsulated data, • digital signature (Hashed-based message authentication code (HMAC) message

digest MD5),• message type, • version, • length.

– SSL records are 8 bytes long. Because the record length is fixed, encrypted messages sometimes include padding and pad length in the frame

• SSL Alert Protocol: handles any questionable packets. If either the server or client detects an error, it sends an alert containing the error. There are three types of alert messages: warning, critical, and fatal. Based on the alert message received, the session can be restricted (warning, critical) or terminated (fatal).


SSL Handshake Protocol

Steps:1. Client sends ClientHello message.2. Server acknowledges with

ServerHello message3. Server sends its certificate 4. Optional: Server requests client's

certificate5. Optional: Client sends its certificate6. Client sends ClientKeyExhcange

message7. Client sends Certificate Verify

message8. Both send ChangeCipherSpec

messages9. Both send Finished messages


Transport Layer Security (TLS) vs SSL

• Originally developed by Netscape Communications to allow secure access of a browser to a Web server, Secure Sockets Layer (SSL) has become the accepted standard for Web security .

• SSLv3 now supports more security algorithms than SSLv2 .

• TLS is defined in the IETF RFC 2246

• TLS is based b SSl version 3.0 Protocol Specification

• However, TLS v 1.0 and SSL 3.0 do not interoperate


PART IVGrid Security Infrastructure


Problem statement

• Since a grid implies crossing organizational boundaries, resources are going to be accessed by a lot of different organizations. This poses a lot of challenges:– Only certain organizations can access our resources, and that we're

completely sure that those organizations are really who they claim to be. In other words, we have to make sure that everyone in my grid application is properly authenticated.

– Suppose organization A asks B to perform a certain task. B, on the other hand, realizes that the task should be delegated to organization C. However, let's suppose C only trusts A (and not B). Should C turn down the request because it comes from B, or accept it since the 'original' requestor is A?

– Depending on my application, I may also be interested in assuring data integrity and privacy, although in a grid application this is generally not as important as authentication.


Grid Security Infrastructure (GSI) based on PKI

PKI(CAs and

Certificates)

Transport-level security

SSL/TLS

Proxies and Delegation

GSI: Proxies and delegation (GSI Extensions) for secure single sign-on

PKI: Public Key Infrastructure, SSL: Secure Socket LayerTLS: Transport Layer Security

Message-level securityWS-Security,

XML-Encryption,XML-Signature, etc


GSI

• Grid Security Infrastructure (or GSI) is a complete public-key system offering programmers the following three features:1. Mutual authentication through digital certificates

2. Single sign-on

3. Credential delegation

• GSI is composed of a set of command-line tools to manage certificates, and a set of Java classes to easily integrate security into our grid Services.

• It is based on standard technologies, such as:– Transport-Level Security: Transport Layer Security protocol – TLS

(formerly Secure Socket Layer - SSL) and

– Message-Level Security: secure Web Services specifications (XML-Signature, XML-Encryption, etc.)


GSI with Transport-Level Security

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

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


1. Mutual Authentication

• The GSI uses X.509 certificates to guarantee a strong authentication.

• Mutual authentication simply means that in GSI, both parts of a secure conversation must be authenticated. In other words, when A wants to communicate with B, A must trust B and B must trust A.

• Mutual trust: in order to trust B, “A” must have the certificate of the CA that signed the certificate of “B”, and vice versa


2. Single sign-on (1/2)

• PROBLEM: Without proxy certificates, Organization A would have to mutually authenticate itself with all the organizations that receive requests 'on behalf of A'. In practice, this mean that: – the user in Organization A with permission to read the private key would

have to access the key each time a mutual authentication is needed. Since private keys are usually protected by a password, this means that the user would have to sign on (provide the password) to access the key and perform mutual authentication.

– Using proxy certificates, the user only has to sign in once to create the proxy certificate. The proxy certificate is then used for all subsequent authentications.


2. Single Sign On (2/2)• The solution of the problem traditionally 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.

• SOLUTION: the user adopting X.509 certificates– Creates a short-lived proxy certificate – Keeps it and its private key unencrypted on local storage– Uses it instead of the user’s 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.


Proxy Certificates for Single Sign-On (1/2)• Proxy: “The instrument by which a person is empowered to

transact the affairs of another" (Webster Dictionary)

• Proxy certificate: similar to the X.509 digital certificates, except that:– It is explicitly declared to be a proxy certificate;

– The subject’s name is the issuer’s name (the end user)

– it's not signed by a Certificate Authority; it's signed by the end user. We can be sure that the certificate is authentic by checking its signature (Organization A digitally signs the certificate).

– The owner either explicitely destroys the proxy certificate or lets it expire

– The owner keeps it and its private key unencrypted on local storage

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


Proxy Certificates for Single Sign-On(2/2)

• Proxy certificate public key: – a proxy certificate has a private-public key pair generated specifically for the

proxy certificate.

– The lifetime of the certificate is usually very limited (for example, to 24 hours). This means that, if the proxy certificate is compromised, the attacker won't be able to make much use of it. Furthermore, proxy certificates extend ordinary X.509 certificates with extra security features to limit their functionality even more (for example, by specifying that a proxy certificate can only be used for certain tasks). In this case the proxy is said to be a “restricted proxy”.


3. Credential delegation

PROBLEM: Organization A asks Organization B to perform a task. Since B trusts A, it accepts to perform the task. But let's suppose that task Z is very complex, and that one of itssubtasks (Y) must be performed by a third organization: Organization C. B will ask C to perform subtask Y but C only trusts A. What should C do? Options:1) Turn down B's request as C doesn't trust B.2) Accept B's request .


Solutions

• SOLUTION A: Anyone could claim to be acting on A's behalf! C to contact A every time it receives a request on A's behalf. Scalability problem: imagine that task Z is composed of 20

different subtasks, and that each subtask is dispatched to a different organization by B. Organization A would be flooded with messages saying "B just asked me to perform a task on your behalf... can you confirm that this is correct?". In response, A would have to mutually authenticate itself with all those organizations and give a confirmation.

• SOLUTION B: delegation, i.e. B demonstrates that it is acting on A's behalf. This is more properly called credential delegation, since proxy certificates allow a user to effectively delegate a set of credentials (the user's identity) to another user.


Using X.509 Proxy Certificates for Delegation (1/2)

• Assume a user process on host A wants to delegate to a server process on host B, which needs to access resources on host C1. The server process generates a key pair and sends a request

(with the public key) to the user process.

2. The user process uses its local proxy certificate (PCA) to sign a new proxy certificate (PCB) – which includes the public key sent by B in step 1– in response to the server’s request. PC

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

Userprocess

User’sJob

FileServer

Machine 1 Machine 2 Machine 3


Command “grid-proxy-init”

• grid-proxy-init creates the local proxy file

• User enters pass phrase, which is used to decrypt private key.

• Private key is used to sign a proxy certificate with its own, new public/private key pair.– User’s private key not exposed after proxy has been signed

• Proxy placed in /tmp, read-only by user

• NOTE: No network traffic!

User certificate file

Private Key(Encrypted)

PassPhrase

User Proxycertificate file


Delegation

• Proxy creation can be recursive– each time a new private key and new X.509 proxy certificate

• Allows remote process to act on behalf of the user

• Avoids sending passwords or private keys across the network


Other Uses of the Proxy Certificate

• The proxy certificate can be also used for all the secure conversations of a Grid user and/or service, instead of using the public-private key pair directly. This reduces the risk of having the conversations compromised because an attacker would only have a chance to crack the proxy's key pair, and not the personal one


Authentication and Authorization Overview

• User requests a certificate from his CA [yearly]

• User registers himself in a given LDAP-VO [once]

• User generates a proxy certificate (short lifetime) [daily]

• Host/service requests a certificate [yearly]

• Local site retrieves the trusted CA’s certificates [periodically] and their CRL’s [daily]

• Local site generates a gridmap-file from the LDAP database for authorization and mapping [daily]

• User contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap-file. For more information on authorization see the following slides...


PART VAuthorization:

Virtual Organization Membership Service andCommunity Authorization Service


Authorization

• Authorization is the granting or denial of permission to carry out a given action.

• Grid users are typically organized in entities called Virtual Organizations, i.e. collections of individuals and institutions that share a set of commons policies for access to resources.

• The VO generally owns resources that are shared with other VOs and establish agreements for use of general resources with local resource providers.

• While authentication is usually delegated to third-party organizations (the certification authorities), authorization is managed by both the VO itself and by the local resource providers.

• The owner of a resource should be able to enforce local authorization according to various user characteristics such as the VO membership, the roles and the identity.

• The set of authorization policies that are applicable to a given user for the user’s credentials.


Authorization• Two types of authorization:

1. VO Authorization: it is based on general information about the relationship between the user and the VOs it belongs to:• Groups he/she belongs to • Roles he is allowed to cover (e.g. administrator, superuser, etc.)• Capabilities: actions that users with a given role in a group are allowed to perform in

general from the point of view of the VO (e.g. the disk quota of the user on Storage Elements owned by the group the user is part of, is equal to 1 Gbyte)

2. Local Authorization: Information regarding what the user is allowed to do for a specific resource instance

The first type of information can be provided by a specific service operated by the VO itself.

The seconf type of information can be kept at a local site, near the resorces involved and controlled by some kind of Access Control Lists.

Local resource policies can always override the permissions granted at a VO level.

• Implementation alternatives described in the following slides:– VOMS (DataTAG project, EU)– CAS (Globus)


VO Structure• VO:

– is devided in groups and sub-groups to cluster users with similar tasks.

– Excluding the root, each group can have serveral ancestors

– The VO structure can be represented with a Direct Acyclic Graph

• User: – can be member of multiple groups at a time

– If it is a member of a group G, it is also member of all the ancestor groups of G

• Roles and capabilities: – A user at a given group level can be associated to any number of roles and

capabilities

– Roles and capabilities are inherited from ancestor groups

– Roles and capabilities can be permanent or temporary

• For each user, the VO authorization information (the user’s credentials) is structured as a list of 3-tuples:

(G1, R2, C1), (Gi, Ri, Ci), ..., (Gn, Rn, Cn)

• The 3-tuple is called: “Fully Qualified Attribute Name”


Fully Qualified Attribute Name: Example

• The fully qualified attribute name describes the membership of the users to groups. If available, for each group, the user’s role and capability information is specified.

• Example:– Role: Administrator

– Group: Nerds

– VO: campus.example.org

– /campus.example.org/Nerds/Role=Administrator

– In general, the form is:

/VO[/group[/subgroup(s)]] [/Role=“role”] [/capability=“cap”]


VOMS Server


VO Membership Service (1/2)

• Objective: to provide a secure system for Virtual Organizations (VOs) to organize users into groups and/or roles and to disseminate this information.– Membership in a VO is a restricted information.

• Grant authorization at the VO level.– Each VO has its own VOMS server.

– Contains (group/ role/ capabilities) triples for each member of the VO.

– Also support for “forced groups” (for negative permissions.)

• 3-tuples are inserted in the user proxy certificate by extending it. Information included forms an “Attribute Certificate” (RFC 3281).

• All client-server communication is secure and authenticated.

• Authorization info must be processed by the local sites.

• Two primary components:

– User client – queries the server for authorization info

– VOMS core server – returns authorization info to the client


VOMS: Client-Server Interaction1) Mutual authentication between client

and server.• Secure communication channel via

Globus GSI.2) The client sends a signed request to

server.3) The server checks the identity of the

user and the syntactic correctness of the request.

4) The server signs the authorization information and returns it back.

5) The client checks the consistency and validity of the information returned.

6) Steps 1-6 may be repeated for any number of servers.

7) The client creates a proxy certificate that includes the information returned by the VOMS servers.

8) Finally, the client may decide to include also additional information provided by the user (e.g. Kerberos tickets).

Query

Authentication

Request

AuthDB

C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy

VOMSpseudo

-cert

VOMSpseudo-cert


Pseudo Certificate Format

• For each VOMS server invoked, the authorization information from the VOMS server is included into a non critical extension of the user’s proxy certificate and signed by the VOMS server issuing the information.

/C=IT/O=INFN/L=CNAF/CN=Vincenzo Ciaschini/[email protected]/C= IT/O=INFN/CN=INFN CA

/C=IT/O=INFN/OU=gatekeeper/L=PR /CN=gridce.pr.infn.it/[email protected]/C=IT/O=INFN/CN=INFN CAVO: CMS URI: http://vomscms.cern.ch:15000

TIME1: 020710134823ZTIME2: 020711134822ZGROUP: montecarloROLE: administratorCAP: “100 GB disk”

SIGNATURE:.........L...B]....3H.......=".h.r...;C'..S......o.g.=.n8S'x..\..A~.t5....90'Q.V.I..../.Z*V*{.e.RP.....X.r.......qEbb...A...

user’s identity

server identity

credentials


VOMS Client


Problem

• Traditionally the Grid mapfile is the local repository which maps authorized Grid users to local users. Problem:– It needs to be periodically updated

– Hardly scales in case of large number of users

– For each user, role and capability information needs to be handled

• Solution: authorization data is presented by the user or user proxy when accessing the resource.


edg-voms-proxy-init• The command replaces “grid-proxy-init” : like the previous one, it generates a

user proxy certificate including authorization information from the VOMS server:

• Adds the ability to contact multiple VOMS servers and to get information.• All connections made require mutual authentication, confidentiality and

integrity.• The gatekeeper needs to:

– Check the certificate (as usual)– Extract the pseudo-certificate information and process it

Information from VOMS

User credentials

VOMS credentials

Time validity

Information addedto user proxy Certificate :


Community Authorization Service


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.


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

– the CAS administrative protocol

• In this way, 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 the users 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: /O=Grid/CN=Laura

Valid: 3/25/03 11:00 – 3/26/03 11:00

AuthorizationAssertion (non-critical extension):

Target Subject: /O=Grid/CN=Laura

Valid: 3/25/03 13:00 –15:00

These actions are allowed:

Read gridftp://myhost/mydir/*

Signature (of assertion, by the VO CAS server)

Signature (of all above, by the user)

It is only valid when used along with the target

user’s authentication

credentials.

The authorization assertion is signed

by the VO’s CAS server. It

delegates a subset of the VO’s rights to a user, during a

validity time.


A Typical CAS Request

CAS Server

What rights does the community

grant to this user?

Client

Resource Server

CAS-maintainedcommunity policy

database

User proxy

Local policyinformation

User proxy

Does the policy statement authorize the request?

What local policy applies to this user?

Is this request authorized for the community?

Policy statementCommunitySignature

Policy statementCommunitySignature


Effective Policy in CAS

AccessGranted by siteTo community

AccessGranted by community

To user

Maximum AccessGranted by site

To user (e.g., via blacklists, whitelists)

Effective Access


VOMS vs CAS

• The CAS server releases a completely new proxy certificate, where the certificate subject is the CAS distinguished name any legacy Grid server cannot decide who the owner is without inspecting the certificate extension

• No handling of either groups or roles, only permissions. The ultimate decision about what happens in a Grid resource is not a responsability of the resource administrator, but of the CAS.


References

• CA-based Trust Issues for Grid Authentication and Identity Delegation; M. Thompson et al; GGF document GFD-1.17, June 2003.

• The GLobus Toolkit 3 Programmer’s Tutorial: GT3 Security Services, PART

III, pag. 94-111, B. Sotomayor.• Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC

2459, Jan 1999.• Introduction to Secure Sockets Layer, CISCO White Paper.

• The TLS Protocol Version 1.0; T.Dierks et al.; RFC 2246, Jan 1999.

• Globus Security (http://www.globus.org/security).

• VOMS: an Authorization System for Virtual Organizations; R.Alfieri et alt.; 1st European Across Grids Conference, Santiago de Compostela, February 13-14, 2003.

• INFN Authorization Group website (http://grid-auth.infn.it)

griglie computazionaligrid security services1 [email protected] infn – cnaf corso di...

Documents

receiving end

globus team security

encrypted message

li li li li li

introduction slide

slide sources

transmitting end

trivial encryption algorithm