Secure Internet Applications on the AS/400 system

Secure Internet Applications on the AS/400 sstem Mark McKelve Abstract Toda s greater emphasis on business relationships and an increasingl mobile work force are driving the demand for secure access to corporate resources via the Internet. As valuable corporate data flows over untrusted networks, the integrit and privac of that data must be preserved. The AS/400 sstem s implementation of the Secure Sockets Laer (SSL) protocol and the collection of applications that use it provide an excellent solution for companies that want to access and share sensitive data over the Internet. SSL-enabled applications ensure that the communicating parties can positivel identif and authenticate each other and that all data exchanged is encrpted, protecting it from the pring ees of outsiders and from possible manipulation or forger. OS/400 Version 4 Release 4 provides a critical mass of SSL-read applications that can be immediatel put to use. These include the Telnet server, HTTP server, Database server (DRDA/DDM), Director Services, Client Access, Management Central, and Lotus Domino. In addition, an SSL Application Programming Interface (API) and a set of Java- SSL classes are available so that application developers and business partners can develop secure applications as well. The highl-optimized SSL support is included as part of OS/400, which makes it equall available to all applications. Unique crptographic controls make it possible for a single application to use different-length crptographic kes in different countries to compl with governmental regulations. Digital certificates are emploed to identif remote users and sstems, paving the wa for single sign-on and the elimination of separate passwords for each sstem. The Digital Certificate Manager provides a single point of control for all digital certificates on the sstem, which makes it eas to get the SSL-enabled applications operational. Introduction As everone in the computer industr knows, the Internet is having a profound impact on the wa in which we do business. More and more applications are being made available to customers and partners over the Internet and an increasingl mobile work force is demanding access to corporate resources via the Internet. One of the main limiting factors to using the Internet in these new was is securit. The initial battles to protect the corporate intranet were fought with packet filtering routers and firewalls, but as sensitive data leaves the confines of the protected network, firewalls are not enough. When data flows between a remote user and a corporate server, we

need to ensure that the integrit and privac of that data is preserved. The AS/400 sstem s Secure Sockets Laer (SSL) and the collection of applications that use it provide an excellent solution for companies that want to access sensitive data b using the Internet. The Secure Sockets Laer (SSL) protocol is a securit protocol that was developed b Netscape Communications Corporation in the earl 1990s. This protocol uses encrption and authentication techniques to ensure communications between a client and a server application remain private, and it enables the client and server to definitivel identif and authenticate each other. An attempts to impersonate one of the parties or modif the data while it is in transit are detectable, and all sensitive data is securel encrpted such that unauthorized third-parties cannot intercept and interpret the data transmission. Figure 1 shows how customers, partners and mobile workers can use the Secure Sockets Laer to communicate securel with public Web servers and sstems in the corporate intranet. Private corporate intranet Mobile workers Secure session Internet Customers and partners Public server Secure session Figure 1. SSL provides secure sessions over the Internet for customers, partners, and mobile workers. The AS/400 sstem supports the SSL protocol and provides a set of SSL-read applications to enable e-business and mobile computing. These features are useful an time the network being utilized cannot be trusted to securel exchange the information. Tpicall this will be the Internet, but it can be applied to corporate intranets and private network connections with customers and partners. Applications on AS/400 that are SSL-read include: Telnet server HTTP server Database server (DRDA/DDM) Director Services (Lightweight Director Access Protocol) Client Access Management Central Lotus Domino-

