next up previous contents index
Next: 3.10 Managing your Condor Up: 3. Administrators' Manual Previous: 3.8 Setting Up IP/Host-Based

Subsections

  
3.9 Using X.509 Certificates for Authentication

  
3.9.1 Introduction to X.509 Authentication

Condor can use the same authentication technology as that used for secure connections in web browsers, i.e., SSL authentication with X.509 certificates.

SSL, an abbreviation for "secure sockets layer", was developed in the Netscape web browser and has since become a de-facto industry standard. Versions of Condor which include this technology supports the authentication method GSS, an abbreviation of "Generic Security Services". The primary difference between SSL and GSS is that GSS is a security API which uses the underlying mechanisms of SSL to accomplish such tasks as user authentication, key exchange, and secure communication. The implementation of SSL used is SSLeay, which is written in Australia, and therefore not subject to the U.S. encryption technology export guidelines. The maintenance of SSLeay was adopted by the OpenSSL group, which oversees its continuing development and documentation. However, the implementation of GSS used in Condor is part of the Globus software http://www.globus.org, which uses the older SSLeay technology. The export restrictions in effect at the time of this writing precludes the Condor team from making this capability available to the general public, and can only be distributed on a case-by-case basis. Email condor-admin@cs.wisc.edu for information.

These technologies use an X.509 certificate hierarchy with public-key cryptography to accomplish two tasks- Key Distribution and User Authentication.

Here is a simplified version of how this works: A public/private keypair (usually RSA) is generated by a CA. All private keys must be safeguarded by their owner against compromise. Public keys are incorporated into a certificate, which is a binding between an X.500 hierarchical name identity and a public key. Public keys (and likewise, certificates) do not need to be protected from disclosure to unauthorized parties (a.k.a. compromise), and can be distributed with software or by insecure electronic means, such as web sites, information servers, etc.

A user wishing to acquire an X.509 certificate also creates a keypair, safeguarding his private key. The public key is incorporated into a "certificate request", which is usually an email message to the CA requesting identity verification and the issuance of a certificate.

If approved, the CA returns to the user a certificate, signed by the CA. A signed certificate is simply the user's public key and X.509 identity encrypted with the CA's private key. Anyone who has access to a copy of the CA's certificate can verify the authenticity of the user's certificate by decrypting the user's certificate with the public key contained in the CA's certficate. Again, the actual implementation is more complicated, but here is a simplified version of how two entities perform mutual authentication: Both the client and server have valid copies of the issuing CA's certificate. A client informs the server that it wishes to mutually authenticate, so the parties exchange certificates Each party verifies the authenticity of the certificate by decrypting the infomation in the certificate with the public key of the CA. The server can then send some value to the client, encrypted with the public key of the client. Only the client can decrypt the ciphertext and read the value. The client performs a transformation of the value, and encrypts the result with the public key of the server and returns this information. Once the parties are satisfied as to the identity of the other party, it is possible to establish a secure connection between the client and server by negotiating a session key and security. Globus (and therefore, Condor) do not perform this final step of establishing a secure connection because of cryptographic export controls.

  
3.9.2 Using X.509 Authentication in Condor

To use GSS authentication in Condor, the pool administrator(s) must also act as a Certification Authority (CA), as well as maintaining an authorization list. Although these are actually two separate but related activities, for the purposes of simplification, consider both these tasks to be the responsibility of a CA. The CA may perform several tasks, including:

1.
Create a local CA with the tool create_ca
2.
Use the tool condor_ca to issue host certificates, as well as to sign host and user certificate requests. The condor_ca utility is a script which automates, configures and simplifies several of the complex tasks in the setup and maintenance of a CA.

Instructions for installing SSLeay and creating a Condor CA

1.
Download and install SSLeay. See http://www2.psy.uq.edu.au/~ftp/Crypto/#Where to get SSLeay - FTP site list for download sites. See http://www2.psy.uq.edu.au/~ftp/Crypto/ for general information. NOTE: There is an error in the SSLeay Makefile. For compilation on Solaris, you have to add -lsocket -nsl to the EX_LIB line in Makefile.ssl

2.
The SSL executables ssleay and c_hash must be in the path of the administrator and any users who want to create certificate requests. If not already normally installed at your site, just symlink these files to the condor bin directory.

3.
Use perl to run the create_ca.pl script, providing the fully-qualified pathname of the install directory (e.g., perl create_ca.pl /usr/local/condor/ca). This will create the install directory and install several needed files there. NOTE: During installation, you will be asked to create a pass-phrase, verify it, and then enter it when your key is used to generate the CA certificate. If you mistype your passphrase, the SSL programs die in a messy manner. This script tries to at least do some graceful cleanup.

4.
Create a symbolic link from <CA install directory>/condor_cert to a directory in the user's path, preferably the condor bin directory

5.
Create certificate directories for daemons using authentication by running: <CA install directory>/condor_ca -daemon <daemon certificate directory> NOTE: Daemon names in the certificate must be of the form: schedd@<fully qualfied host name>

6.
Sign certificate requests ONLY when you are VERY sure of the identity of the requestor. For example, have the user email you their certificate request, and verify their existance with out of band means. to sign certificates:
	condor_ca <in cert request> <out signed cert file>

7.
Add a line to the local condor configuation file defining
	CONDOR_CERT_DIR = <full path of this daemon's certificate directory>.

8.
The local condor configuration file must also have the AUTHENTICATION_METHODS     value defined, and it must include the value GSS.

9.
Restart the daemon.

Instructions for Acquiring User Certificates for X.509 Authentication

1.
The SSL executables ssleay and c_hash must be in the path of the administrator and any users who want to create certificate requests. If not already normally installed at your site, just symlink these files to the condor bin directory.

2.
run: condor_cert <certificate directory to create> 
	[suggested directory: $HOME/.condorcerts]

3.
Upon success, mail the certificate request (<cert dir>/usercert_request.pem) to your CA account or condor admin account (at cs.wisc.edu, it's "condorca")

4.
If approved, the admin will send you a signed certificate, which you must save as <cert dir>/usercert.pem

5.
Authenticated submissions require a variable "x509Directory" to be specified in the submit file, which is set to the full path of their certificate directory. Under the current configuration, the new schedd will allow remote submission if its AUTHENTICATION_METHODS includes GSS. Here is a sample submission file:
   x509Directory = /home/yourname/.condorcerts
   notify_user = mikeu@cs.wisc.edu
   executable = testit
   input = in.$(Process)
   output = out.$(Process)
   queue 2

next up previous contents index
Next: 3.10 Managing your Condor Up: 3. Administrators' Manual Previous: 3.8 Setting Up IP/Host-Based
condor-admin@cs.wisc.edu