activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ARTEMIS-1264) Client authentication via Kerberos TLS Cipher Suites (RFC 2712)
Date Thu, 13 Jul 2017 10:23:00 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074589#comment-16074589
] 

Gary Tully edited comment on ARTEMIS-1264 at 7/13/17 10:22 AM:
---------------------------------------------------------------

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. 

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.


was (Author: gtully):
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
 - validate broker side ticket expiry and renewal
 - work with qpid-jms to validate amqp client
 - validate with non java - proton-c client

> 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
>
> Allow a client authenticated with a kerberos credential to authenticate to the broker
using SSL via the Kerberos cipher suites.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message