Jabber and HTTP

[Latha Kalaga]

Can Jabber use HTTP as the transport such than I do not have to use WinJab or Gabber clients?
Secondly, what kind of security is supported in Jabber?
Thanks,
Latha

[Iain Shigeoka]

There is no official binding for Jabber over HTTP. However standardization work is underway and I think Jabber Inc (www.jabber.com) has implemented it for some of their clients. So it is possible but not widely available.
As for security, Jabber provides three authentication protocols: a simple plain text password, a digest based on stream ID, and a zero-knowledge protocol where passwords are never sent across the network and are not stored on the server (pretty secure). in addition, you can connect to a Jabber server using SSL. However, as discussed in other topics here messages are not secured from the server so you must trust all servers. Clients can get around this by encrypting messages to be sent. This protects the message but still allows the server to know who you're sending messages to and how big they are.
-iain

[David O'Meara]

Originally posted by Iain Shigeoka:
and a zero-knowledge protocol where passwords are never sent across the network and are not stored on the server (pretty secure).

What do you mean by zero-knowledge? Are you refering to a proprietary protocol where the security is based on intermediate viewers not knowing how to read the data?
What about emulating the standard HTTP authentication mechanisms, password digests (ie one way functions) being the obvious exclusion...
You could make use of SSL to encrypt clear text password transport, but if you're working in a client/server world where you control the client and the server, digests would be a simple inclusion.

[Iain Shigeoka]

Originally posted by David O'Meara:

What do you mean by zero-knowledge? Are you refering to a proprietary protocol where the security is based on intermediate viewers not knowing how to read the data?

The zero-knowledge authentication scheme for Jabber is unique to Jabber (invented for Jabber use). It basically works by establishing a standized pattern for password generation. The client starts by telling the server the first password, and some data that is used to generated it. This pattern involves a standard way for generating the next password in the password sequence without knowing what the previous password is (digests of digests).
The next time the client wants to authenticate, it sends the previous password, and the server confirms it by taking that previous password and generating the next password (the one it should have stored). If it matches, the server stores the new previous password as the current password and throws out the old one. So I guess its more accurate to say that the server only stores a one time use pasword that is immediately invalidated once it is succesfully used.

What about emulating the standard HTTP authentication mechanisms, password digests (ie one way functions) being the obvious exclusion...
You could make use of SSL to encrypt clear text password transport, but if you're working in a client/server world where you control the client and the server, digests would be a simple inclusion.

There is currently work underway to switch Jabber over to using SASL for encryption and authentication. All the internet protocols are moving over to SASL so I think this is a great move and essentially achieves what you are suggesting. SASL is a pluggable security system and is being adopted for HTTP, POP, etc. Check out the ietf (www.ietf.org) for more info on it.
-iain