Chapter 12   Configuring Security


iPlanet Directory Access Router (iDAR) supports SSL/TLS for secure communication between its clients and backend directory servers. It also supports SASL bind mechanisms for client authentication. The following sections describe how to configure SSL/TLS functionality in iDAR from the command-line and what types of SASL mechanisms are supported:

• Configuring TLS/SSL in iDAR

• Steps to Configure TLS/SSL Support

• Generating a TLS Key Pair

• Supported SASL Mechanisms

Configuring TLS/SSL in iDAR

---

Transport Layer Security (TLS) is the Internet standard protocol for secure communication between two end points. TLS/SSL is widely used with the HTTP protocol on the Web. Because of US government restrictions on export of cryptography, TLS is supported in the following ways in iDAR:

• For US, Canadian, and customers in specific industry segments, iDAR supports 168-bit encryption.

• iDAR supports 56-bit encryption for export purposes to all other customers.

iDAR supports TLS/SSL for encryption purposes only. An encrypted TLS/SSL connection between clients and iDAR will protect the data transmitted over that connection. iDAR can also be configured to always create a SSL session between itself and the backend directory server if the network between itself and the backend LDAP server is not safe, and the directory server supports TLS/SSL.

iDAR cannot act as a "passthru" for an "end-to-end" TLS/SSL connection between the client and a backend directory server because iDAR has to be configured to bind to a directory server with one set of bind credentials and does not use the bind credentials presented by the client. Furthermore, a compliant TLS/SSL implementation would treat the iDAR as performing a "man-in-the-middle" attack, since proxying a client's credentials is not allowed in strong authentication.

iDAR can be configured to establish TLS/SSL between itself and the client and itself and the server in many different combinations. It supports both the Start TLS method where clients establish TLS/SSL session over the standard LDAP port and the alternate port 636 method where clients connect to an alternate secure port if they want to establish TLS/SSL.

The following matrix summarizes the possible configuration scenarios. The columns represent connections between client and iDAR, and the rows represent connections between iDAR and the backend LDAP directory server.

Table 12-1    TLS/SSL Configuration Scenarios  

		CLIENT
	iDAR	No TLS	TLS using alternate port 636	TLS using START TLS mechanism
SERVER	No TLS	X	X	X
	TLS using alternate port 636	X	X	X
	TLS using START TLS mechanism	X	X	X

Steps to Configure TLS/SSL Support

---

1. Generate a certificate request and a private key for iDAR using the supported certreq utility (see Generating a TLS Key Pair).

2. Send the proxy server's certificate request generated by certreq to a registered Certification Authority (CA) of your choice, e.g., Thawte, and obtain a certificate from the CA.

3. In the ids-proxy-sch-GlobalConfiguration object entry, set the ids-proxy-con-ldaps-port attribute to the port number on which to listen for LDAPS (LDAP over TLS/SSL) connections. This is optional and is necessary for clients that use the alternative port 636 method to establish TLS/SSL.

4. Make the following changes to the ids-proxy-con-GlobalConfiguration object entry.
   1. Set the ids-proxy-con-ssl-cert attribute to the location path name of the file on disk containing the server's own certificate signed by the CA.

   2. If you are configuring iDAR to communicate with a directory server over TLS/SSL and the directory server in question supports receiving certificates, set the ids-proxy-con-send-cert-as-client attribute to TRUE. Otherwise allow it to default to FALSE.

   3. Set the version of TLS that iDAR will use for establishing TLS with its clients or the backend directory server by setting the value of ids-proxy-con-server-ssl-version and/or ids-proxy-con-client-ssl-version to the appropriate version number. (see ids-proxy-con-server-ssl-version, ids-proxy-con-client-ssl-version). The defaults interoperate with iPlanet Directory products.

   4. If you want iDAR to verify the certificates presented to it you must set the ids-proxy-con-ssl-cafile to the file containing the root certificates of CA's that iDAR can trust. This file must contain the list of certificates in PEM format.

   5. If you want your clients to always present a certificate when they initiate a TLS session with iDAR, set ids-proxy-con-ssl-cert-required attribute to TRUE.

5. For each group definition configured, set the ids-proxy-con-ssl-policy attribute in the ids-proxy-sch-NetworkGroup object entry as appropriate depending on whether you want to force the client to start a TLS session before sending any LDAP operation, leave the decision to the client, or disallow the client to start a TLS session. See ids-proxy-con-ssl-policy.

6. Make the following changes to each of the ids-proxy-sch-LDAPServer object entries.
   1. Set ids-proxy-con-link-security-policy to an appropriate value (see ids-proxy-con-link-security-policy) so that iDAR will always establish SSL/TLS to the backend server, never establish TLS/SSL to the backend server, or only establish SSL/TLS with the backend server when the client does the same to iDAR.

   2. Set ids-proxy-con-x509cert-subject to the DN of the backend server that iDAR must receive as value of the subject attribute in the X509 certificate it will receive from the backend server. iDAR will accept any name if this attribute is not set.

Generating a TLS Key Pair

---

In order for TLS to operate, the server must have a private key and a certificate. The certreq program provided in the <server-root>/bin/idar/server/bin directory can be used to generate a private key and a certificate request for the server.

In order to have iDAR's certificate certified by a Certification Authority (CA), you should send the server's certificate request generated by certreq to the CA, and receive back a certificate for the server signed by the CA.

