Last modified 10 years ago Last modified on 12/16/10 09:49:05

Authentication in xrootd

Protocol negotiation

The use of an authentication protocol is controlled by the server and only by the server. Upon kXR_login, the server sends a list of acceptable authentication protocols, one of which the client has to use. Null or none authentication is not an option. If the client can not fulfill any of the requested protocols, it is supposed to give up. Consequently, the server must not accept a fallback to unauthenticated when it had send an authentication protocol list.

Unauthenticated access is only possible if the server sends exactly a 16 byte (empty) response to kXR_login. Hence, it is not possible to have optional authentication with fallback to unauthenticated access (e.g. with token authorization).

Detailed information about the negotiation is on page 111 of the xrootd protocol specification.

Authentication message exchange

xrootd originally intented to use its own OO-like serialization structure for authentication message exchange, called buckets. From source code inspection, these buckets are only used in the GSI (libXrdSecgsi) and password (libXrdSecpwd) plugins. One reason might be that bucket serialization and deserialization can be rather slow, since a single auth request can contain a number of these buckets. The buffer orientation has been found to be a disadvantage.

Authentication plugins


The GSI implementation in xrootd embeds a message exchange that is similar to SSL and is used to obtain the client certificate and optionally in a final step to delegate the client proxy to the server. The information exchanged in the different steps is serialized in buckets, that can optionally be encrypted. The client - server information exchange is as follows:

1.) The client sends a kXGC_certreq request. The request includes:

  • challenge string (rTag1)
  • Diffie-Hellman key exchange parameters

2.) The server sends a kXGS_cert response. The response includes:

  • rTag1 signed with server private key
  • server challenge string (rTag2)
  • string with cryptographic mode (dCache: ssl, AFAIK this can de-facto only be ssl)
  • diffie-hellman key exchange parameters
  • supported cipher modes (dCache: currently only AES-128-CBC)
  • supported message digests (dCache: currently MD5 and SHA1)
  • server certificate

3.) The client sends a kXGC_cert request. The request includes:

  • Diffie Hellman (final) key exchange parameters
  • main bucket encrypted with symmetric key derived from DH parameters
    • client proxy X509 certificate
    • signed rTag2

dCache here replies kXR_ok or kXR_error, depending on the proxy certificate. However, the server can also initiate a delegation step:

4.) The server sends kXGS_pxyreq. This can both request just a proxy forwarded by the client or send a newly created request that is signed by the client.

5.) The client sends kXGC_sigpxy. Depending on configuration that contains the proxy private key or the signed servers proxy-request.

6.) The server extracts the client's proxy private key and combines it with the client's proxy public key or it takes the certificate signed by the client and combines it with the private key stored in step 5. The result is dumped to a proxy file.


The plugin is based on Apache mod_ssl and VOMS attribute extraction based on libgridsite. A presentation about it details the motivation for creating a new GSI-like plugin and its properties.