AIX 5L Version 5.2 and pSeries: 2002 Technical Update ... IBM AIX/aix52... · The standard approach at the operating system level has been to create an entirely new operating system

© Copyright IBM Corp. 2002

ibm.com

International Technical Support Organization

AIX 5L Version 5.2 and pSeries: AIX 5L Version 5.2 and pSeries: 2002 Technical Update Presentation2002 Technical Update Presentation

SecuritySecurity

1 AIX52_Security.PRZ 24.10.02

ibm.com/redbooks© 2002 IBM Corporation

SecuritySecurity

Enterprise Identity Mapping (EIM)

Public Key Infrastructure (PKI) Authentication

PAM Support

Kerberized Secure rcmds enhancement

Cryptographically secure pseudo-random number generator (PRNG)

Internet Key Exchange (IKE)

Common Criteria Security Evaluation


IBM®



AIX 5L Version 5.2 and pSeries: 2002 AIX 5L Version 5.2 and pSeries: 2002 Technical Update PresentationTechnical Update Presentation

SecuritySecurityEnterprise Identity Mapping (EIM)Enterprise Identity Mapping (EIM)

POR:AUM:DDK3 AIX52_Security.PRZ 24.10.02


Enterprise Identity Mapping (EIM)An infrastructure enablement that provides API's to write applications that generalize identity mapping function for the enterprise

Can be utilized on IBM iSeries, pSeries, zSeries platforms over their own user security management system.

Objectives:Enable the creation of heterogeneous cross-platform operating system function and applications that don’t force administrators to manage additional user registries and security semantics

IBM provides API's for: creating, changing, retrieving, removing identity mapping information

Enable IBM and business partners to build a single-point-of-management “enterprise user management” applications.

IBM provides API's needed to create, change, remove local user identities residing in IBM defined user registries

These set of APIs rely on infrastructure built on top of LDAP and Kerberos

POR:AUM:DDK

SecuritySecurity



Enterprise Identity Mapping (EIM)Advantages of Application EIM Enablement:

Simplifies user's logon (Dealing with one user ID only)Save administrator valuable time for other task within the enterprise

Enterprise user management interface to see all of the user's identities in the enterprise

POR:AUM:DDK

SecuritySecurity



Notes:Notes:

EIMOverview The Mulitple User Registry ProblemSince the second computer was built, the industry began laying the foundation of a fundamental problem -- multiple user identities in multiple user registries for a single individual or entity within an enterprise.

Standard Approaches Used Today: The standard approach to the problem of multiple user registries for applications has been tocreate a new application specific user registry and oftentimes a new set of security semantics. This allows the application provider to effectively ignore the multiple user registry problem but doubles the work load of the security administrator. Existing data on a system is already protected by an existing user registry and its associated security semantics. By creating a new registry and newsemantics, that existing data must be secured by the new semantics as well -- not to mention that users of the new application have yet another identity to be managed by both the user and the administrator.

The standard approach at the operating system level has been to create an entirely new operating system. DCE along with DFS is an example of this. Since user registries are an integral part of legacy operating systems like OS/390, AIX, and OS/400, the cost of changing their user registries is very high.

The advent of network security authentication protocols such as Kerberos, Lotus Notes, and PKI based authentication also creates new user registries. To effectively deal with these protocols without rewriting operating systems and while continuing to exploit, operating system security mechanisms requires the ability to map from an identity in one of these registries to an associatedidentity in a user registry of choice for the application. For example, a Kerberos ticket provides network authentication, but in order to access data in an AS/400 database under AS/400 security semantics, one must be able to map the Kerberos principle identity to an AS/400 user profile identity.

Enterprise Identity Mapping (EIM): EIM is different approach to the old problem. EIM accepts the fact that multiple user registriesexist and will continue to exist in an enterprise. Rather than trying to hide the problem by defining yet another user registry and a new set of security semantics, EIM attempts to make it easier for operating systems, applications, and administrators to manage multiple identities.



Notes:Notes:

EIM

The EIM infrastructure provides an alternative to the standard approaches being used today. By using the EIM APIs, operating system function and applications can choose to use any registry for authentication and then “map” that identity to an associated identity in another user registry in order to access data. For cross-platform applications, the user registry of choice will likely be a network authentication registry such as Kerberos or digital certificates. The EIM infrastructure allows the use by applications of alternative user registries for authentication, while minimizing the overhead of using them for security administrators.

EIM Objectives:Enterprise Identity Mapping (EIM) infrastructure has two primary objectives: 1) enable the creation of heterogeneous cross-platform operating system function and applications which don’t force administrators to manage additional user registries and security semantics 2) enable SWG/Tivoli and business partners to build a single-point-of-management “enterprise user management” applications.

To accomplish these objectives, AIX Version 5.2 provides two sets of EIM APIs:- One set will deal with creating, changing, retrieving, removing identity mapping information -- in other words, the APIs necessary for achieving objective 1.- The other set of APIs will provide the function needed to create, change, remove local user identities residing in IBM defined user registries which achieves objective 2. Both sets of APIs will rely on infrastructure built on top of LDAP, and the LDAP protocol, and legacy interfaces to each platform’s user registry function (user profile SPI’s and APIs for AS/400, RACF interafaces for OS/390, and user registry interfaces for AIX).

