HP OpenVMS Systems Documentation

HP OpenVMS Version 8.2 New Features and Documentation Overview

This chapter describes significant new features of OpenVMS operating system associated products. For a listing and directory information about the OpenVMS associated products, refer to the Read Before Installing letter appropriate for your operating system.

5.1 ATI RADEON 7500 Graphics

OpenVMS Version 8.2 will provide support for 2D multi-head and 3D graphics on Integrity servers after the initial release of the operating system. Support is planned to be available in the first half of 2005 and will be announced on the OpenVMS Web site:

http://h71000.www7.hp.com/new/index.html

5.2 Common Data Security Architecture (CDSA) Now Supports a New Encryption Type

CDSA now supports a new encryption type as of CDSA Version 2.1 (OpenVMS Version 8.2). The Advanced Encryption Standard (AES) is now available as one of the standard Encryption types supported by the CDSA SSLeay Cryptographic Service Provider.

The following describes a simple AES encryption/decryption program that uses CDSA, along with the necessary files to build it on OpenVMS. The program consists of two source files (AES.C and DO_AES.C), and two build files (BUILD_AES.COM and AES.OPT). These files can be found in the CDSA AES example directory in SYS$COMMON:[SYSHLP.EXAMPLES.CDSA.AES] .

You must initialize CDSA before this program is run. This needs to be done on a one-time basis, by executing the following command:

$ @SYS$STARTUP:CDSA$INITIALIZE

To build the AES example program, copy the example files into a local build area and run the BUILD_AES command file, as follows:

$ copy SYS$SYSROOT:[SYSHLP.EXAMPLES.CDSA.AES]*.* local_build_area
$ SET DEF local_build_area
$ @AES_BUILD

You can run the resulting AES.EXE file as a foreign command by specifying the following:

$ AES :== $ local_build_area AES.EXE

The program can then be run with the following options:

-e : encrypt with supplied key (requires -k switch)
-d : decrypt with supplied key (requires -k switch)
-h : specifies that the supplied key is a 32,48, or 64 typed character hexadecimal number
-k key : use key "key" (single quotes are necessary if used with -h)

To encrypt MYFILE.TXT using an ASCII key with the AES example program, issue the following command:

$ aes -e -k "xyzzy" MYFILE.TXT MYFILE.AES

To decrypt the same file, you issue this command:

$ aes -d -k "xyzzy" MYFILE.AES MYFILE.TXT

To encrypt/decrypt using a hexadecimal (hex) key, use a key length of exactly 64 typed characters (32 hex bytes) and the -h switch, as follows:

$ aes -e -k 0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqr -h MYFILE.TXT MYFILE.AES
$ aes -d -k 0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqr -h MYFILE.AES MYFILE.TXT

To change this example to a 128- or 192-bit AES example, do following:

1. Edit aes.c
2. Change the key size from key[32] to:

   key[24] for 192-bit AES
   key[16] for 128-bit AES

3. Edit do_aes
4. Change key.KeyHeader.AlgorithmId = CSSM_ALGID_EVP_AES_256; to:

   key.KeyHeader.AlgorithmId = CSSM_ALGID_EVP_AES_192; for 192-bit AES
   key.KeyHeader.AlgorithmId = CSSM_ALGID_EVP_AES_128; for 128-bit AES

5. Rebuild

Kerberos Version 2.1 for OpenVMS is based on MIT Kerberos V5 Release 1.2.6 with CERT patches up to Release 1.2.8. Support for both Kerberos clients and servers is provided on OpenVMS I64, OpenVMS Alpha, and OpenVMS VAX.

New features in Kerberos for OpenVMS Version 2.1 include the ktutil command, which invokes a menu from which an administrator can read, write, or edit entries in a Kerberos V5 keytab or V4 srvtab file.

Kerberos performs authentication as a trusted third-party authentication service by using conventional (shared secret key) cryptography. Kerberos provides a means of verifying the identities of principals, without relying on authentication by the host operating system, without basing trust on host addresses, without requiring physical security of all the hosts on the network, and under the assumption that packets traveling along the network can be read, modified, and inserted at will. After a client and server have used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity.

For more detailed information, refer to HP Open Source Security for OpenVMS, Volume 3: Kerberos.

For information about downloading the latest version of Kerberos for OpenVMS, see the following World Wide Web address:

  http://h71000.www7.hp.com/openvms/products/kerberos/

