You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by Apache Wiki <wi...@apache.org> on 2006/03/15 08:09:46 UTC
[Db-derby Wiki] Update of "SecurityMechanism" by SunithaKambhampati
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.
The following page has been changed by SunithaKambhampati:
http://wiki.apache.org/db-derby/SecurityMechanism
The comment on the change is:
Adding information about securitymechanisms
New page:
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]]
||<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]] ||
[[BR]] Please read the spec for detailed information. But in short the table below specifies what information is needed for security mechanism[[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]] ||
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.[[BR]][[BR]](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 [[BR]]exponent required for DH . These values must be used as is to generate a shared private key.)[[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]]
||<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]] ||
<span style="font-style: italic;">(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).</span>[[BR]][[BR]] Client behaviors:[[BR]][[BR]] 10.1 Client Behavior with respect to security mechanism.[[BR]]
* Default security mechanism used is USRIDONL ( 0x04)
* If no user specified on connection request, default to 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]]
10.2 Client Behavior with respect to security mechanism.[[BR]]
* Default security mechanism used is USRIDONL ( 0x04)
* If no user specified on connection request, default to APP and use USRIDONL security mechanism[[BR]]
* (DERBY-962 under review currently). 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 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.[[BR]]
JCC 2.4 Behavior[[BR]]
* 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[[BR]]
* 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.[[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]]
JCC2.6 Behavior[[BR]]
* 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..[[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]]
* 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. [[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]]
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]]
* 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]]
* 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.[[BR]]
* Client<span style="font-weight: bold;"> will not override </span>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. [[BR]]
Server behavior:[[BR]] 10.1 Server[[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. <TODO>[[BR]]
* Protocol error if a security mechanism other than USRIDPWD,USRIDONL and EUSRIDPWD is sent from client. DERBY-963.[[BR]]
10.2 Server[[BR]]
* Default behavior of server is same as 10.1 server in terms of - it will not restrict client connectiosn 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 [[BR]] security mechanism. No other types of connections are accepted [[BR]]
* 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.[[BR]][[BR]]
||<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 ||
[[BR]] Behavior with derby.drda.securityMechanism set on server.[[BR]]
* 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"[[BR]]
[[BR]] DERBY-962 (patch posted for review). Client upgrade logic for security mechanism and table with different permutations. [[BR]][[BR]] Possible Enhancements in this specific area of security mechanisms:[[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]]
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)
1. Add ability to client to retry the connection if server rejects the security mechanism.
1. Add ability to client to accept user friendly names for securityMechanism attribute. (DERBY-963)[[BR]]
1. Add support for data stream encryption. [[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]]