griglie computazionaligrid security services1 grid security services, part ii (connectivity layer)...

Griglie Computazionali Grid Security Services 1

Grid Security Services, PART II

(CONNECTIVITY LAYER)

[email protected] – CNAF

Corso di Laurea specialistica in InformaticaAnno Acc. 2005/2006

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: Transport Layer Security (TLS)

• PART II: Grid Security Infrastructure

• References


Transport Layer Security (TLS) protocol v.1RFC 2246


Application

Fabric

Connectivity

Resource

Collective

Grid Architecture

Transport Layer Securityprotocol


Goals

1. Cryptographic security: TLS should be used to establish a secure connection between two parties.

2. Interoperability: Independent programmers should be able to develop applications utilizing TLS that will then be able to successfully exchange cryptographic parameters without knowledge of one another's code.

3. Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: – to prevent the need to create a new protocol (and risking the introduction of

possible new weaknesses);– and to avoid the need to implement an entire new security library.

4. Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. 1. TLS protocol has incorporated an optional session caching scheme to reduce the

number of connections that need to be established from scratch. 2. Care has been taken to reduce network activity.


TLS and SSL

• TLS protocol itself are based on the Security Sockets Layer 3.0 Protocol Specification as published by Netscape.

• The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate

• TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0.

• They use public-key encryption only for authentication and key exchange during session initiation.

• Otherwise SSL/TLS use symmetric cryptography (using a new, randomly-generated session key)


TLS: Record and Handshake protocols

• The Transport Layer Security protocol is used between two communicating applications for:– privacy

• Symmetric cryptography is used for data encryption (e.g., DES, RC4, etc.)• keys for this symmetric encryption are generated uniquely for each connection

and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol).

• Encryption is optional

– data integrity • message integrity check using a keyed Message Authentication Code (MAC):

a secure digest of some data, protected by a secret Key. • Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations. • the Record Protocol can operate without a MAC

• The protocol is composed of two layers: – the TLS Record Protocol– the TLS Handshake Protocol.


Protocol Layers

IP

TCP

TLS

HTTP FTP SMTP

TLS Record Protocol

Handshake Change Cipher Spec AlertProtocol Protocol


Architecture

HANDLES COMMUNICATIONWITH THE APPLICATION

ProtocolsINITIALIZES COMMUNCATIONBETWEEN CLIENT & SERVER

INITIALIZES SECURECOMMUNICATION

HANDLES DATACOMPRESSION

ERROR HANDLING


Session vs connection

• Sessions vs. Connections– Multiple connections within a sessions

– One negotiation per session

• Session Resumption– Through session IDs

– Clients use server IP address or name as index

– Servers use the session IDs provide by the clients

– Use of random numbers in resumed session key calculation ensures different keys

• Session Re-handshake– Client can initiate a new handshake within a session


Record protocol (1/2)1. Takes messages to be transmitted, 2. Fragments the data into manageable blocks:

– the record layer fragments information blocks into TLS Plaintext records carrying data in chunks of 2^14 bytes or less.

– client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same Content Type may be coalesced into a single TLS Plaintext record, or a single message may be fragmented across several records)

3. Optionally compresses the data (note: compression must be lossless and should not increase the content length by more than 1024 bytes);

4. Applies a MAC:1. The encryption and MAC functions translate a TLS Compressed structure into a TLS

Ciphertext. The decryption functions reverse the process. 2. The MAC of the record also includes a sequence number so that missing, extra or repeated

messages are detectable. 3. Note that the MAC is computed before encryption.

5. Optionally encrypts, 6. and transmits the result. Received data is:

1. decrypted, 2. verified, 3. decompressed, 4. and reassembled, 5. then delivered to higher level clients.


Record Protocol (2/2)

Message Authentication Code


Record Header

• Three pieces of information1. Content type

• Application data

• Alert

• Handshake

• Change_cipher_spec

2. Content length• Suggests when to start processing

3. SSL version• Redundant check for version agreement


Hashing (1/2)

• Hash:A fixed-size result obtained by applying a mathematical function (the hashing algorithm) to an arbitrary amount of data. The Hash is also known as "message digest”.

• Hashing algorithm (or function):an algorithm used to produce a hash value of some piece of data, such as:

