security - ibm

®

8 2002 IBM Corporation

Security

J02_SecurityJuly20.PRZ1


ibm.com/eserver/iseries

Agenda

What is new in V5R2Enterprise Identity Mapping

mechanism for mapping a person to the appropriate user identities throughout the enterprise

KerberosAuthentication and Authorization System for single Sign-On

Cryptographic hardwareNew feature #4508 cryptographic accelerator card (IBM 2058 e-Business Cryptographic Accelerator)Additional 4758 Cryptographic Coprocessor (feature numbers #4801/;4802) capabilities: Financial pin processing: Unique key per transaction (UKPT) Common Cryptographic Architecture (CCA) 2.4

Service Toolsenhancements and additions to service tools




Enterprise Identity Mapping(EIM)




Typical environment today

z/OSRACF

Intranet User

iSeries

Windows 2000/NT

WebSphere

NetServer

AIX

Example: Back-end access is done using an OS user, unaware of the end users authority.

Linux

NDS

John Smith's Id/pwdu:John Smith p:passwordu:JSimth p:SE50852u:John p:passwordu:Smith1 p:jonnyu:JoSm05 p:eyKd64dvetc..




Notes: Typical environment today

In today’s heterogeneous networks with partitioned servers and multiple platforms, administrators, users, and application developers all have to cope with the complexities that multiple user identities for individual users create within an enterprise. Most network enterprises face the problem of multiple user registries, which require each person or entity within the enterprise to have a userID in each registry.

Users have to remember each user ID and password for each system they use. It is quite common that users try to simplify their own local environment by using the same password in multiple systems. Also it is possible that each system has its own unique rules for userID and passwords. Administrators must perform password resets, attempt to synchronize user IDs and passwords, and remember every system in the network to which each individual has access. Cross platform distributed applications which span platforms often "agree" who a specific user is. When OS protected resources are accessed, the application projects (maps) the application view of a user into the operating system (OS) view of the user. The Back-end system is forced to trust the front-end servers.Application developers are often forced to use non-secure techniques to solve this problem or to invest large amounts of money in writing applications that implement their own user registries and associated security semantics. These problems quickly become a large administrative problem for all parties involved.

20% - 40% of all calls to help desk involve forgotten passwords costing a company $14 - $26 per reset.- Source: Gartner Group. Visit their web site for details.




What is EIM ?

Enterprise Identity Mapping (EIM) is a mechanism for mapping (associating) a person or entity to the appropriate user identities in various registries throughout the enterprise

EIM provides an infrastructure that lowers the expense for application developers to provide single sign-on solutions

Windows 2000 Server

kdc1.itso.myco.com

EIM Domain ControllerJmsith

realm = itso.myco.com

iSeriesB.itso.myco.com

iSeriesA.itso.myco.com

zSeriesC.itso.myco.com

EIM IdentifiersJohn Smith Sharon Jones

SjonesSharonjJonesshJoness2

JsmithJohnsSmithjoSmithj

Kerberos principaliSeries A user nameiSeries B user namezSeries C user name

EIM defined: Identity associations across user registries associated with multiple OS platforms, applications and middle-ware.




Notes: What is EIM?

Enterprise Identity Mapping (EIM) provides an infrastructure that lowers the expense for application developers to provide single sign-on solutions. OS/400’s exploitation of EIM and Kerberos, along with exploitation by other eServer and IBM software, provides single sign-on capabilities. This in turn provide users, administrators, and application developers the benefits of easier password and user identity management across multiple platforms — without changing the underlying security schema. EIM is comprised of multiple technologies that work together to further the security of your network.

EIM is a part of IBM's autonomic computing initiative, a project with the goal to give businesses the ability to manage systems and technology infrastructures that are hundreds of times more complex than those in existence today




What does EIM provide ?

Enables Single sign-on across multiple operating systems!

Simplifies AdministrationRely on existing security semantics already in place for existing dataReduces load on administrators for "lost" passwordsReduces client side risks (cached passwords, post-it notes, etc..)

Better Application designNo need to implement new user registriesNo need to define or enforce additional security semanticsProvides maximum flexibility for distributed, multi-tier application developers

Simplifies process for user, access is controlled under the covers

The iSeries is the first eServer platform that provides EIM enabled services

Other platforms like zSeries, pSeries, xSeries, Java and Linux follow




Notes: What does EIM provide ?

Enterprise Identity Mapping provides the mechanics for cross-platform single sign-on enablement. There are multiple benefits for users, administrators, and application developers alike when single sign-on is used in an enterprise.

The iSeries server uses EIM to enable OS/400 interfaces to authenticate users by means of Network Authentication Service (i.e. Kerberos). Applications, as well as OS/400, can accept Kerberos tickets and use EIM to find the user profile that represents the same person as the Kerberos ticket represents.

Benefits for usersWith single sign-on, authentication occurs only once when users sign into the network. Using EIM reduces the need for users to keep track of and manage multiple user names and passwords to access other systems in the network. Once a user is authenticated to the network, the user canaccess services and applications across the enterprise without the need for multiple passwords to these different systems.Benefits for administratorsSingle sign-on simplifies overall security management of an enterprise and reduces the administrative overhead in managing authentication while helping to keeping the entire network secure. Additionally, single sign-on reduces the administrative costs of resetting forgotten passwords. Administrators can set up a single sign-on environment a Windows 2000 (or later) server that allows access to the entire network, thus minimizing authentication and identification management.Benefits for application developersFor developers of applications that must run in heterogeneous networks, the challenge is to create multi-tiered applications where each tier is likely to be a different type of platform. By exploiting EIM, application developers are free to write applications that use the most appropriate existing userregistry for authentication while using a different user registry for authorization. Not having to implement application specific user registries, associated security semantics, and application level security significantly lowers the cost of implementing multi-tiered, cross-platform applications.

The other eServer platforms are currently working on their EIM implementation, and are almost complete with the infrastructure. It is however possible for applications to benefit from the EIM APIs without relying on the underlying operating system.




EIM Terminology

Multiple technologies are incorporated into Enterprise Identity Mapping functions. Although some EIM terminology may be familiar, some of the EIM terminology and other terms may be new to you.

Understanding these terms will help you plan and implement EIM capabilities and single sign-on enablement.

Alias

EIM authorities

EIM domain controller

EIM identifier

EIM identity mapping association

Identity mapping lookup operation

LDAP distinguished name

LDAP parent distinguished name

User identity

User registry




Notes: EIM Terminology

