1. Griglie ComputazionaliGrid Security Services1 Grid Security Services, PART II (CONNECTIVITY LAYER) Tiziana.Ferrari@cnaf.infn.it INFN – CNAF Corso di Laurea specialistica in Informatica Anno 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 Team Security, Antonia Ghiselli, Corso di Sistemi Distribuiti, A/A 2003-2004

2. Griglie ComputazionaliGrid Security Services2 Outline PART I: Transport Layer Security (TLS) PART II: Grid Security Infrastructure References

3. Griglie ComputazionaliGrid Security Services3 Transport Layer Security (TLS) protocol v.1 RFC 2246

4. Griglie ComputazionaliGrid Security Services4 Application Fabric Connectivity Resource Collective Grid Architecture Transport Layer Security protocol

5. Griglie ComputazionaliGrid Security Services5 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.

6. Griglie ComputazionaliGrid Security Services6 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)

7. Griglie ComputazionaliGrid Security Services7 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.

8. Griglie ComputazionaliGrid Security Services8 Protocol Layers IP TCP TLS HTTP FTP SMTP TLS Record Protocol Handshake Change Cipher Spec Alert Protocol

9. Griglie ComputazionaliGrid Security Services9 Architecture HANDLES COMMUNICATION WITH THE APPLICATION Protocols INITIALIZES COMMUNCATION BETWEEN CLIENT & SERVER INITIALIZES SECURE COMMUNICATION HANDLES DATA COMPRESSION ERROR HANDLING

10. Griglie ComputazionaliGrid Security Services10 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

11. Griglie ComputazionaliGrid Security Services11 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.

12. Griglie ComputazionaliGrid Security Services12 Record Protocol (2/2) Message Authentication Code

13. Griglie ComputazionaliGrid Security Services13 Record Header Three pieces of information 1.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

14. Griglie ComputazionaliGrid Security Services14 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 rangedeterministic mathematical functionsone-to-one domainrange 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).

15. Griglie ComputazionaliGrid Security Services15 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.collisions 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.

16. Griglie ComputazionaliGrid Security Services16 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.HMAC

17. Griglie ComputazionaliGrid Security Services17 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 usingmessage authentication code 1.cryptographic hash function – the hash function is iterativecryptographic hash function 2.a secret keykey 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.data integritymessageMD5SHA-1

18. Griglie ComputazionaliGrid Security Services18 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.concatenationexclusive 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.hexadecimal – HMAC “K” = “client/server MAC secret”

19. Griglie ComputazionaliGrid Security Services19 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

20. Griglie ComputazionaliGrid Security Services20 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.

21. Griglie ComputazionaliGrid Security Services21 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.

22. Griglie ComputazionaliGrid Security Services22 Generating the Master Secret SOURCE: THOMAS, SSL AND TLS ESSENTIALS 1. CLIENT GENERATES THE PREMASTER SECRET 2. ENCRYPTS WITH PUBLIC KEY OF SERVER (server’s public Key Is sent by server in ServerKeyExchange) 3.CLIENT SENDS PREMASTER SECRET IN ClientKeyExchange SENT BY CLIENT IN ClientHello SENT BY SERVER IN ServerHello 4. MASTER SECRET IS 3 MD5 HASHES CONCATENATED TOGETHER = 384 BITS

23. Griglie ComputazionaliGrid Security Services23 Generation of Key Material SOURCE: THOMAS, SSL AND TLS ESSENTIALS JUST LIKE FORMING THE MASTER SECRET EXCEPT THE MASTER SECRET IS USED HERE INSTEAD OF THE PREMASTER SECRET...

24. Griglie ComputazionaliGrid Security Services24 Obtaining Keys from the Key Material SOURCE: THOMAS, SSL AND TLS ESSENTIALS SECRET VALUES INCLUDED IN MESSAGE AUTHENTICATION CODES INITIALIZATION VECTORS FOR 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.

25. Griglie ComputazionaliGrid Security Services25 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.

26. Griglie ComputazionaliGrid Security Services26 Cipher-block chaining (CBC) 2/2

27. Griglie ComputazionaliGrid Security Services27 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)

28. Griglie ComputazionaliGrid Security Services28 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.

