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.
