db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini" <francois.ors...@gmail.com>
Subject Re: [jira] Commented: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
Date Tue, 18 Jul 2006 23:51:36 GMT
Hi David,

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 <David.Vancouvering@sun.com > 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.
> >
>

Mime
View raw message