Each security mechanism provides a set of security services. Each security service addresses some security concern. In a Client-Library application, the requested services correspond to context or connection properties.
Not all of the security services are supported by all security mechanisms. To find out whether a given service is supported by the current security mechanism, the application calls ct_config or ct_con_props with action as CS_SUPPORTED, buffer as the address of a CS_BOOL variable, and property as the symbolic property constant that represents the security service. *buffer is set to CS_TRUE if the service is supported. ct_config and ct_con_props both fail when the application requests a service that is not supported by the current security mechanism.
Network security services are split into two categories:
Login authentication services allow an application to establish a secure connection.
Per-packet security services protect data transmitted over an established connection.
The fundamental security service is login authentication, or confirming that users are who they say they are. Login authentication involves user names and passwords. Users identify themselves by their user name, then supply their password as proof of their identity.
In Sybase applications, each connection between a client and a server has one user name associated with it. If the application uses a security mechanism, then Sybase uses the mechanism to authenticate this user name when the connection is established. The advantage of this service is that the user name/password pairs are managed in a central repository, and not in the system catalogs of individual servers.
When an application requests to connect to a server using network-based authentication, Client-Library queries the connection’s security mechanism to confirm that the given user name represents the authenticated user that is running the application. This means that users do not have to supply a password to connect to the server. Instead, users prove their identity to the network security system before the connection attempt is made. When connecting, Client-Library obtains a credential token from the security mechanism and sends it to the server in lieu of a password. The server then passes the token to the security mechanism again to confirm that the user name has been authenticated.
The following connection properties are related to login authentication. To take effect, these properties must be set before a connection is established. At the connection level, all the following properties are retrieve-only when the connection is open:
CS_USERNAME specifies the name of the user to connect with. If the application requests network-based authentication, then the user must be logged in to the network security system. Otherwise, the CS_PASSWORD property must be set to the user’s server password.
CS_SEC_NETWORKAUTH enables network-based authentication. The default is CS_FALSE, which means network-based authentication is disabled.
CS_SEC_CREDTIMEOUT and CS_SEC_SESSTIMEOUT allow applications to specify or check whether the user’s network credentials or security session have expired. Both apply only when network-based authentication is enabled on the connection.
The credential timeout period begins when the user obtains the credentials (that is, when the user logs in to the network). Some network security systems allow an administrator to specify a timeout value for user credentials. If the credentials expire, they are no longer valid. In addition, some systems allow applications to set credential timeout values.
The session timeout period begins when the connection is opened. Some network security systems allow an administrator to specify a timeout value for all security sessions. In addition, some systems allow applications to set session timeout values.
Table 2-33 lists the possible values for the credential and session timeout properties:
Value |
Meaning |
|---|---|
A positive integer |
The number of seconds remaining before the credential expires. |
0 |
The credential has expired. |
CS_UNEXPIRED |
The credential is valid. Remaining time is unknown. |
CS_NO_LIMIT |
The credential will not expire. |
Some security mechanisms do not support credential or session timeouts. If either type is not supported, the retrieved timeout value is always CS_NO_LIMIT. Some security mechanisms support timeouts, but do not report timeout values to applications. With these mechanisms, the retrieved timeout value is always either CS_UNEXPIRED or 0.
Applications can request a different credential or session timeout value by setting the corresponding property to a positive integer or CS_NO_LIMIT. However, the security system’s administrative settings restrict application-requested values. For example, if the system is configured so that all sessions timeout after 10 minutes, then an application’s request for a 20-minute (1200-second) session timeout has no effect.
No error is raised if an application’s request for a specific credential or session timeout value cannot be granted. If a connection’s security mechanism does not support credential or session timeouts, then calls to set the CS_SEC_CREDTIMEOUT or CS_SEC_SESSTIMEOUT properties have no effect.
When the user’s credential or session expires, the connection is closed either by Client-Library or the server, as follows:
Client-Library checks for credential or session expiration prior to writing to the network, and closes the connection if the session has expired.
The server checks for credential or session expiration before sending data to the client, and closes the connection if the session has expired. When the server closes the connection because of an expired session, the server does not send a warning message to the client.
CS_SEC_MUTUALAUTH requests that the connection’s security mechanism perform mutual authentication. For mutual authentication, the server is required to provide proof of its identity to the client before a connection is opened. The default is CS_FALSE, which means mutual authentication is not performed.
When mutual authentication is requested, the server provides proof of its identity to the client when a connection is established. This proof consists of a credential token sent by the server to Client-Library. The token is an opaque chunk of data that encodes the server principal name and proof that the name is authentic. Client-Library queries the security mechanism to verify that the received token is genuine. If it is not, Client-Library aborts the connection attempt.
CS_SEC_SERVERPRINCIPAL specifies the network security principal name for the server to which a connection will be opened. The default is NULL, which means ct_connect assumes that the server principal name matches the server’s directory entry name. CS_SEC_SERVERPRINCIPAL is meaningful only when network-based authentication is requested.
CS_SEC_DELEGATION determines whether the server is allowed to connect to a remote server using delegated credentials. The default is CS_FALSE, which means the credential delegation is not allowed.
Delegation applies only to applications that use network-based user authentication to connect to an Open Server gateway.
When a client connects to a gateway server, the gateway may establish a connection to a second, remote server that supports network-based authentication with an identical security mechanism. Credential delegation allows the gateway to connect to the remote server using the client’s delegated credential.
CS_SEC_CREDENTIALS allows a gateway application to forward user credentials to a remote server. The client application must have permitted credential delegation by setting the CS_SEC_DELEGATION connection property to CS_TRUE.
Gateways support delegation by retrieving the value of the SRV_T_SEC_DELEGCRED Open Server thread property and setting the CS_SEC_CREDENTIALS Client-Library connection property to the retrieved value. The gateway’s client, the gateway, and the gateway’s remote server must use an identical security mechanism for delegation to work.
The CS_SEC_CREDENTIALS property can only be set or cleared.
CS_SEC_CHANBIND determines whether the connection’s security mechanism performs channel binding. The default is CS_FALSE, which means channel binding is not performed.
When channel binding is enabled, Client-Library and the server both provide a network channel identifier (consisting of the network addresses of the client and the server) to the connection’s security mechanism.
CS_SEC_KEYTAB specifies the name and path to an operating system file (called a keytab file) from which a connection’s security mechanism reads the security key to go with the user name that is specified by the CS_USERNAME property.
Only the DCE security driver
supports keytab files.
CS_SEC_KEYTAB is meaningful only for connections that use DCE as their security mechanism and that have requested network-based authentication. An application specifies a keytab file to connect to a server under a different user name than the DCE user that is running the application. The application sets the CS_USERNAME property to the new user name and sets CS_SEC_KEYTAB to indicate the keytab file that specifies the security key for the user. The default for CS_SEC_KEYTAB is NULL, which means that no keytab file is read, that CS_USERNAME must represent the DCE name of the application user, and that the user must already be logged into DCE.
A keytab file is created with the DCE dcecp utility (see your DCE documentation). The keytab file must be readable by the user who is running the Client-Library application.
Encryption of login and remote passwords in Open Client and Open Server is accomplished with the Sybase Common Security Infrastructure (CSI). CSI 2.6 complies with the Federal Information Processing Standard (FIPS) 140-2.
To support FIPS encryption, a Certicom Security Builder shared library named libsbgse2.so (UNIX and Linux platforms) or libsbgse2.dll (Microsoft Windows platforms) is installed on platforms that do not already use the Certicom Security Builder. Also, the sybcsi subdirectory found in $SYBASE/$SYBASE_OCS/lib3p or $SYBASE/$SYBASE_OCS/lib3p64 has been removed.
In some environments, distributed application designers have to deal with the fact that the network is not physically secure. For example, unauthorized parties may listen to a dialog by attaching analyzers to a physical line or capturing wireless transmissions.
In these environments, applications require protection of transmitted data to assure a secure dialog. Per-packet security services protect transmitted data.
All per-packet services require that one or both of the following operations be performed for each TDS packet to be sent over a connection:
Encryption of the packet’s contents
Computation of a digital signature that encodes the packet contents as well as other needed information
Applications that use the services described in this
section incur a per-packet overhead on all communication between
the client and the server. Do not use per-packet security services
unless application security is more important than application performance.
If an application selects multiple per-packet services, each operation is performed only once per packet. For example, if the application selects the data confidentiality, sequence verification, data integrity, and channel binding services, then each packet is encrypted and accompanied by a digital signature that encodes the packet contents, packet sequence information, and a network channel identifier.
All per-packet services, except data confidentiality, require the connection’s security mechanism to compute a digital signature for each packet that is sent over the connection. The signature encodes information about the packet’s contents, and may encode other information as well. The client and the server both compute packet signatures and send them with each TDS packet. When the packet and signature are received, the security mechanism verifies the received signature. If packet signature is rejected, the connection is closed as follows:
If the error occurs when Client-Library is reading results from the network, Client-Library raises an error and closes the connection.
If the error occurs when the server is reading packets sent by the client, the server closes the connection. In this case, the client application will not discover the error until it tries to read from the network.
The following connection properties control the use of the per-packet services. To take effect, these properties must be set before a connection is established. At the connection level, all of the following properties are retrieve-only when the connection is open. All of the following properties take CS_BOOL *buffer values, and all are CS_FALSE by default:
CS_SEC_CONFIDENTIALITY requests encryption of all transmitted data. All commands sent to the server and all results returned by the server are encrypted.
Data confidentiality protects data that is sent over public networks where the transmission medium is not physically secure. For example, strangers may attach analyzers to a physical line or capture wireless transmissions.
CS_SEC_INTEGRITY requests that integrity checking be performed on all data transmitted over the connection. This service checks all TDS packets sent to the server and all sent from the server to assure that the contents were not modified.
Data integrity checking is used only when the connection is also using network-based user authentication.
CS_SEC_DATAORIGIN determines whether the connection’s security mechanism performs data origin stamping. This service stamps each TDS packet transmitted over the connection with a digital signature that encodes information about the packet’s sender and contents.
CS_SEC_DETECTREPLAY determines whether the connection’s security mechanism detects invalid repetition of transmitted TDS packets.
Replay detection assures that attempts to capture packets and replay them are detected. For example, a stranger could capture the packets that represent a command sent to the server and replay them in an attempt to cause an unauthorized repeat of the command.
CS_SEC_DETECTSEQ determines whether the connection’s security mechanism detects transmitted TDS packets that arrive in a different order than the order in which they were sent.
The replay detection and the sequence verification services are similar. However, they are distinct services. For example, consider the case where packets sent by the client are numbered in the sending order as P1, P2, P3, and so forth. If the server receives the packets in the order P1, P2, P2, then this is a replay error but not an out-of-sequence error. If the server receives the packets in the order P1, P3, P2, this is an out-of-sequence error but not a replay error.
