[JDEV] Security in XMPP/Jabber: some questions

[Robert Norris]

> First, I've done some more research myself, but I still have some 
> questions. From DJ Adams book, I know that there are 3 methodes to 
> authenticate, namely plaintext, digest and zero knowledge. Is it correct 
> that most clients use digest by default?

I beleive so. Its the most secure authentication mechanism that is part
of the standard protocol. Zero-knowledge is used over digest by clients
that support it.

> Then there is SSL (Secure Socket Layer?) that you can use to encrypt the 
> whole stream, am I correct? Still, I don't see that clients use this by 
> default. What is the reason for this? I've read somewhere that it could 
>  be that this causes problems on some proxy servers, is this true? And 
> does SSL provide end-to-end security or only client-to-my-own-server 
> security?

I would imagine the reason it is not more widely used is that there is
more overhead for clients to support it (even using a SSL library such
as OpenSSL is non-trivial).

SSL provides client-to-my-own-server security, not end-to-end.

> Other two known ones are PGP and GnuPG, what's the difference between 
> those two? Is a client supporting PGP compatible with one supporting 
> GnuPG? How does this actually work? Is it encrypted at the client side, 
> decrypted at the server side, to know the to address and then encrypted 
> again to send it to the "other side"? What if the other side doesn't 
> know about PGP, how those this side knows about that lack of feature?

PGP and GnuPG are very similar. My understanding is that they're both
implementations of OpenPGP (RFC2440). I don't know much about their
differences, but I have managed to make them work together on various
occasions.

A client encrypts the message text (ie what would normally be included
in the <body/> tag), and adds it to the message in a
<x xmlns='jabber:x:encrypted'/> tag. The message is passed through the
server as normal (the <message/> tag itself is not encrypted), and is
decrypted by the receiving client.

The only way to determine if the recipient supports this is by some sort
of discovery. Since Jabber has lacked a discovery mechanism until
recently, I beleive this was simply done by asking (in a chat message)
if the person on the other end can support encrypted messages.

The XMPP Working Group is working on a new protocol for end-to-end
encryption. See http://www.jabber.org/ietf/ for more information.

> I read in "The Instant Messaging Standards Race: Comparing XMPP/Jabber 
> and SIP/SIMPLe" from Jabber Inc. sth. about SASL (Simple Authentication 
> and Security Layer) and TLS (Transport Layer Security). What is the 
> principle of those two?

SASL is the Simple Authentication and Security Layer, defined in
RFC2222. Its job is to seperate the protocol used for authentication and
establishment of security layers (integrity checking or encryption) from
the underlying authentication mechanism (plaintext, digest, Kerberos,
etc). This allows implementations to offer different mechanisms without
requiring an update to the protocol.

TLS is Transport Layer Security, which is the Internet-standard version
of SSLv3 (RFC2246). The difference between TLS and SSL is minimal.

Traditionally, servers offering SSL would operate in a "wrappermode",
opening another port for encrypted connections. The encryption begins as
soon as a client connects. This is done with protocols such as HTTPS and
IMAPS.

Newer protocols use the STARTTLS method (see RFC2595), where a cleartext
connection to a server is started, with the client the requesting
encryption. The underlying TCP channel is reused.

SASL and STARTTLS are IETF best practice, and so the XMPP Working Group
Charter requires that the final version of XMPP implements them. More
information about the XMPP usage of these protocols can be found in
XMPP-Core, at http://www.jabber.org/ietf/ .

> What is meant by "end-to-end" vs "hop-to-hop" encryption, that with the 
> first one even the server can't read what is in the message? But how do 
> they know then where to send the message?

There is a difference between the message content (body) and the message
envelope (header). A client would encrypt the body of the message, but
leave the to and from addresses unencrypted, so that the server can use
them to determine routing. This is known as end-to-end encryption - the
original sender encrypts the message body, and only the final recipient
of the message can decrypt it.

Hop-to-hop encryption, on the other hand, simply refers encryption
between two entities in the network, either between a client and a
server or between two servers. This is what SSL/TLS is typically used
for. When used correctly, it can help prevent network-based attacks
(hijacking or sniffing the TCP connection), but does not provide
end-to-end encryption.

> Will jabberd2 support more security than the current jabberd server?

jabberd2 will support the XMPP security protocols (SASL and STARTTLS),
the traditional plaintext, digest and zero-knowledge authentication
protocols, the dialback protocol for server-to-server connections, and
various forms of connection limits (IP restrictions, rate limiting,
etc) which can help to prevent denial-of-service attacks.

> I hope sb. has some time to answer these questions (or some of them). I 
> don't need in-depth information, just enough to understand it :).

Hope this helps :)

Rob.

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20030522/046df8b6/attachment-0002.pgp>