Grid Security Services, PART II (CONNECTIVITY LAYER)

1. 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 Grid Security Services

2. Outline • PART I: Transport Layer Security (TLS) • PART II: Grid Security Infrastructure • References Grid Security Services

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

4. Application Collective Resource Connectivity Fabric Grid Architecture Transport Layer Security protocol Grid Security Services

5. Goals • Cryptographicsecurity: TLS should be used to establish a secure connection between two parties. • 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. • 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. • Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. • TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. • Care has been taken to reduce network activity. Grid Security Services

6. 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) Grid Security Services

7. 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. Grid Security Services

8. Protocol Layers HTTP FTP SMTP TLS Handshake Change Cipher Spec Alert Protocol Protocol TCP TLS Record Protocol IP Grid Security Services

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

10. 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 Grid Security Services

11. Record protocol (1/2) • Takes messages to be transmitted, • 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) • Optionally compresses the data (note: compression must be lossless and should not increase the content length by more than 1024 bytes); • Applies a MAC: • The encryption and MAC functions translate a TLS Compressed structure into a TLS Ciphertext. The decryption functions reverse the process. • The MAC of the record also includes a sequence number so that missing, extra or repeated messages are detectable. • Note that the MAC is computed before encryption. • Optionally encrypts, • and transmits the result. Received data is: • decrypted, • verified, • decompressed, • and reassembled, • then delivered to higher level clients. Grid Security Services

12. Record Protocol (2/2) Message Authentication Code Grid Security Services

13. Record Header • Three pieces of information • Content type • Application data • Alert • Handshake • Change_cipher_spec • Content length • Suggests when to start processing • SSL version • Redundant check for version agreement Grid Security Services

14. 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). Grid Security Services

15. 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: • finding a (previously unseen) message that matches a given digest • finding "collisions", wherein two different messages have the same message digest. • finding two messages whose digests are substantially similar; • 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. Grid Security Services

16. 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. Grid Security Services

17. 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 • cryptographic hash function – the hash function is iterative • 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. Grid Security Services

18. 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” Grid Security Services

19. 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 Grid Security Services

20. 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 MACsecret: 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. Grid Security Services

21. 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. Grid Security Services

22. Generating the Master Secret 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 SERVER IN ServerHello SENT BY CLIENT IN ClientHello 4. MASTER SECRET IS 3 MD5 HASHES CONCATENATED TOGETHER = 384 BITS SOURCE: THOMAS, SSL AND TLS ESSENTIALS Grid Security Services

23. Generation of Key Material JUST LIKE FORMINGTHE MASTER SECRET EXCEPT THE MASTER SECRET IS USED HERE INSTEAD OF THE PREMASTER SECRET . . . SOURCE: THOMAS, SSL AND TLS ESSENTIALS Grid Security Services

24. Obtaining Keys from the Key Material SECRET VALUES INCLUDED IN MESSAGE AUTHENTICATION CODES SYMMETRIC KEYS INITIALIZATION VECTORS FOR DES CBC ENCRYPTION • 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. SOURCE: THOMAS, SSL AND TLS ESSENTIALS Grid Security Services

25. 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. Grid Security Services

26. Cipher-block chaining (CBC) 2/2 Grid Security Services

27. 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. • CONNECTIONSECURITY: 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) Grid Security Services

28. 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. Grid Security Services

29. 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 writepending state the write active state. Grid Security Services

30. 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. Grid Security Services

31. SSL Handshake Protocol (1/2) Steps: • Client sends ClientHello message. • 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 • A. Optional: Client sends its certificate B. Client sends ClientKeyExhcange message (pre-master) • Client sends Certificate Verify message • A. Both send ChangeCipherSpec messages B. Both send Finished messages 1 2 3 4 5 Grid Security Services

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

33. 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; Grid Security Services

34. 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; Grid Security Services

35. 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 Grid Security Services

36. 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. Grid Security Services

37. 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. Grid Security Services

38. (*) 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. Grid Security Services

39. 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 Grid Security Services

40. 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. Grid Security Services

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

42. 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 Grid Security Services

43. PART IIGrid Security Infrastructure: Proxy Certificates Grid Security Services

44. 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 Services

45. Grid Security Infrastructure (GSI) based on PKI GSI: Proxies and delegation (GSI Extensions) for secure single sign-on Proxies and Delegation Transport-level security SSL/TLS PKI (CAs and Certificates) Message-level security WS-Security, XML-Encryption, XML-Signature, etc PKI: Public Key Infrastructure, SSL: Secure Socket Layer TLS: Transport Layer Security Grid Security Services

46. GSI • Grid Security Infrastructure (or GSI) is a complete public-key system offering programmers the following three features: • Mutual authentication through digital certificates • Single sign-on • 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.) Grid Security Services

47. 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). Grid Security Services

48. 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 Grid Security Services

49. 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. Grid Security Services

50. 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. Grid Security Services