db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-962) Upgrade default security mechanism in client to use encrypted userid password if client can support it.
Date Wed, 08 Mar 2006 00:28:55 GMT
     [ http://issues.apache.org/jira/browse/DERBY-962?page=all ]

Sunitha Kambhampati updated DERBY-962:

    Attachment: Derby962_forreview.diff.txt

This patch 'Derby962.forreview.diff.txt' is a patch for review. This patch needs derby 1080
for it to work. Also there is one testfile which is common between the derby-1080 and this
patch and hence it is likely this patch may not apply cleanly once derby1080 gets reviewed
and committed.  I generated the diff keeping the changes of derby1080 for the test file (derbynet/testSecMec.java).

This patch 'Derby962.forreview.diff.txt' improves the upgrade security mechanism logic to
do the following.

1. If securityMechanism is explicitly specified in the connection request then client will
not override it.
2. Dynamically figure out if the jvm in which the client is loaded, supports encrypted userid
password security (EUSRIDPWD) or not and use this information to upgrade to a more secure
security mechanism.
3. Thus if user has not specified the security mechanism, in that case the client will try
to see if 
it can upgrade the security mechanism and use the new upgraded security mechanism for connection
to the server.

Logic in ClientBaseDataSource#getUpgradedSecurityMechanism()
+     * This method has logic to upgrade security mechanism to a better (more secure) one

+     * if it is possible.   Currently derby server only has support for USRIDPWD,USRIDONL,
+     * EUSRIDPWD and this method only considers these possibilities. 
+     * USRIDPWD, EUSRIDPWD require a password, USRIDONL is the only security mechanism
+     * which does not require password.
+     * 1. if password is not available, then security mechanism possible is USRIDONL
+     * 2. if password is available, if client supports EUSRIDPWD, then EUSRIDPWD is 
+     * returned
+     * 3. if password is available, if client does not support EUSRIDPWD, then USRIDPWD
+     * is returned.

-- Added tests with possible permutations for user, password and security mechanism on a connection
see derbynet/testSecMec.java#testAllCombinationsOfUserPasswordSecMecInput()

I have attached a table to this jira entry (962_table.txt) that gives information about what
security mechanism the client sends to the server on different possible inputs.  

-- Ran derbyall on linux/ibm142 ok with known failures.
-- Ran derbynet/testSecMec.java on windows with sane classes for both derbynet(JCC2.4 and
/derbynetclientmats with ibm131/ibm15/jdk131/jdk15/ibm142/jdk142.

Please note: this patch depends and requires fix for derby1080. Most likely when 1080 gets
reviewed and committed, this patch may not cleanly apply. 

Can someone please review this change. Thanks.  

> Upgrade default security mechanism in client to use encrypted userid password if client
can support it.
> -------------------------------------------------------------------------------------------------------
>          Key: DERBY-962
>          URL: http://issues.apache.org/jira/browse/DERBY-962
>      Project: Derby
>         Type: Improvement
>   Components: Network Client
>     Reporter: Sunitha Kambhampati
>     Assignee: Sunitha Kambhampati
>      Fix For:
>  Attachments: 962_table.txt, Derby962_forreview.diff.txt, Derby962_forreview.stat.txt
> Currently in the client, if userid and password are set in the connection url, the default
security mechanism is upgraded to USRIDPWD (which is clear text userid and password).  This
seems to be a security hole here. 
> Current client  driver supports 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  (apt from ibm jce) to be used
as java cryptography providers.  
> Some thoughts:
> -- client can make a check to see if it the jvm it is running in supports the encryption
necessary for EUSRIDPWD. If it supports, then the client can upgrade to EUSRIDPWD. 
> -- if the jvm the client is running is , doesnt support encryption requirements for EUSRIDPWD,
then the security mechanism will be set to USRIDPWD.
> -- DERBY-528 will add support for strong userid and password which is another option
to send encrypted passwords across the wire. When this gets added, maybe this can be considered
as one of the upgrade options after EUSRIDPWD. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message