db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "SecurityMechanism" by SunithaKambhampati
Date Wed, 15 Mar 2006 07:09:46 GMT
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]]

Mime
View raw message