• a message• session key • Typical hashing algorithms include MD2, MD4, MD5, and SHA-1. • A fundamental property of all hash functions is that if two hashes (according to

the same function) are different, then the two inputs were different in some way. This property is a consequence of hash functions being deterministic, mathematical functions, but they are generally not one-to-one, with a large domain and smaller range

• Secure Hash Algorithm (SHA)A hashing algorithm that generates a message digest. There are four varieties of

SHA (SHA-1 160-bit message digest, SHA-256 256-bit, SHA-384 384-bit, SHA-512 512-bit).


Hashing (2/2)

• Iterative hash function:– breaks up a message into blocks of a fixed size and iterates over them with a

compression function. For example, MD5 and SHA-1 operate on 512-bit blocks.

– The size of the output is the same as the underlying hash function (128 or 160 bits in the case of MD5 and SHA-1), although it can be truncated if desired.

• Cryptographic hash function: have the following properties:– behave as much as possible like a random function while still being deterministic

– efficiently computable

– A cryptographic hash function is considered insecure if either of the following is computationally feasible:

1. finding a (previously unseen) message that matches a given digest

2. finding "collisions", wherein two different messages have the same message digest.

3. finding two messages whose digests are substantially similar;

4. learning anything useful about a message given only its digest

– An attacker who can do either 1. or 2. might, for example, use them to substitute an unauthorized message for an authorized one.


Cryptographic properties

• There is no formal definition which captures all of the properties considered desirable for a cryptographic hash function. These properties below are generally considered prerequisites:

• Preimage resistant: given h it should be hard to find any m such that h = hash(m)

• Second preimage resistant: given an input m1, it should be hard to find another input, m2 (m1≠ m2) such that hash(m1) = hash(m2).

• Collision-resistant: it should be hard to find two different messages m1 and m2 such that hash(m1) = hash(m2).

• A hash function meeting these criteria may still have undesirable properties. For instance, most popular hash functions are vulnerable to length-extension attacks: given h(m) and len(m) but not m, by choosing a suitable m' an attacker can calculate h(m || m') where || denotes concatenation. This property can be used to break naive authentication schemes based on hash functions. The HMAC construction works around these problems.


MAC and HMAC

• Message Authentication Code – A cryptographic hashing algorithm that uses a symmetric session key to

help ensure that a block of data has retained its integrity from the time it was sent until the time it was received.

– When using this type of algorithm, the receiving application must also possess the session key to recompute the hash value so it can verify that the base data has not changed.

• A keyed-hash message authentication code, or HMAC, is a type of message authentication code (MAC) calculated using 1. cryptographic hash function – the hash function is iterative2. a secret key

As with any MAC, it may be used to simultaneously verify both the data integrity and the authenticity of a message. Any iterative cryptographic hash function, such as MD5 or SHA-1, may be used in the calculation of an HMAC; the resulting MAC algorithm is termed HMAC-MD5 or HMAC-SHA-1 accordingly. The cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function and on the size and quality of the key.


HMAC (cont)

• HMAC is defined as:

where:– h is an iterated hash function, – K is a secret key padded with extra zeros to the block size of the hash function – m is the message to be authenticated. – "||" denotes concatenation, and denotes exclusive or. – The two constants ipad and opad, each one block long, are defined as

• ipad = 0x363636...3636 and • opad = 0x5c5c5c...5c5c.

That is, if block size of the hash function is 512, ipad and opad are 64 repetitions of the (hexadecimal) bytes 0x36 and 0x5c respectively.

– HMAC “K” = “client/server MAC secret”


Keys

• Session key – A randomly-generated number of approximately 40 to 2000 bits.

– Session keys can be derived from hash values.

– It is used one time for 1 session and then discarded.

– Session keys are symmetric (used for both encryption and decryption).

– When transmitted, they are protected by encryption with a public key from the intended recipient.

– Client write key: the key used to encrypt data written by the client.

– Server write key: the key used to encrypt data written by the server.

– SERVER-READ-KEY = CLIENT-WRITE-KEY

– SERVER-WRITE-KEY = CLIENT-READ-KEY


Pseudo-random function (1/2)

• A function that takes a key, label, and seed as input, then produces an output of arbitrary length

