Overview

Universal Agent implements the SSL/TLS (Secure Socket Layer/Transport Layer Security) protocol using the OpenSSL library or the IBM z/OS System SSL library, available on the z/OS operating system. The most recent SSL standard is version3. A subsequent version was produced, changing the name to Transport Layer Security version 1 (TLSv1). TLSv1 is the actual protocol used by Universal Agent. TLSv1 is often referred to simply as SSL. The term SSL/TLS is used throughout the rest of this documentation to mean TLSv1, unless otherwise noted.

Subsequent SSL/TLS protocol versions have been produced. This includes Transport Layer Security version 1.2 (TLSv1.2) and 1.3 (TLSv1.3). TLSv1.2 is the current default Agent protocol used. However, the Agent still supports TLSv1 and will negotiate down to TLSv1 to communicate with older versions of the Agent. For enhanced security constraints, the Agent provides ways to restrict the SSL/TLS protocol used to a minimum level and impose more strict rules around the SSL/TLS protocol that is allowed.

The SSL/TLS protocol addresses the major challenges of communicating securely over a potentially insecure data network. This page discusses the issue of data privacy and integrity, and peer authentication.

Data Privacy and Integrity

People with sufficient technical knowledge and access to network resources can watch or capture data transmitting across the network. What they do with the data is up to them.

Data sent over the network that should remain private must be encrypted in a manner that unauthorized persons cannot determine what the original data contained regardless of their level of expertise, access to network resources, amount of data captured, and amount of time they have. The only party that should be able to read the data is the intended recipient.

As data is transmitted over the network, it passes through media and hardware of unknown quality that may erroneously change bits of data without warning. Additionally, although data may be encrypted, there is nothing stopping a malicious person from changing the data while it is transmitted over the network. The changed data may or may not be detected by the recipient depending on what changed and how it is processed. It may be accepted as valid data, but the information it represents is now erroneous

Data integrity must be protected from errors in transmission and malicious users. Data integrity checks insures that what was sent is exactly what is received by the recipient. Without integrity checks, there is no guarantee.

Encryption Algorithms

Encryption algorithms are used to encrypt data into an unreadable format. The encryption process is computationally expensive. There are a variety of encryption algorithms, some of which perform better than others. Some algorithms offer a higher level of security than others. Typically, the higher level of security requires more computational resources.

Message Digest Algorithms

Message digest algorithms are used to produce a Message Authentication Code (MAC) that uniquely identifies a block of data. The sender computes a MAC for the data being sent based on a shared secret key the sender and receiver hold. The sender sends the data and the MAC to the receiver. The receiver computes a new MAC for the received data based on the shared secret key. If the two MACs are the same, data integrity is maintained, else the data is rejected as it has been modified.

Message digest algorithms are often referred to as MACs and can be used synonymously in most contexts.

Supported SSL/TLS 1.2 Cipher Suites

The SSL standard defines a set of encryption and message digest algorithms, referred to as cipher suites, that insure data privacy and data integrity. Cipher suites pair encryption algorithms with appropriate message digest algorithms. The two algorithms cannot be specified individually.

Universal Agent supports a subset of the complete SSL cipher suites defined by the standard. The cipher suite name is formatted as an encryption algorithm abbreviation followed by the message digest algorithm abbreviation.

New Installations

For new installations of Universal Agent 6.3.0.1 or later, the following table identifies the supported SSL/TLS 1.2 (and prior) cipher suites and the default order in which they are selected (see Selecting an SSL Cipher Suite, below).
 

The NULL-* ciphers are valid for most components, with these exceptions:

• Universal Broker does not offer NULL-* options for its ciphers list, but it does accept NULL-NULL when no encryption is desired.
• UCTL Server and UEM Server do not allow NULL-* ciphers to be selected for their control sessions.
• UDM Manager ignores the NULL-NULL cipher suite.

Starting with 7.6.0.0, the following Diffie-Hellman Ciphers are supported for TSLv1.2 only.

Supported SSL/TLS 1.3 Cipher Suites

The following table identifies all SSL/TLS 1.3 cipher suites provided by Stonebranch, Inc.

The list is in default order, with the most preferred suite first and the least preferred suite last.

Upgrade Installations

For upgrade installations to Universal Agent 6.3.0.1 or later, any configured SSL cipher suite values will remain as is. The following table identifies the supported SSL cipher suites for Agent 6.3.0.0 and earlier, and the default order in which they are selected (see /wiki/spaces/DEV/pages/123109377, below).
 

 
Universal Agent supports one additional cipher suite name that is not part of the SSL protocol. The NULL-NULL cipher suite turns SSL off completely and instead uses the Universal V2 Protocol (UNVv2).

We'll continue to offer NULL-* values (i.e., no encryption, message authentication only) at the end of any default lists that currently offer them.

SSL Cipher Suites to be Deprecated

RC4_* and DES_* SSL cipher suites will be deprecated in a future release of Universal Agent.

Selecting an SSL Cipher Suite

When two Universal Agent components (for example, a UEM Manager and a UEM Server) first connect, they perform an SSL handshake that negotiates the cipher suite to use for the session. The Manager presents a list of cipher suites (in descending order of preference) that it would like to use. This is compared against a list of ciphers that the Server supports. The first cipher suite in common is the one used for the session.

Lists of cipher suites are helpful where a distributed software solution may cross many organizational and application boundaries, each with its own security requirements. Instead of having to choose one cipher suite for all distributed components, the software components can be configured with their own list of acceptable cipher suites based on their local security requirements.

When a high level of security is required, the higher CPU consuming cipher suite is justified. When lower level of security is acceptable, a lower CPU consuming cipher suite can be used. As long as the Manager has both cipher suites in its list, it can negotiate either cipher suite with servers of different security levels.

Peer Authentication

When communicating with a party across a data network, how do you insure that the party you are communicating with (your peer) is who you believe? A common form of network attack is a malicious user representing themselves as another user or host.

Peer authentication insures that the peer is truly who they identify themselves as. Peer authentication applies to users, computer programs and hardware systems.

SSL uses X.509 certificates and public and private keys to identify an entity. An entity may be a person, a program, or a system. A complete description of X.509 certificates is beyond the scope of this documentation. X.509 Certificates provides an overview to help get the reader oriented to the concepts, terminology and benefits.

For additional details, the following web site is recommended:

http://www.faqs.org/rfcs/rfc3280.html