[jira] Commented: (DERBY-928) Add ability to network server to accept connections with a certain security mechanism.

["Sunitha Kambhampati (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12365369 ] 

Sunitha Kambhampati commented on DERBY-928:
-------------------------------------------

Proposal as follows:
Property name:  derby.drda.securityMechanism
Use this property to set the security mechanism accepted by the server.  If this property is set, then client connections with the security mechanism equal to this property value will only be able to connect to the server.

This property will be static. Server must be restarted for the property to take effect.

Currently the network server has support for the following security mechanisms
1) USRIDONL (userid only),
2) USRIDPWD (clear text userid and password),
3) EUSRIDPWD (encrypted userid and password).

Syntax:
derby.drda.securityMechanism=securitymechanism
    where securityMechanism can be one of the following values - USRIDONL, USRIDPWD,EUSRIDPWD.

E.g.
derby.drda.securityMechanism=USRIDONL          // to accept connections at USRIDONL security mechanism
derby.drda.securityMechanism=EUSRIDPWD       // to accept connections at EUSRIDPWD security mechanism
derby.drda.securityMechanism=USRIDPWD         // to accept connections at USRIDPWD security mechanism

Question: Whats the best way to specify the values.
DRDA spec specifies the following secmec (securitymechanism) values.
USRIDONL = 4
USRIDPWD = 3
EUSRIDPWD = 9

>From client perspective:
Currently in the client url, one would have to pass in the integer value for securityMechanism.
ij>connect 'testdb;securityMechanism=9;user=sa;password=p1';

when using the datasource, the setSecurityMechanism(int) on the ClientDataSource can be used.
Constants are
ClientDataSource.CLEAR_TEXT_PASSWORD_SECURITY (0x03)
ClientDataSource.USER_ONLY_SECURITY (0x04)
ClientDataSource.ENCRYPTED_USER_AND_PASSWORD_SECURITY (0x09)

Given that there is different ways that the same value is represented,  some possible ways to address this:
1) Go with integer values for the property.
e.g  derby.drda.securityMechanism=9
This will mean the encrypted userid and password.
pros: consistent with what the client uses to set security mechanism in url when using drivermanager.
cons: It might be easy to make a mistake with setting number and the number by itself doesnt tell anything unless one looks up the spec/or the code.

2) Go with names used by ClientDataSource constants.
e.g. derby.drda.securityMechanism=ENCRYPTED_USER_AND_PASSWORD_SECURITY
so.
CLEAR_TEXT_PASSWORD_SECURITY would be same as drda's USRIDPWD
USER_ONLY_SECURITY would be same as drda's USRIDONL
ENCRYPTED_USER_AND_PASSWORD_SECURITY  would be same as drda's EUSRIDPWD
pros: Use these names as it is consistent with the client datasource constants.
cons: names are too long

3) Use the drda secmec values itself.
USRIDONL, USRIDPWD,EUSRIDPWD.
pros: names are short and are the secmec values used in drda spec.
cons: names are somewhat cryptic.

4) A combination of #1 & #2. Support both integer values as well as string values.
requires more code for validity checking, otherwise ok.

I lean towards #2 to be consistent with names used to represent the same security mechanism in derby. Does this seem reasonable ?
I welcome any suggestions/comments on this. Thanks.

Future possible enhancements:
1) This property could be used to have a list of security mechanisms to allow instead of just one.
2) Allow a way to set the security mechanism value in client connection url as a string instead of integer.
==============================

Behavior:
- If the property is set to a value that is invalid/unsupported , it will be rejected and an error will be thrown when starting the server.
- if this property is not set, then the server will accept connections from client with security mechanisms that are currently supported by the server.

-Client sends ACCSEC with secmec (security mechanism)  to use.
Server sees ACCSEC, reads the SECMEC value. It the server does not support the requested security mechanism, it returns a list of supported security mechanism otherwise the apprpriate reply data is generated for the requested security mechanism.
(Reference: Security flows are in DRDA manual, pg 96. Section 4.4.2.)

When server sees ACCSEC,  and if this property is set, then the server will check if the secmec value requested by client is the same security mechanism set by this property. If yes, then an appropriate reply data is generated for the requested security mechanism, else the server will return just the security mechanism set by this property to represent the security mechanisms that the server supports/accepts.

I'd appreciate comments and suggestions. Thanks much for reading this.


> Add ability to network server to accept connections with a certain security mechanism.
> --------------------------------------------------------------------------------------
>
>          Key: DERBY-928
>          URL: http://issues.apache.org/jira/browse/DERBY-928
>      Project: Derby
>         Type: New Feature
>   Components: Network Server
>     Reporter: Sunitha Kambhampati
>      Fix For: 10.2.0.0

>
> Currently the network server has support for the following security mechanisms
> 1) USRIDONL (userid only),
> 2) USRIDPWD (clear text userid and password),
> 3) EUSRIDPWD (encrypted userid and password).
> Thus the #3 encrypted userid and password security mechanism is secure with respect to the userid/password sent across the wire.  Currently there is no way to setup the network server to ensure that it accepts connections coming in at a certain security mechanism.   It seems reasonable & useful to have a server want to accept connections from clients with a particular security mechanism (e.g  lets say encrypted userid/password and reject usridpwd ie clear text userid and password)
> This jira will add support for this by adding a property to enable the server to be able to accept connections from clients with a certain security mechanism.
> --------------------
> I actually couldnt find if a rank was given to the security mechanisms in the drda spec.  If it were so, then maybe a property for setting the minimum security mechanism accepted by the server would be appropriate.

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