[jboss-jira] [JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection

[Richard Achmatowicz (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006485#comment-13006485 ] 

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)