Re: [jira] Commented: (DERBY-1517) Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers

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

Hi Francois, Thanks for taking this task on.

Francois Orsini (JIRA) wrote:

><snip>....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).
>
>
>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,
>
It seems to me we need some amount of negotiation between the server and 
client on the security mechanism to use.  (correct?)
E.g. For having secmec 8 to be used by default by the 10.2 client, the 
old server will not recognize this and will currently send a list of 
supported secmecs (in the wrong format -derby926).  Changes will be 
needed in the client to parse these values and then choose one of the 
secmec's that is valid for the server.   Were you planning on making 
these changes so secmec 8 can be used as the fallback default or did you 
have some other approach in mind.   Are you targeting this for 10.2.

 I also noticed a problem in the client, using the default to secmec 9.  
I think it is not sufficient to only check if client jvm can support 
eusridpwd as is done currently (derby-962) but we need to verify if the 
server can support the particular secmec.  At the very least, to avoid 
regressing, we should revert back to secmec 3. I'll open a jira to fix 
this. I'll link all these related jiras (derby-1675,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.
>  
>
+1.

Thanks,
Sunitha.

Re: [jira] Commented: (DERBY-1517) Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers

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

On 8/23/06, Sunitha Kambhampati <ks...@gmail.com> wrote:
>
> Hi Francois, Thanks for taking this task on.
>
> Francois Orsini (JIRA) wrote:
>
> ><snip>....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).
> >
> >
> >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,
> >
> It seems to me we need some amount of negotiation between the server and
> client on the security mechanism to use.  (correct?)


That is correct - This is what I have been implementing/testing thus far.

E.g. For having secmec 8 to be used by default by the 10.2 client, the
> old server will not recognize this and will currently send a list of
> supported secmecs (in the wrong format -derby926).  Changes will be
> needed in the client to parse these values and then choose one of the
> secmec's that is valid for the server.   Were you planning on making
> these changes so secmec 8 can be used as the fallback default or did you
> have some other approach in mind.   Are you targeting this for 10.2.


Originally as I had implemented and tested it as part of derby-528, secmec 8
was the second best default after secmec 9 (32-byte DH key support required)
- Now with the new negotiation logic,  if the target server cannot support
secmec 8, I would have picked secmec 3. Yes, am targeting this for 10.2 - am
just doing testing and fixing right now...

I also noticed a problem in the client, using the default to secmec 9.
> I think it is not sufficient to only check if client jvm can support
> eusridpwd as is done currently (derby-962) but we need to verify if the
> server can support the particular secmec.  At the very least, to avoid
> regressing, we should revert back to secmec 3. I'll open a jira to fix
> this. I'll link all these related jiras (derby-1675,derby-926)


Yep, this is a valid one as well...and I think we should address it for 10.2.
Well, with the client/server negotiation in-place, we should be able to
handle that one as well - the only additional (logic) work is to check if
secmec 9 can be used on the server and as far as I know, this logic needs to
be implemented - would be good to fix all these issues...

>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.



>
> >
> +1.
>
> Thanks,
> Sunitha.
>