HP OpenVMS Systems Documentation
HP OpenVMS Version 8.2 New Features and Documentation Overview
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
For a hexadecimal key:
To change this example to a 128- or 192-bit AES example, do following:
key for 192-bit AES
key for 128-bit AES
key.KeyHeader.AlgorithmId = CSSM_ALGID_EVP_AES_192; for 192-bit AES
key.KeyHeader.AlgorithmId = CSSM_ALGID_EVP_AES_128; for 128-bit AES
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:
For additional information about Kerberos, see the MIT Kerberos web site at the following World Wide Web address:
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:
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:
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:
For additional information about OpenSSL, see the OpenSSL web site at the following World Wide Web address:
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:
|Libpcap Library and TCPDUMP updates||-- Support for libpcap API -- Support for TCPDUMP Version 3.8.3|
|IPv6 Configuration Support and Enhancements||-- The IPv6 configuration procedure has been enhanced to provide more configuration options. -- FailSAFE IP support for IPv6, including new ifconfig commands -- SSH support for IPv6 -- PATHWORKS Internet Protocol (PWIP) driver support for IPv6|
|Support for Network Time Protocol (NTP)||-- Supports NTP Version 4.2.0. Retains backward compatibility with NTP Version 3 and NTP Version 2, but not with NTP Version 1. -- Provides increased security over NTP Version 1.|
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:
The configuration requirements for enabling HBMM on an OpenVMS Cluster system are:
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:
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.
The inclusion in a cluster of a system that does not support write bitmaps turns off HBMM in the cluster and deletes all existing HBMM and minicopy bitmaps.
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
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:
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.
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.
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:
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:
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.
Volume Shadowing for OpenVMS guarantees that data is the same on all members of the shadow set, but it cannot guarantee that a write request that was in flight when a system failed is recorded on the shadow set. The volume might contain the data from the last write request, depending on when the failure occurred. In this regard, the shadow set does not differ from a nonshadowed device. The application should be designed to function properly in either case.