db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
Date Tue, 18 Jul 2006 22:04:11 GMT
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.
> 

Mime
View raw message