db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini" <francois.ors...@gmail.com>
Subject Re: [jira] Commented: (DERBY-1517) Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers
Date Thu, 24 Aug 2006 11:01:03 GMT
On 8/23/06, Sunitha Kambhampati <ksunithaghm@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.

View raw message