Security
With the announcement of IBM i 7.2, this release of IBM i provides significant new security enhancements and enhances many other integrated components and licensed programs that are security-related.
This chapter describes the following topics:
For more information about IBM i 7.2 security enhancements, see the IBM i Technology Updates developerWorks wiki:
4.1 Single sign-on
In IBM i 7.2, support was added to use a Kerberos ticket for automatic sign-on. Both the File Transfer Protocol (FTP) and Telnet servers are enhanced to support authenticating with Kerberos by using single sign-on (SSO).
There are new functions in the integrated IBM i security that enable SSO between a Kerberos-enabled FTP client and an IBM i FTP server and between a Kerberos-enabled Telnet client and an IBM i Telnet server. These functions open the door for more applications to participate in an SSO environment.
With Kerberos authentication, you can eliminate the exposure of transmitting passwords and data in the clear when using the FTP server with an FTP client that uses Kerberos authentication. The “Kerberized” FTP server, with Enterprise Identity Mapping, can support an SSO environment. For more information, see IBM Knowledge Center:
Figure 4-1 shows the Start TCP/IP Telnet (STRTCPTELN) CL command prompt. Notice the *KERBEROS option for the Remote user parameter.
                       Start TCP/IP TELNET (STRTCPTELN)
Type choices, press Enter.
ASCII full screen options . . . *NONE *NONE, *ALL, *LOCALECHO...
+ for more values
Display character attributes . . *YES *NO, *YES
ASCII page scroll feature . . . *NO *NO, *YES
ASCII answerback feature . . . . *NONE
ASCII tab stops . . . . . . . . *DFT 0-133, *DFT, *NONE
+ for more values
Coded character set identifier *MULTINAT 1-65533, *MULTINAT...
ASCII operating mode ID . . . . *VT220B7 *VT220B7, *VT220B8, *VT100...
Remote virtual display . . . . . *DFT Name, *DFT
Remote user . . . . . . . . . . *NONE Name, *NONE, *KERBEROS...
Remote password . . . . . . . . *NONE
Remote password encryption . . . *DES7 *DES7, *SHA1, *NONE
Remote initial program . . . . . *RMTUSRPRF Name, *RMTUSRPRF, *NONE
More...
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Figure 4-1 Start TCP/IP Telnet (STRTCPTELN) CL command prompt
Figure 4-2 shows the Start TCP/IP File Transfer (FTP) CL command prompt. Notice the *KERBEROS option for the Secure connection parameter.
                        Start TCP/IP File Transfer (FTP)
Type choices, press Enter.
Remote system . . . . . . . . .
 
 
Internet address . . . . . . . .
Coded character set identifier *DFT 1-65533, *DFT
Port . . . . . . . . . . . . . . *DFT 1-65535, *DFT, *SECURE
Secure connection . . . . . . . *DFT *DFT, *NONE, *SSL...
*IMPLICIT, *KERBEROS
Data protection . . . . . . . . *DFT *DFT, *CLEAR, *SAFE, *PRIVATE
Additional Parameters
Outgoing EBCDIC/ASCII table . . *CCSID Name, *CCSID, *DFT
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
More...
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys
Figure 4-2 Start TCP/IP File Transfer (FTP) CL command prompt
For more information about Telnet on IBM i, see IBM Knowledge Center:
For an example of creating an SSO test environment, see IBM Knowledge Center:
4.2 Password rule and user profile enhancements
In IBM i 7.2, the following systems values that are related to password rules were added or changed:
•New system values:
 – QPWDRULES: Define new password rules.
 – QPWDEXPWRN: Define the password expired warning interval.
 – QPWDCHGBLK: Prevent passwords from being changed repeatedly.