API's libraryFileset: bos.eim 5.2.0.0 Enterprise Identity MappingFiles located at: /usr/ccs/lib/libeim.a



SecuritySecurity

Enterprise Identity Mapping (EIM)

Johnny

JohnnySJSmith

iSeries AIX 5L zSeries

UserRegistry

LocalUser Identity

Security Admin./User

EIM API' s and LDAP

Global UserJohn Smith

Johnny

JohnnySJSmith

iSeries AIX 5L zSeries

UserRegistry

LocalUser Identity

Security Admin./User

EIM API' s and LDAP

JohnnyJohnnyS

JSmith ???

Non-EIM EIM



Notes:Notes:EIMUsing Enterprise Identity Mapping

The EIM architecture describes the relationships between individuals or entities (such as file servers and print servers) in the enterprise and the many identities that represent them within an enterprise. In addition, EIM provides a set of APIs that allow applications to ask questions about these relationships.

For example, given a person's user identity in one user registry, you can determine which identity in another user registry represents that same person. If the user has authenticated with one identity and you can map that identity to the appropriate identity in another user registry, the user does not need to provide credentials for authentication again. You need only know which identity represents that user in another user registry. Therefore, EIM provides a generalized identity-mapping function for the enterprise.

The ability to map between a user's identities in different registries provides many benefits. Primarily, applications can have the flexibility of using one registry for authentication while using an entirely different registry for authorization. For example, an administrator could map an SAP identity (or better yet, SAP could do the mapping itself) to access SAP resources.

Identity mapping requires that administrators do the following:

1.Create EIM identifiers that represent people or entities in their enterprise. 2.Create EIM registry definitions that describe the existing user registries in their enterprise. 3.Define the relationship between the user identities in those registries to the EIM identifiers that they created.



Notes:Notes:

EIM

Using Enterprise Identity Mapping

No code changes are required to existing registries. Mappings are not required for all identities in a user registry. EIM allows one-to-many mappings (in other words, a single user with more than one identity in a single user registry). EIM also allows many-to-one mappings (in other words, multiple users sharing a single identity in a single user registry, which although supported is not advised for security reasons). An administrator can represent any user registry of any type in EIM.

EIM does not require copying existing data to a new repository and trying to keep both copies synchronized. The only new data that EIM introduces is the relationship information. Administrators manage this data in an LDAP directory, which provides the flexibility of managing the data in one place and having replicas wherever the information is used.

For more information about Enterprise Identity Mapping, refer to the following Web site:

http://publib.boulder.ibm.com/eserver/


IBM®




Security EnhancementSecurity EnhancementPKI AuthenticationPKI Authentication

POR:4WX,84D11 AIX52_Security.PRZ 24.10.02


SecuritySecurity

Public Key Infrastructure (PKI) AuthenticationTechnology providing a framework for security services based on public key cryptography which can be implemented in a distributed computing environment.PKI provides:

Key managementCertificate managementPolicy managementRepository access

Core PKI Components:End-Entities (EE)Certificate Authority (CA)Certificate Repository (CR)Registration Authority (RA)Digital Certificates (X.509 V3)



Notes:Notes:

PKI

CA (Certificate Authority)The CA job is to check an individual 's credential by demanding physical proof of identity. When the CA is satisfied with the individual's proof of identity, it issues a digital certificate. (US Post Office, VeriSign etc.)CA's issue, store and typically publish certificate. A common place to publish certificate is on a LDAP server since LDAP allows for easy acces to community oriented data.CA's also handle revocation of certificate, and management of the Certificate Revocation List (CRLs); certificate no longer valid.CA's have their own certificate, to allow CA's to identify each other in peer-to-peer communication.




SecuritySecurity



Notes:Notes:End-Entity (EE)

An End-Entity is defined as a user of PKI certificates and/or end-user system that is the subject of a certificate. In other words, in a PKI system, End-Entity is a generic term for a subject that uses some services or functions of the PKI system, which may be a certificate owner (human being or organization or some other entities), or a requestor (it might be application program) forcertificate or CRL.

