Bug 601222 - Feature Request: support for SASL EXTERNAL with TLS/SSL
Summary: Feature Request: support for SASL EXTERNAL with TLS/SSL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 1.2
Hardware: All
OS: Linux
high
medium
Target Milestone: 1.2.2
: ---
Assignee: Gordon Sim
QA Contact: Jan Sarenik
URL:
Whiteboard:
Depends On: 533045
Blocks: 567603
TreeView+ depends on / blocked
 
Reported: 2010-06-07 13:57 UTC by Mike Cressman
Modified: 2012-02-06 17:52 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the only way for a user to connect over Secure Sockets Layer (SSL) was to authenticate using a different username, otherwise the access control list (ACL) denied the access. This update introduces a support for the EXTERNAL mechanism for Simple Authentication and Security Layer (SASL), so that users can now connect using the SSL client certificates for authentication.
Clone Of: 533045
Environment:
Last Closed: 2010-10-08 01:50:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
qpidd.log (5.40 KB, text/plain)
2010-08-06 14:08 UTC, Jan Sarenik
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0756 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Messaging security and bug fix update 1.2.2 2010-10-08 01:49:47 UTC

Comment 1 Jan Sarenik 2010-06-08 07:50:38 UTC
According to changelog of qpidc package, I understood that version
0.5.752581-36_cust already contains the change. So I installed latest
build, which is qpidd-ssl-0.5.752581-39_cust.el5 on RHEL5 i386 and
it did not work.

[root@slanina bz533045-2]# ./run 
Creating certificates... done
2010-jun-08 09:48:21 critical Broker start-up failed: Error in command line options: unknown option ssl-require-client-authentication
Use --help to see valid options

Comment 2 Gordon Sim 2010-06-08 08:17:27 UTC
ssl-require-client-authentication was not a new option introduced with this change. That error implies/suggests that the ssl module was not loaded. what does /usr/sbinqpidd --help show? Does it list the ssl options?

Comment 4 Jan Sarenik 2010-06-08 08:59:55 UTC
Verified on RHEL5 i386, qpidd-ssl-0.5.752581-39_cust.el5

Comment 5 Jan Sarenik 2010-06-08 10:46:36 UTC
Verified also on RHEL5 x86_64, qpidd-ssl-0.5.752581-39_cust.el5

Comment 7 Mike Cressman 2010-07-30 20:50:48 UTC
Please reverify with errata build -41 when we get it to candidate

Comment 8 Jan Sarenik 2010-08-04 06:46:29 UTC
I will verify as soon as qpidc-0.5.752581-41 appears in Brew.

Comment 9 Jan Sarenik 2010-08-06 10:20:56 UTC
I am having problems with this build (-41) on both RHELs, both archs.
Will write more soon.

Comment 10 Jan Sarenik 2010-08-06 14:08:20 UTC
Created attachment 437162 [details]
qpidd.log

redhat-release-5Server-5.5.0.2 x86_64
qpidc-perftest-0.5.752581-41.el5
qpidd-0.5.752581-41.el5
qpidd-ssl-0.5.752581-41.el5
qpidc-ssl-0.5.752581-41.el5

1. I create all the certificates using certutil (from nss-tools):
    echo "hoj11597" > pwdfile.txt
    echo "aoeunthao eanote haont he432 aontueh" > noise.txt
    certutil -N -d . -f pwdfile.txt
    certutil -G -d . -z noise.txt -f pwdfile.txt
    certutil -S -n ourCA -s "cn=CAcert" -x -t "CT,," -m 1000 -v 120 -d . \
        -z noise.txt -f pwdfile.txt
    certutil -S -n ourServer -s "CN=$HOSTNAME,O=acme,ST=Mass,C=US" \
        -c ourCA -t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt
    certutil -S -n ourClient -s "CN=bob,O=acme,ST=Mass,C=US" \
        -c ourCA -t "u,u,u" -m 1002 -v 120 -d . -z noise.txt -f pwdfile.txt
    certutil -L -d . -n ourCA -a > cacert.asc

2. I run qpidd using following command:
    qpidd -d --ssl-require-client-authentication \
    --ssl-cert-db $PWD \
    --ssl-cert-password-file $PWD/pwdfile.txt \
    --ssl-cert-name ourServer \
    --auth yes --log-to-file qpidd.log -t

3. I run perftest:
    export QPID_LOAD_MODULE=`rpm -ql qpidc-ssl | grep sslconnector.so`
    export QPID_SSL_CERT_NAME=ourClient
    export QPID_SSL_CERT_DB=$PWD
    export QPID_SSL_CERT_PASSWORD_FILE=$PWD/pwdfile.txt
    perftest --count 10 --port 5671 -P ssl -b $HOSTNAME --summary

When prompted for password, I press ENTER.

4. Stop the qpidd:
    qpidd -q

(and if I repeat step #3 a couple of times, I get a core dump
from perftest)

My question is, why is PLAIN password being asked for?

Comment 11 Jan Sarenik 2010-08-06 14:17:22 UTC
It is vital to add --ssl-sasl-no-dict to qpidd options.

Comment 12 Gordon Sim 2010-08-06 14:25:00 UTC
--ssl-sasl-no-dict restricts the valid mechanisms (for ssl connections); if not present the client can select from all those configured for the broker as usual. If the client does not explicitly choose one the choice will be made by the cyrus sasl libs (and is essentially random it seems).

So to test EXTERNAL, either choose it explicitly (as for any other mechanism) or force it to be the only one available by specifying --ssl-sasl-no-dict.

Comment 13 Jan Sarenik 2010-08-18 08:35:53 UTC
Verified on RHEL4 and RHEL5, builds
  qpidc-0.5.752581-41.el4
  qpidc-0.5.752581-41.el5

Comment 14 Jan Sarenik 2010-08-18 08:59:16 UTC
Both architectures, of course...

       | RHEL4 | RHEL5 |
------------------------
i386   |  OK   |  OK   |
x86_64 |  OK   |  OK   |

Comment 15 Gordon Sim 2010-09-24 16:29:07 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: Desire to utilise the client identity as authenticated by SSL in authorisation.

Consequence: Without this feature clients connecting over SSL would need to authenticate themselves by some other username for them to have permission granted via ACLs.

Change: Allow the authenticated identity from the underlying SSL connection to be used. This is done by supporting the EXTERNAL mechanism defined for SASL.

Result: Can now use the identity as authenticated by SSL (i.e. based on the clients certificate) when writing ACL rules.

Comment 16 errata-xmlrpc 2010-10-08 01:50:00 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0756.html

Comment 17 Jaromir Hradilek 2010-10-08 13:35:03 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,7 +1 @@
-Cause: Desire to utilise the client identity as authenticated by SSL in authorisation.
+Previously, the only way for a user to connect over Secure Sockets Layer (SSL) was to authenticate using a different username, otherwise the access control list (ACL) denied the access. This update introduces a support for the EXTERNAL mechanism for Simple Authentication and Security Layer (SASL), so that users can now connect using the SSL client certificates for authentication.-
-Consequence: Without this feature clients connecting over SSL would need to authenticate themselves by some other username for them to have permission granted via ACLs.
-
-Change: Allow the authenticated identity from the underlying SSL connection to be used. This is done by supporting the EXTERNAL mechanism defined for SASL.
-
-Result: Can now use the identity as authenticated by SSL (i.e. based on the clients certificate) when writing ACL rules.


Note You need to log in before you can comment on or make changes to this bug.