db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-928) Add ability to network server to accept connections with a certain security mechanism.
Date Tue, 07 Feb 2006 00:46:57 GMT
    [ 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


Mime
View raw message