29. Griglie ComputazionaliGrid Security Services29 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.

30. Griglie ComputazionaliGrid Security Services30 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.

31. Griglie ComputazionaliGrid Security Services31 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 certificate B. Client sends ClientKeyExhcange message (pre-master) 3.Client sends Certificate Verify message 4.A. Both send ChangeCipherSpec messages B. Both send Finished messages 1 2 3 4 5

32. Griglie ComputazionaliGrid Security Services32 SSL Handshake Protocol (2/2) OFFER CIPHER SUITE MENU TO SERVER SELECT A CIPHER SUITE SEND CERTIFICATE AND CHAIN TO CA ROOT CLIENT SIDE SERVER SIDE SEND PUBLIC KEY TO ENCRYPT SYMM KEY SERVER NEGOTIATION FINISHED SEND ENCRYPTED SYMMETRIC KEY SOURCE: THOMAS, SSL AND TLS ESSENTIALS ACTIVATE ENCRYPTION CLIENT PORTION DONE ( SERVER CHECKS OPTIONS ) ACTIVATESERVER ENCRYPTION SERVER PORTION DONE ( CLIENT CHECKS OPTIONS ) NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION

33. Griglie ComputazionaliGrid Security Services33 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 ; CompressionMethod compression_methods ; } ClientHello;

34. Griglie ComputazionaliGrid Security Services34 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;

35. Griglie ComputazionaliGrid Security Services35 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

36. Griglie ComputazionaliGrid Security Services36 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.

37. Griglie ComputazionaliGrid Security Services37 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.

38. Griglie ComputazionaliGrid Security Services38 (*) 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.

39. Griglie ComputazionaliGrid Security Services39 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

40. Griglie ComputazionaliGrid Security Services40 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.

41. Griglie ComputazionaliGrid Security Services41 Resuming sessions (2/2) Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data

42. Griglie ComputazionaliGrid Security Services42 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

43. Griglie ComputazionaliGrid Security Services43 PART II Grid Security Infrastructure: Proxy Certificates

44. Griglie ComputazionaliGrid Security Services44 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.

45. Griglie ComputazionaliGrid Security Services45 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 Layer TLS: Transport Layer Security Message-level security WS-Security, XML-Encryption, XML-Signature, etc

46. Griglie ComputazionaliGrid Security Services46 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.)

47. Griglie ComputazionaliGrid Security Services47 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).

48. Griglie ComputazionaliGrid Security Services48 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

49. Griglie ComputazionaliGrid Security Services49 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.

50. Griglie ComputazionaliGrid Security Services50 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.

51. Griglie ComputazionaliGrid Security Services51 Proxy Certificate (1/3)- creation process Source: X.509 Proxy Certificates for Dynamic Delegation, Von Welch et al.

52. Griglie ComputazionaliGrid Security Services52 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. :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.

53. Griglie ComputazionaliGrid Security Services53 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”.

54. Griglie ComputazionaliGrid Security Services54 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.

55. Griglie ComputazionaliGrid Security Services55 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.

56. Griglie ComputazionaliGrid Security Services56 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 its subtasks (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.

57. Griglie ComputazionaliGrid Security Services57 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.

58. Griglie ComputazionaliGrid Security Services58 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.

59. Griglie ComputazionaliGrid Security Services59 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.

60. Griglie ComputazionaliGrid Security Services60 Delegation over a network (2/2) Delegated certificate

61. Griglie ComputazionaliGrid Security Services61 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.

62. Griglie ComputazionaliGrid Security Services62 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 C 1.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 (PC A ) to sign a new proxy certificate (PC B ) – 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 PC B (and the private key it generated in step 1) to authenticate to host C. No private key is ever sent over the network.

63. Griglie ComputazionaliGrid Security Services63 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) Pass Phrase User Proxy certificate file

64. Griglie ComputazionaliGrid Security Services64 Delegation Proxy creation can be recursive – each time a new private key and new X.509 proxy certificate is obtained

65. Griglie ComputazionaliGrid Security Services65 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.

66. Griglie ComputazionaliGrid Security Services66 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

67. Griglie ComputazionaliGrid Security Services67 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).