[jira] [Commented] (ARTEMIS-1264) Client authentication via Kerberos TLS Cipher Suites (RFC 2712)

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on ARTEMIS-1264:
----------------------------------------------------------

Commit 9fedb47c400b9a00dec08b8f3bc280fe674ad915 in activemq-artemis's branch refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=9fedb47 ]

[ARTEMIS-1310] [ARTEMIS-1264] consolidate configuration to require login configuration scope


> 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
>             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
(v6.4.14#64029)