AliasYou can create one or more aliases for an “EIM identifier” or a “User registry” to provide additional information by which the identifier or registry is known. Aliases can be used to help find a specific EIM identifier or user registry during a search or “Identity mapping lookup operation”. An alias does not have to be unique within the EIM domain because it is additional information, not an actual object name.You can “Add an alias to a user registry” either for an EIM identifier or for a user registry. An EIM identifier alias supplies more information about the person or entity that the EIM Identifier name represents.

EIM authoritiesEIM authorities describe and provide authorization for an EIM user to perform specific administrative tasks or “Identity mapping lookup operation” Only users with EIM administrator authority are allowed to grant or revoke authorities for other users. EIM authorities are granted to users identities that are known to EIM. These user identities can be LDAP distinguished names or Kerberos principals.

EIM domain controllerThe EIM domain controller is an LDAP directory server that is configured to manage, and control access to, all EIM data for an EIM domain. The EIM domain controller can be either local or remote. A domain controller is considered to be local when it is configured on the same system that you are using to conduct EIM operations. A domain controller is considered to be remote when it is configured on a different server, separate from the serveryou are using to conduct EIM operations.

EIM identifierAn EIM identifier represents an actual person or entity in EIM. When you create an EIM identifier, you associate it with the “User identity” for that person or entity. Using these “EIM identity mapping association”, or identity mappings, helps you simplify the administrative task of keeping track ofall of the user IDs that a person or entity has in the enterprise.




Notes: EIM Terminology -2

EIM identity mapping association A single sign-on enabled environment is made possible by associating the various user identities of a person or entity to a single “EIM identifier” for that person or entity. By associating all of a person’s user identities with that person’s corresponding EIM identifier, applications and operating systemfunctions can then use EIM APIs to map from an authenticated ID in one user registry to a different ID in another user registry that represents the same person.You can create three different types of associations between a user identifier and an EIM identifier

Source associationSource association indicates that this “User identity” (ID) can be used as the source in a “Identity mapping lookup operation”

Target associationTarget association indicates that the user ID can be returned as the result of a mapping lookup operation.

Administrative associationAdministrative association with an EIM identifier is typically used to show that the person or entity represented by the EIM identifier owns a user ID within a specified system or application user registry which requires special treatment.

Identity mapping lookup operationAn identity mapping lookup operation is conducted by an application that uses the appropriate “APIs for EIM” (eimGetTargetFromSource() or eimGetTargetFromIdentifier() APIs). By allowing the operating system and applications to perform a mapping lookup operation to access this information at run-time, the operating system and applications can easily use one “User registry” for authentication while using an entirely different user registry for authorization.

LDAP distinguished nameAn LDAP distinguished name (DN) is a Lightweight Directory Access Protocol (LDAP) entry that identifies and describes an authorized user for an LDAP server. The EIM wizard configures the iSeries Directory Server (LDAP server) to store the EIM Domain information. You can use LDAP distinguished names as a means of accessing and retrieving this EIM data so that your iSeries server can participate in a “Single sign-on enablement through EIM”.




Notes: EIM Terminology -3

LDAP parent distinguished nameAn LDAP parent distinguished name (DN) is an entry in a Lightweight Directory Access Protocol (LDAP) directory server’s namespace. LDAP directory entries are arranged in a hierarchical structure that reflects political, geographic, organizational, or domain boundaries. A distinguished name is considered a parent DN when the DN is at the highest level of the directory server’s namespace.

User identityA user identity (ID) is an entry in a “User registry”. This entry is typically a string of alphanumeric characters, unique within the registry, that is used to represent a specific person or entity to a system or application. User IDs are associated with an “EIM identifier”, which represents a person or entity within the enterprise.

User registryA user registry contains a set of entries that represents a set of “User identity” that an operating system or an application either knows or trusts, or both. The set of user identities can be a complete system user registry or a subset of a system user registry that is used with a particular application. These user registry types are predefined in EIM:

OS/400AIX RKerberosKerberos - case sensitiveLDAPRACFWindows 2000Novell Directory ServicesPolicy Director

The next few foils show how EIM can work for "EIM identifier Jon Smith."




An EIM identifier represents an actual person or entity in EIM.

The identity associations (mappings) are stored in a well known location, for example LDAP, with common services across platforms to access the mappings.

johnsmithSmith SMITH1JSMITHJOHNS Services

WindowsUser

iSeries User AIX user Kerberos

PrincipalDCE User

z/OS User

EIM Identifier

John Smith

user registries

Local User

Identities

identity

mappings

A Pictorial view of EIM




A Pictorial view of EIM

Having created the needed EIM identifiers and associated them using different “EIM identity mapping associations” your systems and users are ready to participate in a single sign-on environment.




Notes: A Pictorial view of EIM

An EIM domain is much like a typical network domain except that the domain controller not only controls the access to the domain, but also stores all of the EIM data for that domain. By participating in an EIM domain, these systems can also participate in the single sign-on environment.

To be able to participate in the EIM domain, you configure EIM on each system and to participate in the single sign-on environment, you must also configure network authentication service on each system. You then add the appropriate system or application user registries to the EIM domain and create EIM identifiers to represent each user in EIM.

In our example, John Smith, has userIDs on the following systems in the EIM domain:Windows NT/2000 PC - Smith iSeriesA server - JOHNSAIX server - johnsmithWindows 2000 server (Kerberos Principal) - JSMITHzSeries server: SMITH1

John’s EIM identifier, John Smith, represents him as a person in EIM and the various user identities he has on the various systems. They can then be mapped to, or “EIM identity mapping association” with, his EIM identifier to establish the relationship between them. The types of associations that you create affect the way in which the associated user identity can be used in EIM.

In our example, the iSeriesA server is highly secure and you want to restrict John’s access to the system so that he must authenticate directly to the server. To do this, you create an administrative association between the John Smith EIM identifier and the JOHNS user identity on iSeriesA. With this type of association, you can see that John Smith owns an account on iSeriesA, but EIM cannot return information about this identity in a “Identity mapping lookup operation”.

Having created the needed EIM identifiers and associations, your systems and users are ready to participate in a single sign-on environment.




Other Components in the EIM Domain - NAS

Network Authentication Service (NAS) enables the iSeries to use Kerberos tickets for authentication instead of userID and password

Applications can identify users and securely pass on the identity to other services

NAS builds on the Kerberos Network Authentication Service (RFC1510)

By using APIs, EIM can also be used without NAS for other purposes




