Differences between revisions 2 and 3
Revision 2 as of 2006-03-27 17:53:20
Size: 14445
Comment:
Revision 3 as of 2009-09-20 22:12:18
Size: 14445
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Security Mechanisms in Network Server and Client[[BR]][[BR]] Specifications:DRDA manual: Section 4.4.2 talks about drda security flows. [[BR]] Pg 92,has table of security mechanism and secmec mapping.[[BR]][[BR]] NetworkServer and Client have code to support following security mechanisms. [[BR]] Table of supported security mechanisms[[BR]] Security Mechanisms in Network Server and Client<<BR>><<BR>> Specifications:DRDA manual: Section 4.4.2 talks about drda security flows. <<BR>> Pg 92,has table of security mechanism and secmec mapping.<<BR>><<BR>> NetworkServer and Client have code to support following security mechanisms. <<BR>> Table of supported security mechanisms<<BR>>
Line 3: Line 3:
||<style="vertical-align: top;"> SecMec[[BR]] ||<style="vertical-align: top;"> SecMec codepoint value[[BR]] ||<style="vertical-align: top;"> User friendly name[[BR]] ||
||<style="vertical-align: top;"> USRIDONL[[BR]] ||<style="vertical-align: top;"> 0x04[[BR]] ||<style="vertical-align: top;"> USER_ONLY_SECURITY[[BR]] ||
||<style="vertical-align: top;"> USRIDPWD[[BR]] ||<style="vertical-align: top;"> 0x03[[BR]] ||<style="vertical-align: top;"> CLEAR_TEXT_PASSWORD_SECURITY[[BR]] ||
||<style="vertical-align: top;"> EUSRIDPWD[[BR]] ||<style="vertical-align: top;"> 0x09[[BR]] ||<style="vertical-align: top;"> ENCRYPTED_USER_AND_PASSWORD_SECURITY[[BR]] ||
||<style="vertical-align: top;"> SecMec<<BR>> ||<style="vertical-align: top;"> SecMec codepoint value<<BR>> ||<style="vertical-align: top;"> User friendly name<<BR>> ||
||<style="vertical-align: top;"> USRIDONL<<BR>> ||<style="vertical-align: top;"> 0x04<<BR>> ||<style="vertical-align: top;"> USER_ONLY_SECURITY<<BR>> ||
||<style="vertical-align: top;"> USRIDPWD<<BR>> ||<style="vertical-align: top;"> 0x03<<BR>> ||<style="vertical-align: top;"> CLEAR_TEXT_PASSWORD_SECURITY<<BR>> ||
||<style="vertical-align: top;"> EUSRIDPWD<<BR>> ||<style="vertical-align: top;"> 0x09<<BR>> ||<style="vertical-align: top;"> ENCRYPTED_USER_AND_PASSWORD_SECURITY<<BR>> ||
Line 8: Line 8:
[[BR]] Please read the spec for detailed information. But in short the table below specifies what information is needed for security mechanism[[BR]] <<BR>> Please read the spec for detailed information. But in short the table below specifies what information is needed for security mechanism<<BR>>
Line 10: Line 10:
||<style="vertical-align: top;"> SecMec[[BR]] ||<style="vertical-align: top;"> Information sent to server[[BR]] ||
||<style="vertical-align: top;"> USRIDONL[[BR]] ||<style="vertical-align: top;"> Needs only user information and client will send userid in clear text [[BR]] ||
||<style="vertical-align: top;"> USRIDPWD[[BR]] ||<style="vertical-align: top;"> Needs user and password information, and they will be sent to server in clear text ( huge security concern)[[BR]] ||
||<style="vertical-align: top;"> EUSRIDPWD[[BR]] ||<style="vertical-align: top;"> Needs user and password information and client will send encrypted userid and encrypted password to server. [[BR]] ||
||<style="vertical-align: top;"> SecMec<<BR>> ||<style="vertical-align: top;"> Information sent to server<<BR>> ||
||<style="vertical-align: top;"> USRIDONL<<BR>> ||<style="vertical-align: top;"> Needs only user information and client will send userid in clear text <<BR>> ||
||<style="vertical-align: top;"> USRIDPWD<<BR>> ||<style="vertical-align: top;"> Needs user and password information, and they will be sent to server in clear text ( huge security concern)<<BR>> ||
||<style="vertical-align: top;"> EUSRIDPWD<<BR>> ||<style="vertical-align: top;"> Needs user and password information and client will send encrypted userid and encrypted password to server. <<BR>> ||
Line 21: Line 21:
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.[[BR]][[BR]] Table: JVM (jce) support for secmec.[[BR]] 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.<<BR>><<BR>> Table: JVM (jce) support for secmec.<<BR>>
Line 23: Line 23:
||<style="vertical-align: top;"> SecMec[[BR]] ||<style="vertical-align: top;"> Sun JVM[[BR]] ||<style="vertical-align: top;"> IBM JVM 1.4.1[[BR]] ||<style="vertical-align: top;"> IBM JVM 1.4.2[[BR]] ||<style="vertical-align: top;"> IBM JVM 1.3.1[[BR]] ||<style="vertical-align: top;"> IBM JVM 1.5[[BR]] ||
||<style="vertical-align: top;"> EUSRIDPWD[[BR]] ||<style="vertical-align: top;"> N[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> N[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||
||<style="vertical-align: top;"> USRIDONL[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||
||<style="vertical-align: top;"> USRIDPWD[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||<style="vertical-align: top;"> Y[[BR]] ||
||<style="vertical-align: top;"> SecMec<<BR>> ||<style="vertical-align: top;"> Sun JVM<<BR>> ||<style="vertical-align: top;"> IBM JVM 1.4.1<<BR>> ||<style="vertical-align: top;"> IBM JVM 1.4.2<<BR>> ||<style="vertical-align: top;"> IBM JVM 1.3.1<<BR>> ||<style="vertical-align: top;"> IBM JVM 1.5<<BR>> ||
||<style="vertical-align: top;"> EUSRIDPWD<<BR>> ||<style="vertical-align: top;"> N<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> N<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||
||<style="vertical-align: top;"> USRIDONL<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||
||<style="vertical-align: top;"> USRIDPWD<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||<style="vertical-align: top;"> Y<<BR>> ||
Line 28: Line 28:
(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).[[BR]][[BR]] Client behaviors:[[BR]][[BR]] 10.1 Client Behavior with respect to security mechanism.[[BR]] (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).<<BR>><<BR>> Client behaviors:<<BR>><<BR>> 10.1 Client Behavior with respect to security mechanism.<<BR>>
Line 30: Line 30:
  * If no user specified on connection request, default to user 'APP' and use USRIDONL security mechanism[[BR]]
  * 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.[[BR]]
  * If no user specified on connection request, default to user 'APP' and use USRIDONL security mechanism<<BR>>
  * 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.<<BR>>
Line 33: Line 33:
10.2 Client Behavior with respect to security mechanism.[[BR]] 10.2 Client Behavior with respect to security mechanism.<<BR>>
Line 36: Line 36:
  * 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 : [[BR]]   * 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 : <<BR>>
Line 39: Line 39:
  * Does not override user's input for security mechanism.[[BR]]   * Does not override user's input for security mechanism.<<BR>>
Line 41: Line 41:
JCC 2.4 Behavior[[BR]] JCC 2.4 Behavior<<BR>>
Line 45: Line 45:
  * If securityMechanism is not explicitly specified on connection request, and if no password is specified, an exception is thrown - null password not supported[[BR]]   * If securityMechanism is not explicitly specified on connection request, and if no password is specified, an exception is thrown - null password not supported<<BR>>
Line 47: Line 47:
  * 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.[[BR]]
  * 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.[[BR]]
  * 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.<<BR>>
  * 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.<<BR>>
Line 50: Line 50:
JCC2.6 Behavior[[BR]] JCC2.6 Behavior<<BR>>
Line 55: Line 55:
  * 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..[[BR]]
  * On datasource, setting a security mechanism works. It also allows a security mechanism of USRIDONL to be set on datasource unlike jcc 2.4.[[BR]]
  * 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..<<BR>>
  * On datasource, setting a security mechanism works. It also allows a security mechanism of USRIDONL to be set on datasource unlike jcc 2.4.<<BR>>
Line 58: Line 58:
    * 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. [[BR]]
    * This switching does not take into account if the client is running in a JVM that supports EUSRIDPWD or not. [[BR]]
    * 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. [[BR]]
    * 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. <<BR>>
    * This switching does not take into account if the client is running in a JVM that supports EUSRIDPWD or not. <<BR>>
    * 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. <<BR>>
Line 62: Line 62:
ODBC Client (DB2 RTLite)[[BR]] [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"][[BR]] ODBC Client (DB2 RTLite)<<BR>> [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"]<<BR>>
Line 64: Line 64:
  * To connect to derby database via the DB2 CLP, one needs to catalog the database server as well as the database. [[BR]]
  * Syntax for catalog database in db2 is [[BR]] CATALOG DATABASE database-name [AS alias] [ON drive | AT NODE node-name][[BR]] [AUTHENTICATION {SERVER | CLIENT | DCS | DCE SERVER PRINCIPAL principalname[[BR]] | KERBEROS TARGET PRINCIPAL principalname | SERVER_ENCRYPT | DCS_ENCRYPT[[BR]] | DATA_ENCRYPT | GSSPLUGIN}] [WITH "comment-string"]
  * The AUTHENTICATION parameter is relevant to this discussion about security mechanism passed by the odbc client to network server. [[BR]]
  * Security Mechanisms can be set in DB2 CLP via the catalog command and specifying the correct authentication value. [[BR]]
  * To connect to derby database via the DB2 CLP, one needs to catalog the database server as well as the database. <<BR>>
  * Syntax for catalog database in db2 is <<BR>> CATALOG DATABASE database-name [AS alias] [ON drive | AT NODE node-name]<<BR>> [AUTHENTICATION {SERVER | CLIENT | DCS | DCE SERVER PRINCIPAL principalname<<BR>> | KERBEROS TARGET PRINCIPAL principalname | SERVER_ENCRYPT | DCS_ENCRYPT<<BR>> | DATA_ENCRYPT | GSSPLUGIN}] [WITH "comment-string"]
  * The AUTHENTICATION parameter is relevant to this discussion about security mechanism passed by the odbc client to network server. <<BR>>
  * Security Mechanisms can be set in DB2 CLP via the catalog command and specifying the correct authentication value. <<BR>>
Line 71: Line 71:
    * The rest of the values for authentication are not supported for network server.[[BR]]     * The rest of the values for authentication are not supported for network server.<<BR>>
Line 75: Line 75:
    * 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. [[BR]]     * 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. <<BR>>
Line 77: Line 77:
Server behavior:[[BR]] 10.1 Server[[BR]] Server behavior:<<BR>> 10.1 Server<<BR>>
Line 79: Line 79:
  * 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. [[BR]]
  * Protocol error if a security mechanism other than USRIDPWD,USRIDONL and EUSRIDPWD is sent from client. DERBY-963.[[BR]]
  * 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. <<BR>>
  * Protocol error if a security mechanism other than USRIDPWD,USRIDONL and EUSRIDPWD is sent from client. DERBY-963.<<BR>>
Line 82: Line 82:
10.2 Server[[BR]] 10.2 Server<<BR>>
Line 86: Line 86:
    * if derby.drda.securityMechanism is set to a valid mechanism, then the Network Server accepts only client connections which use that [[BR]] security mechanism. No other types of connections are accepted [[BR]]     * if derby.drda.securityMechanism is set to a valid mechanism, then the Network Server accepts only client connections which use that <<BR>> security mechanism. No other types of connections are accepted <<BR>>
Line 89: Line 89:
Table: Server behavior with derby.drda.securityMechanism set and not set.[[BR]][[BR]] Table: Server behavior with derby.drda.securityMechanism set and not set.<<BR>><<BR>>
Line 91: Line 91:
||<style="vertical-align: top;"> Client sends SECMEC value to server[[BR]] ||<style="vertical-align: top;"> derby.drda.securityMechanism not set[[BR]] ||<style="vertical-align: top;"> Server started with derby.drda.securityMechanism=USER_ONLY_SECURITY [[BR]] ||<style="vertical-align: top;"> Server started with derby.drda.securityMechanism=ENCRYPTED_USER_AND_PASSWORD_SECURITY ||<style="vertical-align: top;"> Server started with derby.drda.securityMechanism=CLEAR_TEXT_PASSWORD_SECURITY ||
||<style="vertical-align: top;"> 0x04 ||<style="vertical-align: top;"> OK[[BR]] ||<style="vertical-align: top;"> OK[[BR]] ||<style="vertical-align: top;"> REJECT connection ||<style="vertical-align: top;"> REJECT connection ||
||<style="vertical-align: top;"> 0x03[[BR]] ||<style="vertical-align: top;"> OK[[BR]] ||<style="vertical-align: top;"> REJECT connection [[BR]] ||<style="vertical-align: top;"> REJECT connection ||<style="vertical-align: top;"> OK[[BR]] ||
||<style="vertical-align: top;"> 0x09[[BR]] ||<style="vertical-align: top;"> OK[[BR]] ||<style="vertical-align: top;"> REJECT connection ||<style="vertical-align: top;"> OK[[BR]] ||<style="vertical-align: top;"> REJECT connection ||
||<style="vertical-align: top;"> Client sends SECMEC value to server<<BR>> ||<style="vertical-align: top;"> derby.drda.securityMechanism not set<<BR>> ||<style="vertical-align: top;"> Server started with derby.drda.securityMechanism=USER_ONLY_SECURITY <<BR>> ||<style="vertical-align: top;"> Server started with derby.drda.securityMechanism=ENCRYPTED_USER_AND_PASSWORD_SECURITY ||<style="vertical-align: top;"> Server started with derby.drda.securityMechanism=CLEAR_TEXT_PASSWORD_SECURITY ||
||<style="vertical-align: top;"> 0x04 ||<style="vertical-align: top;"> OK<<BR>> ||<style="vertical-align: top;"> OK<<BR>> ||<style="vertical-align: top;"> REJECT connection ||<style="vertical-align: top;"> REJECT connection ||
||<style="vertical-align: top;"> 0x03<<BR>> ||<style="vertical-align: top;"> OK<<BR>> ||<style="vertical-align: top;"> REJECT connection <<BR>> ||<style="vertical-align: top;"> REJECT connection ||<style="vertical-align: top;"> OK<<BR>> ||
||<style="vertical-align: top;"> 0x09<<BR>> ||<style="vertical-align: top;"> OK<<BR>> ||<style="vertical-align: top;"> REJECT connection ||<style="vertical-align: top;"> OK<<BR>> ||<style="vertical-align: top;"> REJECT connection ||
Line 96: Line 96:
[[BR]] Behavior with derby.drda.securityMechanism set on server.[[BR]] <<BR>> Behavior with derby.drda.securityMechanism set on server.<<BR>>
Line 99: Line 99:
  * 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"[[BR]]   * 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"<<BR>>
Line 101: Line 101:
[[BR]] DERBY-962 - Client upgrade logic for security mechanism and table with different permutations. <<BR>> DERBY-962 - Client upgrade logic for security mechanism and table with different permutations.
Line 104: Line 104:
 [[BR]][[BR]] Possible Enhancements in this specific area of security mechanisms:[[BR]]  <<BR>><<BR>> Possible Enhancements in this specific area of security mechanisms:<<BR>>
Line 106: Line 106:
  1. Implement another security mechanism that will work with sun jce also. DERBY528 [[BR]]
  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.[[BR]]
  1. Implement another security mechanism that will work with sun jce also. DERBY528 <<BR>>
  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.<<BR>>
Line 110: Line 110:
  1. Add ability to client to accept user friendly names for securityMechanism attribute. (DERBY-963)[[BR]]
  1. Add support for data stream encryption. [[BR]]
  1. Add ability to client to accept user friendly names for securityMechanism attribute. (DERBY-963)<<BR>>
  1. Add support for data stream encryption. <<BR>>
Line 113: Line 113:
Appendix::[[BR]] DRDA Specifications [[BR]] 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/ [[BR]][[BR]][[BR]][[BR]] Appendix::<<BR>> DRDA Specifications <<BR>> 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/ <<BR>><<BR>><<BR>><<BR>>

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

SecMec

SecMec codepoint value

User friendly name

USRIDONL

0x04

USER_ONLY_SECURITY

USRIDPWD

0x03

CLEAR_TEXT_PASSWORD_SECURITY

EUSRIDPWD

0x09

ENCRYPTED_USER_AND_PASSWORD_SECURITY


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

SecMec

Information sent to server

USRIDONL

Needs only user information and client will send userid in clear text

USRIDPWD

Needs user and password information, and they will be sent to server in clear text ( huge security concern)

EUSRIDPWD

Needs user and password information and client will send encrypted userid and encrypted password to server.

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.

SecMec

Sun JVM

IBM JVM 1.4.1

IBM JVM 1.4.2

IBM JVM 1.3.1

IBM JVM 1.5

EUSRIDPWD

N

Y

Y

N

Y

USRIDONL

Y

Y

Y

Y

Y

USRIDPWD

Y

Y

Y

Y

Y

(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
    | DATA_ENCRYPT | GSSPLUGIN}] [WITH "comment-string"]

  • 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.

Client sends SECMEC value to server

derby.drda.securityMechanism not set

Server started with derby.drda.securityMechanism=USER_ONLY_SECURITY

Server started with derby.drda.securityMechanism=ENCRYPTED_USER_AND_PASSWORD_SECURITY

Server started with derby.drda.securityMechanism=CLEAR_TEXT_PASSWORD_SECURITY

0x04

OK

OK

REJECT connection

REJECT connection

0x03

OK

REJECT connection

REJECT connection

OK

0x09

OK

REJECT connection

OK

REJECT connection


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

    2. 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.

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

    6. 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/



SecurityMechanism (last edited 2009-09-20 22:12:18 by localhost)