SecurityMechanism

Security Mechanisms in Network Server and Client

Specifications:DRDA manual: Section 4.4.2 talks about drda security flows.
Pg 92,has table of security mechanism and secmec mapping.

NetworkServer and Client have code to support following security mechanisms.
Table of supported security mechanisms

Please read the spec for detailed information. But in short the table below specifies what information is needed for security mechanism

Special case of EUSRIDPWD:

Server and client support encrypted userid/password (EUSRIDPWD) via the use of DH key-agreement protocol - however current Open Group DRDA specifications imposes small prime and base generator values (256 bits) that prevents other JCE's to be used as java cryptography providers - typical minimum security requirements is usually of 1024 bits (512-bit absolute minimum) when using DH key-agreement protocol to generate a session key.(Reference: DDM manual, page 281 and 282.  Section: Generating the shared private key. DRDA's diffie helman agreed public values for prime are 256 bits.  The spec gives the public values for the prime, generator and the size of exponent required for DH . These values must be used as is to generate  a shared private key.)

Encryption is done using JCE. Hence JCE support of the necessary algorithm is required for a particular security mechanism to work. Thus even though the server and client have code to support EUSRIDPWD, this security mechanism will not work in all JVMs. Below see some of the tested jvms's and if the jce supports algorithms needed for EUSRIDPWD.

Table: JVM (jce) support for secmec.

(Note: some older versions of ibm142 ( released in 2004) had a bug that wouldnt support DH prime of 32bytes. This has been fixed in later releases).

Client behaviors:

10.1 Client Behavior with respect to security mechanism.

• If no user specified on connection request, default to user 'APP' and use USRIDONL security mechanism

• If password is specified and if security mechanism is set to USRIDONL, then tries to upgrade security mechanism to USRIDPWD and uses USRIDPWD without giving any warning to user. Overrides user's input.

10.2 Client Behavior with respect to security mechanism.

• If no user specified on connection request, default to user 'APP'.
• If security mechanism is not specified as part of the connection request or on the datasource, then client will do an automatic switching (upgrade) of security mechanism to use. The logic is as follows :

• • if password is available, and if the JVM in which the client is running supports EUSRIDPWD mechanism, in that case the security mechanism is upgraded to EUSRIDPWD.
  • if password is available, and if the JVM in which the client is running does not support EUSRIDPWD mechanism, in that case the security mechanism is upgraded to USRIDPWD
• Does not override user's input for security mechanism.

JCC 2.4 Behavior

• Default security mechanism used is USRIDPWD (0x03)
• If securityMechanism is not explicitly specified on connection request, and if no user is specified, an exception is thrown. - Null userid not supported.
• If securityMechanism is not explicitly specified on connection request, and if no password is specified, an exception is thrown - null password not supported

• If security mechanism is specified, jcc client will not override the security mechanism.
• If securityMechanism is explicitly specified to be USRIDONL, then a password is not required. But in other cases (EUSRIDPWD,USRIDPWD) if password is null - an exception with the message 'a null password not valid' will be thrown.

• On datasource, setting a security mechanism does not work (bug). It defaults to USRIDPWD. Setting a value of USRIDONL or EUSRIDPWD does not seem to have an effect.

JCC2.6 Behavior

• Default security mechanism is USRIDPWD(0x03)
• If securityMechanism is not explicitly specified on connection request and if no user specified, an exception is thrown - Null userid not supported
• If securityMechanism is not explicitly specified on connection request, and if no password is specified, an exception is thrown - null password not supported
• If securityMechanism is explicitly specified to be USRIDONL, then a password is not required. But in other cases (EUSRIDPWD,USRIDPWD) if password is null - an exception with the message 'a null password not valid' will be thrown..

• On datasource, setting a security mechanism works. It also allows a security mechanism of USRIDONL to be set on datasource unlike jcc 2.4.

• There is logic to do upgrade of security mechanism in the 2.6 client. The logic is as follows:
  • If securityMechanism specified by user is USRIDPWD, and server rejects this and says it accepts only EUSRIDPWD, in that case JCC 2.6 will upgrade the security mechanism to EUSRIDPWD and send to server. This switching will override the security mechanism specified by user.

• • This switching does not take into account if the client is running in a JVM that supports EUSRIDPWD or not.

• • Thus if JCC client is running with Sun JVM 1.4.2 and even though Sun JCE does not have support for algorithms needed for EUSRIDPWD, the JCC client will still try to switch to EUSRIDPWD and throw an exception with ClassNotFoundException for the IBM JCE.