Notes: Other Components in the EIM Domain - NASYou can use a Kerberos ticket as an optional replacement for a user name and password for authenticating a user. In a single signon network you would typically use Kerberos to provide the authentication function, though it is technically possible some other authentication function could be used.

Kerberos (primarily developed by the Massachusetts Institute of Technology (USA)) protocol allows a principal (a user or service) to prove its identity to another service within an insecure network - Kerberos provides an "authentication service." Network Authentication Service enables you to use Kerberos authentication on your iSeries server. EIM "just" provides the mapping capabilities. It does not provide any kind of authentication. In order sign on to the network and use the mapped information you need some authentication mechanism.

In theory, you could use any kind of authentication mechanism that is available and use the EIM APIs in your application to achieve the same functions without Kerberos. But in practical terms where authentication is to OS/400 services, such as host servers, Telnet server, SQL, DDM, DRDA7, NetServer and QFileSrv.400, IBM has chosen a single authentication mechanism for EIM and facilities provided with Kerberos is that mechanism.

The Kerberos Key Distribution Center (KDC) service provides the network authentication process and EIM provides the mapping to the local system's user id and password. OS/400 does not support the KDC function. Most Linux distributions and Windows 2000 and XP can provide the KDC service authentication function.

See the Kerberos section of this presentation for more details.

Network Authentication Service verifies the identity of a user or service in a network. Applications can securely authenticate a user and securely pass on his or her identity to other services on the network. Once a user is known, separate functions are needed to verify the user’s authorization to use the network resources. Network authentication service implements the following specifications:

Kerberos Version 5 protocol Request for Comment (RFC) 1510 Many of the de facto standard Kerberos protocol APIs prevalent in the industry today Generic Security Service (GSS) APIs as defined by RFCs 1509, 1964, and 2743

Network authentication service on the iSeries interoperates with authentication, delegation, and data confidentiality services compliant with these RFCs, such as Microsoft’s Windows 2000 Security Service Provider Interface (SSPI) APIs.

J02SecySep12Changes.prz - 2 IBM Confidential 09/16/02



Other Components in the EIM Domain - Kerberos

Kerberos is a network authentication protocol designed to establish secure authentication from client to server (and vice versa) on an untrusted network




Notes: Other Components in the EIM Domain - Kerberos

This foil restates the role of Kerberos as a component in the EIM Domain. The next foils discuss EIM APIs as another component.

Following EIM APIs foils, we have expanded information on Kerberos.




Other Components in the EIM Domain - EIM APIs

EIM uses a collection of APIs that access a Directory server to store Domain information

No new protocol introduced, uses LDAP

EIM APIs can be used for third party products, e.g. for GUI User Admin tools

Security SPIs, APIsand commands

LDAP Server

LDAP Client APIs

EIMAPIs

Various non-EIM interfaces

LDAP

Domain Management

eimGetHandle()eimConnect()

authenticate caller (U1) in registry A (REGA)..eimGetTargetFromSource(U1, REGA, REGB, associated_identity)setuid(associated_identity)perform task as local identityget next request

eimDestroyHandle()




Notes: Other Components in the EIM Domain - EIM APIsEnterprise Identity Mapping (EIM) has multiple application programming interfaces (APIs) that applications can use to conduct EIM operations on behalf of the application or an application user. You can use these APIs to conduct identity mapping lookup operations, various EIM management and configuration functions, as well as information modification and query capabilities.

EIM APIs fall into multiple categories, as follows:EIM handle and connection operations

Manages a token which is an instance of the EIM services. Similar in concept to other services in which the invoker is responsible for hanging-on to a "handle"

EIM domain administrationCreates a EIM domain, establishes the EIM "domain" controller...

Registry operationsSystem or application registries join EIM instance

EIM identifier operationsManages a "anchor" point for a enterprise user

EIM mapping lookup operationsSupports determination of user's ID across disparate registries

EIM management OperationsDefinition of this set of services is in progressDirection is to define XML markup(s) which describe:Users within registries and defines data passed on APIAllows add/modify/delete of users across multiple registries

Applications that use these APIs to manage or utilize the EIM information in an EIM domain typically adhere to the following programming model.Get an EIM handleConnect to an EIM domainNormal application processingUse an EIM administration or EIM mapping lookup operation APINormal application processingBefore ending, destroy the EIM handle




Use of an EIM APIs

A possible use of EIM APIs could be an Administration tool to manage enterprise users...

iSeries

LDAP

Createapp

user..

Jonny

AddRACF

user..

JS50852

RACFAIX

Windows User

EIM

==.

CRTUSRPRF"JOHN12"

PASSWORD(*NONE)

TEXT(JohnSmith,

Salesguy)

Add Domain user..John N. Smith

CreateIDs

EIM Domain

User Details

Gen

erat

eU

ser i

nfo.

Cre

ate

EIM

iden

tity.

.M

ap p

rofil

es.

CatalogUser

MapUser

User Name: Smith, John. N.

Employee # 050852Branch: DummyBranchRole: Sales personStart date: 2002 June 10

End date: 2003 June 9Phone: 1-800-Security

e-mail: [email protected]

Add enterprise user




Note: Use of an EIM APIs

In this example, an administrator creates an enterprise user. This would trigger the creation of profiles and IDs on existing environments, according to his "role". These IDs would be created with Unique identifiers according to the rules of each registry. This would also map the userIDs to his Identity in the EIM database. Finally, this process could involve building an entry for the user in the company's directory.

These user IDs can be setup with very difficult passwords, or in the iSeries case, disable the use of password authentication. (by setting the password to *NONE.)

By using EIM the administration tool could also have functions like removing/disabling a user, or changing a users role in the company. Lets say if the user went to a manager role, it would enable access to administrative systems.

Note: The Java Jar file and the opensource version of the Linux EIM APIs will be licensed to allow business partners (BPs) to freely bundle the APIs with their applications.




EIM enabled functions on the iSeries

On the iSeries V5R2, the following applications can be accessed through single sign-on:

iSeries Navigator / Host ServersPC5250 Emulator (Telnet server)DRDANetServerQFileSvr.400DDM

The following user registry types are predefined in EIM:OS/400AIXKerberosKerberos - case sensitiveLDAP




Comparison between EIM and TUA

EIM is not a Tivoli User Administration (TUA)

EIM is an Enabler for TUA

In the near future, EIM will be an endpoint that Tivoli can manage.

EIM TUAEnable multi-tierheterogeneous apps YES NO

