Introduction

WebSphere Everyplace Connection Manager Version 5.0.1 is a distributed, scalable, multipurpose UNIX communications platform that protects sensitive data, optimizes network traffic, provides wireless messaging, and enables seamless roaming across a wide range of international wireless network technologies. The WebSphere Everyplace Connection Manager, hereafter called Connection Manager, supports secure data access from a wide choice of mobile devices, using standards-based protocols. Connection Manager comprises:

• Connection Manager for AIX, Solaris, and Linux
• Gatekeeper for AIX, Solaris, Linux, and Windows
• Mobility Client for Windows, Windows CE, Palm OS, Linux, and Zaurus

Connection Manager provides a comprehensive enterprise access solution, delivering enterprise-level security from mobile laptops, WAP phones, PDAs, Internet kiosks, and SMS devices. This communications platform, shown below, seamlessly extends the corporate network for e-business on demand solutions into the mobile workforce. Enterprise data and applications can be distributed to workers wherever and whenever they need it.

Mobile VPN

The Mobility Client accesses the enterprise IP network through the mobile access services of Connection Manager. The mobile access services, in conjunction with the Mobility Client, establish connectivity across a diverse set of wireless and wireline networks, providing a secure virtual private network tunnel that is sensitive to the limited bandwidth capabilities and varying latencies found in wireless environments.

With the cross-network roaming features of the product, client devices transition seamlessly from one network to the next without interruption to the end-user applications, smoothing out the network loss, poor coverage, and latency concerns commonly found in wireless wide area networks. The Connection Manager solution enables quick and easy deployment of an application to a wireless environment, while making data communications more efficient and cost-effective.

Secure Web (HTTPS) Access

More and more, corporate applications access information and applications through the HTTP protocol. Connection Manager allows users on an external network to securely access internal corporate web resources without the presence of a VPN client. HTTP access can be provided to a single server, such as a wireless portal, or can be expanded to include multiple servers throughout the corporate intranet.

Messaging Services

The messaging services feature of Connection Manager supports push technology to transmit information to client devices without end-user action, and supports processing of messages originating from a client device. The Connection Manager messaging API provides a unified interface to many different types of networks and client devices, hiding the complex details of message encoding and the specific protocols used by each network, and maintaining connections to the network providers, and other device and network-specific activity.

WAP Proxy

Connection Manager's WAP proxy feature provides access from a WAP Version 1.2.1 standard client device to a range of Web-based services and content in the information network of a service provider or an enterprise. The WAP proxy can also include more value-add functions, such as security, integration with an enterprise authentication server, WAP content caching for improved performance, and cookie storage on behalf of WAP clients.

Back to top

Connection Manager Security

Connection Manager features multiple options for authentication and encryption to assure identity of the mobile user, prevent unauthorized access, and provide data privacy. For environments requiring end-to-end security at the application layer, Connection Manager can transparently encapsulate Internet Protocol Security (IPSec) or SSL communications, while adding the benefits of network optimization and seamless cross-network roaming. However, IBM designed Connection Manager specifically to address the security needs of a mobile environment. When compared to traditional IPSec VPNs or special purpose mobile middleware, the IBM approach has a number of compelling advantages:

The following sections discuss security for these options in detail.

Mobile VPN Security

Connection Manager mobile access services work in conjunction with the Mobility Client to establish a secure virtual private network tunnel, sensitive to the limited bandwidth capabilities and varying latencies found in wireless environments. Authorization, Authentication, and Accounting (AAA) security features are built into the communications flow, assuring the identity of and rights granted to the mobile user before providing enterprise network access through Connection Manager. The Mobility Client can access the enterprise network only by authenticating with the mobile access services of Connection Manager.

Connection Manager can enforce authorization policies by filtering traffic at the IP network layer, based on user access groups. Authentication of the mobile user can be validated by Connection Manager, or the credentials can be communicated to external authentication and authorization servers. Connection Manager maintains detailed accounting records of all data transactions performed by mobile users. To provide for data privacy and protection from eavesdropping, data is encrypted using symmetric key encryption. The encryption algorithms are implemented using the product's FIPS 140-2 certified cryptographic library.

Authentication

In a networked environment, it is essential for parties to be authenticated before sensitive data is exchanged. Connection Manager provides out-of-the-box enterprise grade user management profiles for customers who want to manage isolated pools of authorized users, as well as the option for seamless integration with existing authentication schemes already deployed in the enterprise. Connection Manager provides four different authentication profiles, each of which may be independently assigned to connectivity profiles, allowing for different authentication needs for simultaneous access by different user populations.

