PGI Transport Level Security Profile Proposal
=============================================

Version 0.1, 2009/03/04, Moreno Marzolla


The aim of this document is to provide an initial proposal of a
possible PGI security profile based on Transport Level security;
another separate security profile for Message Level security will be
developed. The use-case for these profiles, as considered in this
document, is to be used with the PGI Execution Service.

Many production Grids currently rely on TLS, combined with an explicit
operation for delegating credentials. Credential delegation is
extremely important because it allows a client (delegator) to securely
allow a service (delegatee) to perform actions on its behalf. In
production grids this is sometimes used for allowing an execution
service to stage data on behalf of the user which submitted a specific
job. The user delegates his/her credentials to the service, so that
the service can access the remote data in the same way as the user
would.

Transport Level Security
========================

All SOAP interactions between client and server MUST be encrypted
using Globus-style X509 proxy certificates (see "X.509 Proxy
Certificates for Dynamic Delegation",
http://www.globus.org/alliance/publications/papers/pki04-welch-proxy-cert-final.pdf). The
proxy certificate contains the identity of the client, so that the
service can decide whether the client is authorized to access certain
resources. The proxy certificate MAY contain VOMS extensions, which
convey Virtual Organization membership information to the service. The
service MAY use the VO information for deciding whether the user/VO
combination is allowed to perform certain actions.

Delegation of credentials
=========================

In order to delegate its credentials to the service, a client MUST use
an explicit delegation operation. After succesfully delegating its
credentials, the client receives a "delegation id", which can be
embedded in subsequent requests (e.g., to the PGI Execution Service)
to let the service know that it MUST use the delegated credentials
associated with that ID. Note that all interactions with the
delegation service MUST be encrypted using X509 proxy certificates as
for normal PGI execution service invocations, so that each request
(containing a delegation ID) does carry the client identify. Thus,
even if an external party gets the string representing the delegation
id, it cannot use this id as the service MUST refuse delegation ids
coming from a client which identifies itself as being different than
the client which performed the original delegation operation with that
id.

The delegation id MUST be passed inside the SOAP-header of the
requests sent to the service. 

The delegation operation MUST be implemented as an appropriate
"delegation port-type", which can (and in general, does) cohexist with
the PGI execution service port-type. The delegation port-type
implements a strictly limited subset of the WS-Trust specification.
The PGI security profile will clearly define the content of all
exchanged messages, which are required for the delegation operation.
PGI-compliant services MUST recognize and support the messages defined
in the profile only. PGI-compliant services MAY or MAY NOT support
additional features as specified in the WS-Trust specification.
PGI-compliant clients are not required to support any additional
feature than those described in the profile.

The delegation operation consists of the following message exchange:

1. The delegator (client) sends an "initiate" message to the delegatee
   (service), by invoking an "initiate" message. The message
   contains a body like the following:

   <S:Body wsu:Id="init">
     <RequestSecurityToken>
       <TokenType>grdp:PKCS#10</TokenType>
       <RequestType>wsse:ReqIssue</RequestType>
       ...
     </RequestSecurityToken>
   </S:Body>

   This message implies that the Delegatee should provide the
   Delegator with a PKC#10 certificate request. NOTE: we also must
   include in this request the delegation ID as specified by the
   client. We will need to define an XML element for that id.

2. The delegatee responds with a "Request Issue" message,
   which contains a PKCS#10 certificate request which must be
   signed by the delegator. The "Request Issue" message
   has the following structure (greatly simplified):

   <Security>
      <BinarySecurityToken
           wsu:Id="ProxyCertToken"
           ValueType="grdp:PKC#10"
           EncodingType="wsse:Base64Binary">
           MIIEZzCCA9CgAwIBAgIQEmtJZc0...
         </BinarySecurityToken>
         <ds:Signature xmlns:ds="...">
             ...
             ...
         </ds:Signature>
    </Security>
    ...
 </S:Header>
 <S:Body>
    <RequestSecurityToken>
        <TokenType>wsse:X509v3</TokenType>
         <RequestType>wsse:ReqIssue</RequestType>
         <Base>
            <Reference URI="#ProxyCertToken"/>
         </Base>
    </RequestSecurityToken>
 </S:Body>

3. The client signs the certificate request with its own private key.
   The signed certificate request is sent back to the service with the
   following operation (greatly simplified):

   <RequestSecurityTokenResponse>
     <RequestedSecurityToken>
         <BinarySecurityToken ValueType="x:ProxCertToken"
              EncodingType="wsse:Base64Binary"
              xmlns:x="...">
              MIIEZzCCA9CgAwIBAgIQEmtJZc0...
         </BinarySecurityToken>
     </RequestedSecurityToken>
     <RequestedProofToken>
         <xenc:EncryptedKey Id="DelegatorProof">
             ...
         </xenc:EncryptedKey>
     </RequestedProofToken>
   </RequestSecurityTokenResponse>


This concludes the delegation operation. A very similar sequence of
itneractions must be defined to renew an existing delegation. The idea
is that delegated credentials must have limited duration (usually
services do not accept delegated proxies longer than 12 hours or so).
It must be possible for a client to renew an existing delegation, that
is, to associate a new proxy to an existing (still valid) delegation
id.