[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Kathey Marsden updated DERBY-528: - Fix Version: 10.2.0.0 (was: 10.1.2.0) Changing to 10.2 instead of the 10.1.2 bug fix release since this is a new feature. > 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 > > 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
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Francois Orsini updated DERBY-528: -- Attachment: 528_SecMec_Testing_Table.txt Updated testing table for the testSecMec.java DRDA security mechanism test(s) - added tests combo for Strong Password Substitute DRDA security mechanism (SECMEC_USRSSBPWD). > 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_stat_v1.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
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Francois Orsini updated DERBY-528: -- Attachment: 528_stat_v1.txt svn status of the files impacted by the changes to support (SECMEC_USRSSBPWD) > 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_diff_v1.txt, 528_stat_v1.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
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Francois Orsini updated DERBY-528: -- Attachment: 528_diff_v1.txt These are the changes to support Strong Password Substitute DRDA security mechanim (SECMEC_USRSSBPWD) in Derby's network client driver and network server code. Am also going to post a description of the changes to help the review. > 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_diff_v1.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
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ 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
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Francois Orsini updated DERBY-528: -- Attachment: 528_stat_v3.txt 528_diff_v3.txt Here is a new updated changes package based on earlier comments. - Fixed indentation issues - Added DerbyNet testSecMec updated canon (out) master files (missing JCC 2.6 and 2.8 for testSecMec) - Fixed a few comments in the code > 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_diff_v3.txt, > 528_SecMec_Testing_Table.txt, 528_stat_v1.txt, 528_stat_v2.txt, > 528_stat_v3.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
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Rick Hillegas updated DERBY-528: Urgency: Normal > 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_diff_v3.txt, > 528_SecMec_Testing_Table.txt, 528_stat_v1.txt, 528_stat_v2.txt, > 528_stat_v3.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
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Francois Orsini updated DERBY-528: -- Attachment: 528_stat_v4.txt 528_diff_v4.txt Sunitha, many thanks for this excellent and thorough review. I've addressed all of the comments - I've run derbyall as well as derbynet/testSecMec.java and derbynet/dataSourcePermissions_net.java under different JVM's. > Spurious diffs because of tabs/spaces etc Took care of them. > Additional testing with securityMechanism=8 and BUILTIN When I had USRSSBPWD upgraded by default, it was exercised a lot more, throughout testSecMec.java and dataSourcePermissions_net.java I have added a new test as part of testSecMec.java - method is testUSRSSBPWD_with_BUILTIN() a) Actually, these are internal connection attributes, which are passed on the connection URL. There really are connection attributes except that they are not exposed - in a similar way as the DRDAID_ATTR attribute. Some attributes such as CRYPTO_EXTERNAL_KEY_VERIFY_FILE and referenced in DERBY-1151 are not. b) The 2 checks are necessary as support for USRSSBPWD SecMec only works if Derby's authentication scheme is BUILTIN or NONE. It has to be done this way as we cannot risk to go ahead and fail authenticating against the Derby engine later during parseSECCHK() - As the password substitute cannot be decrypted, I know for sure that I can regenerate it via the updated BUILTIN scheme which now gets support for it - And as far as the NONE authentication scheme, we do not care as we never check the password, so the password substitute will never get checked...This has to be checked/verified early enough and hence why it is being done during parseACCSEC(). c) Yes, dataSource_.getUser() can be different than dataSource_.propertyDefault_user if a non-null user is specified as part of the getConnection() in ClientDataSource or/and if some connectionAttributes are set via setConnectionAttributes() - also, datasource values can be updated when updateDataSourceValues() gets called in ClientDataSource.getConnection() - I did not want to update user_ as the processing of USRSSBPWD is pretty isolated - I think I could do it but I might want to treat it as a separate JIRA for the simple reason that even with other DRDA security mechanism such as EUSRIDPWD, we keep encrypting the original userName and not the one that gets passed via connection attributes...I think this needs to be addressed as a separate JIRA which I will enter to also fix the current behavior with some other SecMec...This of course, will *not* have any impact on the user authentication. Issues: 1) I had noted that one as well- I have fixed both EncryptionManager.java and AuthenticationServiceBase.java to use toHexByte() instead. 2) I removed it because it was duplicated and therefore set twice in the the updateDataSourceValues() method 3) Took care of them all 4) Took care of them all - going to enter a JIRA for the toHexByte, toHexString methods to be reconciled into one location when we have fully addressed the code sharing aspect of things. Ensured Javadoc was generated properly. Thanks. Am hoping Kathey can run testSecMec with JCC 2.6 and 2.8 and generate the 2 additional testSecMec.out master canon output files for DerbyNet... > 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_diff_v3.txt, > 528_diff_v4.txt, 528_SecMec_Testing_Table.txt, 528_stat_v1.txt, > 528_stat_v2.txt, 528_stat_v3.txt, 528_stat_v4.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 encrypt
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Francois Orsini updated DERBY-528: -- Attachment: 528_stat_v5.txt 528_diff_v5.txt Sunitha/Rick - Please find v5 of the diffs and stat attached. I have taken care of the latest posted comments 1) and 2) as well as run derbyall. Thanks. > 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_diff_v3.txt, > 528_diff_v4.txt, 528_diff_v5.txt, 528_SecMec_Testing_Table.txt, > 528_stat_v1.txt, 528_stat_v2.txt, 528_stat_v3.txt, 528_stat_v4.txt, > 528_stat_v5.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
Re: [jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
Francois Orsini (JIRA) wrote: 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. I thought DERBY-926 was a server issue. Is that not the case ? Thanks, Sunitha.
Re: [jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
On 7/14/06, Sunitha Kambhampati <[EMAIL PROTECTED]> wrote: Francois Orsini (JIRA) wrote: >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. > > I thought DERBY-926 was a server issue. Is that not the case ? Hi Sunitha, Yes it is - I meant to say that the DRDA protocol exception is documented in DERBY-926 and that eventhough this bug has to be fixed on the server side, it would be good to try and parse in the network client, the list of SECMEC(s) returned by older servers which won't have the fix to DERBY-926, even when this last one is fixed. I have entered DERBY-1517 for that and was hoping to be able to parse the current and incorrectly formatted list of SECMEC(s) returned, instead of getting a DRDA protocol exception raised when a securityMechanism is sent to a server which does not support it... Cheers, --francois Thanks, Sunitha.