System Authentication Profile

For system authentication, Connection Manager validates the user's credentials by reading information from a persistent user storage database in an LDAP-compliant directory service and verifying the information internally. IBM Tivoli Directory Server, Netscape directory service server, Sun ONE Directory Server, and OpenLDAP are supported. Connection Manager is responsible for managing user information. Session state and access violation information, such as failed login attempts, password policy enforcement, and account expiration, are stored in the Connection Manager relational database.

When users are first configured by the administrator, they are assigned a password that's securely stored in the directory service and communicated to the user using the ID (by phone, secure e-mail, or postal mail) so both parties know the password. To meet corporate guidelines, rules can be established on Connection Manager to enforce the unpredictability of the password. Connection Manager has the capability of enforcing the following rules:

• Minimum number of characters
• Minimum number of alphabetic characters
• Minimum number of non-alphabetic characters
• Minimum number of characters not contained in the previous password
• Number of previous passwords that cannot be reused
• Maximum number of times a character can be repeated
• Whether or not the password can contain the user ID within its string
• Whether or not the password can begin or end with a numeric character.

Passwords can be set to expire at configured intervals, requiring the user to change the password, and accounts may be locked once a threshold of invalid login attempts is reached.

RADIUS Authentication Profile

For RADIUS authentication, Connection Manager transmits the user's credentials to a RADIUS-compliant authentication server for validation and waits for the verification response. Connection Manager maintains session state and access violation information, such as failed login attempts and account expiration in its relational database. Extensions to the RADIUS protocol, such as Extensible Authentication Protocol (EAP) over RADIUS, are not currently supported.

The RSA SecurID solution is one example of a RADIUS authentication solution. The RSA ACE/Server is configured as a RADIUS server, and the users enter their user name, PIN and Keyfob Token for validation.

LDAP-bind Authentication Profile

For LDAP authentication, Connection Manager transmits the user's credentials to a LDAP-compliant directory server by means of the bind API for validation, and waits for the verification response. Connection Manager maintains session state and access violation information, such as failed login attempts and account expiration, in its relational database.

All LDAP-compliant directory servers, including Microsoft Active Directory, are supported in this configuration.

Certificate Authentication Profile

For Certificate authentication, Connection Manager challenges a Mobility Client user to verify possession of an X.509 certificate and its associated private key. During login, a challenge message is sent to the client, who must in turn digitally sign the message and return the signature, original message, and associated X.509 certificate for verification.

Connection Manager always verifies the digital signature and optionally verifies:

• Expiration: All certificates have a issue date and expiration date. Connection Manager verifies that the current system time is within the valid time window.
• Subject Name: All certificates have aN X.500 formatted subject name. Connection Manager verifies the name against a User ID or Full Name and primary organization unit in an LDAP-compliant directory server.
• Issuer: All certificates are issued by another certificate. Connection Manager verifies its trust relationship with the issuer certificate.

Depending on the key exchange algorithm selected, Connection Manager supports up to two forms of authentication. Since Two-Party Key Distribution protocol combines bi-directional authentication with key distribution, System Authentication is implicitly chosen. You may select one of the other profiles as a second level of authentication. If you select Diffie-Hellman key agreement, you may select any of the four authentication profiles as the primary form of authentication.

Two-Factor Authentication

In addition to traditional two-factor systems such as SecurID or Certificate posession, Connection Manager can tie the user identity to the device of access. Two-factor authentication may be employed on some platforms by utilizing unique hardware serial numbers embedded in the device. In this case, users not only have to know their password, they must also log in from a specific device. These serial numbers may be automatically negotiated on first login, or may be manually entered by the administrator. In addition, administrators can restrict access based on the wireless network physical address assigned to the device network modem, such as static IP address, MSISDN, Mobitex MAN number, or DataTAC EIN number. By restricting access to specific, controlled devices and networks, Connection Manager can strengthen the authentication of the user.

Key exchange and encryption

Key exchange and encryption are used to secure data packets flowing between the Mobility Client and the Connection Manager within the confines of the secure network tunnel. The encrypted data originates from any number of applications configured to route traffic through the IP tunnel created by the Mobility Client and Connection Manager. Only data flowing though this IP tunnel is encrypted. It is possible for the Connection Manager administrator to disable encryption for specific clients, if it is not desired. The session encryption keys may be rotated periodically for improved security.