Tpicall, an SSL application is a sockets program written to the TCP transport laer. The SSL-enabled application will open to a unique port compared to its socket application counterpart. For example, the SSL-enabled Telnet server application opens to port 992 while the regular Telnet server will open to port 23. The SSL protocol consists of two separate protocols, the record protocol and the handshake protocol. The handshake protocol is encapsulated within the record protocol. The SSL handshake is used to establish an SSL session on the TCP/IP connection between a client and a server application. The SSL handshake usuall occurs immediatel after the TCP connection is established. During the handshake, the client and server agree on the encrption algorithms and the encrption kes that the will use for that session. In all SSL handshakes, the client will authenticate and verif the identit of the server. The server can optionall authenticate and verif the identit of the client. After the SSL handshake has successfull completed, information exchanged between the client and the server is encrpted using the negotiated kes. Figure 2 shows the SSL handshake followed b encrpted data transmission. An important advantage of SSL is its abilit to negotiate unique encrption kes for each SSL session between a client and server even if the have not previousl communicated with each other. server certificate (1) Exchange certificates and negotiate kes (handshake). client certificate Server appl (2) Send and receive encrpted data. Client appl Figure 2. Secure Sockets Laer handshake and data exchange. During the SSL handshake, the client and server exchange digital certificates. Digital certificates provide identifing information that enable the client and the server to identif each other. Digital certificates identif users and sstems in a computer network similar to the wa in which a passport or a driver s license identifies a person. Digital certificates are issued b trusted third-parties called certificate authorities, which are analogous to state licensing bureaus for driver s licenses. A SSL client must trust the certificate authorit which issued the server s certificate in order for the SSL handshake to complete successfull. The core of the SSL support on the AS/400 is the SSL protocol engine. It implements SSL protocol versions 2.0 and SSL protocol version 3.0 according to the published Netscape SSL specifications. The SSL protocol has been available on AS/400 since V4R1. It full supports server and client authentication.

The SSL protocol engine provides a set of published application programming interfaces (APIs) that are used b the IBM TCP/IP applications and are available for customers to SSL enable their socket applications. SSL support is also provided for programs written in Java b a set of Java SSL classes. Figure 3 shows the relationships between the various sstem components that implement the Secure Sockets Laer. LDAP DDM/DRDA HTTP Management Central Telnet Client Access User Application Digital Certificate Manager SSL APIs and javax.net.ssl classes SSL Protocol Engine Certificate Management Services TCP/IP Crptographic Service Provider Figure 3. AS/400 Secure Sockets Laer architecture. The SSL protocol engine uses the services of a crptographic service provider to perform all crptographic operations. The SSL protocol engine uses certificate management services to obtain a cop of the digital certificate that identifies the local sstem so it can be shared with the remote peer. It also uses the certificate management services to validate the remote user s or sstem s digital certificate. Certificate management services is responsible for storing and manipulating all digital certificates and their associated public and private kes. The Digital Certificate Manager provides a Web browser-based user interface to create new certificates, manage existing certificates, associate certificates with applications, and man other certificate-related functions. AS/400 applications that support Secure Sockets Laer The SSL support is useful onl when there are applications that use it. The number of applications supporting SSL dramaticall increased in AS/400 Version 4 Release 4. The SSL-read applications are: Telnet server The OS/400 secure Telnet server provides the capabilit for a user to establish a secure 5250 emulation session to an AS/400 sstem. The complete Telnet session is encrpted including the

initial session parameter negotiation, sign-on, and all subsequent data screens. The encrpted Telnet session provides secure access to traditional business applications and sstems administration functions over untrusted networks. The secure Telnet server can handle encrpted Telnet sessions concurrentl with regular Telnet sessions which enables access from the Internet and intranet simultaneousl with appropriate securit. The secure Telnet server is activated b assigning a digital certificate to the Telnet server using the Digital Certificate Manager. Corporate Intranet Telnet Server port 23 port 992 Encrpted session Internet Client Access Express for Windows Figure 4. Telnet server support for SSL. The Telnet client must also support SSL in order for a secure session to be established. Clients currentl available that support SSL include IBM enework Host On-Demand and Client Access Express for Windows. Database server OS/400 databases and files can be accessed securel using the SSL support of the DRDA/DDM TCP/IP server. The database or file request sent to the server and the contents returned to the client are both encrpted. The server interoperates with clients such as the AS/400 Toolbox for Java, the Client Access OLE DB Provider, and with an DRDA application requester products or DDM file I/O clients provided b independent software vendors that support SSL. SSL support is activated b assigning a digital certificate to the DRDA/DDM server using the Digital Certificate Manager. HTTP Server The IBM HTTP Server for AS/400 implements the HTTPS protocol, which is based upon SSL. The HTTP server has been SSL-enabled since V4R1. Beginning with V4R3, the HTTP server supports client authentication. When HTTPS is used, form data entered b the user and the Web pages returned b the server are encrpted to ensure privac. HTTPS is commonl used for Web

