Remoting 3 Security

[dmlloyd]

Some random thoughts about security in Remoting 3.

Authentication - SASL looks like a good option to support client authentication. The API makes it look pretty easy. I know that SRP was proposed at one point as well. Can an SRP mechanism be added to SASL? My first glance makes me think "yes". But I don't know how this would work with other mechanisms (e.g. GSS).

Encryption - currently there is SSL support for certain protocols (http mainly?). It does not look to me like SSL is supported for socket/multiplex/bisocket (see my wiki posting for how/why these could be unified). SSL/TLS should be available for the "default" transport for sure.

[dmlloyd]

One other thing - from what I can see, the only way to allow a client to authenticate a server (or, to have two peers authenticate each other) with SASL is to have both an SASLClient and an SASLServer on both sides of the connection... this means that each chunk has to be processed twice. I'm not sure that SASL is appropriate for this application.

[anil.saldhana]

1) SSL/TLS should be available on the transport as a choice and not default.
2) I am interested in encryption provided as an option when the ssl setup is not acceptable and/or user just needs to avoid man-in-the-middle attacks. An issue with encryption is symmetric key management. This is where SRP is interesting. One end does userid/pwd. The server does prime numbers. They interact and agree on a session key.
3) SRP can be done as a JCA provider for GSS. As far as I know, SASL does challenge/response. So SRP should fit in pretty easily. There is code already written by Scott (probably in the varia module) that can be adapted.
4) An interesting thing that I have noted (but not dealt into deeply) is when the client seeks a stub/proxy from the server, the server can send in SASL chunks to the client to avoid 1 round trip. This is the PUSH on the initial proxy seek.

[dmlloyd]

1) SSL/TLS should be available on the transport as a choice and not default.

Yes, this is what I intended to say.

2) I am interested in encryption provided as an option when the ssl setup is not acceptable and/or user just needs to avoid man-in-the-middle attacks. An issue with encryption is symmetric key management. This is where SRP is interesting. One end does userid/pwd. The server does prime numbers. They interact and agree on a session key.
3) SRP can be done as a JCA provider for GSS. As far as I know, SASL does challenge/response. So SRP should fit in pretty easily. There is code already written by Scott (probably in the varia module) that can be adapted.

OK, so an SASL marshaller would cover this. My understanding is clearer. Thanks for the feedback.

[anil.saldhana]

Cool. An additional note that I just want to place here for archival purpose is that this discussion has been around securing the transport layer only and use of SASL for that.

For JBoss Security in general, SASL can be between the client security interceptors and the server security interceptors.
http://jira.jboss.com/jira/browse/SECURITY-46

So these two areas are separate.

[anil.saldhana]

I may get to the JSR-196 implementation next month. We should certainly use JSR-196 to externalize authentication modules at either end of the transport. I will get back to you on this once I finish the implementation.