During login, Connection Manager generates, encrypts, and distributes a unique session key used for the block-cipher symmetric Data Encryption Key (DEK). The DEK is protected by utilizing the AES key wrapping techniques defined in the FIPS AES Key Wrap Specification. An AES wrapped key is considered an automated method of key transport by the FIPS 140-2 standard, and meets the FIPS 140-2 requirements for key establishment. To gain access to this encrypted session key, a Key Encryption Key (KEK) is negotiated by using the Diffie-Hellman protocol or the Two Party Key Distribution protocol. Connection Manager follows the guidelines for exchange, or agreement upon the KEK as specified for compliance with all FIPS 140-2 requirements.

Two-Party Key Distribution protocol

IBM developed the Two-Party Key Distribution protocol (2PKDP) as an open protocol in 1994. 2PKDP combines bi-directional authentication with key distribution using minimal messages. 2PKDP is a shared-secret key distribution and authentication scheme, where the shared secret is derived from a password stored in a persistent user storage database as defined by the Connection Manager system authentication profile. By using 2PKDP, both the client and the Connection Manager authenticate each other, yet never transmit the password during the authentication process. The shared secret derivation uses a SHA-1 based methodology. A seed may also be used to strengthen the key space of the secret key. As part of the 2PKDP protocol, the Connection Manager generates, encrypts, and distributes the Key Encryption Key.

2PKDP negotiation involves a challenge and response dialog between the the Mobility Client and Connection Manager. The client requests a challenge during login. If the mobile user inputs the correct password and is attempting to login from an allowed device, the client can successfully process the challenge packet and send back an indication of its knowledge of the Key Encryption Key and secret key. By validating this indication, Connection Manager authenticates the user.

Diffie-Hellman

Diffie-Hellman is a public-key method for key agreement, meaning that two parties can derive the same secret key without exchanging any part of that key. The security of Diffie-Hellman relies on the difficulty and number of computations needed to create meaningful keys. Thus, it is a computationally intensive key exchange algorithm, and could impact performance on resource-constrained devices.

As part of the login procedure, the Mobility Client and Connection Manager generate keys pairs, exchange the public portions of the pair, then derive the secret key. This secret key is the Key Encryption Key.

Diffie-Hellman does not provide any authentication. The mobile access services of Connection Manager should be configured to require user authentication using one of the authentication profile methods.

The session key exchanged during login is used to establish data encryption of the communications channel. Because of its increased strength and optimized speed, Connection Manager has chosen the Advanced Encryption Standard (AES) symmetric key encryption algorithm standard. Other algorithms are available in order to maintain backwards compatibility. The encryption algorithms supported vary based on platform, as shown in the table below:

Web Access (HTTPS) Security

Connection Manager's HTTP access services provide an SSL gateway for HTTP communications from any HTTP Version 1.1 client data stream, such as a web browser. The connection provides access to Web-based services and content in the enterprise without requiring the presence of a VPN client, like the Mobility Client. The HTTP session is secured using secure sockets layer (SSL), and can be restricted to allow connections only from specified hosts.

The HTTP access services authenticate each secure HTTP connection, checking the data stream for valid user credentials. If none exist, a form-based login screen is used to challenge for a valid user ID and password. These credentials, along with the network address, are used to authenticate the user. The Connection Manager can validate the user's credentials using either the system authentication profile, RADIUS authentication profile, or LDAP-bind authentication profile.

HTTP access services can also enable single sign-on through lightweight third party authentication (LTPA). LTPA provides a mechanism for storing user authentication information in a token generated after a user is successfully authenticated. The LTPA token is stored as an HTTP cookie and included in all requests for the configured single sign-on domain. Other LTPA-enabled servers within the same domain can authenticate user requests based on the token cookie without challenging the user for credentials.

The HTTP access services of Connection Manager use SSL when communicating with the browser. Both Version 2 and Version 3 of the SSL protocol are supported. The following algorithms are supported:

• Public key algorithms
• RSA (1024, 768, or 512 bit keys)
• Symmetric key algorithms
• DES (56 bit key)
• Triple DES (168 bit key)
• RC4 (40, 56, or 128 bit keys)
• Message authentication codes
• SHA-1
• MD5

