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

Reply via email to