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 Mon, 27 Mar 2006 17:53:21 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

------------------------------------------------------------------------------
  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]]
+ 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.[[BR]][[BR]] Table:
JVM (jce) support for secmec.[[BR]]
@@ -27, +27 @@

  ||<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]]
+ (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]]
  
-   * Default security mechanism used is USRIDONL ( 0x04)
-   * If no user specified on connection request, default to APP and use USRIDONL security
mechanism[[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]]
  
  10.2 Client Behavior with respect to security mechanism.[[BR]]
  
+   * If no user specified on connection request, default to user 'APP'.
-   * 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 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]]
@@ -74, +72 @@

      * 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.
+   * 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. [[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]]
+   * 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]]
  
  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.
+   * 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 [[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
@@ -102, +100 @@

    * 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]]
+ [[BR]] 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
+  [[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]]

Mime
View raw message