[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme

["Francois Orsini (JIRA)" <de...@db.apache.org>]

     [ 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

Re: [jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme

[Francois Orsini <fr...@gmail.com>]

On 7/14/06, Sunitha Kambhampati <ks...@gmail.com> 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.
>

Re: [jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme

[Sunitha Kambhampati <ks...@gmail.com>]

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.