Certificate Authority (CA) The Certificate Authority (CA) is the signer of the certificates. The CA, often together with the RA (Registration Authority, has the responsibility of the certificate subject entity's identification. The logical domain in which a CA issues and manages certificates is called security domain, which might be implemented to cover an organization, company, a large department, a test cell, or another logical community in real cases. A CAs primary operations include certificate issuance, certificate renewal, and certificate revocation.

Certificate issuance A CA creates a digital certificate by signing it with its digital signature. Basically, a public and private key pair is generated by a requesting client (EE). The client then submits a request for certificate issuance to the CA. The certificate request contains at least the client’s public key and some other information, such as the client’s

name, e-mail address, mail address, or other pertinent information. When an RA is established, the CA delegates the client verification process or other management functions to the RA. After the client request isverified, the CA creates the digital certificate and signs it. As an alternative to the above, a CA can generate a client’s key pair and, subsequently, the signed certificate for clients. This process, however, is seldom implemented because the private key needs to be forwarded from the CA to the client, which can be a weak link. It is generally considered more secure when the clients generate their key pairs, in which case, the private keys never leave their area of authority.

In order for a PKI system to work completely, the basic assumption is that any party who wishes to verify a certificate must trust its digital signer CA. In PKI, “A trusts B” means that “A trusts the CA that signed B’s certificate”. In general, “A trusts CA” means that “A” holds a copy of the CA’s certificate locally. In case of secure HTTP using SSL, for example, most commonly used Web browsers have a list of several trustworthy CA certificates already incorporated when they ship, such as for VeriSign, Entrust, IBM World Registry, and others. If a Web server uses a certificate that is signed by such a trusted CA, clients are automatically considered to trust the server, unless the client intensionally deletes the signer CA certificate.

A CA can issue several kinds of certificates, including:

User certificates User certificates may be issued to an ordinary human being or other entities, such as servers and applications. They are trusted end-entities for the CA. An RA should also have this certificate. A user certificate may be limited to e-mail, servers, or for other specific purposes. CA certificates When a CA issues a certificate for itself, it is called a self-signed certificate,or root certificate forthatCA. If a CA issues a certificate for a subordinate CA,

the certificate is also called a CA certificate.

Cross certificate Cross certificates are used for cross-certification,whichis an authentication process across security domains. Certificate renewal Every certificate has a validity period with an expiration date associated with it. When a certificate expires, a renewal process may be initiated and,

upon positive approval, a new certificate will be issued to the End-Entity. Certificate revocation The maximum lifetime of a certificate is its expiration date. In some cases, however, a certificates needs to be revoked before its expiration date.

When this happens, the CA posts the certificate to a Certificate Revocation List (CRL). (To be more precise, the CA posts the certificate’s serial number, along with some other information, to the CRL.) Clients that need to know the validity of a certificate can search the CRL for any revocation notice.



Notes:Notes:The Certificate Repository (CR) The CR (Certificate Repository) is a store of issued certificates and revoked certificates in a CRL. Although a CR is not a required

component in a PKI system, it significantly contributes to the availability and manageability of a PKI system. Because the X.509 certificate format is a natural fit to an X.500 directory, a CR is best implemented as a directory and it is then able to be accessed by the dominant Directory Access Protocol, the Lightweight Directory Access Protocol (LDAP). RFC 2587, Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2, defines the access method to a repository with which an End-Entity or a CA can

retrieve or modify the certificate and CRL information stored in a CR. Thus, a CR can be accessed with LDAP commands or procedures, such as bind, search or modify, and unbind.In RFC 2559, Internet X.509 Public Key Infrastructure LDAPv2 Schema,the attributes and object classes to be supported by an LDAP server acting as server of a CR are defined. The latest LDAP is Version 3, and the new Internet Draft based on LDAP V3 is in the process of being finalized at the time of writing. With the new LDAP V3 protocol, we can expect some improvements, such as UTF-8 exploitation, flexible security mechanism, or better scalability of a CR server.

Although not recommended, there are alternative methods to obtain certificate or CRL information if a CR is not implemented in a directory. However, after considering the requirements that a CR must meet, it turns out that a directory is actually the best place to store CR information. Such requirements include easy accessibility, standards-based access, up-to-date information storage, built-in security (if required), data management issues, and possible merge with similar data. CR makes a CRL distribution system design quite simple. Furthermore, the simplicity and flexibility of LDAP makes a CR more applicable for many purposes.

The Registration Authority (RA) The Registration Authority (RA) is an optional component in PKI. In some cases, the CA incorporates the role of an RA. Where a separate RA is used, the RA is a trusted End-Entity certified by the CA, acting as a subordinate server of the CA. The CA can delegate some of its management functions to the RA. For example, the RA may perform personal authentication tasks, report revoked certificates, generate keys, or archive key pairs. The RA, however, does not issue certificates or CRLs.X.509 certificates X.509 is the most widely used certificate format for PKI, being used in major PKI-enabled protocols and applications, such as SSL, IPSec, S/MIME,Privacy

Enhanced Mail (PEM), or SET. A rare example of one that does not support X.509 certificate format is Pretty Good Privacy (PGP), which uses its own certificate format. Initially, X.509 V1 appeared in 1988 as ITU-T definition. X.509 V2 supports new fields over Version 1; they are issuer and subject identifier.The latest X.509 V3 was defined in 1996, which introduced the extension field. Currently, many PKI deployment applications are based on X.509 V1 or V2, but the PKI technology direction trends clearly to X.509 V3 based implementation. (See Figure 9)

Certificate data is written in abstract syntax notation 1 (ASN.1) syntax rule as can be seen in figure "ASN 1. representation of a certificate). It is then converted into binary data along with ASN.1 distinguished encoding rules (DER). ASN.1 is a data description language and defined as X.208 and X.209 standard by the ITU-T. This operation enables certificate data independent from each platform’s encoding rule. In some fields of a certificate, an object identifier (OID) is used to represent the specific series of parameter values. For example, in Figure "ASN.1 representation of a certificate", you can see the AlgorithmIdentifier for signatureAlgorithm, which actually consists of an object identifier (OID) and optional parameters. This OIDrepresents a specific algorithm used for digital signatures of the certificate issuer (CA). The application that verifies the certificate’s signature has to understand the OID that represents the encryption algorithm and message digest algorithm, along with other information.



Notes:Notes:Extensions Extensions are new fields that were introduced in X.509 V3 and they add flexibility to certificates. One problem, however, is that an extension does not always

have a clear definition of its usage; the exploitation of extension fields is, therefore, to a certain degree, subject to the freedom of the implementor. The IETF PKIX working group aims to fix this situation and to make X.509 V3 certificates a more clearly-defined standard. In RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, several extensions’ usages are defined and they are called standard extensions. Standard extensions are minimum requirements for PKIX standard conforming applications. Such applications still have the freedom to implement some proprietary extensions other than standard extensions. IBM Trust Authority 3.1, which is explained later in this book, uses three extension categories: standard extensions (PKIX-conforming standard extension), common extensions (extensions that are unique to Trust Authority) and private extensions (extensions available for each application’s private use).

Each extension field contains a boolean field that marks it as critical or not. If an extension is marked as critical, a certificate using the system must be able to recognize the field; otherwise, it must reject the certificate. The following extensions should be critical or must be critical:

Key Usage (KeyUsage) Key usage defines the purpose of the key contained in the certificate, such as digital signature, key encipher, data encipher, and so on. This field should be critical. Subject alternative name (subjectAltName) Subject alternative name defines additional identities of a certificate private key owner (subject of certificate). subjectAltName might be an e-mail address, DNS name, IP address, or other defined name that can be used to specify the certificate owner. If this field is provided, a CA (or RA) must do verification of it in the certificate issue process. This field must be critical. Basic constraints (BasicConstraints) Basic constraints is used for a CA certificate and is not used in an End-Entity certificate. It relates to certification paths and designates the subordinate CA certificate number to End-Entity certificate. If the pathLenConstraint value in BasicConstraints is 0, the CA private key can be used only for End-Entity certificates. If the number is 1, the CA has a maximum of 1 subordinate CA between itself and an End-Entity in the certification paths. This field must be critical. Name constraints (NameConstraints) Name constraints are also used for a CA certificate and designates which naming patterns are acceptable in its subordinate name space. This constraint is applicable to the certificate subject name, that is, the subject’s distinguished name (DN) and subject alternative name in the certificate extension. For example, a CA with NameConstraints as ou=abc,o=ibm,c=us will issue certificates for End-Entities whose subject DN is cn=mike smith, ou=abc,o=ibm,c=us but will not be able to issue certificates for another End-Entity whose DN is cn=ken brown,ou=xyz,o=ibm,c=us. This field must be critical.

The above standard extension fields are considered especially important in the PKIX standard. Besides the above fields, other standard extensions are defined: Authority Key Identifier (authorityKeyIdentifier), Subject Key Identifier (keyIdentifier), Private Key Usage Period (PrivateKeyUsagePeriod), Certificate Policies (certificatePolicies), Policy Mappings (PolicyMappings), Issuer Alternative Names (IssuerAltName), Subject Directory Attributes (SubjectDirectoryAttributes), Policy Constraints (PolicyConstraints), extended Key Usage Field (extKeyUsage), and CRL Distribution Points (cRLDistributionPoints). These are described in RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

Certificate classes The certificate class is a generally acceptable idea to distinguish each certificate’s level of trust. VeriSign’s certificate classification is a famous example, and currently, VeriSign has four levels of certificate classes, class1 through class4. The major difference between each certificate class is its registration process (and, thus, the level of trust). A class1 certificate is limited to an individual only. For business entities, such as a Web server certificate, at least a class3 certificate must be required. The usage rules are defined in VeriSign’s Certificate Practice Statement (CPS). You can access VeriSign’s CPS as follows:

http://www.verisign.com/repository/CPS

The class1 certificate registration process only requires a user name and an e-mail address to identify a user. Class1 certificates can be used to secure e-mail messages. As the number of certificate classes increases, the registration process becomes more strict. Most implementations incorporate different certificate classes for the different usages of certificates. For more infomration please refer to Redbook:SG24-5512-00 Deploying a Public Key Infrastructure



Notes:Notes:




SecuritySecurity

Simple Hierarchical Structure

CA-1

CA-6CA-5

User A User B



Notes:Notes:

Figure "Simple hierarchical Structure" shows an example of a simple hierarchy. In this example, CA-1 is a root Certificate Authority that signs (certifies) the public keys of CA-5 and CA-6. CA-5 is a Certificate Authority that issues certificates to a user, user A. CA-6 is a Certificate Authority that issues certificates to user B. Suppose that user A wanted to communicate with user B. User A could send his or her certificate to user B. However, user B does not trust user A’s CA directly. In order to establish trust, the users can find a CA that they both trust, namely CA-1.

This is the essence of a hierarchy; CAs certify each other up and down a hierarchy, building a chain of relationships. This is sometimes referred to as achain of trust. Therefore, user A and user B can scan the hierarchy until they find a CA that they both trust. Users can then authenticate each others publickeys using the CA certificates issued by the trusted CA (CA-1). This process is sometimes referred to as certification path processing.

Organizations will want to and should maintain the management and administration authority of their security domains. In the above diagram, CA-5 and CA-6 are still in control of the administration of their respective security domains. If, however, administration of a security domain is transferred to acentral authority, for instance, then administration of the domains could become very complex as the hierarchy grows. Local administration makescertificate management easier.

There are a number of hierarchy structures that have been proposed. These range from strict hierarchies requiring that everybody needing a certificateeventually trust one authority at the root of the hierarchy (PEM, RFC 1422) to proposals by the IETF to eliminate hierarchies altogether (SPKI). Currently,CAs are cross-certifying each other in order to gain interoperability in the marketplace. As the number of CAs increases, a more hierarchical model could be introduced in order to address scalability concerns.

Others

For more information on PKI, please refer to SG24-5765-02 AIX Version 5.2 Differences Guide at http://www.redbooks.ibm.com




AIX 5L Version 5.2 providesCertificate Authentication Service. V5.2 performs account authentication using Public Key Infrastructure (PKI) certificates.When PKI is chosen as the authentication mechanism, PKI x509 certificates are issued by local "CA". An existing AIX user can request certificates for account authentication. When a user authenticates to AIX using a PKI certificate, the authentication certificate is associated with the user's running process as a proof of user identity. Certificate-based login is performed through AIX Loadable Authentication Modules mechanism. A set of command line tools is provided to manage certificates. The PKI functions of AIX are deployed only in the integrated presence of IBM Directory.

SecuritySecurity




SecuritySecurity

POR:4WX,84D

IBM

CAS LDAPCertificatesCertificatesCertificates

KEYSTORE FILE

tim?

tim?

You are timAccess granted

Login:timPassword:xxx

KEYMATCH ?

1- User Provides user ID and Password2- CAS locates the user's certificate and keystore based on the user's account name3- CAS obtains the certificate's matching private key from the user's keystore using user password4- Signs a data item with the user's private key, and check for the signature using user's public key from the certificate.




PackagingDirectory Services 4.1 (Base Operating System)

Server and Client Utilities for maximum encryption(128bits) (Exp.Pack)DB2 for LDAP (Base Operating System) Java 1.3.1 (Base Operating System)Java 1.3.1 maximum encryption (Expansion Pack)CAS (Certificate Authority Service) (Expansion Pack)

SecuritySecurity




Client/Server Model Server side (cas.server)

Creating and maintaning X.509 V3 Certificate and Certificate Revocation List (CRL)Typically one CA for the entire organization

Client side (cas.client)Contains the software (commands, libraries, load module and configuration files) required by every system participating in PKI authentication.

SecuritySecurity




New Set of Commands

SecuritySecurity

POR:4WX,84D

Certificate Administration Commands:

certaddcertcreatecertdaemoncertdeletecertgetcertlistcertpasswdcertrevokecertverify

User Administration Commands:

chuserloginlsusermkuserpaginitpaglistpasswdpagdelrmuser




Creating PKI user AccountsAIX user management commands have been enhanced to support PKI authentication.Administrator creates new PKI user accounts using the AIX mkuser commands

Once created, each account has a certificate and a private keystore.Administrator supplies the keystore passwords to the new user and new users can then login to the system and change their keystore password

SecuritySecurity

POR:4WX,84D

Note: Existing account can be converted to PKI account too.



Security Enhancement: PKI AuthenticationSecurity Enhancement: PKI Authentication

POR:4WX,84D

A way of checking

PKI Authentication

User Creation Example

# mkuser -R PKIfiles SYSTEM=PKIfiles registry=PKIfiles test1

# certlist -f ALL test1test1: auth_cert=auth_cert distinguished_name=c=us,o=mycompany.example,ou=cert,cn=test1 [email protected] validafter=0830091302 validuntil=0827152403 issuer=c=us,o=mycompany.example,ou=cert tag=auth_cert verified=true label=DefaultLabel keystore=file:/var/pki/security/keys/test1 serialnumber=07


IBM®




Security EnhancementSecurity EnhancementPAM supportPAM support

POR:94U28 AIX52_Security.PRZ 24.10.02


Security Enhancement :PAM supportSecurity Enhancement :PAM supportWhat is new in AIX Version 5.2?

AIX/PAM fully integrated PAM applications have access to aix security services

Portability from other PAM enable platformApplications that use AIX security interface can access PAM modules

Cutomize AIX security services with existing PAM modulesPAM libraries allows developer to create modules that are not AIX specific

How is it Implemented? PAM to AIX is implemented with pam_aix module which is configured in /etc/pam.confAIX to PAM is implemented with the PAM load authentication module and configured in /usr/lib/security/methods.cfg

This integration allows commonplace components of the AIX system, such as login, su, and ftp to access PAM services and for PAM-enabled applications to access AIX security services.



Security Enhancement :PAM supportSecurity Enhancement :PAM supportWhat is new in AIX Version 5.2 ?

System administrators can perform the following tasks: Choose any authentication service available on a system to perform end-user authentication for an application

PAM configuration file /etc/pam.conf Use multiple authentication services thus providing a means of integrating authentication technologies with system-entry services.Dynamicaly configure an aplication's authentication service without having to modify it.



Security Enhancement :PAM supportSecurity Enhancement :PAM support

PAM Support provided by IBM in Base Operating System

Located at:/usr/include/security/pam_appl.h

/usr/include/security/pam_modules.h

/usr/lib/nls/msg/en_US/libpam.cat

/usr/lib/security/pam_aix

/usr/lib/libpam.a



Notes:Notes:

PAM OverviewBackgroundPluggable Authentication Modules (PAM) is a system which defines a set of functions to provide authentication, password management, and session management services, accomplished through a configurable set of loadable modules. This has been accomplished on AIX through the Universally Extensible Security Scheme (UESS), a proprietary scheme, providing a rich set of authentication and user database services. PAM has emerged as an industry standard, used on a variety of UNIX-like operating systems and with a diverse range of modules written for it.

The Open Group has published a PAM standard in its X/Open Single Sign-on Service (XSSO), with which AIX seeks to conform, available at:

http://www.opengroup.org/onlinepubs/008329799/

Current AIX PAM OfferingPAM functionality is provided by a library which is called by applications and manages PAM transactions, providing infrastructure to manage transactions and have the appropriate modules perform the requested operations. This was delivered in AIX 5.1, however the AIX security services do not utilize its services, so it cannot be used by the standard AIX programs for services such as login, su, ftp, etc.

AIX 5.2 PAM IntegrationPAM services is access through the AIX security interface (UESS) and conversely to provide access to AIX security services (UESS and compat) through the PAM interface. This will result in a degree of integration that allows commonplace components of the AIX system, such as login, su, ftp, etc., to access PAM services, and conversely PAM enabled applications to access AIX security services. Practically, this means that if properly configured, an user defined through a PAM module could login to AIX through any of the standard services and that a PAM application, for example a FTP daemon, could access users defined in through an UESS service without modification. This is accomplished with a UESS module that calls PAM and a PAM module (pam_aix) that callsthe AIX security interfaces.

POR:94U

-



Notes:Notes:UESS ModuleOverviewThe UESS module provides applications calling the AIX security interfaces access to PAM services by implementing UESS interfaces which perform operations supported by PAM by calling the appropriate PAM interfaces. Each call establishes a PAM transaction, provides any necessary information to PAM, calls the interface which performs the required action, and terminates the PAM transaction. Due to the limited scope of PAM as compared to UESS, the UESS module is an authentication only module, implementing the following interfaces:method_authenticate(), method_chpass(), method_passwdexpired(), andmethod_passwdrestrictions().



Notes:Notes:

AIX security services can be configured to call PAM modules through the use of the existing AIX loadable authentication module framework. When the /usr/lib/security/methods.cfg file is set up correctly, the simple load module PAM will route AIX security services (passwd, login, and so on) to the PAM library. The PAM library will check the /etc/pam.conf file to determine which PAM module to use and then make the corresponding PAM SPI call. Return values from PAM are mapped to AIX error codes and returned to the calling program.

The following figure shows the path an AIX security service call will take when PAM is properly configured. The PAM modules shown (pam_krb, pam_ldap, and pam_dce) are listed as examples of third party solutions.



Notes:Notes:

PAM is a simple load module that is installed in the /usr/lib/security directory and is an authentication only module. The PAM module must be combined with a database to form a compound load module. The following example shows the stanzas that could be added to the methods.cfg file to form a compound PAM module with a database called files. The BUILTIN keyword for the db attribute will designate the database as UNIX files.

PAM: program = /usr/lib/security/PAM

PAMfiles: options = auth=PAM,db=BUILTIN

Creating and modifying users is then performed by using the -R option with the administration commands and by setting the SYSTEM attribute when a user is created.

mkuser -R PAMfiles SYSTEM=PAMfiles registry=PAMfiles pamuser

This act will inform further calls to AIX security services (login, passwd, and so on) to use the PAM load module for authentication. While the files database was used for the compound module in this example, other databases, like LDAP, can also be used if they are installed. Creating users as previously described will result in the following mapping of AIX security to PAM API calls:

AIX PAM API ===== ========= authenticate --> pam_authenticate chpass --> pam_chauthtok passwdexpired --> pam_acct_mgmt passwdrestrictions --> No comparable mapping exists, success returned



Notes:Notes:

Customizing the /etc/pam.conf file allows the PAM API calls to be directed to the desired PAM module for authentication. Stacking can be implemented in order to further refine the authentication mechanism.

Data prompted for by an AIX security service is passed to PAM through the pam_set_item function because it is not possible to accommodate user dialog from PAM. PAM modules written for integration with the PAM module should retrieve all data with pam_get_item calls and should not attempt to prompt the user to input data as this is handled by the security service.

Loop detection is provided to catch possible misconfiguration in which an AIX security service is routed to PAM and then a PAM module in turn attempts to call the AIX security service to perform the operation. Detection of this loop event will result in an immediate failure of the intended operation. Note: The /etc/pam.conf file should NOT be written to make use of the pam_aix module when using PAM integration from an AIX security service to a PAM module as this will result in a loop condition.



Notes:Notes:

The pam_aix module is a PAM module that provides PAM-enabled applications access to AIX security services by providing interfaces that call the equivalent AIX services where they exist. These services are in turn performed by a loadable authentication module or AIX builtin function based on the users definition and the corresponding setup in methods.cfg. Any error codes generated during execution of an AIX service are mapped to the corresponding PAM error code.The following shows the path a PAM application API call will follow if the /etc/pam.conf file is configured to make use of the pam_aix module. As shown in the diagram, the integration allows users to be authenticated by any of the loadable authentication modules (DCE, LDAP, or KRB5) or in UNIX files (compat).



Notes:Notes:

The pam_aix module is installed in the /usr/lib/security directory. Integration of the pam_aix module requires that the /etc/pam.conf file be configured to make use of the module. Note that stacking is still available but chosen not to be shown in the following simple example of the /etc/pam.conf file:

# Authentication managementOTHER auth required /usr/lib/security/pam_aix# Account managementOTHER account required /usr/lib/security/pam_aix # Session managementOTHER session required /usr/lib/security/pam_aix # Password managementOTHER password required /usr/lib/security/pam_aix

The pam_aix module has implementations for the pam_sm_authenticate, pam_sm_chauthok and pam_sm_acct_mgmt SPI functions. The pam_sm_setcred, pam_sm_open_session, and pam_sm_close_sessionSPI are also implemented in the pam_aix module, but these SPI simply return PAM_SUCCESS invocations.



Notes:Notes:

The following is a rough mapping of PAM SPI calls to the AIX security subsystem:

PAM SPI AIX ========= ===== pam_sm_authenticate -->authenticate pam_sm_chauthtok -->passwdexpired, chpass Note: passwdexpired is only checked if the PAM_CHANGE_EXPIRED_AUTHTOK flag is passed in. pam_sm_acct_mgmt --> loginrestrictions, passwdexpired pam_sm_setcred --> No comparable mapping exists, PAM_SUCCESS returned pam_sm_open_session --> No comparable mapping exists, PAM_SUCCESS returned pam_sm_close_session --> No comparable mapping exists, PAM_SUCCESS returned

Data intended to be passed to the AIX security subsystem may either be set using the pam_set_item function prior to module use or the pam_aix module will prompt for data if it does not already exist.


IBM®




POR:AUK

Security EnhancementSecurity EnhancementKerberized secure rcmds enhancementKerberized secure rcmds enhancement



Security Enhancement:Security Enhancement:Kerberized secure rcmds enhancementKerberized secure rcmds enhancementSecure rcmds command

Updated to support native Kerberos and GSSAPI librariesDCE (Distributed Computing Environment) independent

Does not require DCE installed when using native KerberosDynamically linked to NAS (Network Authentication Services) librarySecure rcmds command can authenticate against:

DCEKerberos Version 5Kerberos Version 4Native Kerberos Version 5

To enable secure rcmds to use KerberosInstall and configure the NAS client

krb5.client.rte filesetSet the authentication method to Kerberos Version 5 and standard AIX

POR:AUK41 AIX52_Security.PRZ 24.10.02


Security Enhancement:Security Enhancement:Kerberized secure rcmds enhancementKerberized secure rcmds enhancement

Examples:Set the authentication method to Kerberos version 5 and standard AIX

# chauthent -k5 -std

List authentication methods currently configured

# lsauthent

Kerberos 5 Standard Aix



Notes:Notes:

Note: To use the secure rcmd with DCE, DCE version 2.2 or higher must be installed. The only supported version of DCE, for use with the secure rcmds is version3.2 or higher

If NAS client is not configure, the following message appears

Kerberos 4 permited on SP system onlyKerberos 5_DCE requires DCE version 3.2 or greaterKerberos 4,Kerberos 5_DCE and Kerberos 5 requires krb5.client.rte version 1.3

To Configure NAS, please refer to "IBM NAS Administrator's and user's guide" locate at fileset krb5.doc.XX_XX.html. Where XX_XX is the character string representing your languagge code, for example U.S Englis is en_US.


IBM®




POR:9VP

Security EnhancementSecurity EnhancementCryptographically secure Cryptographically secure

pseudo-random number generator pseudo-random number generator (PRNG)(PRNG)



Security Enhancement: Cryptographically secure Security Enhancement: Cryptographically secure Pseudo-Random Number Generator (PRNG) Pseudo-Random Number Generator (PRNG)

The PRNG is based on Yarrow engineCollect entropy from the running system and feed an entropy pool to seed a PRNGThe process select three hardware devices upon startup

SSA, Ethernet, SCSI Adapter, etc.The process detects hardware interrupts or network packets

Determined time between two events. (This timing is put into the entropy pool)

The engine Support API Very simple to use

Application must open the /dev/random or /dev/urandom to read

POR:9VP

Acumulate Pool Reseed key Generatepseudo-ramdom

Output

unpredictable

input



Notes:Notes:

AIX 5L Version 5.2 now supports a cryptographically secure pseudo-random number generator (PRNG). Random numbers are extremely important for any sort of cryptographic application. Random numbers are used to generate session keys, salts used for hashed passwords and initializing public key certificates. If the generated random numbers are easily predictable, any application using those insecure numbers is also insecure. No algorithms or protocol can fix problems with random number generation.

The PRNG on Version 5.2 is based on the Yarrow engine and collects entropy from the running system and feeds an entropy pool to seed a PRNG. The entropy gathering process selects three hardware devices upon startup such as, SSA, ethernet and SCSI adapters. The entropy gathering daemon detects hardware interrupts or network packets and determines the times between two events. These timings are then put into the entropy pool.

The API for accessing the PRNG is quite simple. An application just has to open the /dev/random or /dev/urandom file and read the required number of bytes the special device. The /dev/random and /dev/urandom have different behaviors when the pool of entropy is exhausted or required reseeding. The /dev/random device will have the reading application block until more entropy is gathered. The /dev/urandom device will behave the same as /dev/random but when entropy is exhausted it will fallback and generate entropy using a software algorithm. The level of randomness of the numbers generated by the software algorithm is not as high as the entropy gathered from the running system.

The PRNG automatically keeps the entropy pools replenished and reseeds it occasionally. When the entropy pool is half empty, the entropy gatherer will intercept the hardware interrupts and network packets until the entropy is replenished. There is a slight performance penalty, while entropy is being gathered. When the pools are full, the entropy gathering process goes idle and no longer effects machine performance.For more information on the Yarrow engine please refer to the Counterpane Labs Home Page at the following URI:http://www.counterpane.com/yarrow.html



Security Enhancement: Cryptographically LibrarySecurity Enhancement: Cryptographically Library

AIX 5L Version 5.2 now include criptographic library V5.2Up-to-Date cryptographic functions.

POR:9VP-2

Rijndael (128-bit block cipher) 28, 192, 256 bitsSEAL (stream cipher) 160 bitsMars (128-bit block cipher) 128, 192, 256 bitsTwofish (128-bit block cipher) 128, 192, 256 bitsMD5 (cryptographics hash generator

128 bits

SHA-1 (cryptographic hash generator

160 bits

Algorithms Key length



Notes:Notes:

The licensed product packages (LPP) for Cryptographics Library v5.2 areincluded on the AIX expansion Pack.

Filesets:modcrypt.base.includes contains the xcrypt.h header filemodcrypt.base.lib contains the libmodcrypt.a library file


IBM®




SecuritySecurityInternet Key Exchange (IKE)Internet Key Exchange (IKE)



Security Enhancement:Internet Key ExchangeSecurity Enhancement:Internet Key Exchange (IKE) (IKE)

IKE components (IKE)Now uses the system wide pseudo-ramdom number generator (PRNG) as the random number source.

/dev/random virtual device

POR:CTX50 AIX52_Security.PRZ 24.10.02


Notes:Notes:

There are several places in the Internet Key Exchange (IKE) protocol that need random numbers. As a security protocol, these numbers must be as random as possible. Any detectable pattern in the random numbers can make it easier to mount an attack on data encrypted under this protocol. Since there is a new pseudo ramdom number generator (PRNG), IKE is being modified to use it.

The /dev/random virtual device produces cryptographically secure pseudo-random numbers generator



Security Enhancement:Internet Key ExchangeSecurity Enhancement:Internet Key Exchange (IKE) (IKE)

New features to the IP security :The first feature is to add Diffie-Helllman Group 5 support.

Currently supports DH Groups 1 &2. Cisco and Linux have incorporated DH group 5.

The second feature is to create a generic data management tunnel support.

Support IKE peers which get IP addresses dynamically assigned (DHCP). This feature allows a user to create a generic data management tunnel default (phase 2) policy to allow a customer to configure an IKE tunnel without a predefined IP address.

POR:9NZ52 AIX52_Security.PRZ 24.10.02


Notes:Notes:

The AIX IKE (Internet Key Exchange) has now been enhanced to support Diffie-Hellman (GH) group 5. Prior releases of the AIX only supported DH group 1 and 2. Diffie-Hellman key exchange is a public key cryptosystem where public values are exchanged to arrive at a symmetric key among the end entities. The OAKLEY Key Determination Protocol defines 5 well known DH groups. Each DH group defines a prime and a generator function to create symmetric key. DH groups 1, 2 and 5 are all MODP (modular exponentiation group primes) with 768, 1024 and 1536 bit respectively. Since DH group 5 has greater entropy then DH groups 1 and 2, symmetric keys generated from DH group 5 will be more secure but require more processing time.

For further references please check:

SG24-5765-02 AIX Version 5.2 Differences Guide

At http://www.redbooks.ibm.com


IBM®




Security EnhancementSecurity EnhancementCommon Criteria Security EvaluationCommon Criteria Security Evaluation

POR:A6V54 AIX52_Security.PRZ 24.10.02


Security Enhancement:Security Enhancement:Common Criteria Security EvaluationCommon Criteria Security Evaluation

Prior to AIX 5L Version 5.2Customer required special CD' (CC_EVAL, previously C2)Install during Basic Operating System (BOS) Install

AIX 5L Version 5.2Does not required special CD's (Located on standard BOS CD's)Option of the Advanced option menu

Install option available only if overwrite install is selected.Install only in 64 bit systemJFS2 will be set to yes (Requires 64 bit kernel enabled)English laguage is also set to yesTrusted Computing Base is also required

Can be installed from CD's or NIM

When "Enable CAPP and EAL4+ Technology" is selected all the required options are set automatically






Notes:Notes:

Prior to Version 5.2 it was necessary to install common criteria security code from the Bonus CDs. Version 5.2 allows Controlled Access Protection Profile and Evaluation Assurance Level 4+ (CAPP/EAL+) to be selected in the “More options” screen on the install menu. The code is now located on the standard BOS CDs.

This option is available for new and complete overwrite install only and the system has to be 64-bit enabled and installed with the 64-bit kernel, JFS2 enabled and trusted computing base is also required. If CAPP/EAL+ is selected, trusted computing base, the 64-bit kernel and the enabled of JFS2 filesystems are automatically selected. The install language is set to English.



Documents

AIX 5L Version 5.2 and pSeries: 2002 Technical Update ... IBM AIX/aix52... · The standard approach at the operating system level has been to create an entirely new operating system