For additional information about Kerberos, see the MIT Kerberos web site at the following World Wide Web address:

  http://web.mit.edu/kerberos/www/

HP SSL Version 1.2 is based on OpenSSL 0.9.7d. (Previous versions of HP SSL were based on OpenSSL 0.9.6g.) This release includes fixes to security vulnerabilities reported on September 30 and November 4, 2003, and March 17, 2004 at http://www.openssl.org/news/ .

Support for HP SSL is provided on OpenVMS I64, OpenVMS Alpha, and OpenVMS VAX.

New features in HP SSL Version 1.2 include OCSP (Online Certificate Status Protocol), AES (Advanced Encryption Standard), and Elliptic Curve cryptography. These features are described in the following list:

• OCSP (Online Certificate Status Protocol)
  The Online Certificate Status Protocol allows an application to more quickly determine the status of a certificate than it can by using Certificate Revocation Lists (CRLs). This is achieved by allowing the server or client application to request certificate status information from a Validation Authority (VA) in real time, rather than relying on CRL information that is issued from a Certificate Authority (CA) on a periodic basis (weekly or monthly). The VA and CA can be the same entity, but are not required to be.
• AES (Advanced Encryption Standard)
  The Advanced Encryption Standard (AES) is a new Federal Information Processing Standard (FIPS) Publication that specifies a cryptographic algorithm for use by U.S. Government organizations to protect sensitive (unclassified) information. The AES is also widely used on a voluntary basis by organizations, institutions, and individuals outside of the U.S. Government and outside of the United States. Rijndael has been selected as the AES algorithm.
  The AES was developed to replace DES, but Triple DES will remain an approved algorithm (for U.S. Government use) for the foreseeable future. Single DES is being phased out of use.
  The AES will specify three key sizes: 128, 192 and 256 bits. Assuming that one could build a machine that could recover a 56-bit DES key in a second, it would take that machine approximately 149 trillion years to crack a 128-bit AES key.
• Elliptic Curve cryptography
  Elliptic curves are simple functions that can be drawn as gently looping lines in the (x,y) plane. Elliptic curves can provide versions of public-key methods that, in some cases, are faster and use smaller keys, while providing an equivalent level of security. Their advantage comes from using a different kind of mathematical group for public-key arithmetic.
  RSA, SPEKE, Diffie-Hellman, and many other public-key methods can easily work with elliptic curves.

Secure Sockets Layer (SSL) is the open standard security protocol for the secure transfer of sensitive information over the Internet. HP SSL addresses these three fundamental security concerns about communication over the Internet and other TCP/IP networks:

• SSL server authentication
  Allows a user to confirm a server's identity. SSL-enabled client software can use standard techniques of public-key cryptography to check whether a server's certificate and public ID are valid and have been issued by a Certificate Authority (CA) listed in the client's list of trusted CAs. Server authentication is used, for example, when a PC user is sending a credit card number to make a purchase on the web and wants to check the receiving server's identity.
• SSL client authentication
  Allows a server to confirm a user's identity. Using the same techniques as those used for server authentication, SSL-enabled server software can check whether a client's certificate and public ID are valid and have been issued by a Certificate Authority (CA) listed in the server's list of trusted CAs. Client authentication is used, for example, when a bank is sending confidential financial information to a customer and wants to check the recipient's identity.
• An encrypted SSL connection
  Requires all information sent between a client and a server to be encrypted by the sending software and decrypted by the receiving software, thereby providing a high degree of confidentiality. Confidentiality is important for both parties to any private transaction. In addition, all data sent over an encrypted SSL connection is protected with a mechanism that automatically detects whether data has been altered in transit.

For more detailed information, refer to HP Open Source Security for OpenVMS, Volume 2: HP SSL for OpenVMS.

For information about downloading the latest version of HP SSL for OpenVMS, see the following World Wide Web address:

  http://h71000.www7.hp.com/openvms/products/ssl/

For additional information about OpenSSL, see the OpenSSL web site at the following World Wide Web address:

  http://www.openssl.org/

This release of OpenVMS includes a new version of TCP/IP Services for OpenVMS that supports I64 systems.

