Grid Security Services, PART II CONNECTIVITY LAYER

1
Grid Security Services, PART II(CONNECTIVITY
LAYER)

• Tiziana.Ferrari_at_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
Outline

• PART I Transport Layer Security (TLS)
• PART II Grid Security Infrastructure
• References

3
Transport Layer Security (TLS) protocol v.1RFC
2246
4
Grid Architecture
Transport Layer Security protocol
5
Goals

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

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)

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.

8
Protocol Layers
HTTP FTP SMTP
TLS
Handshake Change Cipher Spec Alert Protocol
Protocol

TCP
TLS Record Protocol
IP
9
Architecture
ERROR HANDLING
INITIALIZES SECURE COMMUNICATION
HANDLES COMMUNICATION WITH THE APPLICATION
Protocols
INITIALIZES COMMUNCATION BETWEEN CLIENT SERVER
HANDLES DATA COMPRESSION
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

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

12
Record Protocol (2/2)
Message Authentication Code
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

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

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.

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.

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.

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

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

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 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
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_h
ash(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
Generating the Master Secret
1. CLIENT GENERATES THE PREMASTER SECRET 2.
ENCRYPTS WITH PUBLIC KEY OF SERVER (servers
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
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
24
Obtaining Keys from the Key Material
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.
SOURCE THOMAS, SSL AND TLS ESSENTIALS
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.

26
Cipher-block chaining (CBC) 2/2
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.
• 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
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
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
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
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
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
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_suiteslt2..216-1gt CompressionMethod
compression_methodslt1..28-1gt ClientHello
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_sui
  tes. 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
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
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
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
() 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
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
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
Resuming sessions (2/2)
Client Server ClientHello --------gt
ServerHello ChangeCipherSpec
lt-------- Finished ChangeCipherSpec
Finished --------gt Application Data
lt-------gt Application Data
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

43
PART IIGrid Security Infrastructure Proxy
Certificates
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.

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

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

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

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.

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 users 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
Proxy Certificate (1/3)- creation process
Source X.509 Proxy Certificates for Dynamic
Delegation, Von Welch et al.
52
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 subjects name is computed from the issuers
  name (the end user). Subjects of different proxy
  certificates have to be unique within the scope
  of the issuer (e.g. ltissuergthash(public_key_reque
  ster).
• it's not signed by a Certificate Authority it's
  signed by the end user (using the users
  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 issuers
  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
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
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
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 users 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 users
  longterm 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 users
  application without intervention.

56
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
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
  users 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 users 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
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
Delegation over a network (1/2)

• 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.
• After the initiator expresses its desire to
  delegate by some application-specific means, the
  target service generates a new public and private
  key pair.
• With the new public key, a signed certificate
  request is created and sent back over the secured
  channel to the initiator.
• 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.
• 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 users behalf.

60
Delegation over a network (2/2)
Delegated certificate
61
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
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
• The server process generates a key pair and sends
  a request (with the public key) to the user
  process.
• 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 servers request. PC
• 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.

63
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.
• Users private key not exposed after proxy has
  been signed
• Proxy placed in /tmp, read-only by user
• NOTE No network traffic!

User certificate file
User Proxy certificate file
Private Key (Encrypted)
Pass Phrase
64
Delegation

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

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