applications that contain personal information such as credit card numbers, financial information, or health records. SSL support is activated via the HTTP server configuration interface. A digital certificate must also be assigned to the HTTP server instance using the Digital Certificate Manager. The HTTP Server for AS/400 also has the capabilit of authenticating the user at the Web browser b using digital certificates. The Web browser automaticall supplies the user s digital certificate when a secure Web page is accessed. The use of client certificates provides improved user identification and reduces the need for passwords. The Web Server article has more information on the Web server. Director Services OS/400 Director Services (option 32) implements the Lightweight Director Access Protocol (LDAP), which is a director protocol that runs over TCP/IP. Common uses of LDAP directories include online telephone and e-mail directories. Director Services follows a client/server model where one or more LDAP servers contain the director data. An LDAP client connects to an LDAP Server, makes a request, and receives a repl or a referral to another LDAP server. If confidential director data is to be accessed over an untrusted network, a secure LDAP session can be used. The LDAP client establishes an SSL session with the LDAP server. Both the LDAP request and the repl are encrpted to ensure privac. OS/400 Director Services has supported SSL since V4R3. SSL support is activated b assigning a digital certificate to OS/400 Director Services b using the Digital Certificate Manager. The LDAP and OS/400 Director Services article has more information on Director Services. Client Access Client Access Express for Windows supports TCP/IP communications using SSL to the host servers on AS/400. The following servers used b Client Access Express are enabled for SSL communications: Sign-on server File server Database (ODBC) server Network print server Data queue server Central server Remote command/distributed program call server Once digital certificates are assigned to these host servers b using the Digital Certificate Manager and the host servers are started, the servers will automaticall be prepared to handle incoming

SSL connections, as well as non-ssl connections. Each server listens on a port that is used for non-ssl connections and a second port that is used exclusivel for SSL connections. It is not necessar to specificall start "SSL servers" or "non-ssl servers" because the host servers are prepared for either tpe of connection. The end user, b changing properties of the servers from the client, determines if SSL is actuall used. All data passed between the client and the secure host servers is encrpted using SSL. The Client Access Express for Windows article has more information on this new PC client product. Management Central Management Central provides the infrastructure to schedule and perform sstem management transactions on a group of sstems. Transactions include: asset inventor collection, software fix management, object packaging and distribution, remote command and real-time performance monitoring. Management Central transactions originate on a PC client, are processed b AS/400 central site sstem, and retransmitted to multiple AS/400 endpoint sstems. Each AS/400 sstem has a single Management Central server that ma accept connections and service transactions from multiple graphical clients and from multiple AS/400 sstems. The Management Central server on each AS/400 sstem interacts in a peer-to-peer fashion with other AS/400 sstems and is not restricted to a single role of central site or endpoint. Graphical Clients Win 32 Central Sites/End Points AS/400 End Points AS/400 Figure 5. Management Central uses SSL to identif sstems within the peer group. To ensure that transactions are accepted onl from trusted sstems within the peer group, Management Central uses digital certificates for sstem identification. During an introductor period, sstems within the peer group establish SSL sessions with each other and exchange digital certificates. Once the introductor period is over, sstems will accept transactions onl from sstems that had been previousl introduced. All transactions are sent using the SSL protocol, which ensures that the originated from a trusted sstem and that the were not modified while in-transit. The Sstems Management article has more information on Management Central.

