|
|
|
|
|
|
Administering Link-Level Encryption
Link-level encryption establishes data privacy for messages moving over the network links that connect the machines in an ATMI application. There are three levels of link-level encryption (LLE) security: 0-bit (no encryption), 56-bit (International), and 128-bit (United States and Canada). The International LLE version allows 0-bit and 56-bit encryption. The United States and Canada LLE version allows 0, 56, and 128-bit encryption.
LLE applies to the following types of ATMI links:
Understanding min and max Values
Before you can configure LLE for your ATMI application, you need to be familiar with the LLE notation: (min, max). The defaults for these parameters are:
For example, the default min and max values for the United States and Canada LLE version are (0, 128). If you want to change the defaults, you can do so by assigning new values to min and max in the UBBCONFIG file for your application.
For more information, see How LLE Works and Encryption Key Size Negotiation.
Verifying the Installed LLE Version
You can verify the LLE version installed on a machine by running the tmadmin command in verbose mode.
tmadmin -v
Key lines from the local BEA Tuxedo lic.txt file will appear on your computer screen, similar to the sample display shown below. The sample entry STRENGTH=128 indicates a United States and Canada LLE version.
[BEA Tuxedo] VERSION=8.0
[LINK ENCRYPTION] VERSION=8.0
STRENGTH=128
.
.
.
All BEA Tuxedo licenses are in the $TUXDIR/udataobj/lic.txt file on a UNIX host machine, or in the %TUXDIR%\udataobj\lic.txt file on a Windows 2000 host machine.
How to Configure LLE on Workstation Client Links
If Workstation clients are included in an application, the administrator must configure one or more workstation listeners (WSLs) to listen for connection requests from Workstation clients. Each WSL uses one or more associated workstation handlers (WSHs) to handle the Workstation client workload. Each WSH can manage multiple Workstation clients by multiplexing all requests and replies with a particular Workstation client over a single connection.
As the administrator, you enable Workstation client access to the ATMI application by specifying a WSL server in the SERVERS section of the application's UBBCONFIG file. You need to specify the -z and -Z command-line options for the WSL server if you want to override the defaults for the LLE min and max parameters. (See Understanding min and max Values for details.) Of course, link-level encryption is possible only if LLE is installed on both the local machine and the Workstation client.
Note: At the Workstation client end of a network connection, you use environment variables TMMINENCRYPTBITS and TMMAXENCRYPTBITS to override the defaults for the LLE min and max parameters.
To configure LLE on Workstation client links, follow these steps.
*SERVERS
WSL SRVGRP="group_name" SRVID=server_number ...
CLOPT="-A -- -z min -Z max ..."
In the preceding example, when tmboot(1) starts the ATMI application, it passes the "-A -- -z min -Z max" command-line options to the WSL server. When establishing a network link between a Workstation client and the WSH, the Workstation client and WSL negotiate the key size until they agree on the largest key size supported by both.
See WSL(5), WS_MIB(5), and UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference for additional information.
How to Configure LLE on Bridge Links
The BEA Tuxedo system architecture optimizes network communications by establishing a multiplexed channel among the machines in a multiple-machine application. BEA Tuxedo messages flow in both directions over this channel, and the message traffic is managed by a specialized ATMI server known as a Bridge server.
As the administrator, you place an entry in the NETWORK section of the UBBCONFIG file for each machine in an ATMI application on which a Bridge server resides. You need to specify the MINENCRYPTBITS and MAXENCRYPTBITS optional run-time parameters for the Bridge server if you want to override the defaults for the LLE min and max parameters. (See Understanding min and max Values for details.) Of course, Bridge-to-Bridge link-level encryption is possible only if LLE is installed on the machines where the Bridge servers reside.
To configure LLE on Bridge links, follow these steps.
*NETWORK
LMID NADDR="bridge_network_address" BRIDGE="bridge_device"
NLSADDR="listen_network_address"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
LMID is the logical machine where the Bridge server resides; it has direct access to the network device specified in the BRIDGE parameter.
In the preceding example, when tmboot(1) starts the ATMI application, the Bridge server reads the TUXCONFIG file to access various parameters, including MINENCRYPTBITS and MAXENCRYPTBITS. When establishing a network link with a remote Bridge server, the local and remote Bridge servers negotiate the key size until they agree on the largest key size supported by both.
See TM_MIB(5) and UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference for additional information.
How to Configure LLE on tlisten Links
tlisten(1) is a network-independent listener process that provides connections between nodes of a multiple-machine application, on which administrative utilities such as tmboot(1) can run. The application administrator installs tlisten on all machines defined in the NETWORK section of the UBBCONFIG file.
To configure LLE on tlisten links, follow the steps given in the previous topic, How to Configure LLE on Bridge Links. If you so desire, you can start a separate instance of tlisten on the local machine by entering a command such as:
tlisten -l nlsaddr [-z min -Z max]
The nlsaddr value must be the same as that specified for the NLSADDR parameter for this machine in the NETWORK section of the UBBCONFIG file. See tlisten(1) in the BEA Tuxedo Command Reference, and TM_MIB(5) and UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference for additional information.
How to Configure LLE on Domain Gateway Links
A domain gateway is a GWTDOMAIN process that relays service requests and service replies between two or more ATMI applications. It provides interoperability through a specially designed transaction processing (TP) protocol that flows over network transport protocols such as TCP/IP.
A domain gateway belongs to a domain gateway group, for which a separate Domains configuration file is required. A domain gateway group consists of a local domain access point (LDOM) and the remote domain access points (RDOMs) with which the LDOM communicates. Like the application configuration files, UBBCONFIG and TUXCONFIG, a Domains configuration file is created in text format and then converted to binary format. The text and binary files are referred to as DMCONFIG and BDMCONFIG, respectively. The DMCONFIG and BDMCONFIG files, and the environment variables associated with them, are described on the DMCONFIG(5) reference page in the File Formats, Data Descriptions, MIBs, and System Processes Reference.
As the administrator, you must place an entry in the DM_TDOMAIN section of the DMCONFIG file for each local domain access point that will accept requests for local services from remote domain access points. You must also create an entry for each remote domain access point accessible by a defined local domain access point. You need to specify the MINENCRYPTBITS and MAXENCRYPTBITS optional run-time parameters for each domain access point for which you want to override the defaults for the LLE min and max parameters. (See Understanding min and max Values for details.) Of course, domain-to-domain link-level encryption is possible only if LLE is installed on the machines where the domains reside.
To configure LLE on domain gateway links, follow these steps.
*DM_TDOMAIN
# Local network addresses
LDOM NWADDR="local_domain_network_address"
NWDEVICE="local_domain_device"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
.
.
.
# Remote network addresses
RDOM NWADDR="remote_domain_network_address"
NWDEVICE="remote_domain_device"
MINENCRYPTBITS=min
MAXENCRYPTBITS=max
.
.
.
LDOM is a local domain access point identifier, and RDOM is a remote domain access point identifier.
In the preceding example, when tmboot(1) starts the ATMI application, each domain gateway reads the BDMCONFIG file to access various parameters, including MINENCRYPTBITS and MAXENCRYPTBITS, and propagates those parameters to its local and remote domains. When the local domain is establishing a network link with a remote domain, the two domains negotiate the key size until they agree on the largest key size supported by both.
See DMCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference for additional information. Also, see Setting Up Security in Domains" in Using the BEA Tuxedo Domains Component.
See Also
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|