Enable enterprise user mgmt products YES NO

Single point of user mgmt product NO YES

Enable ESG cross-platform interoperability at OS level

YES NO

I BM

pla

ns a

nd d

ir ect

i ons

ar e

sub

ject

t o c

hang

e w

ithou

t not

ice




Notes: EIM and Tivoli User Administration

Tivoli User Administration offers user management across multiple systems and multiple operating systems. This charts servers to compare EIM an d Tivoli User Administration functions.

Note the planned future "integration" between EIM and TUA.




Kerberos




What is Kerberos

Kerberos is a network authentication protocol designed to establish secure authentication from client to server (and vice versa) on an untrusted network

Can also allow clients to enable cryptography to secure an established connection

Client dependent, iSeries Access currently does not support Kerberos encryption

Widespread throughout the industry, allows for interoperability between platforms

Simplifies trust management

Outlined in RCF1510

RFC1510The Kerberos Network Authentication Service




According to, The Enlarged Devil's Dictionary ( Ambrose Bierce), Kerberos (also spelled Cerberus) is the watchdog of Hades, whose duty was to guard the entrance (against whom or what does not clearly appear); Kerberos is known to have three heads."

The Kerberos Authentication and Authorization System is an encryption-based security system that provides mutual authentication between the users and the servers in a network environment. In summary, Kerberos is a solution to your network security problems. It provides the tools of authentication and strong cryptography over the network to help you secure your information systems across your entire enterprise.

Kerberos authentication itself does not automatically imply that the rest of the session is encrypted. Kerberos does however enable a secure exchange of encryption keys, that could be utilized by a client program for session encryption. iSeries Access for example does not implement the encryption part of Kerberos, however iSeries Access traffic can be encrypted by SSL instead.

Kerberos system was designed and developed in the 1980’s by the Massachusetts Institute of Technology (MIT), as part of the Athena project. The current version of Kerberos is Version 5, which is standardized in RFC 1510, The Kerberos Network Authentication Service (V5). For more details see http://www.ietf.org/rfc/rfc1510.txt

Kerberos is freely available from MIT, under copyright permissions very similar those used for the BSD operating system and the X Window System. MIT provides Kerberos in source form so that anyone who wishes to use it may look over the code for themselves and assure themselves that the code is trustworthy. In addition, for those who prefer to rely on a professionally supported product, Kerberos is available as a product from many different vendors.

Notes: What is Kerberos




A Kerberos Environment

Key Distribution Center(KDC)

"A"

TGT "A"

John

Server A

AS TGS

Service"A"

1

3

4

5

6

1

2

3

4

5

6

as_request:"Hi, I'm John.could I have a ticket for getting tickets?"

as_reply: "Here's a Ticket granting ticket, encrypted with Johns secret key".

tgs_request:"Here is my TGT, could I have a ticket for Service A. "

tgs_reply: "Here's a Ticket for Service A."

ap_request:"Here is my Ticket, let me use your service. "

ap_reply: "By the way, here's the proof that I'm Service A"

TGT2




The Kerberos protocol consists of several sub-protocols (or exchanges). There are two methods by which a client can ask a Kerberos server for credentials. In the first approach, the client sends a clear text request for a ticket for the desired server to the Authentication Service (AS). The reply is sent encrypted in the client's secret key. Usually this request is for a ticket-granting ticket (TGT) which can later be used with the ticket-granting server (TGS). In the second method, the client sends a request to the TGS. The client sends the TGT to the TGS in the same manner as if it were contacting any other application server which requires Kerberos credentials. The reply is encrypted with the session key from the TGT.

The client and server do not initially share an encryption key. Whenever a client authenticates itself to a new verifier it relies on the authentication server to generate a new encryption key and distribute it securely to both parties. This new encryption key is called a session key and the Kerberos ticket is used to distribute it to the verifier.

The Kerberos ticket is a certificate issued by an authentication server, encrypted using the server key. Among other information, the ticket contains the random session key that will be used for authentication of the principal to the verifier, the name of the principal to whom the session key was issued, and an expiration time after which the session key is no longer valid. The ticket is not sent directly to the verifier, but is instead sent to the client who forwards it to the verifier as part of the application request. Because the ticket is encrypted with the server key, known only by the authentication server and intended verifier, it is not possible for the client to modify the ticket without detection.

Notes: A Kerberos Environment




Components of Kerberos - KDC

The Key Distribution Center (KDC) has two primary services:AS - Authentication Server

The AS contains the shared secret that is required to prove ones identityOnce authentication has been made, a TGT is issued

TGS - Ticket Granting ServiceIssues Service Tickets (containing session keys)Does not keep track of ticket delivery


AS TGS




Notes: Components of Kerberos - KDCThe Key Distribution Center (KDC), a network service that supplies tickets and temporary session keys; or an instance of that service or the host on which it runs.

The initial ticket portion is sometimes referred to as the Authentication Server (AS). The user request will be authenticated by the AS. It will look up the client name and the server/service name in the Kerberos Database and obtain an encryption key for both the requester and the Ticket Granting Server (TGS). The client in return will receive an encrypted message called initial ticket, which will grant him access to the requesting server/service which is the TGS.

The ticket-granting ticket portion is sometimes referred to as the ticket-granting server (TGS). The TGS is logically distinct from the AS, although they may reside on the same physical machine. The function of the TGS is that before accessing any server/service, the user requests a ticket to contact the TGS, just as if it were any other service. This ticket is called the ticket granting ticket (TGT). The TGS uses the initial ticket encrypted by AS to now grant him another ticket called the TGT.

After receiving the TGT, any time that the user wishes to contact a server/service, he requests a ticket not from the AS, but from the TGS to which he replies a new session key which is encrypted with the session key to grant him access to the requesting server/service.

The KDC services both initial ticket and ticket-granting ticket requests. They are often referred to collectively as the KDC - the Key Distribution Center.

Note: The KDC function does not run under OS/400 through 2002. At this time it is known that most Linux distributions support the KDC function and so do Windows 2000 and Windows XP.

J02SecySep12Changes.prz - 3 IBM Confidential 09/16/02



Components of Kerberos - Ticket

Ticket: A record that helps a client authenticate itself to a server or service and establish a session.

Ticket Granting Ticket (TGT): A Ticket used for requesting tickets subsequently used for sessions. A TGT is received once the proper credentials have been given to the Authentication Server.

Some other tickets:Proxy Ticket: Ticket that can be used by servers to represent the client against a back-end server