• From two random values (one generated by the client, one by the server) and from a pre-master secret (randomly generated by the client), for Key generation or validation, a construction is required to do expansion of secrets into blocks of data– Pseudo-random function used:

• To calculate the master key • And from master key:

– client write MAC secret: the secret data used in the secure hash function at the client, used to authenticate data written by the client

– server write MAC secret: the secret data used in the secure hash function at the server, to authenticate data written by the server.

– Symmetric keys:» Client write key: the key used to encrypt data written by the client.» server write key: the key used to encrypt data written by the server.


Pseudo-random function (2/2)A(0) = seed A(i) = HMAC_hash(secret, A(i-1))

Where: Seed: (ClientHello.random, ServerHello.random)Secret: pre_master_secret

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + ...

Where + indicates concatenation.

master_secret = Pseudo_Random_Function (pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47] by.

- The master secret is always exactly 48 bytes in length. - The length of the premaster secret will vary depending on key exchange method.- The pre_master_secret should be deleted from memory once the master_secret has been computed. - pre_master_secret is encrypted when transmitted.


Generating the Master Secret

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

1. CLIENT GENERATES THEPREMASTER SECRET

2. ENCRYPTS WITH PUBLICKEY OF SERVER (server’s publicKey Is sent by server in ServerKeyExchange)

3.CLIENT SENDS PREMASTERSECRET IN ClientKeyExchange

SENT BY CLIENTIN ClientHello

SENT BY SERVERIN ServerHello

4. MASTER SECRET IS 3 MD5HASHES CONCATENATEDTOGETHER = 384 BITS


Generation of Key Material


JUST LIKE FORMINGTHE MASTER SECRET

EXCEPT THE MASTERSECRET IS USED HEREINSTEAD OF THEPREMASTER SECRET

. . .


Obtaining Keys from the Key Material


SECRET VALUESINCLUDED IN MESSAGE

AUTHENTICATION CODES

INITIALIZATION VECTORSFOR DES CBC ENCRYPTION

SYMMETRIC KEYS

Note: initialization vecto (Cipher-block chaining – CBC) (IV) A sequence of random bytes appended to the front of the plaintext before encryption by a block cipher.

Adding the initialization vector to the beginning of the plaintext eliminates the possibility of having the initial ciphertext block the same for any two messages. For example, if messages always start with a common header (a letterhead or "From" line) their initial ciphertext would always be the same, assuming that the same cryptographic algorithm and symmetric key was used. Adding a random

initialization vecto eliminates this from happening.


Cipher-block chaining (CBC) 1/2

• Initialization vector (IV) – A sequence of random bytes appended to the front of the plaintext

before encryption by a block cipher.

– Adding the initialization vector to the beginning of the plaintext eliminates the possibility of having the initial ciphertext block the same for any two messages. For example, if messages always start with a common header (a letterhead or "From" line) their initial ciphertext would always be the same, assuming that the same cryptographic algorithm and symmetric key was used. Adding a random initialization vector eliminates this from happening.


Cipher-block chaining (CBC) 2/2


Handshake protocol (1/2)

• TLS Handshake Protocol– AUTHENTICATION: allows the server and client to authenticated each

other – NEGOTIATION: to negotiate an encryption algorithm and cryptographic

keys before the application protocol transmits or receives its first byte of data.

– CONNECTION SECURITY: provides connection security that has three basic properties:

• 1- The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA, DSS, etc.). This authentication can be made optional, but is generally required for at least one of the peers.

• 2- The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection.

• 3- The negotiation is reliable (no attacker can modify the negotiation communication without being detected)


Handshake protocol (2/2)The TLS Handshake Protocol consists of a suite of three sub-protocols which are used

to:– allow peers to agree upon security parameters for the record layer, – authenticate themselves, – instantiate negotiated security parameters change cipher spec – and report error conditions to each other alert protocol

The Handshake Protocol is responsible for negotiating a session, which consists of the following items: – session identifier: an arbitrary byte sequence chosen by the server to identify an active or

resumable session state. – peer certificate X509v3: certificate of the peer (may be null).– compression method: algorithm used to compress data prior to encryption. – cipher spec: specifies the bulk data encryption algorithm (such as null, DES, etc.) – MAC algorithm (such as MD5 or SHA). It also defines cryptographic attributes such as the