Lotus Domino Lotus Domino is a separate licensed program that comes with its own complete SSL implementation. This SSL support enables Web pages served b the Domino server to be encrpted in the same manner as the IBM HTTP Server. In addition, data exchange between a Notes client and a Notes server can be optionall encrpted. Lotus Domino provides its own complete set of certificate management functions. The Domino for AS/400 article has more information on Lotus Domino. Partner and customer applications Because the SSL support is provided b both an Application Programming Interface (API) and a set of Java classes, application developers and business partners can write secure applications as well. In particular, client-server socket applications that are used over the Internet ma benefit from using the SSL protocol. The APIs and Java SSL classes are provided with OS/400 at no additional charge. AS/400 SSL architecture The SSL support on AS/400 is provided b an SSL infrastructure that includes the SSL APIs, SSL protocol engine, a software crptographic service provider, and certificate management services. The Digital Certificate Manager option of OS/400 provides the necessar digital certificates to enable the SSL protocol. There are multiple versions of the SSL protocol defined. The OS/400 implementation supports SSL Version 3.0, SSL Version 2.0, and SSL Version 3.0 with 2.0 compatibilit. However, the OS/400 implementation does not support a new Request for Comment (RFC), RFC2246, that was recentl made a standard b the Internet Engineering Task Force (IETF). This RFC defines The Transport Laer Securit (TLS) protocol. The TLS protocol is heavil based on the SSL version 3.0 protocol, but the are not identical or upward compatible. However, the can interoperate if the TLS implementation negotiates to an SSL V3.0 level. Secure Sockets Laer APIs OS/400 provides a set of SSL APIs that extend the OS/400 sockets APIs to provide secure communications between applications on a network. An application that uses SSL for secure communications is basicall a client/server application that is written using sockets. The OS/400 SSL APIs support both server and client authentication. The OS/400 SSL APIs are: SSL_Init() - Initialize the current job for SSL using a specific ke database. SSL_Init_Application() - Initialize the current job for SSL using the certificate registration facilit. SSL_Create() - Enable SSL support for the specified socket descriptor.

SSL_Handshake() - Initiate the SSL handshake protocol. Causes digital certificates to be exchanged, certificates to be authenticated, and smmetric encrption kes to be negotiated. Upon successful conclusion, an SSL session has been established. SSL_Read() - Receive data from an SSL-enabled socket descriptor. The encrpted data received from the remote sstem is decrpted before it is returned to the application. SSL_Write() - Write data to an SSL-enabled socket descriptor. The application data is encrpted before it is sent to the remote sstem. SSL_Destro() - End SSL support for the specified socket descriptor. Applications ma intermix these SSL APIs with the standard sockets APIs to selectivel encrpt information. These APIs are available with OS/400 but are onl enabled if option 34 is installed and one of the three available Crptographic Access Provider products is installed. Because these APIs are extensions to the sockets programming interface, existing socket applications can be easil updated to use SSL to transmit data in encrpted form. Java SSL classes OS/400 supports SSL for Java programs b providing the javax.net, javax.net.ssl, and javax.securit.cert packages defined b Sun Microsstems. These Java SSL classes use the same SSL protocol engine used b the SSL APIs to maximize performance. The SSLSockets and SSLServerSockets classes defined in these packages can be used like an other sockets unless SSL-specific features are required, which makes it eas to enable SSL for an existing Java program. Secure Sockets Laer protocol engine The SSL protocol engine is responsible for performing the communication with the remote sstem according to the SSL protocol specification. The protocol engine is part of OS/400 s communication infrastructure for maximum performance and securit. The first action that the protocol engine performs when communicating with a remote sstem is an SSL handshake. The handshake establishes a common cipher suite, which identifies the crptographic algorithms to be used and the length of the kes to be generated. Next, the identit of the remote sstem or user is authenticated via digital certificates and the crptographic kes, which are subsequentl used for encrpting data, are established. If the local machine has previousl communicated with the remote sstem, the protocol engine ma be able to use cached information about that remote sstem and will attempt to do an abbreviated SSL handshake. An abbreviated SSL handshake improves performance because fewer data transmissions are required. During the handshake, digital certificates are exchanged. The digital certificate received from the remote sstem is verified to ensure that it is valid and that it has not been subject to tampering. This is done b verifing that the digital signature on the received certificate is consistent with the contents of the certificate. A check is also made to ensure that the certificate authorit that issued the certificate is in the list of trusted certificate authorities.