Forwardable Ticket: Ticket that delegates the task of obtaining tickets on behalf of the client




Notes: Components of Kerberos - Ticket

Ticket:A record that helps a client authenticate itself to a server. It contains the client's identity, a session key, a timestamp, and other information, all sealed using the server's secret key. It only serves to authenticate a client when presented along with a recently created Authenticator*.

Ticket Granting Ticket:A ticket that is created once initial authentication has been made. This allows for use of a temporary session key for further communication with the TGS instead of using the secret key for each request. The TGT usually has a time limit of 8-10 hours, where as the secret key would normally have a much longer lifetime.

Proxiable and proxy tickets:A proxiable ticket is a ticket granting ticket (TGT) that allows you to get a ticket for a service with IP addresses other than those in the TGT. Unlike forwardable tickets, you cannot proxy a new TGT from your current TGT; you can only proxy service tickets. Forwardable tickets let you transfer your complete identity (TGT) to another machine, where proxiable tickets only let you transfer particular tickets. Proxiable tickets allow a service to perform a task on the behalf of a principal. The service must be able to take on the identity of the principal for a particular purpose. A proxiable ticket tells the KDC that it can issue a new ticket to a different network address, based on the original ticket granting ticket. With proxiable tickets, a password is not required.

Forwardable tickets:Forwardable tickets allow a server to pass on the credentials of the requester to another service. For this to happen, the initial TGT must have been requested with the forwardable option and the server is allowed to delegate credentials An example where it might be used is when a user logs in to a remote system and wants authentication to work from that system as if the login were local.

* Authenticator: A record containing information that can be shown to have been recently generated using the session key, only known by the client and server. An authenticator consists of the above fields. (refer RFC1510 for exact specification).




This structure is the same for all tickets *

Details on "The Ticket" ...1

Version

RealmService

Flags

Session Key

Client Name

Client Realm

Transited

Auth. time

Start Time

End Time

Renew till

Client Address

Auth. data

Enc-part.Holds the encrypted part of the ticket.(Using the recipients secret key.)Flags.Various options that were set when the ticket was issued. Dictates what type of ticket this is.Key.The Session Key used between the client and server.crealm.The realm that initially authenticated the client.crname.The name of the clients principal identifier.transited.Realms that took part in authenticating the user.Authtime.Time of authenticationStartTime.The Start time for which the ticket is valid.EndTime.The time when the ticket expires.RenewTill.The 'final' end time if the ticket is renewable.CAddr.Address from which the ticket can be used.Authorization-data.(Optional) Field used for passing data from issuer to server/service.

tkt-vnoKerberos version used. (v.5)Realm.Name of the realm that issued the ticket.Sname.Server/Service Name the ticket is intended for.

*This graphic is simplified, please see RFC1510 for exact details.




Details on "The Ticket" ...2

Bit Flag Description.0 RESERVED Reserved for future expansion of this field.1 FORWARDABLE The FORWARDABLE flag is normally only interpreted by the TGS, and can be ignored by end servers. When

set, this flag tells the ticket-granting server that it is OK to issue a new ticket- granting ticket with a different network address based on the presented ticket.

2 FORWARDED When set, this flag indicates that the ticket has either been forwarded or was issued based on authentication involving a forwarded ticket-granting ticket.

3 PROXIABLE The PROXIABLE flag is normally only interpreted by the TGS, and can be ignored by end servers. The PROXIABLE flag has an interpretation identical to that of the FORWARDABLE flag, except that the PROXIABLE flag tells the ticket-granting server that only non- ticket-granting tickets may be issued with different network addresses.

4 PROXY When set, this flag indicates that a ticket is a proxy.5 MAY-POSTDATE The MAY-POSTDATE flag is normally only interpreted by the TGS, and can be ignored by end servers. This

flag tells the ticket-granting server that a postdated ticket may be issued based on this ticket-granting ticket.6 POSTDATED This flag indicates that this ticket has been postdated. The end-service can check the authtime field to see

when the original authentication occurred.7 INVALID This flag indicates that a ticket is invalid, and it must be validated by the KDC before use. Application servers

must reject tickets which have this flag set.8 RENEWABLE The RENEWABLE flag is normally only interpreted by the TGS, and can usually be ignored by end servers

(some particularly careful servers may wish to disallow renewable tickets). A renewable ticket can be used to obtain a replacement ticket that expires at a later date.

9 INITIAL This flag indicates that this ticket was issued using the AS protocol, and not issued based on a ticket-granting ticket.

10 PRE-AUTHENT This flag indicates that during initial authentication, the client was authenticated by the KDC before a ticket was issued. The strength of the preauthentication method is not indicated, but is acceptable to the KDC.

11 MAY-AUTHENT This flag indicates that the protocol employed for initial authentication required the use of hardware expected to be possessed solely by the named client. The hardware authentication method is selected by the KDC and the strength of the method is not indicated.

12-31 RESERVED Reserved for future use.

The following table is a list of the possible flags in a Kerberos version 5 ticket




2

Client

ClientName "TGS" Time

Stamp

as_req1

TGT Session Key

as_rep

KDC - ASnot an iSeries

1. AS_REQ

The client initiates a connection to the AS, requesting a TGT.

This request contains the client identity and the identity of the server.

2. AS_REP

The AS_REQ is compared with existing principals to retrieve the shared secret key. A normal response is a Ticket Granting Ticket (TGT) and a Session Key, which will be used for further communication with the KDC.

-- All encrypted with the client's secret key.

Example of a Kerberos Session ...1




3. TGS_REQ

When the client wants to initiate a connection with a service, the client first requests a Service ticket from the Ticket Granting Server (TGS).

This request consists of the service name, the TGT and an authenticator proving the identity of John.

4. TGS_REPThe TGS responds with a Service Ticket for the requested service and a Session Key.This response is encrypted with the Session key received earlier with the TGT.

ap_rep

TimeStamp 6

KDC (TGS)

Authenticator

ap_req

ServiceTicketService

Name

5

ServiceTicket

Session Key

tgs_rep4TGT Authenticator

tgs_req

ServiceName 3

Server_A

5. AP_REQThe client can now forward the service ticket, along with an authenticator. After the Server validates that the ticket came from the trusted third party, KDC, a session is established.

6. AP_REPOptionally, the client could require the server to authenticate itself by using the session key to encrypt a timestamp.

Example of a Kerberos Session ...2




Notes: Example of a Kerberos Session