hash_size. – master secret 48-byte: secret shared between the client and server. – Resumable: a flag indicating whether the session can be used to initiate new connections.

These items are then used to create security parameters for use by the Record Layer when protecting application data.

Many connections can be instantiated using the same session through the resumption feature of the TLS Handshake Protocol.


Handshake protocol: Change cipher spec protocol

• The change cipher spec protocol exists to signal transitions in ciphering strategies.

• The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) connection state. The message consists of a single byte of value 1.

• The change cipher spec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying finished message is sent

• The change cipher spec message is sent by both the client and server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys.

• Reception of this message causes: – the receiver to instruct the Record Layer to immediately copy the read pending state

into the read current state. – Immediately after sending this message, the sender should instruct the record layer to

make the write pending state the write active state.


Handshake protocol: Alert protocol

• One of the content types supported by the TLS Record layer is the alert type.

• Alert messages convey the severity of the message and a description of the alert.

• Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier must be invalidated, preventing the failed session from being used to establish new connections.

• Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.


SSL Handshake Protocol (1/2)Steps:1. Client sends ClientHello message.2. A. Server acknowledges with ServerHello

message• The client hello and server hello establish the

following attributes: • Protocol Version, • Session ID, • Cipher Suite, • Compression Method. Additionally

• two random values are generated and exchanged: • ClientHello.random • ServerHello.random

B. Server sends its certificate (if requested)C: ServerKey Exchange (info to compute pre-master at the client side)D: Optional: Server requests client's certificate

3. A. Optional: Client sends its certificateB. Client sends ClientKeyExhcange message (pre-master)

3. Client sends Certificate Verify message4. A. Both send ChangeCipherSpec messages

B. Both send Finished messages

1

2

3

4

5


SSL Handshake Protocol (2/2)

OFFER CIPHER SUITEMENU TO SERVER

SELECT A CIPHER SUITE

SEND CERTIFICATE ANDCHAIN TO CA ROOT

CLIENT SIDE SERVER SIDE

SEND PUBLIC KEY TOENCRYPT SYMM KEY

SERVER NEGOTIATIONFINISHED

SEND ENCRYPTEDSYMMETRIC KEY


ACTIVATEENCRYPTION

CLIENT PORTIONDONE

( SERVER CHECKS OPTIONS )

ACTIVATESERVERENCRYPTION

SERVER PORTIONDONE

( CLIENT CHECKS OPTIONS )

NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION


Client Hello message• Contains:– random_bytes (total: 32 by):

• 28 bytes generated by a secure random number generator, used later in the protocol

• + 4 bytes (time of day in seconds), prevents replay attacks

– CipherSuite list, passed from the client to the server in the client hello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). Each CipherSuite defines a public key algorithm, a bulk encryption algorithm (including secret key length) and a MAC algorithm:

• CipherSuite = {public key alg., bulk encryption alg., MAC alg.}

– The client hello includes a list of compression algorithms supported by the client, ordered according to the client's preference.

struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-1>; CompressionMethod compression_methods<1..2^8-1>; }

ClientHello;


Server Hello message

• The server will send this message in response to a client hello message when it was able to find an acceptable set of algorithms. – If it cannot find such a match, it will respond with a handshake failure alert.

• This structure is generated by the server and must be different from (and independent of) ClientHello.random.

• cipher_suite: the single cipher suite selected by the server from the list in ClientHello.cipher_suites. For resumed sessions this field is the value from the state of the session being resumed.

• compression_method: the single compression algorithm selected by the server from the list in ClientHello.compression_methods.

struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; }

ServerHello;


Server Key Exchange message

• The server key exchange message conveys cryptographic information to allow the client to communicate the pre_master secret: – either an RSA public key to encrypt the pre_master secret with. If RSA is

being used for key agreement and authentication, the client: • generates a 48-byte pre_master secret,

• encrypts it using the public key from the server's certificate or the temporary RSA key provided in a server key exchange message, and

• sends the result in an encrypted pre_master secret message.

– Or a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the pre_master secret).

• In this case, the client key exchange message will contain Diffie-Hellman parameters which will allow each side to agree upon the same pre_master secret


Connection state• A TLS connection state is the operating environment of the TLS