•Changed system values:
QLMTDEVSSN: Limit device sessions. The options are *NONE or 1 - 9 sessions.
The following user profile parameters are updated in IBM i 7.2:
•LMTDEVSSN: Limit device sessions (1 - 9 sessions).
•PWDCHGBLK: Block password changes (1 - 99 hours).
4.3 Intrusion detection
When an intrusion detection system (IDS) is active, it reports the suspected intrusions and extrusions that are defined by the enabled IDS policies. The production and service stacks detect these intrusions and extrusions. When an intrusion or extrusion event occurs that exceeds user-defined or default thresholds, IDS writes an intrusion monitor record to the audit journal, and optionally sends a notification to a message queue and sends an email message.
As shown in Figure 4-3, IDS behavior is defined as policies in a policy file, with audit events logged to the security audit journal. When an intrusion is detected, it is logged in the message queue and an optional email notification can be sent.
Figure 4-3 Intrusion detection implementation
An intrusion detection policy defines the parameters that the IDS uses to monitor for potential intrusions and extrusions on the system. If a potential intrusion or extrusion is detected, an intrusion event is logged in an intrusion monitor record in the security audit journal and displayed as intrusion events in the IDS GUI. Table 4-1 shows the format of an intrusion monitor journal record.
Table 4-1 Format of an intrusion monitor record in the security audit journal
Journal value
Description
P
Potential intrusion event detected.
2006-01-11-13.19.42.329688
Timestamp (11 Jan 2006, 13:19:42.329688).
1107
Detection point identifier.
02
Local address family.
119
Local port number.
9.5.92.48
Local IP address that is associated with the detected event.
02
Remote address family.
3511
Remote port number.
9.5.92.102
Remote IP address that is associated with the detected event.
SCANE
Probe type identifier (SCANE = Scan Event).
0020
Unique identifier for this specific intrusion event. You can use this identifier to correlate this audit record with other intrusion detection information.
For more information about IDS support on IBM i, see IBM Knowledge Center:
In IBM i 7.2, the following enhancements are enabled for IDS:
•Intrusion events that are detected or audited. This includes well-known attacks such as “Smurf”, “Fraggle”, ACK storms, address poisoning (both IPv4 ARP poisoning, and IPv6 neighbor discovery poisoning), and Ping-Of-Death, which can now be detected.
•Extrusions detected, which includes attacks, scans, and other traffic regulation anomalies initiating from your IBM i server, which can now be detected.
•IPv4 and IPv6 support.
•Real-time notification enablement that uses email, messages, and other options (for example, pagers and ISV solutions) can be used in addition to IM records for real-time notification. See Figure 4-4.
Figure 4-4 IBM Navigator for i GUI interface for the configuration of real-time notification
•Graphical User Interface (GUI) is available for the management of IDS policies and displaying intrusion events as an alternative to viewing the audit journal. See Figure 4-5.
Figure 4-5 IBM Navigator for i GUI interface for the configuration of IDS policies
4.4 Vector Scalar eXtension and cryptographic acceleration
In IBM i 7.2, POWER8 vector instructions can be used to improve the performance of cryptographic operations. In particular, Advanced Encryption Standard (AES) encryption and decryption performance for electronic codebook (ECB) and cipher-block chaining (CBC) modes were improved. These improvements are used by the internal software cryptographic library, and are automatically used for the particular cryptographic algorithms in the cryptographic services APIs and other system-provided encryption functions.
The use of vector instructions is not directly available, such as by using a new hardware provider that uses cryptographic services APIs. However, IBM i Portable Application Solutions Environment (PASE) applications can use Vector Scalar eXtension (VSX) instructions. This function can be unlocked when SLIC PTF MF58198 is applied.
POWER8 in-core cryptographic performance acceleration includes the following functions:
•Support within the processor itself. No additional products or hardware is required.
•Automatic performance acceleration for certain cryptographic algorithms (AES and SHA-2 message digest).
•Does not support cryptographic key storage. In some instances, the Cryptographic Coprocessor card still is required.
• Performance gains are realized in support of the following items:
 – Customer applications that use the cryptographic services APIs
 – Secure Sockets Layer (SSL)
 – Virtual Private Network (VPN)
 – Software tape encryption