1. AS_REQ: The client initiates a connection to the AS, requesting a TGT. Optionally, the server can require that the client preauthenticate himself by using the secret key* to encrypt a timestamp. The request sent contains the clients identity and the identity of the server** in clear text, and the optional encrypted timestamp.

2. AS_REP: The AS_REQ is compared with existing principals to retrieve the shared secret key. A normal response is a Ticket Granting Ticket (TGT) and a Session Key, which will be used for further communication with the KDC. All are encrypted with the client's secret key. By using a TGT, the client does not have to use it's own secret key every time a request is made for a new service. Usually the TGT has a lifetime of 8-10 hours.

These steps (3-5) are repeated for every new service requested.

3) TGS_REQ: When the client wants to initiate a connection with a service, the client first requests a service ticket from the Ticket Granting Server (TGS). This request consists of the service name, the TGT and an authenticator proving the identity of John. This transaction uses the session key the client received earlier from the AS_REP to encrypt the authenticator.

4) TGS_REP: The TGS responds with a Service Ticket for the requested service and a Session Key. This response is encrypted with the Session key received earlier with the TGT. Besides for the initial fields, the client will not be able to decrypt the service ticket. It can only be used to forward to the intended service. This is why the session key also is sent "outside" of the ticket for the client.

5) AP_REQ: The client can now forward the service ticket, along with an authenticator. After the Server validates that the ticket came from the trusted third party, KDC, a session is established. The client used the session key to encrypt the authenticator, which the Server is able to read once the ticket is decrypted.

6) AP_REP: Optionally, the client could require the server to authenticate itself by using the session key to encrypt a timestamp. This would prove that the Server actually managed decrypt the ticket, and was able to use the session key for response.

*The "secret key" is derived from the password that the user enters the first time he signs in to the Kerberos "service". In a Windows 2000 environment the secret key would be generated at the time of logging onto the Domain. Biometrics and smartcards could also be used to increase the security level of the client and storing the secret key.

** The TGS server, whose identity is 'krbtgt'.




Kerberos Limitations

Kerberos requires that the client is 'secure'Does not protect against Trojans or other password sniffing techniquesPutting all of your trust on the client security solution

Vulnerable to off-line brute-force and dictionary attacks

Not available 'everywhere' on any platform

Clients must use same time (skew of 5 min default)




Notes: Kerberos Limitations

Kerberos imposes a few assumptions on the environment in which it can properly function:

"Denial of service" attacks are not solved with Kerberos. There are places in these protocols where an intruder can prevent an application from participating in the proper authentication steps. Detection and solution of such attacks (some of which can appear to be not-uncommon "normal" failure modes for the system) is usually best left to the human administrators and users.

Principals must keep their secret keys secret. If an intruder somehow steals a principal's key, it will be able to masquerade as that principal or impersonate any server to the legitimate principal.

"Password guessing" attacks are not solved by Kerberos. If a user chooses a poor password, it is possible for an attacker to successfully mount an off-line dictionary attack by repeatedly attempting to decrypt, with successive entries from a dictionary, messages obtained which are encrypted under a key derived from the user's password.

Each host on the network must have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of "looseness" can be configured on a per-server basis. If the clocks are synchronized over the network, the clock synchronization protocol must itself be secured from network attackers.

Principal identifiers are not recycled on a short-term basis. A typical mode of access control will use access control lists (ACLs) to grant permissions to particular principals. If a stale ACL entry remains for a deleted principal and the principal identifier is reused, the new principal will inherit rights specified in the stale ACL entry. By not reusing principal identifiers, the danger of inadvertent access is removed.




EIM and Kerberos together

EIM Server

Registry: User: TypeDomServer John Smith Kerberos

ServerA JOHN OS/400

ServerB JOHN OS/400

IntraNet JohnS AIX

SysA JS50852 RACF


AS TGS

Identifier: John N. Smith

Source

Can I have a ticket

for SysA?

Sure. Here's my ticket,

can you let me in ?

Hey, who is this

John Smith ?

Why that's JS50852

Oh. Welcome JS50852

1

2

3

4 5

6

Target

Target

Target

Target

John

SysA




Assuming the client already has a TGT:

Credentials for a service is requested from the TGS.

A Service ticket is returned for Sys_A.

The client requests the service using the service ticket.

Sys_A, which is capable of handling EIM requests, uses EIM APIs to forward the user identity to the EIM server. The EIM Server looks at the 'source' user and registry to find an Identifier in the EIM database.

The EIM server returns the user ID for which that Identifier has a 'target' registry entry.

Sys_A opens the connection for John and lets him in as the RACF user JS50852, with appropriate authorizations.

Notes: EIM and Kerberos together




Cryptographic Hardware




New Cryptographic Hardware