In order to determine that the remote sstem is the rightful holder of the certificate, an additional test is performed using public/private ke crptograph. Some random data is sent to the remote sstem. The remote sstem encrpts the random data with its private ke and returns the result. The local sstem decrpts the returned data with the public ke contained in the received certificate and compares it to the random data originall sent. If the values are equal, it means that the remote sstem must have the matching private ke for the certificate and is therefore the legitimate holder of the certificate. Once the remote sstem or user is identified and authenticated, a separate temporar ke is created. This temporar ke is used to generate the actual smmetric kes, which are used for encrpting and decrpting data sent between the two sstems. The temporar ke is based upon secret, randoml-generated data and is securel exchanged with the remote sstem. The actual smmetric kes used for the SSL session are never exchanged between the sstems. Certificate management services keeps certificates private Certificate management services is responsible for storing and manipulating all digital certificates and their associated kes. The certificates and an private kes are kept in a certificate store, which is an encrpted file. The certificate store contains two tpes of certificates: 1. Sstem certificates, which are used to identif the local AS/400 sstem when communicating with a remote user or sstem. For example, the certificate store on the www.xz.com sstem would contain a certificate identifing it as the www.xz.com server, as shown in Figure 6. 2. Certificate authorit certificates, which are used during the verification of certificates received from remote users or sstems. Certificate authorit certificates identif the trusted third-part who signed the remote user s or sstem s certificate. VeriSign is one of the most well-known certificate authorities. Certificate Management Services Certificate Store Server certificate for www.xz.com VeriSign CA GTE Cbertrust CA USPS CA - trusted - trusted - not trusted Figure 6. Certificates are kept in the sstem certificate store. Certificate management services decodes certificates received from remote sstems during the SSL handshake. It verifies that there has been no tampering with the certificate b checking its digital signature and verifing that the certificate was signed b a certificate authorit that is considered trusted. When these checks are completed, the application can be assured that the certificate identifies the remote user or sstem. The application can use the name, organization, and address information in the certificate in an wa that it sees fit.

Crptographic service providers provide efficient encrption OS/400 uses the BSAFE- tool kit developed b RSA Data Securit Inc., an industr leader in crptographic technolog, as the software crptographic service provider. The BSAFE encrption algorithms have been optimized for the AS/400 64-bit RISC architecture for greater performance. Since BSAFE is included with OS/400, ou do not need to purchase a separate encrption package to write SSL applications on the AS/400 sstem. Although BSAFE is included with OS/400, it is not directl accessible and is subject to the crptographic controls described in the next section. The AS/400 sstem also supports a hardware crptographic service provider with the 4758 card, however, this crptographic service provider currentl cannot be used b SSL. Crptographic controls ensure compliance with government regulations Due to regulations imposed b the United States and other governments, the crptographic algorithms available and associated ke lengths permissible var b countr. To avoid shipping separate versions of each product that uses crptograph, AS/400 emplos a unique mechanism for controlling access to crptographic functions. A list of permitted algorithms and associated maximum ke lengths is maintained for each crptographic service provider. This SSL protocol engine queries the crptographic service provider installed on the AS/400, to ensure onl permitted algorithms are used and that maximum ke lengths are not exceeded. IBM provides a collection of no-charge Crptographic Access Provider products that specif the list of permitted algorithms and ke lengths for the crptographic service providers. The products are: 5769-AC1 - Supports smmetric ke algorithms with ke lengths no greater than 40 bits. Available onl in France. 5769-AC2 - Supports DES and other smmetric ke algorithms such as RC2 and RC4 with ke lengths up to 56 bits. Available in most countries in which IBM does business with the exception of France, the United States and Canada. (Note: Recent changes in the encrption polic in France ma allow this product to be available there in the future.) 5769-AC3 - Supports DES and other smmetric ke algorithms such as RC2 and RC4 with ke lengths up to 128 bits. Available in the United States and Canada without restriction. With specific export approval b the U.S. government, it is also available to certain tpes of companies, such as financial institutions, in other countries. The AS/400 crptographic controls provide a number of unique advantages: Onl one version of each SSL-enabled application needs to be shipped, which reduces software distribution and management complexit for multinational corporations. As government regulations change, either new crptographic access provider products will be created or the existing products will be modified. When these new or changed products are

