[
https://issues.apache.org/jira/browse/ARTEMIS-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425447#comment-17425447
]
ASF subversion and git services commented on ARTEMIS-1264:
----------------------------------------------------------
Commit a5b5a504e0426daa1f2598582ea3252f8bca4cf8 in activemq-artemis's branch
refs/heads/main from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a5b5a50 ]
ARTEMIS-3038: unwind effect of defunct changes from ARTEMIS-1264
Follows earlier test removal in a3de3d4c75ba1482706e8c42a5c9b0f9811901eb
> Client authentication via Kerberos TLS Cipher Suites (RFC 2712)
> ---------------------------------------------------------------
>
> Key: ARTEMIS-1264
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1264
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Affects Versions: 2.1.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Fix For: 2.2.0
>
>
> Allow a client authenticated with a kerberos credential to authenticate to
> the broker using SSL via the Kerberos cipher suites.
> next steps:
> - -ensure mapping from kerberos principal to broker identity is locked down-
> -- https://github.com/apache/activemq-artemis/pull/1388
> - -ensure jms client config is trivial-
> -- the connector properties can be configured in the same way as for core.
> - -validate broker side ticket expiry and renewal-
> - work with qpid-jms to validate amqp client (on hold)
> - validate with non java - proton-c client ({color:red}problem{color})
> Interop with non java clients is a problem. OpenSSL [has removed
> support|http://openssl.6102.n7.nabble.com/openssl-users-Kerberos-tp57906p58095.html]
> for [rfc2712|https://www.ietf.org/rfc/rfc2712.txt].
> While reusing the TLS handshake was a good idea at the time; it has issues
> (non compatible impl between openssl and sun) and the world has moved on to
> layering authentication over TLS rather than with.
> This makes sense b/c kerberos does two things, authentication over an
> insecure connection and session encryption over that connection. With rfc2712
> the available session encryption options are known to be insecure, best to
> leave encryption entirely to TLS.
> In a java only scenario (sun jdk on both ends), using this feature for
> kerberos *authentication only* is viable.
> For example, if clients use username/password for authentication and TLS to
> encrypt the connection to secure the password, but don't care about
> encrypting the rest of the data, there is some value here.
> They can swap the username/password for a kerberos token and achieve
> authentication. They will essentially drop encryption because the cypher in
> use is insecure. Note a kerberos ticket is designed to be validated across an
> insecure channel.
> The modern approach is to layer kerberos authentication over TLS using
> something like the GSSAPI and SASL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
