[
https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz edited comment on JGRP-1883 at 9/26/14 10:14 AM:
---------------------------------------------------------------------
That isn't what I had in mind... and also there would have to be a lot of mechanism
added to the protocol to make a scheme which reuses the SaslClient and SaslServer
wrap/unwrap functions work in any case. What I had in mind is adding functionality to the
JGroups SASL layer so that, from the outside, it looks and is configured as a regular SASL
framework, supporting the QoP features mentioned above. Internally, it would bypass the
SaslClient and SaslServer wrap/uwrap functions (which is what Tristan is referring to) and
use the protocols and design of ENCRYPT to enforce integrity and confidentiality in a
multicast setting..
Otherwise, we will always be in the situation where we say "JGroups supports
SASL" when in fact it does not; not in the sense that the QoP features of SASL are
not there for use for *any* mechanism and we always have to add in an additional ENCRYPT
layer to make up the shortfall on the integrity and confidentiality side. In that case, I
don't see what the advantage of having a non fully-functional SASL layer is anyway. It
seems like we want to move to a standard for configuring security, but not the whole way.
As for David's remark, we could consider the shortcomings that he mentions and see to
what extent they apply at present to ENCRYPT. Because as far as I understand it, ENCRYPT
is basically SSL/TLS for JGroups. But that's potentially a separate issue.
was (Author: rachmato):
That isn't what I had in mind... and also there would have to be a lot of mechanism
added to the protocol to make a scheme which reuses the SaslClient and SaslServer
wrap/unwrap functions work in any case. What I had in mind is adding functionality to the
JGroups SASL layer so that, from the outside, it looks and is configured as a regular SASL
framework, supporting the QoP features mentioned above. Internally, it would bypass the
SaslClient and SaslServer wrap/uwrap functions (which is what Tristan is referring to) and
use the protocols and design of ENCRYPT to enforce integrity and confidentiality..
Otherwise, we will always be in the situation where we say "JGroups supports
SASL" when in fact it does not; not in the sense that the QoP features of SASL are
not there for use for *any* mechanism and we always have to add in an additional ENCRYPT
layer to make up the shortfall on the integrity and confidentiality side. In that case, I
don't see what the advantage of having a non fully-functional SASL layer is anyway. It
seems like we want to move to a standard for configuring security, but not the whole way.
As for David's remark, we could consider the shortcomings that he mentions and see to
what extent they apply at present to ENCRYPT. Because as far as I understand it, ENCRYPT
is basically SSL/TLS for JGroups. But that's potentially a separate issue.
Extend SASL protocol to handle Quality of Protection
-----------------------------------------------------
Key: JGRP-1883
URL:
https://issues.jboss.org/browse/JGRP-1883
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.5
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Fix For: 3.6
SASL implementations generally provide authentication and encryption services to
communication protocols.
At present, the JGroups SASL protocol layer handles only authentication of a client
joining a group; it does not support encryption of messages (unicast and multicast)
passing through the SASL layer. This is presently handled by the separate ENCRYPT layer.
It would be nice to provide an integrated and complete solution for authentication and
encryption for JGroups based on SASL. This could be achieved by adding functionality from
ENCRYPT to the SASL layer.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)