Browse Prior Art Database

Secure Communication for Split Stack Clients to Host

IP.com Disclosure Number: IPCOM000123937D
Original Publication Date: 1999-Jul-01
Included in the Prior Art Database: 2005-Apr-05
Document File: 2 page(s) / 79K

Publishing Venue

IBM

Related People

Mathew, J: AUTHOR [+2]

Abstract

Netware for SAA (NWSAA) and CS/NT are split stack implementations of SNA. The API layers (APPC, RUI, NOF etc.,) reside on the client. When an application issue a verb (for example RUI_INIT) the client send the verb parameters to its server over an IP or IPX connection. The verb will be executed in the server and the result will be send back to the client on the same IP or IPX connection. For an application to run on the client it sets up a transport connection to the server (IP or IPX), and the server sets up another connection to a host (usually SNA). For secure communication from client to host NWSAA and CS/NT uses 2 different encryption (1) From client to server it uses 40 bits RC4 encryption (2) From server to host it uses 56 bits DES encryption.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Secure Communication for Split Stack Clients to Host

   Netware for SAA (NWSAA) and CS/NT are split stack
implementations of SNA.  The API layers (APPC, RUI, NOF etc.,)
reside on the client.  When an application issue a verb (for example
RUI_INIT) the client send the verb parameters to its server over an
IP or IPX connection.  The verb will be executed in the server and
the result will be send back to the client on the same IP or IPX
connection.  For an application to run on the client it sets up a
transport connection to the server (IP or IPX), and the server sets
up another connection to a host (usually SNA).  For secure
communication from client to host NWSAA and CS/NT uses 2 different
encryption (1) From client to server it uses 40 bits RC4 encryption
(2) From server to host it uses 56 bits DES encryption.

   Problems with this approach:
  (1) Bad performance at the server.  The client encrypts
      the data and send to the server.  The server decrypts
      the data using RC4 algorithm.  Then the server encrypts
      it using 56 bits DES.  We propose to avoid both the
      decryption and encryption at the server.
  (2) Encryption and decryption are CPU intense operations.
      Only a limited number of sessions can be supported by
      the server with the current approach.
  (3) CS/NT does not have the software version of SLE.  Customers
      need to buy expensive hardware cards for end to end secure
      sessions.
  (4) End to end performance is not optimum since the data is
      encrypted and decrypted twice.

   Solution for LUA Clients:

   The current client configuration has the following three
options, ENC_ON, ENC_OPT, ENC_OFF.  Add a new one ENC_SLE (or
ENC_ENDtoEND).  The client sends Request_encryption(ENC_SLE) to the
server The server sends the ACK The client generates a
Private/Public key pair and sends the public key to the server The
server encrypts the "Master Key (the user defined key)" using the
public ke...