installed, the crptographic capabilities of all applications on the AS/400 sstem are immediatel effected. AS/400 applications written b customers and business partners that use SSL will automaticall use these controls, which makes compliance with government regulations easier. The SSL implementation for AS/400 is enabled for Global Server ID support. The Global Server ID support allows, with the proper government approvals, financial and other qualified companies residing outside the United States to use 128 bit smmetric kes for crptographic operations. The compan must obtain the proper United States Export Office approvals, install the 5769-AC3 product, and obtain a special certificate from VeriSign in order to use this support. Browsers from outside the United States will negotiate a 128 bit ke instead of the tpical 40 or 56 bit ke when connecting to a server using this special certificate. Digital Certificate Manager manages all certificates on the sstem The Digital Certificate Manager, which is included in OS/400 option 34, provides capabilities for an administrator to create or obtain the necessar digital certificates in order to use the Secure Sockets Laer (SSL) for secure browser access to Web sites and other secure Internet applications. The Digital Certificate Manager user interface is accessed from the AS/400 Tasks page using a Web browser. The Digital Certificate Manager is the central point for management of all sstem certificates for all secure applications. A given digital certificate can be easil shared between man applications (for example, HTTP, LDAP, and Telnet) or unique certificates can be used for each application at the administrator s discretion. The Digital Certificate Manager provides management functions for three tpes of certificates: Certificate authorit Sstem User Certificate authorit certificates The Digital Certificate Manager provides the abilit to issue certificates, on a limited basis, to users and sstems. Test certificates can be created to test secure applications that are to be used on the Internet prior to purchasing a certificate from an Internet certificate authorit such as VeriSign. Certificates can also be issued to sstems and users in corporate intranets. The Digital Certificate Manager is not intended to manage large certificate deploments throughout a corporate intranet or the Internet. The Digital Certificate Manager becomes a certificate authorit b creating a self-signed digital certificate for an organization. This certificate is used to issue certificates to sstems and users in the network. Certificate authorit polic that is set b the administrator specifies whether user certificates can be issued and the validit period for certificates.

Sstem certificates Applications on the AS/400 sstem require certificates in order to use SSL. These sstem certificates identif the local AS/400 sstem when communicating with remote sstems. The Digital Certificate Manager provides the capabilities to create these sstem certificates either using the local certificate authorit function or b requesting a certificate from an Internet certificate authorit. Each secure application on the AS/400 sstem is registered with the Digital Certificate Manager. When a new sstem certificate is created or received, the administrator can assign the certificate to one or more secure applications. Once a certificate is assigned to an application, the application is enabled to use SSL. Since the Digital Certificate Manager is aware of all secure applications, it eas to use the same certificate for man applications, simplifing sstem administration. The Digital Certificate Manager also keeps a list of certificate authorit certificates that are to be considered trusted. A certificate received from a remote sstem during an SSL handshake must be signed b a trusted certificate authorit in order for SSL to be enabled. Highl secure applications ma trust onl a single intranet certificate authorit while other applications ma trust certificates signed b an of a number of Internet certificate authorities. User certificates The Digital Certificate Manager provides the functions necessar for users to obtain the certificates the need in order to use SSL. Certificate authorit certificates can be downloaded and installed into Web browsers or other client software. This enables the Web browser to validate an server certificates that it receives during an SSL handshake. If the AS/400 sstem is acting as a certificate authorit, Web browser users ma request that a certificate be created for them and automaticall installed into their Web browser. Web browser users that alread have a certificate ma register it with the AS/400 sstem so that it can be used in the future to identif them. Man of the user certificate management functions involve associating a digital certificate with an AS/400 user profile. Once associated with a profile, a certificate ma be used as a form of identification instead of requiring a password. Certificates issued to users are automaticall associated with their AS/400 user profile, and existing certificates from other certificate authorities ma be registered with a user profile.