X.509 certificates can provide authentication for the SSL communications. These certificates, along with root certificates to validate the other party's certificate, are in a key database that is installed with Connection Manager. The Connection Manager administrator can configure the source of this database using the Gatekeeper administration console. The administrator can configure the desired root certificates and client side certificates using the administration interface of the SSL toolkit, IBM Key Management.

Messaging Services Security

The messaging services feature of Connection Manager supports push technology to transmit information to client devices without previous end-user action, and supports processing messages originating from a client device. The Connection Manager Push and Messaging API provides a unified interface to many different types of networks and client devices. For example, an application using the messaging API can push a message to an e-mail client, two-way pager, or Global System for Mobile Communications Short Messaging System (GSM-SMS) phone by specifying different address types. The complex details of how the message is encoded, the specific protocols used by each network, maintaining connections to the network provider SMS centers, and other device and network-specific activity, are hidden by the API.

The messaging services of Connection Manager can be configured to use secured connections when communicating with push initiators using SSL. Result notifications and mobile-originated messages transferred between the messaging service and the message-processing applications may also be sent over a secured link when using secure HTTP (HTTPS) protocol. The standard Connection Manager Messaging Services and Push Toolkit does not provide for SSL communication between the application and the Connection Manager. Customers who have Connection Manager and want to write an SSL-enabled message processing server or push initiator application can contact IBM to get access to an SSL-enabled toolkit. The SSL interface boundary is contained within the toolkit, and is neither exposed nor controlled by applications written using the toolkit. Both Version 2 and Version 3 of the SSL protocol are supported. The following algorithms are supported:

• Public key algorithms
• RSA (1024, 768, or 512 bit keys)
• Symmetric key algorithms
• DES (56 bit key)
• Triple DES (168 bit key)
• RC4 (40, 56, or 128 bit keys)
• Message authentication codes
• SHA-1
• MD5

X.509 certificates can provide authentication for the SSL communications. These certificates, along with root certificates to validate the other party's certificate, are in a key database that is installed with Connection Manager. The Connection Manager administrator can configure the source of this database using the Gatekeeper administration console. The administrator can configure the desired root certificates and client side certificates using the administration interface of the SSL toolkit, IBM Key Management.

Messages flowing between Connection Manager, SMS centers, and the client devices are not encrypted.

WAP proxy security

Connection Manager's WAP proxy feature allows access from a WAP client device to a range of Web based services and content in the information network of a service provider or an enterprise. The WAP proxy behaves much like a Web proxy in conventional internet-based networks. The end user's WAP device is configured to communicate with Connection Manager using the appropriate network address (MSISDN, IP, and so on). The WAP proxy terminates the WAP session and provides the appropriate conventional HTTP or HTTPS session to the remote content (Web) server. The WAP session can be secured by the Wireless Transport Security Layer (WTLS) protocol, as defined in the WAP specification. The HTTPS session is secured by the SSL protocol.

Separate authentication and encryption options can be set for communications from the WAP client to the Connection Manager, and from the Connection Manager to the web server.

Authentication and encryption between Connection Manager and the WAP client

Several methods can be configured for Connection Manager to validate a WAP client, as described below:

Native PPP connections

The Connection Manager mobile access services can accept connections from dial-in devices that support the Point-to-Point Protocol (PPP). Using either the PAP or CHAP authentication protocols, users negotiate authentication with Connection Manager. Connection Manager can validate the user's credentials using either the system authentication profile, RADIUS authentication profile, or LDAP-bind authentication profile, as defined by the mobile access services configuration. The authentication for establishing a PPP session serves as the authentication mechanism for WAP proxy transactions.

Device resolver

Though not a method of authentication, device resolver serves to uniquely identify a WAP client. Authentication of the WAP client takes place elsewhere in the environment, usually at the server that provides network access.

In a typical service provider environment, the network access server (NAS) has direct access to the provider's wireless network infrastructure, where unique information about a device, like its phone number, is available. The NAS uses the RADIUS protocol to inform the WAP proxy of that unique identity. The WAP proxy uses device resolver to match this information to WAP requests and validate that the device has previously been authenticated.

Account resolver

Account resolver is similar to device resolver, but instead of using the RADIUS protocol to retrieve information, the WAP proxy uses HTTP to query the NAS for information about the device.

HTTP challenge