POWER8 has enhanced Vector Scalar eXtension (VSX) capabilities, including new instructions to accelerate some frequently used cryptographic operations. VSX in Power Systems supports vector and scalar binary floating point operations conforming to the Institute of Electrical and Electronics Engineers Standard for Floating Point Arithmetic (IEEE-754).
VSX can be used to increase parallelism by providing single-instruction, multiple-data (SIMD) execution function for floating point double-precision operations, greatly improving the performance of some applications. IBM i PASE applications running on IBM i 7.2 with POWER8 processors can now take advantage of VSX.
IBM i 7.2 uses the enhanced POWER8 vector processing capabilities to accelerate AES cryptographic operations when operating in the POWER8 processor compatibility mode. Cryptographic services APIs, SSL, VPN, Backup Recovery and Media Services (BRMS) tape encryption, and SQL encryption functions automatically use POWER8 enhanced vector processing capabilities to deliver significant increases in performance.
For more information, see the following IBM i 7.2 and IBM POWER8 developerWorks article:
4.5 Cryptographic key management enhancements
A data encryption key can be used to encrypt important or sensitive data, such as social security numbers or credit card numbers, and should be well-protected, or the data will be at risk for exposure. It is considered a preferred practice to encrypt the data encryption key with a key encrypting key (KEK). A master key can then be used to encrypt all KEKs.
In IBM i 7.2, the following cryptographic key management enhancements are included:
•GUI and CL command interfaces to manage master keys
•GUI and CL command interfaces to manage keystores and keys:
 – Create keystore files
 – Create encryption keys
Managing master keys by using IBM Navigator for i
To manage master keys in IBM Navigator for i (see Figure 4-6), click Security → Cryptographic Services Key Management → Master Keys.
 
Note: The SAVRST Master Key is not yet set in the example that is shown in Figure 4-6. However, a default key is in place to provide minimal protection until the key is set. This means that the master keys are not “in the clear” on the SAVSYS tape, but any IBM i system can decrypt them.
Figure 4-6 Manage master keys in IBM Navigator for i
Creating keystore files by using IBM Navigator for i
Keystores are protected by master keys. A single keystore file can be encrypted only under one master key, but one master key can encrypt multiple keystore files.
KEKs and data keys are stored in the keystore file. A keystore is a database file with the normal file access methods disabled. Figure 4-7 shows an example of a keystore.
Figure 4-7 Keystore file
To create a keystore by using IBM Navigator for i, click Security → Cryptographic Services Key Management → Keystores. In the Manage Keystores window (Figure 4-8), click Create New Keystore to create a keystore file and then click Add Keystore to add encryption key entries.
In the example that is shown in Figure 4-8, the keystore Q1AKEYFILE in library QUSRBRM is for BRMS tape encryption. Application keystore files can be assigned any file name.
Figure 4-8 Create a keystore in IBM Navigator for i
4.6 Cryptography enhancements
This section describes the enhancements for cryptography, system values that are related to cryptography, and Digital Certificate Manager.
The following topics are covered in this section:
4.6.1 Default value for the QSSLPCL system value
The Secure Sockets Layer protocol system value, QSSLPCL, controls the TLS versions that are supported by system SSL, with the special value *OPSYS indicating the default behavior. In IBM i 7.2, the TLSv1.2 and TLSv1.1 protocols are on and SSLv3 is off by default. Changing the setting for QSSLPCL or the value of *OPSYS influences every system SSL-consuming application on the system.
When migrating from an earlier release, a user-defined QSSLPCL value is retained, preventing the new default behavior for this release from being in effect. In this case, after the migration, the system administrator can set the QSSLPCL system value to *OPSYS if its definition for the release meets their security policy requirements.
For information about how to determine the SSL protocol and cipher suite that are used for each system SSL connection to the IBM i, see the following website:
Here are the QSSLPCL *OPSYS definitions by release:
•IBM i 7.2: *TLSV1.2, *TLSV1.1, and *TLSV1
•IBM i 7.1: *TLSV1 and *SSLV3
If an application must continue to use SSLv3 with an IBM i 7.2 system, the administrator is forced to update the QSSLPCL system value to include *SSLV3. The application with a dependency on *SSLV3 can now be configured to allow *SSLV3. For the core IBM i networking applications, this task can be controlled by using the Digital Certificate Manager (DCM) Application Definition. If SSLv3 has been enabled, create an action plan to eliminate the external dependency on SSLv3 so it can be turned off again.
IBM i 7.2 enables TLSv1.2 and TLSv1.1 for applications that are coded to use TLSv1.0 because of the focus on improving the default security position without requiring client intervention.
 
