[ http://issues.apache.org/jira/browse/DERBY-528?page=all ]
Francois Orsini updated DERBY-528:
----------------------------------
Attachment: 528_stat_v2.txt
528_diff_v2.txt
Thanks for the comments / feedback.
I have attached some new changes which include some bug fixes. Merged with the
latest as well.
@Bernt
- I have removed NetConnectionRequest.java
- USRIDPWD is the default if EUSRIDPWD was not supported by the client - I had
made the default USRSSBPWD (strong password substitute) as it can be supported
by all the clients >= 10.2 and JVM from 1.3.1 - I have reverted back to a
default of USRIDPWD because of DERBY-926 which I have to fix as if I make
USRSSBPWD the default, it will cause a protocol exception on derby servers
prior to 10.2; until DERBY-926 is fixed and can be handled better on the
client..as well as doing the right thing on the server when returning supported
SECMEC's as part of ACCSECRD.
- Regarding EncryptionManager and DecryptionManager - there are comments in
the code stating that these classes will be refactored to be more modular as
they share a lot of similar code - It will also be easier to add support for
other DRDA security mechanisms - I will log a JIRA and would live to implement
this separately as I had started to do it when we were on the topic of shared
code/classes, some months ago.
So for now, USRSSBPWD is no longer the default after EUSRIDPWD in the client
until DERBY-926 is fixed or a temporary handling of the protocol exception
reported as in DERBY-926 is duoable in Derby's client driver.
@Kathey - Yes, I have tested all the compatibility combos - my main issue is
DERBY-926 which causes the COMPAT test to fail when going CLIENT_10.2---->
SERVER_PRE_10_2 - otherwise all the tests were passing...If I can put a
temporary workaround to handle the protocol exception (DERBY-926) in the
client, then I will put USRSSBPWD back as the default secMec to use on the
client _when_ EUSRIDPWD cannot be used...In the meantime, we can leave USRIDPWD
as the 2nd default in ClientBaseDataSource until either a workaround is found
or DERBY-926 is fixed (after the commit of this JIRA). I have traced that
correct message exchanges is happening as well.
> 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
> Type: New Feature
> Components: Security
> Versions: 10.1.1.0
> Reporter: Francois Orsini
> Assignee: Francois Orsini
> Fix For: 10.2.0.0
> Attachments: 528_SecMec_Testing_Table.txt, 528_diff_v1.txt, 528_diff_v2.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.
--
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
