Yes I did in various bits and chunks as part of the comments for this JIRA. Also,am not sure that the javadoc is published for all the Derby core classes (non-published ones)...
--francois
On 7/18/06, David Van Couvering <
[EMAIL PROTECTED]
> wrote:
Thanks, Francois. Have you added this very helpful documentation, or
some form of it, to the javadocs, so it's kept with the code? It should
be very helpful for those coming after you to maintain this...
David
Francois Orsini (JIRA) wrote:
> [ 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 changes).
>
> Tests:
> - derbynet/testSecMec.java functional test has been expanded to use and test USRSSBPWD security mechanism (STRONG_PASSWORD_SUBSTITUTE_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 supported)
> - Application requester is 'DNC' (Derby Network Client) and version of the client is >= 10.2
>
> 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
> ** (SECMEC_USRSSBPWD).
> */
> 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 authentication.
>
> 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: 10.1.1.0
>> Reporter: Francois Orsini
>> Assigned To: Francois Orsini
>> Fix For: 10.2.0.0
>>
>> 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 key.
>> 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.
>
