db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
Date Mon, 07 Aug 2006 19:10:17 GMT
     [ http://issues.apache.org/jira/browse/DERBY-528?page=all ]

Francois Orsini updated DERBY-528:
----------------------------------

    Attachment: 528_stat_v4.txt
                528_diff_v4.txt

Sunitha, many thanks for this excellent and thorough review.

I've addressed all of the comments - I've run derbyall as well as derbynet/testSecMec.java
and derbynet/dataSourcePermissions_net.java under different JVM's.

  > Spurious diffs because of tabs/spaces etc

Took care of them.

  > Additional testing with securityMechanism=8 and BUILTIN

When I had USRSSBPWD upgraded by default, it was exercised a lot more, throughout testSecMec.java
and dataSourcePermissions_net.java

I have added a new test as part of testSecMec.java - method is testUSRSSBPWD_with_BUILTIN()

a) Actually, these are internal connection attributes, which are passed on the connection
URL. There really are connection attributes except that they are not exposed - in a similar
way as the DRDAID_ATTR attribute. Some attributes such as CRYPTO_EXTERNAL_KEY_VERIFY_FILE
and referenced in DERBY-1151 are not.

b) The 2 checks are necessary as support for USRSSBPWD SecMec only works if Derby's authentication
scheme is BUILTIN or NONE. It has to be done this way as we cannot risk to go ahead and fail
authenticating against the Derby engine later during parseSECCHK() - As the password substitute
cannot be decrypted, I know for sure that I can regenerate it via the updated BUILTIN scheme
which now gets support for it - And as far as the NONE authentication scheme, we do not care
as we never check the password, so the password substitute will never get checked...This has
to be checked/verified early enough and hence why it is being done during parseACCSEC().

c) Yes, dataSource_.getUser() can be different than dataSource_.propertyDefault_user if a
non-null user is specified as part of the getConnection() in ClientDataSource or/and if some
connectionAttributes are set via setConnectionAttributes() - also, datasource values can 
be updated when updateDataSourceValues() gets called in ClientDataSource.getConnection() -
I did not want to update user_ as the processing of USRSSBPWD is pretty isolated - I think
I could do it but I might want to treat it as a separate JIRA for the simple reason that even
with other DRDA security mechanism such as EUSRIDPWD, we keep encrypting the original userName
and not the one that gets passed via connection attributes...I think this needs to be addressed
as a separate JIRA which I will enter to also fix the current  behavior with some other SecMec...This
of course, will *not* have any impact on the user authentication.

Issues:

1) I had noted that one as well- I have fixed both EncryptionManager.java and AuthenticationServiceBase.java
to use toHexByte() instead.

2) I removed it because it was duplicated and therefore set twice in the the updateDataSourceValues()
method

3) Took care of them all

4) Took care of them all - going to enter a JIRA for the toHexByte, toHexString methods to
be reconciled into one location when we have fully 

addressed the code sharing aspect of things.

Ensured Javadoc was generated properly.

Thanks.

Am hoping Kathey can run testSecMec with JCC 2.6 and 2.8 and generate the 2 additional testSecMec.out
master canon output files for DerbyNet...

> 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
>          Issue Type: New Feature
>          Components: Security
>    Affects Versions: 10.1.1.0
>            Reporter: Francois Orsini
>         Assigned To: Francois Orsini
>             Fix For: 10.2.0.0
>
>         Attachments: 528_diff_v1.txt, 528_diff_v2.txt, 528_diff_v3.txt, 528_diff_v4.txt,
528_SecMec_Testing_Table.txt, 528_stat_v1.txt, 528_stat_v2.txt, 528_stat_v3.txt, 528_stat_v4.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

        

Mime
View raw message