 |
 |
||||||||
|
 |
||||||||
|
|
 |
New Features and Updates for APPX Router
Last Update: 11/17/01
1. APPX Router v1.40 Enhancements ================================= - Encryption - Encryption Negotiation - Specifying Encryption (PC Client) - Encryption Exits - Specifying Encryption (APPX Router) - Encryption Databases - Operation of Encryption without a Database - Configuring a Local Database - Configuring a Remote Database (TCP/IP) - Accessing a Remote Database via LU6.2 - Accessing the pcMAINFRAME Remote Database - Configuring a Database DLL - Encryption Module "0" - Description - Encryption Module "A" - Description Encryption ========== The most significant new feature of v1.40 is support for link level encryption between PC clients and the APPX Router. This release adds support for encrypting PC initiated sessions. Encryption on host initiated sessions is not supported. Support is provided for the coexistence of non-encrypted sessions, if needed. Once the encrypted session is established, the existence of encryption is essentially transparent to the APPX applications. Encryption (a separately licensed feature of Across the Boards and pcMAINFRAME, available only in the United States) is provided by enhancements to the APPX/TCP device drivers, and new loadable encryption modules. Encryption modules support one or more modes of operation, and each side of the link (eg. the PC client and the APPX Router) are configured with a list of "encryption modes" that are acceptable to that side. At link startup, the two side will negotiate (if possible) an encryption mode acceptable to both sides. If so configured, the two side may agree on a non-encrypted mode of operation as well. Note: encryption modules have considerable latitude in how things like key exchange are implemented. The following discussion describes typical cases. See the description of individual encryption modules for more information. In addition to the standard link startup data, additional data is required during the startup of most encrypted sessions. Amongst other things, three data strings are factored into the session key used to actually encrypt the link. These are a "Shared Secret", an "ID" and an "ID Shared Secret." In most applications, the ID and ID Shared Secret are implemented as a user ID and password. These are all optional. In addition, most encryption modules provide for an optional Diffie-Hellman exchange, or other key exchange, in addition to the three user specified data items. Encryption modules are structured so that neither of the shared secrets are ever directly exchanged over the link, in any form. They are verified as they are used to modify the session encryption key during the key negotiation process. If the shared secrets on the two sides do not match, "challenge strings" sent back and forth will not be decryptable into valid data by the receiver, thus leading to a key negotiation failure. If an ID is provided, it is exchanged over the link in encrypted form. In this phase the encryption key is built from the shared secret and any data from the (optional) key exchange protocol. The initiating PC client provides its local encryption module with the ID and its corresponding ID shared secret. The answering side (the APPX Router) receives only the ID (as described above), and uses that to look up the corresponding ID shared secret in a database. Both sides then factor the ID shared secret (in addition to the other data) into the session key, and again exchange challenge strings. If successful, an encrypted session is established, and the PC client and APPX Router will have authenticated themselves to each other. In addition to encryption modes, the two sides can negotiate non-encrypted operation or non-encrypted-ID'd operation. Non-encrypted operation is essentially the same as "old" APPX operation, while non-encrypted-ID'd provides for an exchange of ID and ID shared secret information in a non- encrypted form. Non-encrypted-ID'd operation is useful in cases where encryption is not required (for example, for users on an internal LAN), but the application wishes to let APPX and the APPX Router take care of authentication. Note: A mainframe APPX application that wishes to require encryption, or at least an "ID'd" mode, must enforce that requirement. An APPX session can still be started with that mainframe application, especially over a link that does not support encryption (for example, over a 3270 connection). If this is not acceptable, the mainframe APPX application must check the status of the session after the APPX Connect, and reject the session (via an APPX Disconnect), if encryption is not on. A PC application can require encryption by specifying the "Encryption Required" option, and verifying that the device driver accepted the ENCRYPTLINK data. Encryption support requires an APPX Router v1.40, with installed encryption modules, and client APPX/TCP device driver (CFXATWS3) with a build date of at least 7/10/01, with installed encryption modules. Encryption also requires that the PC client be configured to use the "Format-3" (or "APPX Router") connect type (the Format-2 connect type is intended to support CICS Listeners, and does not have provisions for exchanging the extra data required to negotiate encryption). In addition, each side must have a configured list of acceptable encryption modes, and must specify an "encryption requirement." Encryption Negotiation ====================== Encryption modes are negotiated by the initiating and answering APPX service modules (the APPX/TCP driver on the PC client side). Each side begins with a user configurable list of acceptable encryption modes. In addition, a "encryption requirement" flag is defined for each side. Each entry in the mode list is three characters, typically a letter and two digits. The letter is used to build the name of the encryption module (eg. CFXENCRx3.DLL), and the digits are used to select the mode of operation (00-31). The list of acceptable modes from the initiating APPX is matched by the answering APPX Router against its list of acceptable modes. The "leftmost" matching mode in the answerer's list is selected. In addition to the specific encryption modules' modes, modes "000" and "001" are available. Mode "000", specifies no encryption, if negotiated. Mode "001" specifies no encryption, but requires an ID exchange. While these modes may be specified explicitly, they are usually added to the list of modes implicitly by the specified "encryption requirement." If encryption "allowed" is specified, "001" and "000" are implicitly added to the list of modes. If "allowed ID" is specified, only "001" is implicitly added. Each side may specify one of four "encryption requirement" settings: - Not allowed - Encryption is never negotiated - Allowed - Encryption is negotiated if possible - Allowed ID - Encryption is negotiated if possible, but if not, only the ID exchange non-encrypted mode is allowed - Required - Encryption is required, and one of the explicitly listed modes must be negotiated Note: if modes "000" or "001" are explicitly specified, these may weaken the meaning of the encryption requirement setting. Any mode specified explicitly will negotiate as an acceptable mode for that encryption requirement. Thus explicitly specifying mode "001" and "encryption required," will allow mode "001" to be negotiated. If "Allowed ID" or "Encryption Required" is specified, the session will fail if a Format-3 connect is not used, even if mode "000" is explicitly listed. At the APPX Router side, the specification of allowed-ID or encryption required will fail the session if the PC client does not use the Format-3 connect, and does not offer to negotiate encryption (eg. if the PC specified "Encryption Not Allowed" or is an older version that does not support encryption). "Preference tags" may be included in a mode list. A preference tag is two dash characters followed by a digit, 1-9. Preference tags are inserted in the list of acceptable modes, and are included in the list sent during the negotiation process. An implicit preference tag of "--0" exists at the very left of the acceptable mode list, and preference tag "0" remains in effect until another tag is encountered. When matching modes, the answering APPX keeps track of the preference tag in effect for each list (the one from the initiator and the one from the caller), and records the preference tag in effect for the mode selected. For example, given the following lists: D01 --2 D02 --7 C01 --9 B02 B01 (initiator) A01 A02 --2 B01 B02 --3 C01 C02 (answerer) The matched mode would be "B01", and the preference tag returned to the initiator would be "9", and "2" would be returned to the answerer. Wildcards may be included in a mode list. The initiator expands any wildcards in its list by attempting to load all encryption modules matching the wildcard, and enumerating all modes in the selected modules matching the wildcard. Thus the list sent to the answerer in the negotiation process contains no wildcards, and only modes that are actually supported at the client. The answerer follows a similar process before matching its list of acceptable modes against the client's. An asterisk in the first position of the mode provides for a wildcard selection of the encryption DLL. Asterisks or letters in the second and third position provides for wildcard selection of the mode with the selected DLL(s). See the section on "Wildcard Mode Selection" below. Some sample wildcard specifications: A** - Any mode in encryption DLL "A" AAB - Encryption DLL "A", any mode that "Includes Shared Secret" *** - Any encryption DLL, any mode *01 - Any encryption DLL, mode 1 *AJ - Any encryption DLL, any mode w/"Shared Secret" and "Strong" Wildcard Mode Selection ----------------------- The wildcard used for mode selection is a two character string representing an eight bit binary number. Any set bit in the binary number adds a filter to the modes selected for the encryption DLL. hgfedcba -------- a - Includes Shared Secret "**" - 00000000 b - Includes ID Shared Secret "AA" - 00000000 c - Include Key Exchange "AB" - 00000001 d - "Strong" Encryption "AC" - 00000010 . e-h - Reserved . . Note: "**" is a synonym for "AA" "AP" - 00001111 "BA" - 00010000 . . . "PP" - 11111111 The selected mode, and its associated preference tag, is returned to the initiating APPX. The mode and preference tag are also made used by the APPX Router and passed to the mainframe APPX. Note that the two preference tags represent the tags for each side, and may well be different. Specifying Encryption (PC Client) ================================= The PC client specifies its encryption requirement by sending an ENCRYPTLINK XAPI Device Control String to the device driver before the APPX Connect. The ENCRYPTLINK control string is shown in "Appendix B - ENCRYPTLINK Control String" (see cfxctls.h for the latest version). The control string provides for the specification of the encryption requirement, list of acceptable encryption modes, shared secret, ID and ID shared secret, as described in the previous sections. The shared secret, ID and ID shared secret fields should be padded with nulls. The exact interpretation of the ID field is dependent on the encryption database source configured at the APPX Router, but the ID field is typically case-insensitive. The two shared secret fields are always case sensitive and must match the values specified at the APPX Router bit for bit. pcMAINFRAME note: pcMAINFRAME uses only uppercase passwords for the ID shared secret. The PC client may specify the address of an encryption exit that is called by the encryption support in the driver to provide an additional source of data and to further qualify the session authorization. In conjunction with the exit, the PC client may specify up to 32 bytes of data in the session_id field. This is a data area reserved for the application and will be passed intact to the encryption exit. While any data the application wishes may be stored in the session_id field, the primary use for this field is to allow the encryption exit to correlate a call to the exit, to a particular APPX session in the application. A common use for the session_id field is to pass a pointer to a storage area to the exit (this is especially useful if the application is multi-threaded and more than one APPX Connect can be in progress at a time). Programming note: a client application that wishes to provide the user with a signon screen, and an ability to retry the signon if it fails, should interpret the message field if the APPX connect fails. Specifically the 1x10:, 1x13: and 1582: messages should be considered for retry. The PC client APPX application may also check the status of the encryption on the link via the ENCRYPTSTATUS XAPI Send/Receive Device Control String. The ENCRYPTSTATUS control string is shown in "Appendix C - ENCRYPTSTATUS Control String" (see cfxctls.h for the latest version). Encryption Exits ================ The application may specify an encryption exit, which will be invoked during negotiation and key exchange to supply data and validate the connection. The address of the encryption exit is passed in the ENCRYPTLINK control string. The exit is called and passed a pointer to an ENCR_EXIT_BLOCK control block. The ENCR_EXIT_BLOCK control block is shown in "Appendix D - ENCR_EXIT_BLOCK Control Block" (see cfxctls.h for the latest version). If an exit exists, it may provide the following functions: 1. Get Version - Returns version information about exit 2. Get ID - Returns ID to use - If the exit does not respond to this request, the ID specified at connect time will be used. If no ID was specified at connect time, a default of nulls will be used for the ID. 3. Get shared secret - If the exit does not respond to this request, the shared secret specified at connect time will be used. If no shared secret was specified at connect time, a default of nulls will be used. 4. Get shared secret for ID - Query ID shared secret based on ID - Exit must fill in ID-shared-secret based on passed ID - At the answering APPX: If the exit does not respond to this request, the ID passed at the connect, will be matched against the ID from the peer. If they match, the shared secret set at connect time will be used (default of null). Two special IDs are defined that may be passed at connect: "<ignore"> and "<nomatch>". "<ignore>" will always match, and "<nomatch>" will always fail to match. 5. Validate session - The encryption mode, preference tag, ID, IP address, and other data is passed - The exit must decide if the session may proceed - If the exit does not respond to this request, the session will be accepted. 6. Session Failure report - If the encryption module fails a session due to a negotiation error, or a shared secret error, this exit function will be called. If available, the ID, and other information, will be passed. Intended to allow "locking" an ID if too many errors occur. 7. There are "special" variants of "Get shared secret for ID" and "Validate session." With these, special names of the form "<..>" can be passed. Note that these names are reserved, and should be rejected for the non-special versions of these functions. Currently defined are: <nil> - Used if passed User ID is all nulls <unknown> - Used if no User ID is available (eg. for a non-encrypted session or a "000" session) The exit can set various return codes, in addition to the defined responses: -1. No response 0. OK, continue 1. Reject ID (message returned) 2. Reject ID Locked (message returned) 3. Reject session (message returned) 4. Error (graceful shutdown) (message returned) 5. Error (hard shutdown) (message returned) Specifying Encryption (APPX Router) =================================== Encryption is specified on the APPX Router on a per-listener basis. The "Encryption" tab of a TCP/IP listener may be used to specify the "encryption requirement" flag and the list of acceptable encryption modes. In addition, the encryption database source may be defined. An encryption source of "None" may be specified. This is equivalent to specifying an encryption database source that itself is coded as have a source of "None." Encryption Database Sources are a new major level configuration option in the APPX Router. One encryption database source may be used by one or more TCP/IP listeners. The encryption database source entry defines the source of the encryption database containing IDs, ID shared secrets and similar data. Four types of sources may be defined (these are described in more detail below): None (or "None" Specified in Listener) -------------------------------------- No database is specified. In general this will lead to all encrypted sessions failing, unless an encryption mode with no external data requirements is used. Local Database -------------- A file on the APPX Router is used as the database. Currently, one format, "EX1", is supported. The layout of and features of this file is described in "Appendix A - Router Encryption Database 'EX1' Format." Remote Database (TCP/IP) ------------------------ A remote encryption database server is queried for the encryption data. pcMAINFRAME's security database can be used for a Remote database. Database DLL ------------ A user written DLL is called for the encryption data. Encryption Databases ==================== Encryption databases are used to store data specific to an ID on the APPX Router. Encryption database can provide several types of information, based on, and in addition to, the basic ID data. The exact capabilities are dependent on the particular data source, but an overview is provided in this section. Note: encryption databases may contain entries for two special user names: "<nil>" and "<unknown>". The <nil> user ID is used if the client passes a user ID of all nulls. The <unknown> user ID is used when no ID is exchanged with the client (for example, if an old non-encryption capable client starts a session). These special users allow for other data, such as security classes and overrides, to be supplied for sessions not using user IDs. Note: From the APPX Router's perspective, the encryption database has one flat record per ID. Most databases will physically have a more complex structure, but the code supporting those databases hides those complexities from the Router (for example, "EX1" format local databases use a two level scheme of users and profiles, but present only "users" to the Router). Note: Encryption databases are queried from inside an Encryption Exit supplied by the APPX Router to the encryption module. The database should be designed to support the queries defined in the interface to the encryption exit. Databases may provide additional rules regarding encryption requirements for specific users, and for specific IP addresses. Encryption can be allowed, disallowed or required on a per-user basis, and also based on the source address of the Client (for example, encryption might be optional for a particular user while working from the company's internal LAN, but required when working from home). Note: Some care must be taken when planning the encryption requirements and allowed mode list configured for the listener in the APPX Router, as they interact with the encryption requirements specified in the encryption databases. The base session is established by the rules specified for the listener (the base session and listener encryption rules are applied before the encryption database is accessed). Thus, if encryption is required in the listener definition, encryption will always be required at the base level, and a specification of "encryption optional" in the database will not have any real effect. A database may provide some scheme for classifying encryption modes (generally based on the associated preference tags), and provide rules for when which class of encryption modes is allowed. Databases may provide additional security classes that are processed by the APPX Router, and allow authorization of Host Connections based on the user ID. Databases may also provide additional ("Format-3") override data on a per user basis. This would, for example, allow storage of the LU6.2 user ID and password (if needed for a particular host connection) on the APPX Router, instead of allowing/requiring end-users to set that configuration. Overrides specified in the encryption database are applied before overrides from the client, thus may be overridden by data from the client. The format and capabilities of the "EX1" format local encryption database are described in "Appendix A - Router Encryption Database 'EX1' Format." Operation of Encryption without a Database ------------------------------------------ If no database is specified, the APPX Router will provide default values of all nulls for the "Shared Secret", "ID" and "ID Shared Secret." In general this will lead to all encrypted sessions failing, unless an encryption mode with no external data requirements is used, or nulls are specified for the "Shared Secret", "ID" and "ID Shared Secret" on the client. Configuring a Local Database ---------------------------- A local database is a file containing the user IDs, passwords, and security information that is accessible to the APPX Router. To configure a Local Encryption Database, create an Encryption Database Source with a type of "Local Database", and specify the filename of the local database file (as described in "Appendix A - Router Encryption Database 'EX1' Format"). The APPX Router will load the specified database into memory at startup. The database can be reloaded without stopping the Router from the APPX Router Manager application. Configuring a Remote Database (TCP/IP) -------------------------------------- A remote database is a database hosted on another machine. The APPX Router establishes an APPX connection to a transaction program on that remote machine which handles the database queries from the APPX Router encryption support. Typically the remote transaction will access a file or database on the remote machine. cfSOFTWARE's pcMAINFRAME v5.50 includes a remote database transaction that uses the pcMAINFRAME "PCID" database to provide the required security data. See Section 9, "Programming a Remote Encryption Database Transaction or Database DLL" for information on writing a remote encryption database transaction. The remote database support in the APPX Router creates a pool of worker threads (one or more), which establish APPX/TCP (TCP/IP Direct) sessions to the remote database transaction. The worker threads start the sessions on demand, and shut them down if no new requests are received in a configured interval. During periods of modest demand, only a single session will be established, but under high loads additional worker threads will be established, allowing multiple database queries to occur in parallel. All database queries are processed through the active worker threads, and a single worker thread (and associated APPX session and remote transaction) may remain active for a considerable period of time (assuming there is work to do), and process the queries for a large number of incoming sessions. By taking advantage of the APPX Router, remote databases can be accessed via LU6.2 as well. This is described below. To configure a Remote Encryption Database, create an Encryption Database Source with a type of "Remote Database (TCP)", and specify the communications parameters as required. These are described below: DB: Host - The DNS name or IP address of the host running the remote database transaction. Note: if the APPX Router on the same machine will be used to translate the APPX/TCP connection to an LU6.2 connection, the loop-back address of 127.0.0.1 or "localhost" should be specified. *Required* DB: Port - The port number on which the host running the remote database transaction is listening. *Required* Conn: Fmt - The APPX/TCP Connect Format to be used (1-3). Hosts connecting via native sockets support in CICS use Format-2 connects, host connecting via the APPX Router or the APPX TPNS Service use either Format-2 or 3. *Required* Conn: TPN - The name of the transaction program to run. Applies only to Format-2 and 3 connections. *Required* Conn: Data - Additional data passed to the host on Format-2 and 3 connections. On Format-2 connections this is the "User Data" field as described for the IBM or cfSOFTWARE TCP/IP Listeners for CICS. For Format-3 connections, this can contain Host Connection Override data as described in the APPX Router documentation. Exit: Name - This data is passed to the remote database transaction in the parm1 field during the AREN_XREQ_INIT request. The usage is specific to the remote database transaction, and is intended to allow a single transaction program on a host to support more than one database. The contents of this field would be used by the transaction program to select which database it will serve. Exit: Data - This data is passed to the remote database transaction in the parm2 field during the AREN_XREQ_INIT request. The usage is specific to the remote database transaction, and is intended to pass transaction program specific parameters to the transaction program. This may be considered an extension of the "Exit: Name" field. Threads: Limit - The maximum number of worker threads (and thus the maximum number of parallel sessions to the remote database transaction) that will be created. From 1 to 10 may be specified. Note: except for installations with very high loads, the default of 1 is typically adequate. *Required* Threads: Start Delay - The time delay (in seconds) that is applied before the APPX Router activates additional worker threads (parallel sessions). New worker threads are activated if the time database requests are spending in the queue exceeds this time interval. Note: if all worker threads are idle, and a database request is queued, this delay does not apply, and a worker thread is activated immediately. From 1 to 10 seconds may be specified. The default of 2 seconds is a good starting point for most installations. If a smaller value is configured more worker threads will typically be activated, a higher value will cause fewer worker threads to be activated. Worker threads are managed based on this field and the "Threads: Cache Time" field. Note: if the "Threads: Limit" field is 1, this field has no effect. *Required* Threads: Cache Time - The time that an active worker thread (active session with a remote database transaction) will be kept active while it has no work to do. If the worker thread processes no database requests for this interval, it will be shut down. From 10 to 600 seconds may be specified. The default of 30 seconds is a good starting point for most installations. If a smaller value is configured, worker threads will be deactivated more often, and thus there will be more worker thread activations. A larger setting will have the opposite effect, but idle worker threads and sessions will remain active longer. Worker thread and remote database transaction session startup is relatively expensive both in time and resource requirements. By caching active worker threads and sessions, the APPX Router reuses sessions with the remote database transaction for multiple database queries, reducing overhead and increasing query performance. On the reverse side, active, but idle, worker threads and sessions do have some communications and system overhead (both on the Router and on the host running the transaction), and should be shut down if they are unlikely to have work to perform in the near future. Worker threads are managed based on this field and the "Threads: Start Delay" field. *Required* Comm: Timeout - The communications timeout for the session with the remote database transaction. If the remote transaction does not respond to a query within this interval, the session will be assumed to have failed, and will be restarted. From 10 to 600 seconds may be specified. The default of 30 seconds is a good starting point for most installations. Note: as a practical matter, the timeout at the client APPX should be set to at least this value, or it will timeout while the APPX Router continues to wait for a response from the remote transaction. *Required* Comm: Trace - If a non-zero value is specified, diagnostic traces of the communication with the remote database transaction will be produced. Two traces for each session will be created. First, an APPX trace named "ex2ppx###.buf" will be created, and second a TCP/IP line trace (using the specified trace buffer size in KB) named "ex2tcp###.buf" will be created. These are standard Across the Boards traces, and may be formatted with the TRACEFMT.EXE utility. Normally a trace should only be configured at the request of cfSOFWARE technical support. Accessing a Remote Database via LU6.2 ------------------------------------- By using the APPX Router, a remote database transaction can be accessed via LU6.2. For example, a remote database transaction running in CICS on a mainframe might be accessed this way. pcMAINFRAME provides such a remote database, described in the next section. To configure this, a normal Encryption Database Source with a type of "Remote Database (TCP)" is created, but with the "DB: Host" and "DB: Port" fields pointing at the APPX Router that will handle the connection. The "Conn: TPN" is then used to select a Host Connection on that Router, which is used to establish the LU6.2 connection to the host. The "Conn: Fmt" and "Conn: Data" fields further qualify the session with the APPX Router. In general, the port number may reference any Listener on an APPX Router that does not require encryption. If all other users of the APPX Router require encryption, or increased isolation is desired, it is simple to set up a Listener dedicated to the remote encryption database support on an unused port. The Host Connection should specify the name of the transaction (TPN) and the LU name in which it runs. The Host Connection must be protected from general access. APPX Router security classes can be used to accomplish this. In the Listener that will be used to access the host connection, a specific address range entry for the source address of the remote database requests (eg. the APPX Router at which the database requests originate) should be entered, and a specific security class, unused by any other Host Connections, should be assigned to that IP address (be sure to assign the security class to the IP address [on the "Addresses" tab], and not to the Listener [on the "General" tab]). If more than one APPX Router will be accessing a remote database via this Listener, then the IP addresses of all of those Routers should be configured with that class. Note: if the Host Connection will be accessed via the loopback address from the local Router, specify the address as 127.0.0.1. Next, in the Host Connection definition itself, specify only the security class assigned to the "allowed" IP addresses. This will prevent anyone other than those IP addresses from accessing the Host Connection leading to the remote database transaction. If desired, the LU6.2 login information can also be used to help secure the connection. By coding the LU6.2 user ID and password as Host Connection overrides in the "Conn: Data" field, and allowing those parameters to be overridden in the Host Connection definition (and including the appropriate security definitions on the mainframe), the user of the remote database transaction will be required to supply correct mainframe logon data. Note: as the Router is typically installed in the data center, this is not usually required. Accessing the pcMAINFRAME Remote Database ----------------------------------------- pcMAINFRAME v5.50 provides an LU6.2 Remote Database transaction suitable for use with the APPX Router. This remote database transaction uses the existing pcMAINFRAME "PCID" database (with enhancements) to provide logon and security data to the APPX Router. In general, follow the procedures described in the two prior sections for setting up access to the pcMAINFRAME remote database. The pcMAINFRAME remote database is usually installed as transaction "PCME", and does not make use of the "Exit: Name" and "Exit: Data" fields. The normal PCMM transaction is used to manage PCID records and security profiles (pointed to by the PCID records) which make up the pcMAINFRAME encryption/ security database. In addition, some global fields are defined on the Options Customization screen. Overall the pcMAINFRAME encryption database parallels the local "EX1" format database in structure. See the pcMAINFRAME documentation for additional information. The following is a sample configuration for an Encryption Database Source accessing a pcMAINFRAME remote encryption database. Assumptions: - The local APPX Router will be used to access the mainframe pcMAINFRAME components, including the encryption database, thus the loopback address will be used. - The LU name of the CICS region running pcMAINFRAME v5.50 is "DBDCCICS" - The standard pcMAINFRAME transaction names are in use ("PCME" for the remote database transaction). - TCP/IP Port number 2501 is available on the APPX Router machine, and can be used for a new Listener to support the remote encryption database. Note: a new Listener is not necessary, but is easier to explain and plan since it only needs to support one type of traffic. - Security Class "E" is not being used and is available. - LU6.2 access is already established for the APPX Router machine to the CICS region running pcMAINFRAME. - An existing Listener has been set up to access pcMAINFRAME, and this Listener will be changed to use encryption. Step 1: Create a new Encryption Database Source: Encryption Tab -------------- Name - pcMAINFRAME Remote DB Database Source - Remote Database (TCP) DB: Host - 127.0.0.1 DB: Port - 2501 Conn: Fmt - 3 Conn: TPN - PCMEHC Conn: Data - <leave blank> Exit: Name - <leave blank> Exit: Data - <leave blank> Threads: Limit - 1 Threads: Start Delay - 2 Threads: Cache Time - 30 Comm: Timeout - 30 Comm: Trace - 0 Step 2: Create a new Listener: General Tab ----------- Description - Listener for pcMAINFRAME Remote DB Port - 2501 Security Classes - <leave blank> Addresses Tab ------------- Add a single address range with the following properties: From-Address - 127.0.0.1 To-Address - 127.0.0.1 Security Classes - E (add security class "E" only) Encryption Tab -------------- Encryption Req'ment - None Allowed Modes - <leave blank> Source - None Advanced Tab ------------ Trace Size - 0 Step 3: Create a new Host Connection: General Tab ----------- Client TPN - PCMEHC Variant - <leave blank> Host TPN - PCME PLU - DBDCCICS (or the alias defined for the LU) Mode Name - #INTER LU - <leave blank> (not needed in most cases) (leave the "Overridable" items unchecked) Security Tab ------------ Add security class "E" only. Advanced Tab ------------ Conversation Security Type - Default (if a CICS signon is required, User ID - <leave blank> set the Type to Program and Password - <leave blank> enter a User ID and Password) (leave the "Overridable" items unchecked) Trace Size - 0 Note: the existing Host Connection definition for pcMAINFRAME (typically "PCMX") may be used as a model - typically only the Client TPN and Host TPN fields will need to be changed. Step 4: Change the Listener that runs pcMAINFRAME (PCMX) to use encryption: Encryption Tab -------------- Encryption Req'ment - Allowed Allowed Modes - A01 (Additional modes as desired) Source - pcMAINFRAME Remote DB Step 5: Define the required PCIDs and Security Profiles in pcMAINFRAME with the PCMM transaction. Also, enable encryption in the Options Customization screen, and define the APPX Router LU as one of the "Trusted LU Names." Configuring a Database DLL -------------------------- A Database DLL is a Win32 DLL which is written to support encryption database queries from the APPX Router. Note: cfSOFTWARE does not currently supply any Database DLLs, but provides documentation and other materials to people needing to write one. To configure a Database DLL, create an Encryption Database Source with a type of "Database DLL", and specify the filename of the DLL to access. If required the "DLL Parm 1" and "DLL Parm 2" fields can be specified. These are passed to the Database DLL in the parm1 and parm2 fields during the AREN_XREQ_INIT request. See the documentation for the Database DLL for more information. See Section 9, "Programming a Remote Encryption Database Transaction or Database DLL" for information on writing a database DLL. Encryption Module "0" - Description =================================== Encryption module "0" is not a real encryption module, rather support for encryption modes "000" and "001" is built into the APPX/TCP driver. Encryption mode "000" is "no encryption," and if negotiated, will result in no encryption being performed. Mode "000" does not support any ID or authentication mechanism. Encryption mode "001" provides ID data exchange (signon) only, but with no encryption. The ID and ID shared secret is passed, unencrypted, to the APPX Router and validated against the encryption database. Security classes and overrides are processed as normal. Encryption Module "A" - Description =================================== Encryption Module "A" uses the "Blowfish" encryption algorithm and provides authentication via an ID and ID Shared Secret. Four modes of operation are supported: A00 - 128 bit blowfish A01 - 128 bit blowfish, plus Diffie-Hellman A02 - 40 bit blowfish A03 - 40 bit blowfish, plus Diffie-Hellman Each mode optionally makes use of a shared secret. Encryption module "A" is implemented by CFXENCA3.DLL in ATB/Win32.
| << Previous Page | Next Page >> |