Note: The possibility exists that an application’s internal code will not tolerate negotiation of a new protocol it does not know. In this situation, the mitigation is to turn off the new protocols at the application layer if possible. This task is accomplished through changing the application definition in DCM or by changing the application code to turn off explicitly TLSv1.2. The last option is to disable TLSv1.2 with QSSLPCL for the entire system until the application can be updated to tolerate TLSv1.2.
4.6.2 Cipher specification list changes
The Secure Sockets Layer cipher specification list system value, QSSLCSLCTL, determines who controls the values in system value QSSLCSL. The *OPSYS value indicates that the operating system determines the list and the *USRDFN value indicates that the system administrator controls the QSSLCSL values.
The new definition of the cipher suite list in QSSLCSL, when QSSLCSLCTL is set to *OPSYS, also has an impact on clients. QSSLCSL governs both the supported and default cipher suites. In IBM i 7.2, *OPSYS introduces over a dozen new cipher suites for the first time. The default cipher suites are a release-restricted subset of the supported cipher suites. Some cipher suites previously in the restricted default subset were removed from the subset. The order of some suites in the default subset also changed, which can impact which cipher suite is negotiated.
4.6.3 Elliptic Curve Cryptography
Elliptic Curve Cryptography (ECC) is a new function that is available for the first time with
IBM i 7.2. ECC is an asymmetric encryption algorithm, and in simplistic terms, it is similar to RSA. One the attributes of ECC is that it has smaller key sizes than RSA to obtain the same strength. ECC encompasses many different elliptic curve types, families, and strengths.
System SSL and DCM support five named elliptic curves:
•Secp521r1
•Secp384r1
•Secp256r1
•Secp224r1
•Secp192r1
All five of the named curves are enabled by default. System SSL support for one or more of the named curves can be disabled at the system level by using the System Service Tools advanced analysis SSLCONFIG command.
As it relates to TLS, there are two components to ECC:
•The first part of ECC is Elliptic Curve Digital Signature Algorithm (ECDSA) certificates. These certificates use ECDSA for the key type rather than RSA.
•The second part is the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange. The ephemeral part means that a key that is associated with a certificate is not used, but rather new anonymous key pairs are used for each handshake.
ECDHE does not use the key in the certificate, so it works with both RSA and ECDSA certificates. The keyword ECDHE in a cipher suite name indicates that ECDHE is used for the key exchange. The keywords RSA or ECDSA in the cipher suite indicate which certificate type to use. If ECDHE is not in the cipher suite name, this means that there is an unwritten RSA keyword to indicate RSA key exchange. RSA key exchange uses the key from the RSA certificate and does not work with ECDSA certificates. ECDSA certificates can be used only with the ECDHE key exchange.
The transition to ECDHE for the key exchange in TLS connections is painless. It requires that each side supports the same ECDHE cipher suite and has one supported named curve in common. The server’s ordered cipher suite list also must prefer the ECDHE cipher suite over any RSA key exchange cipher suites for it to be selected.
The transition to ECDSA is more complicated because in addition to the ECDHE requirements, ECDSA requires a new certificate be generated and assigned to the application. A server application cannot migrate from RSA certificates to ECDSA certificates until all of its potential clients can negotiate ECDSA and ECDHE cipher suites. This is a long-term consideration when negotiating with previous IBM i releases that do not support ECC.
4.6.4 Multiple server certificates
To assist with the interoperability issues of migrating to ECDSA certificates, IBM i 7.2 server applications can now have multiple server certificates that are assigned at one time. The new multiple certificates infrastructure supports up to four concurrent certificates, although two certificates are typical. An administrator rolling out the use of ECDSA assigns both an RSA certificate and an ECDSA certificate to the server configuration.
Servers with a DCM application definition use the DCM Update Certificate Assignment window to assign multiple certificate labels. GSKit based servers can configure multiple certificate labels to be used by setting the GSK_KEYRING_LABEL_EX attribute.
The Telnet server DCM Update Certificate Assignment window is shown in Figure 4-9. In this example, Telnet has one certificate that is assigned, although the four certificates with the check mark next to the label names are about to be assigned instead.
 
