[jdev] Signing (Was: Alternate MUC Authentication Mechanisms)

[Kurt Zeilenga]

On Oct 16, 2010, at 6:55 PM, Peter Saint-Andre wrote:

>> And, yes, this could be used as a way to 'authenticate' authorized
>> users into rooms (clients can sign the join stanzas, the MUC service
>> can verify those signatures, and then choose whether to allow the
>> join or not).
> 
> That seems a lot less flexible than SASL, because you're basically
> allowing only certificate-based authentication.  But maybe I'm missing
> someting about your proposal...

It's not a proposal, per say, just confirming the possibility Dave noted.  A possibility which seems not be generally applicable.

Personally, I don't see much general applicability for SASL use here either, at least using 'common' mechanisms.  Now there might be some applicability of using federated authentication in MUC authorization, and SASL might path to that.

But at this stage, I think I'll wait for real driver before push for anything in particular here.  That is, this is all just food for thought.

I mean, what's the problem to be solved here.  In the OP:
> I'd like to have better guarantees on who is actually in the room.

Just having 'stronger' authentication does little to guarantee where's the room traffic coming from or going to.  With just 'stronger' authentication, one would still have to worry about 'hijacking' of the subscriber's session by the subscriber's server, and the subscriber's server filtering content to the subscriber, and doing other things with room content; and more.   To prevent hijacking, content injection, and other such attacks, one would need to have 'session integrity' between the subscriber and the MUC service.  And to provide eavesdropping, session encryption.   Sounds like a job for a entity-to-entity secure tunneling solutions.

-- Kurt