Overview of SSL Support in the N1 Service Provisioning System 4.1

SSL is a protocol for securing communication over IP networks. SSL uses TCP/IP sockets technology to exchange messages between a client and a server, while protecting the message with a public and private key encryption system developed by RSA. Support for SSL is included in most web server products, as well as in the Netscape Navigator and Microsoft web browsers.

N1 Service Provisioning System 4.1 applications can be configured to use SSL for their network communications, preventing messages from being read or tampered. Optionally, applications can be configured to use SSL to authenticate before communicating, further increasing network security.

Cipher Suites: Encryption and Authentication Overview

The SSL protocol supports a variety of different cryptographic algorithms, or ciphers, for use in operations such as authenticating the server and client to each other, transmitting certificates, and establishing session keys. The cipher suite that SSL uses to connect determines whether any authentication will take place.

Exercise caution when selecting cipher suites. Each application must enable only those cipher suites that provide the minimum security needed by the node. SSL uses the most secure cipher suites supported by both the client and server. If low security cipher suites are enabled, a third party client can force the server to use the less secure cipher suites by publishing support for only the least secure cipher suite during cipher suite negotiation.

SSL can be operated in the following modes.

• Encryption only, no authentication – Connections are encrypted. However, SSL does not authenticate the applications that are connecting.

• Server Authentication – Clients authenticate the server to which they are connecting.

• Server and Client Authentication – Both the client and server authenticate each other.

During the installation, when you select to use SSL to secure communications between applications, you are prompted to select the cipher suite to use. The cipher suite value is stored in net.ssl.cipher.suites in the config.properties file. The cipher suite value is set to the following value based on the selection you make.

• If you select encryption, no authentication, the cipher suite is set to SSL_DH_anon_WITH_3DES_EDE_CBC_SHA.

• If you select authentication with encryption, the cipher suite is set to SSL_RSA_WITH_3DES_EDE_CBC_SHA.

For lists of SSL cipher suites that do and do not require server authentication, see SSL Cipher Suites. You can configure client authentication only for cipher suites requiring server authentication.

Authentication Key Stores

The N1 Service Provisioning System 4.1 supports self-signed certificates. Two types of key stores exist:

• Private Key Store – The private key store contains the public-private key pairs that the application uses to authenticate itself when connecting to other applications.

• Trust Key Store – The trust key store contains the public key, in self-signed certificates, of other applications that the key store trusts and allows them to connect to the application.

When enabling SSL for client-server authentication, each enabled application needs to be configured with two key stores that SSL will use to authenticate itself to other applications and to authenticate other applications.

When enabling SSL for server-only authentication, the application acting as the SSL server requires a private key store and the application acting as the SSL client requires a public, or trusted, key store. The public key stores are in the proprietary JKS format provided by the Java Secure Sockets Extension (JSSE) v1.0.3.

You must specify a password for both of the key stores. The password for both of the key stores must be the same.

For example, application A, an SSL client, and application B, an SSL server, want to connect with each other using SSL. Both are configured to use a cipher suite that requires server authentication. Application B must have a public-private key pair in its private key store, and application A must have application B's public key in its trust key store. When application A attempts to connect to application B, application B sends its public key down to application A. Application A is able to verify the public key by finding it in its trust key store.

If application B is configured to require client authentication, application A must have a public-private key pair in its private key store, and application B must have application A's public key in its trust key store. After application A has authenticated application B, application B is able to verify application A's public key, as it finds the public key in its trust key store.

Using Passwords With SSL

If you supply a password for trust key store operations, the password is only used to verify the integrity of the key store. The password does not prevent access to the contents of the trust key store, but it does protect updates to the key store. Users are not able to change the contents of the key store without supplying the password.

If you supply a password for private key store operations, the password is used to verify the integrity of the key store, protect against modifications of the key store contents, and to encrypt and protect access to the private key.

The crkeys script validates that you specified the same password for both the key stores. When creating a trust store for the first time by importing certificates, the crkeys script ensures that the trust store has the same password as the private store, if one exists. Similarly, when creating a private store for the first time, the crkeys script ensures that the private store has the same password as the trust store, if one exists.

To use the crkeys script to prompt for and verify the key store password when starting applications, use the -vpass option. The crkeys script prompts the user for the key store password if any of the key stores exist, and verifies the password against the key store. If the verification succeeds, it prints the password on the standard output so that it can be fed into the application.

Limitations of SSL on the N1 Service Provisioning System 4.1

The SSL implementation on the N1 Service Provisioning System 4.1 has the following limitations:

• Only self-signed certificates are supported. The trust key store contains self-signed certificates only. You cannot use CA-signed certificates.

• Both the trust and the private key stores must be configured with the same password. Also, within the private key store, the key password for each key in the store must be the same as the store password. The crkeys script used to create keys enforces this limitation.

• Passwords echo to the terminal. To overcome this limitation on POSIX platforms, you may have the startup script disable terminal echo and then prompt the user for a password.

• Although enabling client authentication for CLI Client applications is possible, this setup is not supported due to security limitations. The CLI Client applications do not prompt the user for key store passwords. If the key stores have been created, the key stores must be provided in the CLI Client properties file.

  The N1 Service Provisioning System 4.1 uses single trust key store for both incoming and outgoing connections. Hence, if a Master Server connects to a Remote Agent and trusts its public key and if that Remote Agent becomes compromised, that Remote Agent's keys could be used to authenticate the CLI Client to the Master Server, if the CLI Client were to use client authentication.

  Client authentication is not supported for CLI Client, therefore, the CLI Client only has a trust store. The benefit of supplying a password is that you can verify that the trust store has not been tampered with. You can specify the password in the properties file, but prompting the user for the password each time the CLI Client is run is more secure.

• For SSH connections, the remote application, the Local Distributor or Remote Agent, is automatically started. The system does not prompt you for the key store passwords to start these applications. If the applications are initialized with key stores, the passwords to their key stores must be specified in their properties file.

• When you configure the CLI Client to connect to the Master Server using SSH, the CLI Client connects to the Master Server using an SshProxy application that connects to the Master Server through sockets. The SshProxy can connect to the Master Server through SSL, but this configuration is not supported.