TCP/IP Services Version 5.5 is supported only with this release of OpenVMS and runs on both Alpha and I64 systems. VAX systems continue to be supported by TCP/IP Services Version 5.3. Note, in a cluster, use the corresponding version of TCP/IP that is appropriate for your version of the operating system. For information on cluster configurations and warranted pair support, refer to the Guidelines for OpenVMS Cluster Configurations.

The following new features are included in Version 5.5:

For further information about the enhancements and corrections in TCP/IP Services V5.5, refer to the TCP/IP Services V5.5 Release Notes.

This chapter provides the following information:

• HBMM configuration requirements
• HBMM restrictions
• HBMM in a mixed-version or mixed-architecture OpenVMS Cluster system
• Overview of full merge and minimerge operations
• Overview of host-based minimerge (HBMM)
• HBMM policy specification syntax
• Rules governing HBMM policies
• Guidelines for establishing HBMM policies
• Configuring and managing HBMM
• New system parameters that affect HBMM
• Use of /DEMAND_MERGE when HBMM is enabled
• Prioritizing merge and copy operations
• Visible impact of transient state events

In addition to the HBMM features, new capabilities for prioritizing merge and copy operations, as described in Section 6.12, are provided.

6.1 HBMM Configuration Requirements

The configuration requirements for enabling HBMM on an OpenVMS Cluster system are:

• In a cluster of Alpha and HP Integrity server systems, all HP Integrity server systems must be running OpenVMS I64 Version 8.2 and all OpenVMS Alpha systems must be running OpenVMS Version 7.3-2 or Version 8.2.
• In a cluster of Alpha and VAX systems, Alpha systems must be running OpenVMS Alpha Version 7.3-2 or higher and all VAX systems must be running OpenVMS VAX Version 7.3.
  For supported OpenVMS Cluster configurations of Alpha and HP Integrity server systems, refer to HP OpenVMS Version 8.2 New Features and Documentation Overview.
• Sufficient available memory to support bitmaps, as described in Section 6.5.1.

The following restrictions pertain to the configuration and operation of HBMM in an OpenVMS Cluster system.

6.2.1 Cluster Configuration Restrictions

An HBMM enabled shadow set can only be mounted on HBMM capable systems. However, systems running versions of OpenVMS that support write bitmaps can coexist in a cluster with systems that support HBMM, but these systems cannot mount an HBMM enabled shadow set. The following OpenVMS versions support write bitmaps but do not include HBMM support:

• OpenVMS VAX Version 7.3 systems
• OpenVMS Alpha Versions 7.2-2 through Version 7.3-2. (Version 7.3-2 supports HBMM if the Volume Shadowing HBMM kit is installed.)

For OpenVMS Version 8.2, the earliest version of OpenVMS Alpha that is supported in a migration or warranted configuration is OpenVMS Alpha Version 7.3-2.

HBMM can be used with all disks that are supported by Volume Shadowing for OpenVMS except disks on HSJ, HSC, and HSD controllers.

6.2.3 System Parameter Restrictions

Host-based minimerge operations can only take place on a system that has an HBMM master bitmap for that shadow set. If you set the system parameter SHADOW_MAX_COPY to zero on all the systems that have a master bitmap for that shadow set, HBMM cannot occur on any of those systems.

Furthermore, full merges will not occur on any of the other systems (that lack a master bitmap) on which the shadow set is mounted, even if SHADOW_MAX_COPY is set to 1 or higher.

If a merge is required on a shadow set that is mounted on some systems that have HBMM master bitmaps and on some systems that do not, then the systems that do not have an HBMM master bitmap will not perform the merge as long as the shadow set is mounted on a system with an HBMM master bitmap. See Section 6.12.8 for information on how to recover from this situation.

6.3 HBMM in a Mixed-Version or Mixed-Architecture OpenVMS Cluster System

HBMM is supported by OpenVMS Alpha Version 8.2 and OpenVMS I64 Version 8.2. HBMM is also supported by OpenVMS Alpha Version 7.3-2 with an HBMM kit.

HBMM does not require that all cluster members have HBMM support, but does require that all cluster members support write bitmaps.

Earlier versions of OpenVMS that support write bitmaps are:

• OpenVMS Alpha Version 7.2-2 and higher
• OpenVMS VAX Version 7.3

If a system in the cluster does not support write bitmaps, neither HBMM nor minicopy functionality can be used in that cluster. Furthermore, if a system that does not support write bitmaps joins a cluster whose members do support them, all existing HBMM and minicopy bitmaps are deleted.

