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] Commented: (DERBY-962) Upgrade default security mechanism in client to use encrypted userid password if client can support it.
Date Fri, 17 Feb 2006 02:55:26 GMT
    [ http://issues.apache.org/jira/browse/DERBY-962?page=comments#action_12366737 ] 

Sunitha Kambhampati commented on DERBY-962:
-------------------------------------------

I just started looking at this issue on how to know if the jvm in which the client is running
can support encrypted userid and password mechanism or not;  to decide if we can upgrade the
default security mechanism.  

I wanted to share some thoughts I have, so I could get early feedback from the list.

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.  

-- org.apache.derby.client.am.EncryptionManager (EM) constructor is responsible for instantiating
the appropriate Provider and the KeyPairGenerator.  The Sun JCE throws java.security.InvalidAlgorithmParameterException
exception when trying to use the 256bits prime. 

I think we can conclude if the EM throws an exception, then the JCE doesnt support the required
algorithms.
=> An exception from this constructor indicates that it is not possible to use encrypted
userid/password.

The next step seems to me to decide where to put the call to new EncryptionManager(EM)
#A.Put in static initializer block in ClientBaseDataSource and store the result in a static
variable.  The ClientBaseDataSource seems to be place where all the url attribute values'
gets and sets methods are present. Also the upgrade logic for the security mechanism is in
this class.

something like:
static boolean SUPPORTS_EUSRIDPWD = false;
static
{
    try
    {
        
        new org.apache.derby.client.am.EncryptionManager(null);
        SUPPORTS_EUSRIDPWD = true;
    }catch(Exception e)
    {
       //ignore
    }
}

---------------

#B. Another place this check could go was in the ClientDriver itself since this will be loaded
 in the JVM. In the static initializer of ClientDriver, new of EM can be done to check if
it will go through OK. If so, a static 'protected' variable in ClientDriver can be used to
store the state that the driver supports the algorithms required for encrypted userid/password.

1. Are there any issues with adding code to the static initializer block of the Client Driver.
I see the following comment in ClientDriver which sounds a little scary to me. 

static {
       // This may possibly hit the race-condition bug of java 1.1.
        // The Configuration static clause should execute before the following line does.
	 if (Configuration.exceptionsOnLoadResources != null) {
......
}

I can see that the Configuration static initializer needs to run before the access to the
static variable Configuration.exceptionsOnLoadResources. 

I'm curious and would like to look at it sometime. If someone could point me to some reference
of this bug, I'd be grateful. I googled but didnt find any related to the static intializer
blocks. 
--------------

#C Explicitly check the jvm and decide.  Not a good way for e.g. if SunJCE supports the DH
with 256 bits prime some day, we would have to remember to remove this check that disables
encrypted userid/password for this particular JVM. 

I like #A because it seems clean.    What do others think ? 

Comments/Thoughts.

Thanks much,
Sunitha. 

> 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
>      Fix For: 10.2.0.0

>
> 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message