db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
Date Tue, 18 Jul 2006 21:19:15 GMT
    [ http://issues.apache.org/jira/browse/DERBY-528?page=comments#action_12421969 ] 
Francois Orsini commented on DERBY-528:

Here is additional information about this JIRA:

This patch implements DRDA  Strong Password Substitute security mechanism (USRSSBPWD) in the
Derby network client and  DRDA server - Ultimately we want to 
have  USRSSBPWD be the 2nd-best upgrade choice after Encrypted userid & password (EUSRIDPWD)
when this last one cannot be used with certain JVM's. There 
is also an existing JIRA-1517 which needs to be addressed in order to make USRSSBPWD a possible
SecMec upgrade choice for a DerbyNetClient datasource.

USRSSBPWD's SecMec implementation presented a challenge due to the non-recoverability of the
client password in the DRDA server - Effectively, USRSSBPWD 
causes a substitute password (in-lieu of the client's original one)  to be generated and sent
to the DRDA server - Basically, there is no way to decrypt or 
recover the substitute password on the server side. The server must regenerate a substitute
password on its side and compare it with the one sent by the 
client. Some 8-byte random seeds are exchanged between the client and server and are used
to generate the hashed password substitute along with the userName and 
some spec'ed constant value. When the server generates on its turn the password substitute,
it obviously needs to do it against the user's stored password within the 
authentication realm repository (i.e. BUILTIN).

In the current implementation, USRSSBPWD is only supported with Derby's BUILTIN authentication
scheme as well as when there is no authentication enabled (NONE scheme).

On the DRDA server, USRSSBPWD can be forced to be the only SecMec to support by setting the
property 'derby.drda.securityMechanism' to the newly introduced 
STRONG_PASSWORD_SUBSTITUTE_SECURITY string which maps to USRSSBPWD (See impl/drda/NetworkServerControlImpl.java

- derbynet/testSecMec.java functional test has been expanded to use and test USRSSBPWD security
- Full compatibility tests are running successfully.

Flow of events w/ source impacts when authenticating via SECMEC_USRSSBPWD:

On the Derby network client side (driver), strong password substitute can be set to authenticate
via the existing connection attribute 'securityMechanism'  with a value of '8'. SECMEC_USRSSBPWD
(0x8) has therefore been added to client/net/NetConfiguration.java.

Right now and as mentioned above, the security mechanism cannot be upgraded in the client
datasource due to the fact that old servers do not support USRSSBPWD and return a list of
SECMEC(s) which cannot be processed by the derby network client (see JIRA-926 & JIRA-1517)
- Eventhough USRSSBPWD was tested to be considered as a possible security mechanism upgrade
on the client, the changes in ClientBaseDataSource.java have been disabled - Logic placeholders
have been left (commented out) so that it can be re-enabled once JIRA-1517 is addressed.

(client) Flow orchestration of authentication via USRSSBPWD, is implemented in client/net/NetConnection.java
as it is currently done for other DRDA SecMec's handling- I tried to respect and follow as
much as possible the current flow infrastructure in place which is already used by similar
DRDA security mechanisms (i.e. EUSRIDPWD) - See flowUSRSSBPWDconnect().

As defined by the DRDA v3 specs, the client generates an 8-byte random seed which is sent
as part of the SECTKN parameter during ACCSEC - The DRDA server parses ACCSEC and determine
if the SECMEC is supported - It does this in by calling validateSecMecUSRSSBPWD() during the
parsing of the ACCSEC - The server rules for this implementation phase to use USRSSBPWD as
a valid SecMec for this connection are:

- Current authentication provider is Derby BUILTIN or NONE. (database and system level are
- Application requester is 'DNC' (Derby Network Client) and version of the client is >=

If the server can authenticate via USRSSBPWD , it retrieves the client seed for this connection
and generates an 8-byte random server (target) seed which gets sent back to the client as
part of the SECTKN in the ACCSECRD response. Pretty much all the server logic to handle the
communication and message parsing is in impl/drda/DRDAConnThread.java.

The client now has all the elements to generate the password substitute (client & server
seeds, userName) and calls passwordSubstituteForUSRSSBPWD().

client/am/EncryptionManager contains the logic to generate the password substitute - As previously
specified, the password cannot be recovered on the server side, hence and for the implementation
to work successfully with Derby BUILTIN authentication, the password, before being substituted,
is also hashed the same way as it is stored in Derby. Otherwise, it would not be possible
to authenticate a client with the existing BUILTIN Derby authentication scheme.

Once the password substitute has been generated, it is sent as part of the SECCHK command
which is parsed in DRDAConnThread. A connection to the database will be verified by calling
verifyUserIdPassword() in parseSECCHK() as it is done for other security mechanisms.

Internally and during user credentials validation in DRDAConnThread.getConnFromDatabaseName(),
I'm setting some attributes as part of the connection properties to pass the client and server
seeds, as well as the SecMec value for the BUILTIN authentication logic to regenerate the
password substitute - I've only expanded the BUILTIN authentication scheme to be capable of
authenticating a password substitute with some hashed stored password in Derby. The attributes
which are used to pass-in information to the BUILTIN provider are defined in org/apache/derby/iapi/reference/Attribute.java

    ** Internal attributes. Mainly used by DRDA and Derby BUILTIN
    ** authentication provider in some security mechanism context
    String DRDA_SECTKN_IN = "drdaSecTokenIn";
    String DRDA_SECTKN_OUT = "drdaSecTokenOut";

The changes are they are right now are pretty isolated - I believe that once JIRA-1517 is
addressed, we can make USRSSBPWD be the default upgraded network security mechanism for the
context where the JVMs restrict the use of EUSRIDPWD. In the meantime, these changes provide
a mean to authenticate on the network and not pass in clear-text the password during Derby

I have fixed the indentation issues due to mixing old-generation code (where 4-space tab was
not a must) with new one I had added in some of the classes.

I've fixed the master (out) canons for DerbyNet when running testSecMec.java as well.

Kathey ,as you offered, I would appreciate if you could run testSecMec under DerbyNet with
JCC 2.6 and 2.8 - I have only got JCC 2.4 and this is what II used for Derbynet.

Hope this helps.

> Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
> -----------------------------------------------------------------------------------------
>                 Key: DERBY-528
>                 URL: http://issues.apache.org/jira/browse/DERBY-528
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security
>    Affects Versions:
>            Reporter: Francois Orsini
>         Assigned To: Francois Orsini
>             Fix For:
>         Attachments: 528_diff_v1.txt, 528_diff_v2.txt, 528_SecMec_Testing_Table.txt,
528_stat_v1.txt, 528_stat_v2.txt
> This JIRA will add support for (DRDA) Strong User ID and Password Substitute Authentication
(USRSSBPWD) scheme in the network client/server driver layers.
> Current Derby DRDA network 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  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
> Strong User ID and Password Substitute Authentication (USRSSBPWD) is part of DRDA specifications
as another alternative to provide ciphered passwords across the wire.
> Support of USRSSBPWD authentication scheme will enable additional JCE's to  be used when
encrypted passwords are required across the wire.
> USRSSBPWD authentication scheme will be specified by a Derby network client user via
the securityMechanism property on the connection UR - A new property value such as ENCRYPTED_PASSWORD_SECURITY
will be defined in order to support this new (DRDA) authentication scheme.

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


View raw message