Digital identification of users is possible with OS/400 The OS/400 securit component contains a set of functions that enable AS/400 users to be identified using digital certificates. A set of digital ID APIs enable digital certificates to be stored inside OS/400 user profile objects, as shown in Figure 7. When a certificate is stored inside a user profile, it means that a user presenting a cop of that certificate and possessing the associated private ke is entitled to all of the privileges of that user profile. OS/400 User Profile Objects Sam Sall VeriSign Certificate 19783 GTE Certificate 07854... VeriSign Certificate 29776 XYZ Corp. Certificate 59 Figure 7. User profile objects contain user certificates. The functions provided b the OS/400 digital ID APIs are: Add a certificate to a user profile. Delete a certificate from a user profile. List all certificates for a user profile. Find the user associated with a given certificate. The digital ID functions are used b the IBM HTTP Server to allow certificates to be used as an alternative to passwords as proof of identit for Web browser users. Since a single digital certificate can be used to identif one s self to multiple sstems, the have the potential for becoming a solution for single sign-on. Validation list objects ma be used for situations where authentication using certificates is desirable but ou do not wish to create OS/400 user profiles. A validation list object contains a list of certificates that are authorized to a particular function such as a Web application. The primar use of validation lists is to provide Internet users controlled access to applications without creating user profiles. Virtual Private Networks are an alternative to SSL SSL is not the onl mechanism available for creating secure communications between sstems. The AS/400 sstem supports Virtual Private Networks (VPN) through its implementation of the IETF IPSec (RFC 2401) and related standards. VPN differs from SSL in that it creates a secure channel between two TCP/IP hosts over which multiple TCP/IP connections can be established, as shown in Figure 8. Authentication is at the TCP/IP host interface level for VPN versus a user

application level for SSL. All TCP and UDP applications can use the secure channel created b the VPN without requiring changes to the applications. Because SSL requires a handshake for ever session established, it is less efficient than VPN, which requires onl a single handshake between a pair of hosts. But, SSL can selectivel encrpt portions of a TCP/IP session while the all data over a TCP interface is alwas encrpted with VPN. SSL has generall been easier to set up because configuration is supported directl b client software such as Web browsers. Because of the unique operational advantages of each, it is likel that most organizations will deplo both SSL and VPNs for the foreseeable future. All data sent over the VPN is encrpted. Internet Two sessions over a virtual private network between two AS/400 sstems. Conclusion Figure 8. Data transmission over a Virtual Private Network. The AS/400 sstem provides a comprehensive SSL solution for those companies worried about who might be looking at their data as it flows through an untrusted network such as the Internet. The entire SSL infrastructure and associated certificate management functions are provided b OS/400 making it available for a variet of IBM and partner-developed applications. Since these functions are integrated into the operating sstem, the provide a highl reliable and secure environment. IBM provides a number of applications based on SSL that mean secure access to the our AS/400 sstem is a realit toda.

References OS/400 Sockets Programming, SC41-5422. September, 1998. OS/400 Securit APIs, SC41-5872, June 1998. AS/400 Sstem API Reference, SC41-5801, June 1998. AS/400 Information Center: http://as400bks.rochester.ibm.com/ IBM white papers on Internet securit: http://www.as400.ibm.com/tstudio/secure1/secdex.htm SSL Java Standard Extension to JDK 1.1: http://java.sun.com/securit/ssl/api_users_guide.html IETF Transport Laer Securit (TLS) working group: http://www.ietf.org/html.charters/tls-charter.html Notices IBM, AS/400, and OS/400 are trademarks of the IBM Corporation in the United States or other countries or both. Java is a trademark of Sun Microsstems, Inc. BSAFE is a trademark of RSA Data Securit, Inc. The VeriSign Name and Mark are exclusivel licensed to VeriSign, Inc. Digital ID and Digital ID Center are service marks of VeriSign, Inc. Other compan, product, and service names ma be trademarks or service marks of others.