Once an HBMM-capable system mounts a shadow set, and HBMM is enabled for use, only the cluster members that are HBMM capable can mount that shadow set.

Whereas minicopy requires that all cluster members have minicopy support, HBMM requires only that all cluster members support write bitmaps but does not require that they all support HBMM.

Enhanced Shadowing Features

To enforce this restriction (and to provide for future enhancements), shadow sets using the HBMM feature are marked as having Enhanced Shadowing Features. This designation is included in the SHOW SHADOW DSAn display, as are the particular features that are in use, as shown in the following example:

$ SHOW SHADOW DSA0
_DSA0:    Volume Label: TST0
  Virtual Unit State:   Steady State
  Enhanced Shadowing Features in use:
    Host-Based Minimerge (HBMM)

  VU Timeout Value      3600    VU Site Value          0
  Copy/Merge Priority   5000    Mini Merge       Enabled
  Served Path Delay     30

  HBMM Policy
    HBMM Reset Threshold: 50000
    HBMM Master lists:
      Any 1 of the nodes: RAIN,SNOW
    HBMM bitmaps are active on RAIN
    Modified blocks since bitmap creation: 254

  Device $252$DKA0
    Read Cost             2     Site 0
    Member Timeout        10

 Device $252$DKA100            Master Member
   Read Cost             501   Site 0
   Member Timeout        10
$

Once a shadow set is marked as using Enhanced Shadowing Features, it remains so until it is dismounted on all systems in the cluster. When you remount the shadow set, the features being requested will be reevaluated. If the shadow set is no longer using any enhanced features, then it will be noted on the display and this shadow set will be available for mounting even on nodes that do not support the enhanced features.

Systems that are not HBMM capable will fail to mount HBMM shadow sets. However, if HBMM is not used by the specified shadow set, the shadow set can be mounted on prior versions of OpenVMS that are not HBMM capable.

Mount Utility Messages

If a MOUNT command for an HBMM shadow set is issued on a system that supports bitmaps but is not HBMM capable, an error message is displayed. (As noted in Section 6.2, systems running versions of Volume Shadowing for OpenVMS that support bitmaps but are not HBMM capable can be members of the cluster with systems that support HBMM, but they cannot mount HBMM shadow sets.)

The message varies, depending on the number of members in the shadow set and the manner in which the mount is attempted. The mount may appear to hang (for 30 seconds or so) while the Mount utility attempts to retry the command, and then fails.

The errors that can be generated by the Mount utility failing to mount an HBMM shadow set include the following:

%MOUNT-F-DEVBUSY, mount or dismount in progress on device
%MOUNT-F-XSMBRS, maximum number of shadow members exceeded

A Mount utility remedial kit that eliminates the delay and displays a more useful message may be available in the future for earlier versions of OpenVMS that support bitmaps.

Once a shadow set is marked as an HBMM shadow set, it remains so marked until it is dismounted from all systems in the cluster. When you remount a shadow set, if it is no longer using HBMM, it can be mounted on prior versions of OpenVMS that are not HBMM capable.

6.4 Overview of Full Merge and Minimerge Operations

The purpose of either a full merge or minimerge recovery operation is to compare data on shadow set members to ensure that all of them contain identical data on every logical block. Each block is identified by its logical block number (LBN). During the recovery operation, application I/O continues but at a slower rate. A full merge or minimerge operation is managed by one of the OpenVMS systems that has the shadow set mounted. Throughout this manual, minimerge operation and merge operation refer to a minimerge recovery operation and a merge recovery operation, respectively.

A full merge or minimerge operation is initiated by any of the following events:

• A system failure results in the possibility of incomplete application writes.
• A shadow set enters mount verification and then times out or aborts mount verification, under certain conditions (as described in Section 6.4.2).
• A system manager issues a SET SHADOW/DEMAND_MERGE command.

When a system with a mounted shadow set fails, if a write request is made to a shadow set and the system fails before a completion status is returned to the application, the data might be inconsistent on the shadow set members:

• All members might contain the new data.
• All members might contain the old data.
• Some members might contain new data and others might contain old data.

The exact timing of the failure during the original write request determines the outcome. Volume Shadowing for OpenVMS ensures that corresponding LBNs on each shadow set member contain the same data (old or new), when the application issues a read to the virtual unit.