Andrew McNab University of Manchester Joni Hahkala Helsinki University of Technology Akos Frohner CERN, Geneva February 2004 DRAFT DRAFT DRAFT DRAFT Grid use of HTTP(S) Status of this document This document describes protocols adhered to by certain mid- dleware[1][2] produced by the EU DataGrid[3] project. This document is informational and does not specify a Global Grid Forum standard. Purpose This document describes the so-called "G-HTTPS" extensions that allow clients to delegate credentials to servers for use in subsequent operations by the server on behalf of the client. These extensions make use of standard HTTPS client authentica- tion as described in RFC 2818, and add support for delegation by the addition of new HTTP methods, rather than by a modifi- cation to the underlying SSL/TLS protocols or by a separate Delegation Service (such as a SOAP-based service.) This ap- proach is relatively straighforward to support with existing HTTPS client and server frameworks, without the need to modify the implementation or to run additional services. It is also fully backwards compatible with non-delegation aware clients such as web browsers. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OP- TIONAL" in this document are to be interpreted as described in RFC 2119. In this document, the terms "GSI-proxy" and "HTTP-proxy" are used to differentiate GSI delegated credentials (defined in [4]) from HTTP proxies (defined in RFC 2616.) Terms such as Header and Method are used following the defini- tions of RFC 2616. Delegation Extensions Three new HTTP methods and one new HTTP header are added to provide delegation over HTTPS. No new HTTP response codes are defined. GET-PROXY-REQ The GET-PROXY-REQ method allows a client to prompt a server to generate an X.509 certificate request and key, and to re- turn the certificate request to the client. This method has the following form: GET-PROXY-REQ /uri HTTP/1.1 where /uri can be used to declare a sub-hierarchy of future requests to the server for which the delegated GSI-proxy should be available. This request may include an additional Delegation-ID header giving the alphanumeric string used to identify the resulting delegation session. The string must be no longer than 64 char- acters, and consist only of the characters a-z, A-Z and 0-9. The server then generates an X.509 certificate request and private key, and stores the private key for retrieval using the Delegation ID. Any certificate Subject or Issuer name will be ignored and overwritten by the client when the re- quest is subsequently signed. Successful requests receive the response "200 OK" followed by normal HTTP/1.1 headers. The MIME type must be Content-Type: application/x-x509-cert-request and the body a PEM encoded X.509 certificate request. If the client’s SSL credentials are not acceptable to the server, then it must respond with "403 Forbidden". Other problems during processing should be reported as "500 Internal Server Error". PUT-PROXY-CERT The PUT-PROXY-CERT request is made by the client after receiv- ing a successful response to a GET-PROXY-REQ request, and takes the form: PUT-PROXY-CERT /uri HTTP/1.1 The request must have the MIME type Content-Type: application/x-x509-user-cert-chain and send the PEM-encoded, concatenated new GSI-proxy certifi- cate and the original certificate chain as the request body. Before the certificate request is signed, the desired certifi- cate Subject and Issuer names must be filled in by the client The request may also include a Delegation-ID header with the same delegation ID header as sent to the server in the GET- PROXY-REQ request. This allows the client to maintain multi- ple delegation sessions with the same server with different delegated credentials, and is especially important when using GSI-proxies containing optional additional credentials, such as attribute certificates. Before responding, the server stores the signed certificate and chain, associated with the private key the server generat- ed, the client’s GSI identity and the Delegation ID if present. If the delegation is accepted, the server must store the pri- vate key and delegated GSI-proxy for the duration of the va- lidity of the GSI-proxy. (This can readily be found by the server by examining the GSI-proxy certificate’s expiration time.) If the server is not willing to store the GSI-proxy for the duration given (in particular, if the lifetime of the GSI- proxy exceeds the server’s policy for the maximum sensible lifetime of GSI-proxies) then the server must respond with "403 Forbidden." If the client’s SSL credentials are otherwise not accept- able to the server, then it must also respond with "403 For- bidden". If the request is successful, the server must respond with "200 OK" and standard HTTP/1.1 headers. Other errors should be reported as "500 Internal Server Er- ror". Delegation-ID header The Delegation-ID header is first presented by the client in the initial GET-PROXY-REQ request and is used again by the client in the corresponding PUT-PROXY-CERT request. This al- lows the server to easily associate the private key it gener- ates with the signed certificate and chain the client sends. However, the Delegation-ID may also be used in the headers of subsequent requests by other HTTP methods, so that the delegated GSI-proxy can be used by the server to fulfill the request. For example, if accessing a file on an AFS filesystem for which an AFS token is required, a delegated credential may be used by the HTTPS server to obtain the AFS token from a GSI-aware AFS Authentication server: GET /afs/@cell/some/file HTTP/1.1 Delegation-ID: 1234ABCD5678EFGH If the Delegation ID is not given, then a GSI-proxy delegated without a Delegation ID by the same GSI identity may be used to fulfill the request. Whether a Delegation ID is given or not, the delegated GSI- proxy must only be used by the server if the initiator of this subsequent request represents the original GSI identity, or is authorized to use the GSI-proxy by that GSI identity. If the delegated GSI-proxy includes additional credentials, such as VOMS attribute certificates, the server may refuse to obey subsequent requests from clients which do not have the same additional credentials but try to use the associated Del- egation ID. Servers may choose to impose this restriction if they are concerned that GSI-proxies may be stolen and used to initiate operations on the server with escalated, previously delegated credentials. GET-PROXY-INFO The GET-PROXY-INFO method has the form: GET-PROXY-INFO /uri HTTP/1.1 If the server receives a GET-PROXY-INFO request from an au- thenticated client, it may respond with a list of GSI-proxy certificates delegated to the server by the client’s GSI iden- tity for the /uri sub-hierarchy of the server’s URI-space. The private key components of the GSI-proxies are never transmit- ted. If the Delegation-ID header is present in the request, then only the GSI-proxy delegated with that ID will be returned. If a Delegation ID is not given in the GET-PROXY-INFO request, the server may choose to return all the delegated GSI-proxies which are associated with the client’s GSI identity, irrespec- tive of Delegation ID. The returned GSI-proxies certificates and chains must have the MIME type Content-Type: application/x-x509-user-cert-chain If multiple chains are to be returned, then the response must be a multipart MIME response as described in RFC 2616. Each part should include a Delegation-ID header, with the Delega- tion ID associated with that GSI-proxy. If the server does not support GET-PROXY-INFO requests (even if it understands what they are), it should respond with "501 Not Implemented". If the server is not willing to list GSI- proxies because of some feature specific to this request (such as the absence of a Delegation-ID header) then it should re- spond with "403 Forbidden" response. DELETE-PROXY The DELETE-PROXY method has the form: DELETE-PROXY /uri HTTP/1.1 If the server receives a DELETE-PROXY request from an authen- ticated client, it may remove the GSI-proxies delegated in the name of the client’s GSI identity for the /uri sub-hierarchy of the server’s URI-space. If the Delegation-ID header is present in the request, then only the GSI-proxy delegated with that ID will be deleted. If a Delegation ID is not given in the DELETE-PROXY request, the server may choose to delete all the delegated GSI-proxies which are associated with the client’s GSI identity, irrespec- tive of Delegation ID. If the server does not support DELETE-PROXY requests (even if it understands what they are), it should respond with "501 Not Implemented". If the server is not willing to delete GSI-prox- ies because of some feature specific to this request (such as the absence of a Delegation-ID header) then it should respond with "403 Forbidden" response. Security Considerations G-HTTPS relies on the security of the underlying HTTP over SSL implementation. In G-HTTPS, the Delegation ID is not used as a secret, and each operation by the client is re-validated using the authen- tication provided by the HTTPS context. Servers with delegated GSI-proxies must take precautions to protect the GSI-proxies from access by other users of the server. For example, if the GSI-proxy is stored as a file owned by the server process, then it should not be possible for unrelated CGI scripts or programs which are also run as the server’s user ID to access the file. Clients should only delegate GSI-proxies to properly authenti- cated and trustworthy servers. Proper authentication of servers is readily possible due to the Certification Authori- ties infrastructure deployed by users and organisations making use of HTTPS and GSI. Clients may need to use means outside the scope of this document to determine the trustworthiness of servers (such as a signed and audited statement of adherence to an operational practices statement.) Authors’ Addresses Andrew McNab High Energy Physics University of Manchester Manchester United Kingdom M13 9PL Andrew.McNab@man.ac.uk Joni Hahkala Helsinki University of Technology CERN/PH CH-1211 Geneva 23 Switzerland Joni.Hahkala@cern.ch Akos Frohner CERN Information Technology Division CERN CH-1211 Geneve 23 Switzerland Akos.Frohner@cern.ch References [1] GridSite http://www.gridpp.ac.uk/gridsite/ [2] EDG Java Security http://www.cern.ch/edg-wp2/security/ [3] EU DataGrid Project http://www.eu-datagrid.org/ [4] Grid Security Infrastructure (GSI) proxies "A Security Architecture for Computational Grids", I. Fos- ter, C. Kesselman, G. Tsudik, S. Tuecke. Proc. 5th ACM Conference on Computer and Communications Security Conference, pp. 83-92, 1998.