Derby
  1. Derby
  2. DERBY-1517

Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Network Client
    • Labels:
      None
    • Environment:
      The Derby network client should be made capable of handling a list of SECMEC(s) returned by previously released DRDA Derby network servers
    • Urgency:
      Normal

      Description

      Currently, the Derby DRDA network server does not properly return the list of SECMEC(s) it can support if a client is requesting to authenticate with a non-supported SECMEC (see JIRA-926 - http://issues.apache.org/jira/browse/DERBY-926)

      The motivation for this JIRA is to add the logic for the Derby client to be capable of parsing the list of supported SECMEC(s) returned by previous released Derby network servers (pre-JIRA-926 Fix) - This is necessary for backwards compatibility with older servers - This issue has been even more visible as Derby-528 introduces support for a new DRDA security mechanism (Strong Password Substitute), which causes a DRDA protocol exception when trying to authenticate with the new supported mechanism against older Derby DRDA servers (JIRA-926 issue)

      JIRA-926 has to be fixed nonetheless on the server side to properly return the list of supported SECMEC(s) in conformance with the DRDA (DDM) specs - This JIRA focuses on the client side to do its best and be capable of parsing a list of SECMEC(s) returned pre-926 fix.

      Ultimately, the derby network client can be made capable of parsing a list of SECMEC(s) from pre-926 fixed (older) and post-926 fixed servers...

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          Unknown release vehicle.

          Show
          Rick Hillegas added a comment - Unknown release vehicle.
          Hide
          Rick Hillegas added a comment -

          Moving to 10.2.2.0.

          Show
          Rick Hillegas added a comment - Moving to 10.2.2.0.
          Hide
          Francois Orsini added a comment -

          I know you figured it out already Kathey - am just adding a comment here for the record.

          You're right that there is no longer an issue with a DERBY-528 and a 10.2 client connecting to a 10.1 derby server, I reverted back to having CLEAR_TEXT_PASSWORD being the default SECMEC to use on client datasource (if EUSRIDPWD cannot be selected because of the current JVM restricting the use of 256-bit DH keys).

          So, yes as it stands right now, the current DERBY-528 do not cause impact changes for existing users of Derby whom would use a 10.2 client for instance.

          Without DERBY-1517, a DRDA protocol exception will be raised if an invalid securityMechanism is specified for the server the client connects to - This was a fairly non-blocking and non-visible issue since all pre-DERBY-528 DRDA secmec were supported by pretty much all existing Derby DRDA servers out there. Eventhough DERBY-926 needs to be addressed, DERBY-1517 will allow a new DRDA secmec (like USRSSBPWD) to be used as a fall-back default when EUSRIDPWD cannot be used, and no longer causing the protocol exception described in DERBY-926. Also, the sooner we fix DERBY-926, the better it is for no longer carrying servers that are returning the list of supported secmec's incorrectly.

          Thanks,

          Show
          Francois Orsini added a comment - I know you figured it out already Kathey - am just adding a comment here for the record. You're right that there is no longer an issue with a DERBY-528 and a 10.2 client connecting to a 10.1 derby server, I reverted back to having CLEAR_TEXT_PASSWORD being the default SECMEC to use on client datasource (if EUSRIDPWD cannot be selected because of the current JVM restricting the use of 256-bit DH keys). So, yes as it stands right now, the current DERBY-528 do not cause impact changes for existing users of Derby whom would use a 10.2 client for instance. Without DERBY-1517 , a DRDA protocol exception will be raised if an invalid securityMechanism is specified for the server the client connects to - This was a fairly non-blocking and non-visible issue since all pre- DERBY-528 DRDA secmec were supported by pretty much all existing Derby DRDA servers out there. Eventhough DERBY-926 needs to be addressed, DERBY-1517 will allow a new DRDA secmec (like USRSSBPWD) to be used as a fall-back default when EUSRIDPWD cannot be used, and no longer causing the protocol exception described in DERBY-926 . Also, the sooner we fix DERBY-926 , the better it is for no longer carrying servers that are returning the list of supported secmec's incorrectly. Thanks,
          Hide
          Kathey Marsden added a comment -

          I want to understand the user impact of this issue with and without the patch for DERBY-528. Do I understand the description correctly that if DERBY-528 patch is applied, 10.2 clients do not work with 10.1 servers but without the DERBY-528 patch there is no impact on users?

          Thanks

          Kathey

          Show
          Kathey Marsden added a comment - I want to understand the user impact of this issue with and without the patch for DERBY-528 . Do I understand the description correctly that if DERBY-528 patch is applied, 10.2 clients do not work with 10.1 servers but without the DERBY-528 patch there is no impact on users? Thanks Kathey

            People

            • Assignee:
              Unassigned
              Reporter:
              Francois Orsini
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development