Record Protocol. It specifies:– a compression algorithm, encryption algorithm, and MAC algorithm. – The parameters for these algorithms are known, and are set through the

Handshake protocol.– Four connection states:

• the current read and write states, • the pending read and write states. All records are processed under the

current read and write states.• The security parameters for the pending states can be set by the

TLS Handshake Protocol.• The Handshake Protocol can selectively make either of the pending

states current, in which case the appropriate current state is replaced with the pending state; the pending state is then reinitialized to an empty state.


Security parameters

• The security parameters for a TLS Connection read and write state: – Connection end: whether this entity is considered the "client" or the "server"

in this connection.– Bulk encryption algorithm: an algorithm to be used for bulk encryption. This

specification includes:• the key size of this algorithm, • how much of that key is secret (*), • whether it is a block or stream cipher, • the block size of the cipher (if appropriate), etc.

– MAC algorithm: an algorithm to be used for message authentication. This specification includes the size of the hash which is returned by the MAC algorithm.

– Compression algorithm: an algorithm to be used for data compression. all information the algorithm requires to do compression.

– master secret: a 48 byte secret: shared between the two peers in the connection.

– client random A 32 byte value provided by the client.– server random A 32 byte value provided by the server.


(*) Pre-master key in Client Key Exchange Message

• Some of the fields:– CLEAR-KEY-LENGTH

– ENCRYPTED-KEY-LENGTH

– CLEAR-KEY-DATA

– ENCRYPTED-KEY-DATA

• The CLEAR-KEY-DATA contains the clear portion of the MASTER-KEY.

• CLEAR-KEY-DATA || SECRET-KEY-DATA =MASTER-KEY, with the SECRET-KEY-DATA being the least significant bytes of the final MASTER-KEY.

• The ENCRYPTED-KEY-DATA contains the secret portions of the MASTER-KEY, encrypted using the server's public key.


Client Key Exchange message

• With this message, the premaster secret is set:– either though direct transmission of the RSA-encrypted secret,

– or by the transmission of Diffie-Hellman parameters which will allow each side to agree upon the same premaster secret


Resuming sessions (1/2)

When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters) the message flow is as follows: – The client sends a ClientHello using the Session ID of the session to be

resumed.

– The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value.

– At this point, both client and server must send change cipher spec messages and proceed directly to finished messages.

– Once the re-establishment is complete, the client and server may begin to exchange application layer data. (See flow chart below.)

– If a Session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake.


Resuming sessions (2/2)

Client Server ClientHello -------->

ServerHello [ChangeCipherSpec]

<-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data


TLS Overhead

• 2-10 times slower than a TCP session

• Where do we lose time?– Handshake phase

• Client does public-key encryption

• Usually clients have to wait on servers to finish

– Data Transfer phase• Symmetric key encryption


PART IIGrid Security Infrastructure:

Proxy Certificates


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: Repeated authentication– 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 pass phrase or by a PIN (in case of smart cards), 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 Certificate (1/3)- creation process

Source: X.509 Proxy Certificates for Dynamic Delegation, Von Welch et al.


Proxy Certificates (2/3)• 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 computed from the issuer’s name (the end user). Subjects of