Note: Assigning two or more certificates that have the exact same cryptographic properties adds unnecessary processing because only the first one (as determined internally) is selected.
The certificate that is selected for a secure connection is determined by the server configuration that is paired with each client’s advertised capabilities. The certificate selection logic is deterministic and is described in detail in IBM Knowledge Center:
Figure 4-9 Digital Certificate Manager: update certificate assignments
4.6.5 Digital Certification Manager local certificate authority
IBM i 7.2 DCM supports creating ECDSA local certificate authorities (CAs) and ECDSA certificates. Multiple local CAs can exist on the same partition, and which one signs a new certificate is selected when the certificate is created.
An RSA server certificate can be signed by an ECDSA CA and vice versa. An early phase of the rollout of ECDSA can include signing an ECDSA server certificate with an existing RSA local CA. The peer clients (user PCs) trust the new certificate chain because they already trust the root RSA local CA. Otherwise, the new ECDSA local CA must be distributed to all the peers so they can trust a pure ECDSA certificate chain.
4.6.6 Default cipher specification list
As mentioned in 4.6.3, “Elliptic Curve Cryptography” on page 218, the list of values for the QSSLCSL system value when QSSLCSLCTL is *OPSYS changed in IBM i 7.2.
The default cipher suites for each release are shown in Figure 4-10 as the shaded values. A system administrator can alter the default list for the system in three ways:
•If a default cipher suite is removed from the QSSLCSL list, it is no longer supported, which removes it from the default list at the same time.
•For the default cipher suites, the order they appear in the list is the order they are preferred by server applications. By rearranging the order in QSSLCSL, the order is changed for all applications that use the default list.
•If a default suite is added or removed from the eligible default cipher suite list by using the System Service Tools (SST) Advanced Analysis Command (SSLCONFIG), the SSLCONFIG option –eligibleDefaultProtocols changes which cipher suites are shaded in Figure 4-10.
The SSLCONFIG command is described in more detail in IBM Knowledge Center:
 
Figure 4-10 Default IBM i 7.2 ciphers
As shown in Figure 4-10 on page 221, four new ECDHE_ECDSA_AES-based cipher suites are positioned first. This is the first time a new cipher suite is added to the top position in the list. This positioning is due to this set of cipher suites remaining dormant for a server until the administrator assigns an ECDSA certificate. If an administrator goes to the effort to configure ECDSA, it is assumed they want it to be used whenever possible.
Because ECDHE requires no explicit configuration, the ECDHE_RSA_AES based cipher suites are positioned after the RSA_AES set to prevent a new (to System SSL) cipher suite from being the primary cipher suite that is used by most of the server applications without administrator action.
When migrating from an earlier release, a user-defined QSSLCSL value is retained to prevent the new cipher suites from being supported. In that case, after the migration, the system administrator can set QSSLCSLCTL to *OPSYS to have QSSLCSL primed with the new list. Working with the full list, the administrator can then modify the list as needed to meet their security requirements.
4.6.7 Signature and hash algorithms
The TLSv1.2 protocol made the signature algorithm and the hash algorithm that are used for digital signatures independent attributes. In previous protocol versions, the negotiated cipher suite and certificate determined these algorithms.
System SSL has a default ordered list of allowed signature/hash algorithm pairs. The list serves two purposes for TLSv1.2 and has no meaning for prior protocols:
•The first use is that the ordered signature algorithm list is sent to the peer when the System SSL requests a certificate during the handshake. The peer uses the received list to guide its certificate selection process when it has more than one certificate from which to pick.
•The second use is that the list of algorithm pairs restricts which signature and hash algorithms can be used for handshake message signatures. A TLSv1.2 handshake message signature algorithm can be different from the signature algorithm of the certificate that is used for the session. For example, the handshake message can be protected by SHA512 even though an MD5 certificate is selected for the session. This increases the security attributes of the handshake without requiring a new certificate.
There are two methods of setting this list for an application:
•Applications with a DCM application definition can use the DCM Update Application Definition window to configure the list.
•GSKit based applications can configure the list by setting the GSK_SSL_EXTN_SIGALG attribute.
There is no system value for this property, but the entries in the system list can be removed or reordered by using SSLCONFIG. Anytime a value is removed from a supported list, the potential exists to introduce interoperability issues. The typical user does not care about this list, but it might be important for the most restrictive security policies.
Here is the IBM i 7.2 default System SSL signature algorithm list:
•ECDSA_SHA512
•ECDSA_SHA384
•ECDSA_SHA256
•ECDSA_SHA224
•ECDSA_SHA1
•RSA_SHA512
•RSA_SHA384
•RSA_SHA256
•RSA_SHA224
•RSA_SHA1
•RSA_MD5
4.7 DB2 security
DB2 security enhancements are described in Chapter 8, “IBM DB2 for i” on page 321, which includes the following topics:
4.8 Networking security
Security improvements in networking are described in Chapter 5, “Networking” on page 225, which includes the following topics:
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.172.220