Release 8.0
A58229-01
 Library |
 Product |
 Contents |
 Index |
| Oracle Advanced Networking Option Administrator's Guide Release 8.0 A58229-01 |
|
This chapter includes the following sections:
The configuration instructions assume that your Net8 network software has already been installed and is running. For more information about Net8, refer to the Oracle Net8 Administrator's Guide.
Refer to Appendix A, "Encryption and Checksum Parameters" for examples of encryption and checksumming parameters in configuration files.
Note:
You can install and configure the Oracle Advanced Networking Option with other Oracle networking products and configure everything at once, or you can add the Oracle Advanced Networking Option to an already existing network.
This guide contains generic information on how to configure your already-existing Net8 network to use the Oracle Advanced Networking Option. It is meant to be used in conjunction with the guide that describes how to install and configure the Oracle Advanced Networking Option on your particular platform.
This release of the Oracle Advanced Networking Option provides support for 128-bit encryption with the RSA RC4 algorithm. This feature provides very strong encryption security for transmitted data. Following is a discussion of the benefits of using one algorithm over another.
The Oracle Advanced Networking Option for Domestic Use provides the DES (Data Encryption Standard) algorithm for customers with specialized encryption needs. DES has been a U.S. government standard for many years and is sometimes mandated in the financial services industry. In most specialized banking systems today, DES is the algorithm used to protect large international monetary transactions. The Oracle Advanced Networking Option allows this high-security system to be used to protect any kind of application, without any custom programming.
In a secure cryptosystem, the plaintext (a message that has not been encrypted) can not be recovered from the ciphertext (the encrypted message) except by using the secret decryption key. In a "symmetric cryptosystem", a single key serves as both the encryption and the decryption key. DES is a secret-key, symmetric cryptosystem: both the sender and the receiver must know the same secret key, which is used both to encrypt and decrypt the message. DES is the most well-known and widely-used cryptosystem in the world. It has never been broken, despite the efforts of researchers over the last 15 years.
The DES40 algorithm, available internationally, is a variant of DES in which the secret key is preprocessed to provide 40 effective key bits. It is designed for use by customers outside the USA and Canada who want to use a DES-based encryption algorithm. This feature gives commercial customers a choice in the algorithm they use, regardless of their geographic location.
The RC4 algorithm, developed by RSA Data Security Inc., has quickly become the de-facto international standard for high-speed data encryption. Despite ongoing attempts by cryptographic researchers to "crack" the RC4 algorithm, the only feasible method of breaking its encryption known today remains brute-force, systematic guessing, which is generally infeasible. RC4 is a stream cipher that operates at several times the speed of DES, making it possible to encrypt even large bulk data transfers with minimal performance consequences.
RC4 is a variable key-length stream cipher. The Oracle Advanced Networking Option for Domestic Use, release 8.0, offers an implementation of RC4 with 56 bit and 128 bit key lengths. This provides strong encryption with no sacrifice in performance when compared to other key lengths of the same algorithm.
Oracle has obtained special license to export the RC4 data encryption algorithm with a 40-bit key size to virtually all destinations where other Oracle products are available. This makes it possible for international corporations to safeguard their entire operations with fast, strong cryptography.
The secrecy of encrypted data is dependent on the existence of a secret key shared between the communicating parties. Providing and maintaining such secret keys is known as "key management". In a multi-user environment, secure key distribution may be difficult; public-key cryptography was invented to solve this problem. The Oracle Advanced Networking Option uses the public-key based Diffie-Hellman key negotiation algorithm to perform secure key distribution for both encryption and crypto-checksumming.
When encryption is used to protect the security of encrypted data, keys should be changed frequently to minimize the effects of a compromised key. For this reason, the Oracle Advanced Networking Option key management facility changes the session key with every session.
The Oracle Advanced Networking Option includes the Diffie-Hellman key negotiation algorithm to choose keys used both for encryption and for crypto-checksumming.
A key is a secret shared by both sides of the connection and by no one else. Without the key, it is extremely difficult to decrypt an encrypted message or to tamper undetectably with a crypto-checksummed message. Diffie-Hellman is subject to a particular computationally-expensive table-based attack. Site-specific Diffie-Hellman, on the other hand, lowers the effectiveness of this attack by enabling the Diffie-Hellman parameters at each site to be changed frequently.
The system administrator can lessen the consequences of this attack by running a parameter generation program called naegen to change the default Diffie-Hellman parameters. The Oracle Advanced Networking Option server will then use the modified parameters to establish a Diffie-Hellman session key with the Oracle Advanced Networking Option client. If the Diffie-Hellman parameters do not exist, the Oracle Advanced Networking Option server will use its default parameters.
You can use the naegen utility to generate the new Diffie-Hellman parameters. naegen takes as an argument either zero or an integer argument in the range of 256 to 512. For example:
naegen 300
This argument represents the number of bits in those parameters. If you do not provide an argument to naegen, naegen generates 512-bit parameters. If a number lower than 256 is provided as the argument, naegen will generate 256-bit parameters. Once it has generated the parameters, naegen stores them in snsdh.ora which is then read by the Oracle Advanced Networking Option server to be used in key negotiation. Note that every time the administrator runs naegen, the values in the snsdh.ora file will be different.
If you are using a 40-bit key such as that used by RC4_40, you should provide naegen argument of 300 or greater. If you are using a 56-bit key such as DES, you should provide an argument of 512.
Although using different Diffie-Hellman parameters for each connection is preferred for better security, it is not feasible because naegen can take up to 4 minutes to generate the necessary parameters, depending on the parameter size. Therefore, it is recommended that network administrators generate the parameters once a day. Optionally, you could generate the parameters once a week or once a month.
The purpose of the Authentication Key Fold-in encryption enhancement is to defeat a possible "middle-man attack" on the Diffie-Hellman key negotiation. It strengthens the session key significantly by combining a shared secret (which is known only to both the client and the server), with the original session key negotiated by Diffie-Hellman.
The client and the server begin communicating using the session key generated by Diffie-Hellman. When the client authenticates itself to the server, there is a shared secret that is only known to both sides. The Oracle Advanced Networking Option then combines the shared secret and Diffie-Hellman session key to generate a stronger session key that would defeat the middle-man, who has no way of knowing the shared secret.
The authentication key fold-in encryption enhancement feature is included in the Oracle Advanced Networking Option and requires no configuration by the system or network administrator.
Encryption of network data provides data privacy, so no unauthorized party is able to view the plaintext data as it passes over the network. The Oracle Advanced Networking Option also provides protection against two other forms of attack: Data Modification Attack and Replay Attack.
In a data modification attack, an unauthorized party on the network intercepts data in transit and changes portions of that data before retransmitting it. An example of this would be to change the dollar amount of a banking transaction.
In a replay attack, an entire set of valid data is repeatedly interjected onto the network. An example would be to repeat a valid bank account transfer transaction.
The Oracle Advanced Networking Option uses a keyed, sequenced implementation of the MD5 message digest algorithm to protect against both of these forms of active attack. This protection is activated independently from the encryption features provided.
Due to export controls placed on encryption technology, the Oracle Advanced Networking Option is available in two versions: an Export version and a Domestic version.
The Oracle Advanced Networking Option for Export Use contains the Diffie-Hellman key negotiation algorithm, MD5 message digest algorithm, and DES40 and RC4_40 encryption algorithms.
The Oracle Advanced Networking Option for Domestic Use contains the Diffie-Hellman key negotiation algorithm, MD5 message digest algorithm, and DES40, DES, RC4_40, RC4_56, and RC4_128 encryption algorithms.
In certain circumstances, a special license may be obtained to export the domestic version. Licenses are generally available to wholly owned subsidiaries of US corporations. Special licenses can be obtained to allow banks to have the export version updated to include DES. Export and import regulations vary from country to country and change from time to time, so it is important to check on current restrictions in your area.
As a network administrator, you set the encryption and checksumming configuration parameters. For information about configuring your existing Net8 network to use the Oracle Advanced Networking Option, see Section 2.5, "Using Oracle Net8 Assistant to Configure Servers and Clients to Use Encryption and Checksumming".
The profile (SQLNET.ORA) on clients and servers using encryption and checksumming must contain some or all of the parameters listed below. See Appendix A, "Encryption and Checksum Parameters" for sample SQLNET.ORA configuration files for clients or servers using the Oracle Advanced Networking Option.
To negotiate whether to turn on encryption or checksumming, you can specify four possible values for four of the Oracle Advanced Networking Option configuration parameters: "ACCEPTED", "REJECTED", "REQUESTED", "REQUIRED". Each of these four values is listed below followed by a brief one-sentence explanation. This explanation is followed by a paragraph or two containing detailed explanations of its meaning and behavior. The default value for these four parameters is ACCEPTED. If you do not specify a value for a parameter, it defaults to ACCEPTED.
Turn on the security service if the other side wants it.
My side of the connection does not desire the security service, but it will be allowed if the other side asks with a setting of REQUIRED or REQUESTED. If the other side is set to REQUIRED or REQUESTED, and an algorithm match is found, the connection will continue without error and with the security service turned on. If the other side is set to REQUIRED and no algorithm match is found, the connection will terminate with error message ORA-12650.
If the other side is set to REQUESTED and no algorithm match is found, or if the other side is set to ACCEPTED or REJECTED, the connection will continue without error and without the security service enabled.
Do not turn on the security service even if the other side wants it.
My side of the connection specifies that the security service is not allowed. If the other side specifies REQUIRED, the connection will terminate with error message ORA-12650. If the other side is set to REQUESTED, ACCEPTED, or REJECTED, the connection will continue without error and without the security service enabled.
Turn on the security service if the other side allows it.
My side of the connection specifies that the security service is desired, but not required. The security service will be active if the other side specifies ACCEPTED, REQUESTED, or REQUIRED. There must be a matching algorithm available on the other side, otherwise the service will not be activated. If the other side specifies REQUIRED and there is no matching algorithm, the connection fails.
Turn on the security service or do not make the connection.
My side of the connection specifies that the security service must be activated. The connection will fail if the other side specifies REJECTED or if there is no compatible algorithm on the other side.
Table 2-1, "Encryption and Checksumming Negotiation Scheme" below shows whether or not the security service will be turned on based on a combination of client and server configuration parameters. If either the server or client has specified REQUIRED, lack of a common algorithm will cause the connection to fail. Otherwise, if the service would be on, lack of a common service algorithm will result in the service being turned off.
Table 2-1 Encryption and Checksumming Negotiation Scheme
|
Server |
Accepted |
OFF |
OFF |
ON |
ON |
|
|
Rejected |
OFF |
OFF |
OFF |
Connection will fail |
|
|
Requested |
ON |
OFF |
ON |
ON |
|
|
Required |
ON |
Connection will fail |
ON |
ON |
There are nine parameters used to turn on encryption and checksumming. These parameters are described in the following sections:
Section 2.4.2.1, "Server Encryption Level Setting"
Section 2.4.2.2, "Client Encryption Level Setting"
Section 2.4.2.3, "Server Encryption Selected List"
Section 2.4.2.4, "Client Encryption Selected List"
Section 2.4.2.5, "Server Checksum Level Setting"
Section 2.4.2.6, "Client Checksum Level Setting"
Section 2.4.2.7, "Server Checksum Selected List"
Section 2.4.2.8, "Client Checksum Selected List"
Section 2.4.2.9, "Client Profile Encryption"
Refer to Section 2.4.1, "Negotiating Encryption and Checksumming" for descriptions of the possible values you can specify for the four level setting parameters listed above.
SQLNET.ENCRYPTION_SERVER = valid_value
This parameter specifies the desired behavior when a client (or a server acting as a client) is connecting to this server. The behavior of the server will depend in part on the SQLNET.ENCRYPTION_CLIENT setting at the other end.
Possible values: ACCEPTED, REJECTED, REQUESTED, REQUIRED
Default value: ACCEPTED
SQLNET.ENCRYPTION_CLIENT = valid_value
This parameter specifies the desired behavior when this client (or this server acting as a client) is connecting to a server. The behavior of the client will depend in part on the value set for SQLNET.ENCRYPTION_SERVER at the other end of the connection.
Possible values: ACCEPTED, REJECTED, REQUESTED, REQUIRED
Default value: ACCEPTED
SQLNET.ENCRYPTION_TYPES_SERVER = (valid_encryption_algorithm [,valid_encryption_algorithm])
where valid_encryption_algorithm is one of the following:
|
RC4_56 |
Domestic only |
|
RC4_128 |
Domestic only |
|
DES |
Standard DES (56-bit key size) Domestic only |
|
DES40 |
Domestic & International |
This parameter specifies a list of encryption algorithms this server is allowed to use when acting as a server in the order of desired use. Type the most desired algorithm first. This list is used to negotiate a mutually acceptable algorithm with the other end of the connection. Each algorithm will be checked against the list of client algorithm types available until a match is found. If an algorithm that is not installed is specified on this side, the connection will terminate with error message ORA-12650.
Default value: All installed algorithms will be used in a negotiation if no algorithms are defined in the SQLNET.ORA file.
Domestic version: If you are using the Domestic version, all five algorithms are installed: RC4_40, RC4_56, RC4_128, DES, and DES40. If no algorithms are specified, the installed algorithms will be used in that order to negotiate a mutually acceptable algorithm with the other end of the connection.
Export version: If you are using the Export version, the following algorithms are installed: RC4_40 and DES40. If no algorithms are specified, the installed algorithms will be used in that order to negotiate a mutually acceptable algorithm.
You can specify multiple encryption algorithms, that is, either a single value or a list of algorithm names. For example, either of the following encryption parameters is acceptable:
SQLNET.ENCRYPTION_TYPES_SERVER=(RC4_40) SQLNET.ENCRYPTION_TYPES_SERVER=(DES,RC4_56,RC4_128,DES40)
SQLNET.ENCRYPTION_TYPES_CLIENT = (valid_encryption_algorithm [,valid_encryption_algorithm])
where valid_encryption_algorithm is one of the following:
|
RC4_56 |
Domestic only |
|
RC4_128 |
Domestic only |
|
DES |
Standard DES (56-bit key size) Domestic only |
|
DES40 |
Domestic & International |
This parameter specifies a list of encryption algorithms this client (or this server acting as a client) is allowed to use when connecting to a server. This list is used to negotiate a mutually acceptable algorithm with the other end of the connection. The parameters can be listed in any order. If an algorithm that is not installed is specified on this side, the connection will terminate with error message ORA-12650.
Default value: All installed algorithms will be used if no algorithms are defined in
the SQLNET.ORA file.
Domestic version: If you are using the Domestic version, all five algorithms are installed: RC4_40, RC4_56, RC4_128, DES, and DES40. If no algorithms are defined in the SQLNET.ORA file, the installed algorithms will be used in that order to negotiate a mutually acceptable algorithm with the other end of the connection.
Export version: If you are using the Export version, the following algorithms are installed: RC4_40 and DES40. If no algorithms are defined in the SQLNET.ORA file, the installed algorithms will be used in that order to negotiate a mutually acceptable algorithm.
You can specify multiple encryption algorithms, that is, either a single value or a list of algorithm names. For example, either of the following encryption parameters is acceptable:
SQLNET.ENCRYPTION_TYPES_CLIENT=(DES,DES40,RC4_56,RC4_40) SQLNET.ENCRYPTION_TYPES_CLIENT=(RC4_40)
SQLNET.CRYPTO_CHECKSUM_SERVER = valid_value
This parameter specifies the desired checksum behavior when a client (or another server acting as a client) is connecting to this server. The resulting behavior will depend in part on the SQLNET.CRYPTO_CHECKSUM_CLIENT setting at the other end.
Possible values: ACCEPTED, REJECTED, REQUESTED, REQUIRED
Default value: ACCEPTED
SQLNET.CRYPTO_CHECKSUM_CLIENT = valid_value
This parameter specifies the desired checksum behavior when this client (or this server acting as a client) is connecting to a server. The resulting behavior will depend in part on the SQLNET.CRYPTO_CHECKSUM_SERVER setting at the other end of the connection.
Possible values: ACCEPTED, REJECTED, REQUESTED, REQUIRED
Default value: ACCEPTED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (crypto_checksum_algorithm)
where crypto_checksum_algorithm is:
MD5
Currently, the only supported crypto-checksum algorithm choice is RSA Data Security's MD5 algorithm. Other algorithms may be supported in future releases.
This parameter specifies a list of the checksumming algorithms this server is allowed to use, in order of desired use with the most desired algorithm first, when acting as a server to a client or another server. This list is used to negotiate a mutually acceptable algorithm with the remote end. Each algorithm will be checked against the list of client algorithm types available until a match is found. The first algorithm match will be the one that is used. If an algorithm is specified that is not installed on this side, the connection will terminate with error message ORA-12650.
Default value: MD5 (currently the only valid value)
Currently, the only supported crypto-checksum algorithm choice is RSA Data Security's MD5 algorithm. Other algorithms may be supported in future releases.
This parameter specifies a list of checksumming algorithms this client (or this server acting as a client) is allowed to use when connecting to a server. This list is used to negotiate a mutually acceptable algorithm with the remote end. The order in which the algorithms are listed is not important. If an algorithm that is not installed on this side is specified, the connection will terminate with error message ORA-12650.
Default value: MD5 (currently the only valid value)
SQLNET.CRYPTO_SEED = "10-70 random characters"
The characters that form the value for this parameter are used when generating cryptographic keys. The more random the characters entered into this field are, the stronger the keys are. You set this parameter by entering from 10 to 70 random characters into the above statement.
|
Note: It is recommended that you enter as many characters as possible (up to 70), since the resulting key will be more random and therefore stronger. |
This parameter must be present in the profile (SQLNET.ORA) whenever encryption or checksumming is turned on.
Use the Oracle Net8 Assistant to configure clients and servers in your network to use encryption and checksumming. Oracle Net8 Assistant automatically updates your profile (SQLNET.ORA) with the parameters you select. Refer to the Oracle Net8 Assistant HELP system for detailed configuration information. Refer to Appendix A, "Encryption and Checksum Parameters" for sample configuration files using encryption and checksumming.
The following instructions assume you are using the Oracle Net8 Assistant configuration tool. Configure Servers to use encryption as follows. Refer to Figure 2-1, "Oracle Net8 Assistant Profile Encryption Tab".
Configure Clients to use encryption as follows:
Configure Servers and Clients to use checksumming as follows. Refer to Figure 2-2, "Oracle Net8 Assistant Profile Integrity Tab".