(#4805) PCI CRYPTOGRAPHIC ACCELERATORIBM 2058 e-business Cryptographic Accelerator

Offers a large capacity for accelerating SSL transactions than currently supported 4758 e-business Cryptographic Coprocessor (Hardware Feature codes 4801, and 4802)

Minimal configuration and management effort required

Does not have some functions available with the IBM 4758, which has:Tamper-resistant storage for keysFinancial pin processing: Unique key per transaction (UKPT) Common Cryptographic Architecture (CCA) 2.4




Notes: New Cryptographic Hardware

(#4805) PCI CRYPTOGRAPHIC ACCELERATOR: Feature #4805 provides improved performance for high transaction rate secure web applications which use the secure sockets layer (SSL) or transport layer security (TLS) protocols. Establishing SSL/TLS secure web connections requires very compute intensive cryptographic processing. The Cryptographic Accelerator can be used to offload cryptographic processing. SSL/TLS secure web connections are typically used to protect information (e.g., credit card number) as it is transferred over the Internet -- for example between a web browser and a server.

The IBM 2058 e-business Cryptographic Accelerator (Hardware Feature code 4805, and hereafter referred as its internal IBM product feature number - as the 2058 Cryptographic Accelerator) is supported in V5R2, in addition to the 4758 Cryptographic Coprocessor.

Designed to improve iSeries performance by rerouting the processing of private keys away from the system processors, this hardware option is an excellent choice for iSeries implementations that handle high volumes of SSL (Secure Sockets Layer) transactions.

Note: While the 2058 Cryptographic Accelerator is an excellent choice for enhancing the SSL performance of iSeries servers, and is easy to install and initialize, it does not offer the wide range of configuration options that the 4758 Coprocessor offers.

The 2058 Cryptographic Accelerator provides a competitive option to customers who do not require the high security of a 4758 Cryptographic Coprocessor, but do need the high cryptographic performance that hardware acceleration provides to offload a host processor. The 2058 Cryptographic Accelerator has been designed to improve the performance of those SSL applications that do not require secure key storage. It does not provide tamper-resistant storage for keys, like the 4758 Cryptographic Coprocessor.

You can install up to four 2058 Cryptographic Accelerator cards in an iSeries server. The 2058 Cryptographic Accelerator provides special hardware which is optimized for RSA encryption (modular exponentiation) with data key lengths up to 2048 bits. The 2058 Accelerator uses multiple RSA (Rivest, Shamir and Adleman algorithm) engines.

The 2058 Cryptographic Accelerator requires the OS/400 V5R2M0 (Version 5 Release 2 Modification 0) software and the Cryptographic Access Provider 128-bit (5722-AC3) licensed program product must also be installed to enable the cryptographic functions in OS/400 that SSL also uses.




Notes: New Cryptographic Hardware -2

A single card high performance cryptographic adapter (standard PCI card):Is designed and optimized for RSA encryption Has Onboard hardware-based RNG (random number generator) Includes five mounted IBM UltraCypher Cryptographic Engines

For more information about the 2058 Cryptographic Accelerator, refer to the following pages within V5R2 iSeries Information Center: 2058 Cryptographic Accelerator features Cryptographic hardware scenario: Enhance iSeries SSL performance Plan for the 2058 Cryptographic Accelerator Configure the 2058 Cryptographic Accelerator

To use the 2058 Cryptographic Accelerator feature, you must create a Cryptography device description: Enter CRTDEVCRP DEVD(CRYPT01) RSRCNAME(XXXX01) PKAKEYFILE(*NONE) DESKEYFILE(*NONETEXT('*Cryptography Device')Use either the Vary Configuration (VRYCFG) or the Work with Configuration Status (WRKCFGSTS) CL commands to vary on the device once you have created the device description.

For digital certificates that are generated by software, and stored in software, OS/400 SSL automatically starts using the 2058 Cryptographic Accelerator once the device is varied-on. The private key processing associated with SSL and TLS session establishment is off-loaded to the 2058 Cryptographic Accelerator. When the device is varied-off, OS/400 SSL switches back to software based encryption for establishing SSL and TLS sessions, thereby placing the private key processing load back on the server.

Note: This is only true for certificates and private keys that were not created by the 4758 Cryptographic Coprocessor. If a certificate was generated using the 4758 Cryptographic Coprocessor, the 4758 Cryptographic Coprocessor has to be used for those SSL or TLS sessions which use that particular certificate.

The detailed Hardware presentation also has information on this new V5R2 support.See also:

V5R2 Information Center -> Networking -> Networking Security for additional detailsV5R2 Performance Capabilities manual at: http://www-1.ibm.com/servers/eserver/iseries/perfmgmt/resource.htm




Notes: New Cryptographic Hardware -3

The following is a general description of the two types of cryptographic algorithms: With a secret or symmetric key algorithm, one key is a shared secret between two communicating parties. Encryption and decryption both use the same key. The Data Encryption Standard (DES) and Triple DES are examples of secret key algorithms. With a public key or asymmetric key algorithm, a pair of keys is used. One of keys, the private key, is kept secret and not shared with anyone. The other key, the public key, is not secret and is shared with anyone. When data is encrypted by one of the keys, it can only be decrypted and recovered by using the other key. The two keys are mathematically related, but it is virtually impossible to derive the private key from the public key. The RSA algorithm is an example of a public key algorithm.

Both types of algorithms use keys to determine how to change the data. Different cryptographic processes use an algorithm to achieve one of several purposes such as message authentication and data encryption.




Financial pin processing: Unique key per transaction (UKPT)

Common Cryptographic Architecture (CCA) 2.4

4758 Cryptographic Coprocessor enhancements




The 4748 cryptographic coprocessor offers:Tamper-resistant hardware features Numerous configuration options, enabling you to customize its functions to fit your needs Provides secure key storage for applications and SSL transactions Offers a rich set of cryptographic functions for applications, including Triple-DES, RSA digital signature support, financial PIN processing, and robust key management services

The 4758-023 PCI Cryptographic Coprocessor supports DES, triple-DES, RSA, MD5, SHA-1, RIPEMD-160, and financial PIN services. In addition, it supports SET (Secure Electronic Transaction) block cryptographic services. The main benefit of the 4758 Coprocessor is that it provides the capability to store encryption keys. It does this in a tamper-responding, battery backed-up module, which is also referred to as the secure module. The 4758-023 PCI Cryptographic Coprocessor the Federal Information Processing Standard (FIPS) PUB 1400-1, Level 3 requirements. Another benefit of the 4758 Coprocessor is that it can be used to off-load the iSeries server main CPU from computationally-intensive cryptographic processing during the establishment of a SSL session.

The following resources for providing additional information relating to cryptographic concepts or hardware can be accessed directly from V5R2 iSeries Information Center :

IBM Redbooks(TM) IBM iSeries Wired Network Security: OS/400 V5R1 DCM and Cryptographic Enhancements

IBM Sources The IBM Cryptographic hardware site contains information on the 4758 Cryptographic Coprocessor hardware solution for iSeries servers. The CCA Basic Services Manual is intended for systems and applications analysts and application programmers who will evaluate or create programs for the IBM 4758 Common Cryptographic Architecture (CCA) support. The IBM PCI Cryptographic Coprocessor documentation library contains downloadable PDF documents that include general, support, and programming information for the 4758 Cryptographic Coprocessor. The IBM developerWorks site includes tutorials for cryptographic concepts, cryptography, and encryption.

Notes: 4758 Cryptographic Coprocessor enhancements




Service Tools




What is new in Service Tools ?

Terminology changed

Manage service tool user IDs from SST

Specify limited ability to change default and expired DST/SST passwords

Start service tools (STRSST) privilege added




Notes: What is new in Service Tools ?

Service tools are used to configure, manage, and service your server. Service tools can be accessed from dedicated service tools (DST) or system service tools (SST). Service tools user IDs are required to access DST, SST, and to use the iSeries Navigator functions for logical partition (LPAR) management and disk unit management.

Terminology changed:- Service tools user IDs have been referred to as DST user profiles, DST user IDs, service tools user profiles, or a variation of these names. Textual data and other documentation have been changed to reflect the new service tools terminology, specifically the use of the term service tools user IDs instead of previous uses such as DST user profiles, DST user IDs, service tools user profiles, or variations of these names.

Manage service tool user IDs from SSTService tools user IDs can now be managed and created from system service tools (SST). You no longer need to go into dedicated service tools (DST) to reset passwords, grant or revoke privileges, or create service tools user IDs. These functions can now be accessed from SST by selecting option 8 (Work with service tools user IDs) from the main SST display. If you want to create a service tools user ID or use the Work with service tools user IDs option from SST, the password for the service tools user ID you use to sign on must not be the default password. If you sign on to SST using a service tools user ID that has a default password and try to create a new service tools user ID or use the Work with service tools user IDs option, an error results.

Limited ability to change default and expired passwordsThe server is shipped with limited ability to change default and expired passwords. This means that service tools user IDs that have default and expired passwords cannot be changed through the Change Service Tools User ID (QSYCHGDS) API, nor can their passwords be changed through SST. A service tools user ID with a default and expired password can only be changed through DST. You can change the setting to allow default and expired passwords to be changed. Use SST or DST and select the Work with System Security option. From the Work with System Security display, change theAllow a service tools user ID with a default and expired password to change its own password field from No (the default) to Yes.

Start service tools (STRSST) privilege addedA new Start service tools (STRSST) privilege has been added. This privilege allows a service tools user ID to be created that can access DST, but can be restricted from accessing SST. Example you can create a user ID and revoke the privilege of the Start Service Tool function. This ID can be used in iSeries Navigator for Disk Functions but does not have access to the other service tool commands.




Miscellaneous

Enhancements to Digital Certificate Manager

Object Signing and signature verification

IP filtering and NAT

Secure Sockets Layer (SSL)

Audit file enhancements




Notes: Miscellaneous

Digital Certificate Manager (DCM): There are several new features for DCM. You can use the Assign a certificate task to more quickly and easily assign a certificate to one or more applications. You can now use DCM to sign command (*CMD) objects. You can choose the scope of the signature for these objects; you can choose whether to sign the entire *CMD object or to sign only the object's core components. Also, you can use two new APIs so that you can use your Local Certificate Authority (CA) to issue certificates to non-iSeries users. These APIs allow you to issue certificates to users without iSeries user profiles and without the users having to use DCM to individually obtain a certificate for client authentication.

Object signing and signature verification: OS/400 object signing and signature verification support now allows you to sign a larger variety of objects, such as command (*CMD) objects. When signing *CMD objects, you can choose whether to sign an entire object or to sign only the core components of an object. Also, you can now use iSeries Navigator Management Central to sign objects that you package and distribute to iSeries endpoint systems. Additionally, new APIs allow you to programmatically add a signature verification certificate to an iSeries server so that your install programs can verify signed objects as they are installed.

IP filtering and NAT: You can use a new, easy-to-use Packet Rules Editor to create your own filter rules file as an alternative to using property sheets. Also, there are three new wizards that you can use to create the appropriate set of filter rules for some common scenarios. These wizards include Permitting a service, Spoof protection, and Address Translation (which includes both mapping an address and hiding addresses). You can use these wizards to configure and create the filter and Network Address Translation (NAT) statements that you need. Also, there is support for creating packet rules files according to an XML data type definition, as well as a sample packet rules file that you can use to learn the proper syntax for creating packet rules. You can view the sample file in either the traditional .i3p format or the .xml format.

Secure Sockets Layer (SSL): You can use a new OS/400 Global Secure Toolkit (GSKit) API to create an asynchronous instance of a Secure Sockets Layer (SSL) session. This API provides a secure connection for handling multiple clients or if the number of incoming requests are high and require multiple jobs.

Audit file enhancements: There is a new outfile format, TYPE5, for the security audit journal. All new fields in existing records will only be added to the TYPE5 outfiles, and new audit records will only have TYPE5 outfiles. When you display the security audit journal, you can specify *TYPE5 as the outfile format for the journal. TYPE5 outfiles include remote IP information and thread IDs in the header portion of the security audit records. This data was added to the header portion of the audit record to keep the size of the records to a minimum. The remote IP information is helpful with intrusion detection and in determining the source of some actions on your system. The thread ID is useful for isolating actions within a thread in multi-threaded jobs. For more information refer to the Security Reference manual.




Trademarks and Disclaimers8 IBM Corporation 1994-2002. All rights reserved.References in this document to IBM products or services do not imply that IBM intends to make them available in every country.The following terms are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both:

cc:Mail, Domino.Doc, Freelance, LearningSpace, Lotus, Lotus Domino, Lotus Notes, iNotes, QuickPlace, Sametime, and Word Pro are trademarks of Lotus Development Corporation in the United States, other countries, or both.Tivoli and NetView are trademarks of Tivoli Systems Inc. in the United States, other countries, or both.C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. PC Direct is a trademark of Ziff Communications Company in the United States, other countries, or both and is used by IBM Corporation under license. ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. IBM's VisualAge products and services are not associated with or sponsored by Visual Edge Software, Ltd.Linux is a registered trademark of Linus Torvalds.UNIX is a registered trademark of The Open Group in the United States and other countries.SET and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product and service names may be trademarks or service marks of others.

Information is provided "AS IS" without warranty of any kind.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.

Information in this presentation concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products.

All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction.

Some information in this presentation addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning.

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here.

Photographs shown are of engineering prototypes. Changes may be incorporated in production models.

400 BRMS Host Integration Series JustMail Payment Manager Stylized ADSTAR Client Series Host on Demand MQSeries Payment Server SystemViewAdvanced Function Printing ClusterProven Host Publisher MQSeries Integrator PCOM VisualAge for JavaAFP CODE/400 HTTP Server for AS/400 Net.Commerce PowerPC VisualAge for RPGAIX DataGuide IBM Net.Data PowerPC AS WebSphereAnyNet DB2 IBM Logo Netfinity Print Service Facility WebSphere Advanced EditionApplication Development DB2 Extenders IBM Network Station NetView pSeries WebSphere Commerce SuiteAPPN DB2 UDB for AS/400 Information Warehouse NUMA-Q PSF WebSphere Development Tools for AS/400AS/400 DB2 Universal Integrated Language Environment OfficeVision S/390 WebSphere Standard EditionAS/400e e-business logo Intelligent Printer Data Stream OS/2 SanFrancisco WorkpadAT e(logo) Server IPDS Operating System/400 Screen Publisher xSeriesBrioQuery Enterprise Storage Server iSeries OS/400 SmoothStart


security - ibm

Documents