[JDEV] Jabber server in Java

[Iain Shigeoka]

At 01:52 PM 7/3/2001 -0700, you wrote:

>>I like the debate.  :)  I should put in the caveat that this is a
>>discussion of the "most secure" mode of the server.  Clients may relay
>>these requirements as needed (not all messages must be encrypted or
>>signed, you can send plain text messages as you like (however the server
>>on the recipient may refuse messages that aren't signed or encrypted)).
>
>This sounds like something that a centralized (maybe residing on the 
>server) policy engine could do. The policy engine could always enforce 
>checks to make sure messages follow the requirements. I am also not too 
>favorably inclined towards a scenario that allows a server to peek into 
>messages exchanged between clients. Logging of messages is maybe better 
>left to the client and the log may even be better off being stored on the 
>client.

Yes.  I see two policies in effect.  One for the server to allow the server 
admin to control the server's consumption of resources and usage (allow 
only signed documents, allow only messages from authenticated connections, 
etc).  The second policy would be from a user.  Accept only signed 
messages, etc.  A declarative security policy seems best suited to this.

>>I think the server should only have access to these pieces of information:
>>
>>Sender (indicated by JID & signature)
>>Recipient (indicated by JID & signature)
>>Quality of Service Descriptors
>>
>>If you want to log information at the "server" it can only be these three
>>items (and the size of the message).  If you want to log application
>>specific items, then the "recipient" should be a "chatbot" operating on
>>behalf of the application that has permissions to access the message.
>
>I can see this also being enforced by the policy engine. The client cannot 
>dictate what information it will reveal and what it won't. For eg. the 
>client cannot hide the JID of the user. The server on the other hand 
>cannot ask the client to reveal too much (like the body of the actual 
>message). If the client needs some specific QoS, it is indicated in the 
>Qos descriptor. The server is the one that negotiates this with the other 
>server(on the recipient's side) and comes back with a Yes/No/Maybe (in 
>case lesser quality is supported).

I agree with the latter but not the former.  Clients can dictate what 
information they reveal by only sending data in a particular format.  The 
only thing a client MUST reveal is the recipient of the message.  Even this 
can be obfuscated if the Jabber system supports an anonymous resending 
service.  Of course, the server may require knowing who the sender is (to 
avoid relay attacks) as part of its own security policy.  And QoS is 
optional for either party but if a client requires a QoS, the server MUST 
refuse the message if it can't guarantee it.

>>Essentially, my goal is to create a JAM framework with the server only
>>providing the base foundation you can build on top of.  Standard JAM
>>services can begin with those that support IM such as presence/roster
>>management, pub/sub, user directory browsing, etc.

-iain