Generating Files With certreq

The certreq program is invoked as follows:

certreq -dn dn -reqout filename -keyout filename
[-dsaparms filename] [-bits bits]

The arguments are:

-reqout filename

certreq writes a certificate request to this file. This file should be sent to a Certification Authority to be signed.

-keyout filename

certreq writes the private key to this file. Make sure that only the administrator has read permission for this file.

-dn dn

The distinguished name of the server or client.

-dsaparms filename

A Digital Signature Algorithm (DSA) key is based on a set of shared parameters. Two parameter sets are provided in the lib directory: dsa512.pem for 512 bit keys and dsa1024.pem for 1024 bit keys. This argument is not needed if an RSA key is to be generated.

-bits bits

The bits field should contain the number of bits of key to generate for the RSA algorithm, such as 512 or 1024.

For example, to create a RSA key in the file k and a certificate request in the file r:

certreq -reqout r -keyout k -dn "dc=iPlanet, dc=com" -bits 1024

To create a DSA key in the file k and the certificate request in the file r:

certreq -reqout r -keyout k -dn "dc=iPlanet, dc=com"
-dsaparms <server-root>/idar-<hostname>/etc/dsa512.pem

Key File

When RSA is being used, the file specified by the -keyout parameter will contain the RSA private key similar to the following:

-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDrYc78Q9PnU8Q5d0SfFyNXI84sRtGP9NXgP70XxY6Wdg3xoQAx
Z/xWyE/0dx0xRR8bzCpi25eTVyYbyQMxY6yu2OxvsywDYwkAN2bRBgePUMVSlx2j
Zi62Fr2CzsAaajbOO0yqXFP/gyjXphYorbOvyG78Xp3vFIesWYl6GgzglwIDAQAB
AoGBAOIm1E9N/+/XbMXl0Nmlyn+z2Ch0Vm6gx0kxFEYduvTXMmiAzwWpKipbRW7V
bwfiqJP1opfe8hBPgD7b8CRo5wQziQlypp7JnFnDjL7U/QARzRATUax/t8RdCxQ4
PrZ45At/amZpkkWCozYfXA+57LlhW535KxLcstMTNpNu7YPhAkEA+PgUO09eSzMs
YyAfvVlctmaLDmcapMLRlNp5oAnUYvwK17l0mCrATTgT3w1rQ1h2zKixlUSooqy5
W3fTN19ZMQJBAPIHgJvjGGKTvDVWM4kKOQgUm1KqaUgwBqfBnpSfA+kgJenSgRs9
aX1OM6xa0w+V3zwMSeF5VBLZ4X94kgsEZEcCQA/2iAWNfzQ/IbdxVdekJSekx4Gy
5qhtvVZX87hpKO73zhIq1+jxxMaus8d3ass0ntlcb5Zsgot7m57bvfUs7eECQC/s
nmG/wQdb+4uQKxo6pPpdojfnOHurztWO+EiziAG0dO1s2lW7flTqlD7PqTVP1uk8
AbEc5jHpZMZp6Hk4AGcCQQC2PtFQ4jykO/VdXETM3jUGPbyavxA7prdb8ut1fPfi
lzPtow1Lcn4uCK/sXecS+RaXEh3wPKJkaoTlUMJpivbO
-----END RSA PRIVATE KEY-----

This is the base 64 encoding of the RSA private key. The private key file must be protected against theft, tampering, or viewing.

Certificate Request File

The file specified by -reqout will contain a certificate request. This should be sent to the CA or discarded; iDAR does not make use of the certificate request. An example file is:

-----BEGIN CERTIFICATE REQUEST-----
MIIBbTCB1wIBADAuMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQB
GRYHaVBsYW5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA62HO/EPT51PE
OXdEnxcjVyPOLEbRj/TV4D+9F8WOlnYN8aEAMWf8VshP9HcdMUUfG8wqYtuXk1cm
G8kDMWOsrtjsb7MsA2MJADdm0QYHj1DFUpcdo2Yutha9gs7AGmo2zjtMqlxT/4Mo
16YWKK2zr8hu/F6d7xSHrFmJehoM4JcCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GB
AHcBoLa3Bi3o+HblCIkD6Rx29gShLwVK+QyzrPHrC9iGgrOuZBcrJSqSVXx5U/iR
8ia14YKkZDqPJmEIe/eoxhKWgfxUQyi3D0DUovzg/+M0EIWxoCrwbJhl/1DvUgQl
eTLj+mPeW3cj4KSQdWa5TJxj6Zf2PvIMppVB0wmbkPfj
-----END CERTIFICATE REQUEST-----

The contents of the certificate request file are a base 64 encoding of a value of the ASN.1 type defined in PKS#10.

SIGNED { SEQUENCE {
version Version,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
attributes [0] IMPLICIT Attributes } }

Supported SASL Mechanisms

---

iDAR supports clients that bind to the directory using the SASL mechanism. However, not all SASL mechanisms are supported. Table 12-2 summarizes the current support.

Table 12-2    Supported SASL Mechanisms  

CRAM-MD5	Yes
DIGEST-MD5 (auth only)	Yes
DIGEST-MD5 (connection protection)	No
EXTERNAL	No
GSSAPI	No