ODBC Client (DB2 RTLite)
[Tested with DB2 RTLite client - db2level output is DB21085I Instance "DB2" uses "32" bits and DB2 code release "SQL08023" with level identifier "03040106". Informational tokens are "DB2 v8.1.10.812", "s050811", "WR21362", and FixPak "10"]

• To connect to derby database via the DB2 CLP, one needs to catalog the database server as well as the database.

• Syntax for catalog database in db2 is
  CATALOG DATABASE database-name [AS alias] [ON drive | AT NODE node-name]
  [AUTHENTICATION {SERVER | CLIENT | DCS | DCE SERVER PRINCIPAL principalname

  KERBEROS TARGET PRINCIPAL principalname	SERVER_ENCRYPT	DCS_ENCRYPT
  <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e96c5dea-4e22-4f20-ae7f-4cdf72f2a03a"><ac:plain-text-body><![CDATA[	DATA_ENCRYPT	GSSPLUGIN}] [WITH "comment-string"]]]></ac:plain-text-body></ac:structured-macro>

• The AUTHENTICATION parameter is relevant to this discussion about security mechanism passed by the odbc client to network server.

• Security Mechanisms can be set in DB2 CLP via the catalog command and specifying the correct authentication value.

• • Catalog derby database with AUTHENTICATION CLIENT, db2 client will send secmec of USRIDONL (0x04) to the server.
  • Catalog derby database with AUTHENTICATION SERVER, db2 client will send secmec of USRIDPWD (0x03) to the server.
  • Catalog derby database with AUTHENTICATION SERVER_ENCRYPT, db2 client will send secmec of EUSRIDPWD(0x09) to the server.
  • The rest of the values for authentication are not supported for network server.

• Client will not override the security mechanism that was set by user by setting authentication value on the catalog database command.
• If no authentication value is specified which means that securityMechanism was not explicitly set , in this case the client does some automatic switching. The logic is as follows:
  • By default, the client first sends security mechanism of EUSRIDPWD(9). If server <span style="font-weight: bold;">rejects</span> this and sends information about what security mechanism it supports - then the client retries with the security mechanism that the server supports.

Server behavior:
10.1 Server

• Does not restrict connections based on the security mechanism sent by client. Server supports USRIDPWD, USRIDONL for both sun and ibm jvms. EUSRIDPWD will work only if JVM in which server is running supports the necessary algorithms.

• Protocol error if a security mechanism other than USRIDPWD,USRIDONL and EUSRIDPWD is sent from client. DERBY-963.

10.2 Server

• Default behavior of server is same as 10.1 server in terms of - it will not restrict client connections based on security mechanism sent by client.
• Has ability to restrict client connections from client by setting the following property derby.drda.securityMechanism. (DERBY-928)
  • if derby.drda.securityMechanism is set to a valid mechanism, then the Network Server accepts only client connections which use that
    security mechanism. No other types of connections are accepted

• • the derby.drda.securityMechanism is not set at all, then the Network Server accepts any connection which uses a valid security mechanism
    

Table: Server behavior with derby.drda.securityMechanism set and not set.

Behavior with derby.drda.securityMechanism set on server.

• If any (10.1 or 10.2) derby client sends a secmec value that is not the same as derby.drda.securityMechanism, in that case the server will reject the connection saying security mechanism not supported and will send the security mechanism that it supports (which is the security mechanism set using derby.drda.securityMechanism).
• The error message at the derby client will look something like this. <span style="font-family: monospace;"></span>"Connection authorization failure occurred. Reason: security mechanism not supported"

DERBY-962 - Client upgrade logic for security mechanism and table with different permutations. see method comments in testAllCombinationsOfUserPasswordSecMecInput in test derbynet/testSecMec.java. http://svn.apache.org/viewcvs.cgi/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/testSecMec.java?rev=386501&view=markup

Possible Enhancements in this specific area of security mechanisms:

1. Implement another security mechanism that will work with sun jce also. DERBY528

1. Network Server when running in Sun jvm incorrectly reports that it supports EUSRIDPWD. It seems correct to reject the client connection saying it doesnt support EUSRIDPWD.

1. Derby client should use EUSRIDPWD as default security mechanism if possible and should not override if user has explicitly specified security mechanism. (DERBY-962)
2. Add ability to client to retry the connection if server rejects the security mechanism.
3. Add ability to client to accept user friendly names for securityMechanism attribute. (DERBY-963)

1. Add support for data stream encryption.

Appendix::
DRDA Specifications
Article talks about how to connect via odbc using db2 client to derby server. http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0409kartha/