different proxy certificates have to be unique within the scope of the issuer (e.g. <issuer>:hash(public_key_requester).

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

– The public key of the proxy certificate is different from the public key of the issuer’s certificate.

– Proxy Certificate Information (PCI) extension: • Identifies the proxy certificate as such• Allow the issuer to express their deside to delegate rights to the Proxy Certificate bearer• Allow the issuer to limit further proxy certificates that can be issued by the holder

– 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 (3/3)

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


Proxy certificate validation

• Validation of a certificate chain has two distinct phases:– First validation of the certificate chain up to the public key certificate occurs,

– Validation of the Proxy Certificate portion of the chain is then performed as follows:

• Ensuring each Proxy Certificate has a valid Proxy Certificate Information extension;

• Each Proxy Certificate must have a subject name derived from the subject name of its issuer;

• Verifying the number of Proxy Certificates in the chain does not exceed the maximum length specified in any of the Proxy Certificate Information extensions in the chain;

• And Storing the delegation policies of each Proxy Certificate so that the relying party can determine the set of rights delegated to the bearer of the end Proxy Certificate used to authenticate.


Creation of a Proxy Certificate for single sign-on

• A new key pair, consisting of a public and private key, is generated for use in the Proxy Certificate. The public key is encoded in a certificate request for further processing.

• The user’s private key associated with their long-term public key certificate is accessed (possibly requiring the manual entering of a pass phrase or PIN by the user) to sign the certificate request containing the public key of the newly generated key pair hence generating a Proxy Certificate.

• After signing the Proxy Certificate, the user’s long–term private key can remain secured (or the associated smart card can be removed) until the Proxy Certificate expires.

• The Proxy Certificate and its associated private key are then placed in a file. This file is protected only by local file system permissions to allow for easy access by the user’s application without intervention.


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 .


Examples

• Dynamic delegation:– a user needing to move a dataset in order to use it in a computation may

want to grant to a reliable file transfer service the necessary rights to access the dataset and storage so that it may perform a set of file transfers on the user’s behalf. Since these actions may be difficult to predict, having to arrange delegation ahead of time through some administrator is prohibitive.

• Dynamic entities:– In addition to delegation to persistent services and entities, the requirement

exists to support delegation of privileges to services that are created dynamically, often by the user them self, that do not hold any form of identity credential. A common scenario is that a user submits a job to a computational resource and wants to delegate privileges to the job to allow it to access other resources on the user’s behalf, for example, to access data belonging to the user on other resources or start sub-jobs on other resources. An important point here is that the user wants to delegate privileges specifically to the job and not to the resource as a whole.


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.


Delegation over a network (1/2)

1. The initiator, on host A at left, connects to the target service on host B at right. The initiator and target service perform mutual authentication, the initiator using its existing Proxy Certificate and the target service uses the public key certificate of its own (not shown). After authentication, an integrity protected channel is established. These two steps can be accomplished by using the SSL protocol.

2. After the initiator expresses its desire to delegate by some application-specific means, the target service generates a new public and private key pair.

3. With the new public key, a signed certificate request is created and sent back over the secured channel to the initiator.

4. The initiator uses the private key associated with its own Proxy Certificate to sign the certificate request, generating a new Proxy Certificate containing the newly generated public key from the target service. The initiator fills in appropriate values for the fields in the Proxy Certificate as well as a policy describing the rights it wishes to delegate.

5. The new Proxy Certificate is sent back over the secured channel to the target service, which places it into a file with the newly generated private key. This new Proxy Certificate is then available for use on the target service for applications running on the user’s behalf.


Delegation over a network (2/2)

Delegated certificate


Considerations

• While the host receiving the delegated Proxy Certificate may have a long-term key pairof its own (bound to an X.509 public key certificate that it used for authentication), this key pair is typically not reused for the delegated Proxy Certificate.

• The reason is that a given host may have multiple users delegating privileges to it that are intended to be bound to specific processes and not shared across processes.

• The generation of a new key pair for each process greatly simplifies the task of keeping privileges compartmentalized.

• This approach also allows a user to “revoke” the delegation by deleting the Proxy Certificate private key.


In other words: 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 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.


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 is obtained


Delegation tracing

• A relying party accepting a Proxy Certificate may have an interest in knowing which parties issued earlier Proxy Certificates in the certificate chain and to whom they delegated them.

• For example it may know that a particular service or resource is known to have been compromised and if any part of a Proxy Certificate's chain was issued to the compromised service a relying party may wish to disregard the chain.

• Delegation tracing mechanism can be carried as additional information in the ProxyCertInfo extension. However at this time agreement has not been reached as to what this information should include so it was left out of this document, and will instead be considered in future revisions.

• The debate mainly centers on whether the tracing information should simply contain the identity of the issuer and receiver or it should also contain all the details of the delegated proxy and a signed statement from the receiver that the proxy was actually acceptable to it.


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


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.• HMAC: Keyed-Hashing for Message Authentication; RFC 2104

• Introduction to Secure Sockets Layer, CISCO White Paper.

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

• X.509 Proxy Certificates for Dynamic Delegation; Welch, V.; Foster, I.; Kesselman, C. Et al; articolo.

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

griglie computazionaligrid security services1 grid security services, part ii (connectivity layer)...

Documents

new protocol

ssltls protocol

protocol specification

macthe protocol

tls implementation

grid security services

security sockets layer

entire new security