Connection Manager can require that user credentials exist in each WAP transaction header. Any transaction that does not contain a user ID and password is discarded, and the WAP client browser is sent a reply with a status code of either Proxy-Authenticate or WWW-Authenticate, depending on the environment. The WAP client browser prompts users to enter their user ID and password, and then resubmit the transaction with the credentials included. These credentials, along with the network address of the WAP client, are used to authenticate the user. The Connection Manager can validate the user's credentials using either the system authentication profile, RADIUS authentication profile, or LDAP-bind authentication profile.

When configured for this authentication method, Connection Manager can enable single sign-on through lightweight third party authentication (LTPA). LTPA provides a mechanism for storing user authentication information in a token generated after a user is successfully authenticated. The LTPA token is stored as an HTTP cookie and included in all requests for the configured single sign-on domain. Other LTPA-enabled servers within the same domain can authenticate user requests based on the token cookie without challenging the user for their credentials.

The WAP Forum has defined the WTLS layer as the means for securing communications between a WAP client and a WAP proxy. The Connection Manager WAP proxy supports the WTLS Class 2 options. The following WTLS protocols are supported:

• Public key algorithms
• RSA (1024, 768, or 512 bit keys)
• Diffie-Hellman (1024, 768, or 512 bit keys)
• Symmetric key algorithms
• DES (56 bit key)
• Triple DES (168 bit key)
• RC5 (40, 56, or 128 bit keys)
• Message authentication codes
• SHA-1

The WAP proxy can be configured to use either a WTLS certificate as defined in the WAP WTLS specification, or a randomly generated key-pair for public key communications with the WAP clients. X.509 and X9.68 certificate formats, although supported by the WAP WTLS specification, are not supported by the WAP proxy. The Connection Manager administrator can enable the desired protocols (including disabling encryption altogether), and the desired strength of the protocols.

Authentication and encryption between Connection Manager and a secure Web server

When a WAP client requests secure Web content using the HTTPS protocol, the WAP proxy forwards the communications to the content server. The WAP proxy decodes the WAP request, encrypted with the WTLS protocol, and sends the request to the secure Web server using an SSL connection. Both Version 2 and Version 3 of the SSL protocol are supported. The following SSL protocols are supported:

• Public key algorithms
• RSA (1024, 768, or 512 bit keys)
• Symmetric key algorithms
• DES (56 bit key)
• Triple DES (168 bit key)
• RC4 (40, 56, or 128 bit keys)
• Message authentication codes
• SHA-1
• MD5

You can use an X.509 certificate to provide client side authentication for the WAP proxy's SSL communications. These certificates, along with root certificates to validate the Web server's certificate, are stored in a key database that's installed with Connection Manager. The Connection Manager administrator can configure the source of this database using the Gatekeeper administration console. The administrator can configure the desired root and client side certificates using the administration interface of the SSL toolkit, IBM Key Management.

Connection Manager Administration Security

The Connection Manager can be administered from Gatekeeper, a Java™ application, or through administration portlets with WebSphere Portal Server. Administrators are required to log in to Connection Manager, which then authenticates them against a persistent user storage database in an LDAP-compliant directory server.

The Connection Manager validates the administrator's credentials against a persistent user storage database in an LDAP-compliant directory server. The password has to be initially communicated to the end user administrator by a secure media, so both parties know the password. Passwords can be set to expire at configured intervals, requiring the administrator to change the password. Rules can be established on Connection Manager to enforce the unpredictability of the password. The Connection Manager has the capability of enforcing the following rules:

• Minimum number of characters
• Minimum number of alphabetic characters
• Minimum number of non-alphabetic characters
• Minimum number of characters not contained in the previous password
• Number of previous passwords that cannot be reused
• Maximum number of times a character can be repeated
• Whether or not the password can contain the user ID within its string
• Whether or not the password can begin or end with a numeric character.

Administrators have an access control list (ACL) associated with their user ID that governs the level of administration that can be performed. The various resources of Connection Manager can be organized into separate organizational units (OUs), with separate administrators having different access rights to these resources, based on their assigned ACLs.

The Connection Manager access manager subsystem is used to communicate with the administration interface. Access manager can restrict the source IP address from which a Gatekeeper may connect, and can force all administrative tasks to be performed over SSL-secured communications channels. Encryption and hashing of transactions processed in access manager are used within the confines of the SSL protocol. Both Version 2 and Version 3 of the SSL protocol are supported. The following SSL protocols are supported for access manager:

• Public key algorithms
• RSA (512 bit key)
• Symmetric key algorithms
• DES (56 bit key)
• Triple DES (168 bit key)
• RC4 (40, 56, or 128 bit keys)
• Message authentication codes
• SHA-1
• MD5

X.509 certificates can be used to provide authentication for the SSL communications. This certificate, and root certificates to validate the Gatekeeper's certificate, are stored in a key database that is installed with Connection Manager. The Connection Manager administrator can configure the source of this database using the Gatekeeper administration console.

Load balancing and clustering

For load balancing and high availability performance, you can configure several Connection Manager installations to work together in a cluster. The cluster manager subsystem controls the communications among the nodes. You can configure the cluster of Connection Manager nodes to communicate using either SSL or IPSec. The following SSL protocols are supported:

• Public key algorithms
• RSA (512 bit keys)
• Symmetric key algorithms
• DES (56 bit key)
• RC4 (40 bit key)
• Message authentication codes
• SHA-1
• MD5

Single Sign-On Security

Single Sign-On (SSO) enables servers within the same domain to authenticate user requests once, at the first point of entry in to the domain. When the transaction reaches other servers within the domain, the already validated credentials are trusted by the server without challenging the user for input. Connection Manager provides four methods of Single Sign-On integration, depending on how the platform is configured:

• Web Access Server (HTTP access services or WAP proxy)
• Lightweight Third-Party Authentication (LTPA)
• WebSphere Everyplace Server X-IBM-PvC HTTP Headers
• Mobile Access Server (Mobility Client or PPP connections)
• WebSphere Application Server Trust Association Interceptor (TAI)
• WebSphere Everyplace Server Active Session Table
• RADIUS Accounting

Lightweight Third-Party Authentication (LTPA)

LTPA provides a mechanism for storing user authentication information in a token that is generated when a user is successfully authenticated with Connection Manager. The token is encrypted and signed using a password and a public/private key pair, stored in a HTTP cookie, and included in all requests for the configured SSO domain. The LTPA keys are shared with other LTPA-enabled servers within the same domain, so the servers can validate the token and authenticate user requests instead of challenging the user. LTPA tokens include a configurable expiration timestamp; after the token expires, a new authentication challenge is issued.

WebSphere Everyplace Server Integration

When deployed as part of WebSphere Everyplace Server, Connection Manager integrates with other WebSphere Everyplace Server components to provide an SSO environment. WebSphere Everyplace Server defines a set of HTTP header extensions that identify users, their devices, and the characteristics of the wireless network transports. Connection Manager supplies this information after users have been authenticated, allowing for other WebSphere Everyplace Server components to validate the transaction without challenging the user for additional information.

When Connection Manager serves as a network access server, an entry for each login is added to the WebSphere Everyplace Server Active Session Table. Other WebSphere Everyplace Server components can query the Active Session Table to validate the transaction without challenging the user for additional information.

Trust Association Interceptor

WebSphere Application Server provides a plug-in model for enabling SSO, known as the Trust Association Interceptor (TAI). When an HTTP transaction request reaches the Application Server, it calls into the Connection Manager TAI plug-in, using the requester IP address to retrieve login information from the Connection Manager session database. Since Connection Manager manages IP addresses and only hands out IP addresses to authenticated users, the requester IP address can be directly mapped to a user record. The information obtained through TAI is used to establish a user context in Application Server, enabling SSO.

RADIUS Accounting

As part of the RADIUS protocol, information tying a network address to a particular user can be communicated from the Connection Manager to other servers interested in that information. Servers can identify the network source of the transaction requests and validate that the user has previously been authenticated.

Back to top

Appendix A: FIPS 140-2 Certification

Federal Information Processing Standard 140 was jointly developed in 1994 by NIST of the United States and CSE of Canada to ensure secure operations on sensitive information in computer and telecommunication systems. The FIPS 140-1 version was superseded by FIPS 140-2 in 2001. No new 140-1 certifications are being issued. FIPS 140-2 defines 11 areas of conformance requirements in 4 increasing, qualitative levels of security to be performed against a cryptographic module. Each requirement area is separately rated to the level of security achieved. The overall rating indicates the lowest achieved in the 11 areas.

The encryption algorithms utilized by Connection Manager have been isolated into a cryptographic module for validation. This module is FIPS 140-2 certified (certificates 320 and 321) as follows:

The encryption algorithms contained in the module have also received certification for:

• FIPS 197 (AES)
• FIPS 46-3 (DES)
• FIPS 46-3 (TripleDES)
• FIPS 186-2 (DSA)
• FIPS 180-1 (SHA-1)

When Connection Manager utilizes the cryptographic module in an approved manner, the product complies with the FIPS 140-2 requirements. Only Connection Manager mobile access services utilize the FIPS 140-2 certified cryptographic module. The Mobility Client maintains compliance when running on all Microsoft Windows and Windows CE operating system versions. The Connection Manager gateway maintains compliance only when running on AIX and Solaris Common Criteria (CC) evaluated operating systems.

The FIPS 140-2 logo is a Certification Mark of NIST, which does not imply product endorsement by NIST, the U.S. or Canadian Governments

Back to top

Appendix B: Import/Export Control Information

WebSphere Everyplace Connection Manager is mass marketed in the United States of America (U.S.) and worldwide, as a separately orderable product through various channels including IBM Passport Advantage (volume purchase option programs, online/fax/phone), IBM Software Business Partner programs, and IBM direct sales.

Previous versions of the product have been named IBM Everyplace Wireless Gateway, IBM SecureWay Wireless Gateway and IBM eNetwork Wireless Gateway. The previous version of the IBM WebSphere Everyplace Server was called IBM WebSphere Everyplace Suite.

WebSphere Everyplace Connection Manager V5.0 has U.S. export certification status under ECCN 5D002.C.1 with an ERO identifier of A6va, having completed the required government review, and has been granted approval for import into France. The product has been granted retail status for U.S. export purposes, meeting the required criteria as follows:

• The product is mass marketed in the U.S. and worldwide.
• Encryption algorithms are not accessible to external applications coexisting on the computer running Connection Manager, Gatekeeper, or Mobility Client, through any application interface provided by the product. The encryption interface is only accessible from the internal functions of the Connection Manager product code.
• Encryption algorithms are only distributed in object code as a part of the Connection Manager product. No cryptographic source code is made available to customers.
• There is no requirement for substantial vendor support, such as service contracts, for use of this product. The software is designed to be setup and configured easily by a customer.
• WebSphere Everyplace Connection Manager is a distributed, scalable, multipurpose UNIX communications platform that provides general application functionality.

Resources

• Simpson, W., et al. July 1994. The Point-to-Point Protocol (PPP) . The Internet Engineering Task Force. Internet. 22 April 2002.
  
  
• Lloyd, B., et. al. October 1992. PPP Authentication Protocols . The Internet Engineering Task Force. Internet. 22 April 2002.
  
  
• Simpson, W., et al. August 1996. PPP Challenge Handshake Authentication Protocol (CHAP) . The Internet Engineering Task Force. Internet. 22 April 2002.
  
  
• Rigney, C., et. al. April 1997. Remote Authentication Dial In User Service (RADIUS) . The Internet Engineering Task Force. Internet. 22 April 2002.
  
  
• WAP Forum. February 1999. Wireless Application Protocol Wireless Transport Layer Security Specification11-February-1999 . WAP Forum. Internet. 22 April 2002.
  
  
• Janson, P. and Tsudik, G. 1994. Secure and Minimal Protocols for Authenticated Key Distribution . Computer Communications.
  
  
• National Institute of Standards and Technology. May 2001. Security Requirements for Cryptographic Modules . Federal Information Processing Standards Publication 140-2.
  
  
• National Institute of Standards and Technology. November 2001. AES Key Wrap Specification . Internet. November 2001.
  
  
• National Institute of Standards and Technology. November 2001. Advanced Encryption Standard (AES) . Federal Information Processing Standards Publication 197.
  
  
• Rivest, R. April 1992. The MD5 Message-Digest Algorithm . The Internet Engineering Task Force. Internet. 22 April 2002.
  
  

About the author

Henry Welborn is a Software Engineer for IBM in Research Triangle Park, North Carolina. He started with IBM as a co-op student from Virginia Tech in 1994, has been developing wireless middleware since he joined IBM full-time in 1998, and has served as lead developer of the WebSphere Everyplace Connection Manager security team since 2000. You can reach Henry at hwelborn@us.ibm.com

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Connection Manager Security
• Appendix A: FIPS 140-2 Certification
• Appendix B: Import/Export Control Information
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers