[JDEV] Re: [secure-jabber] Server authentication?
Thomas Charron
tcharron at ductape.net
Fri Nov 19 12:31:45 CST 1999
(To those reading this message from jdev. This is a conversation taking place
on security at jabber.org. If you are interested, please see
http://mailman.jabber.org/listinfo/security and subscribe. It's a lower volume
list, but we'd like to try to keep this conversation ON security at jabber.org.
If anyone has comments regarding this, but do not wish to be on the list,
please just forward them to myself or quad at jabber.org. It's being cross posted
to address the fact that many people interested about this subject are not ON
security at jabber.org ;-P )
Quoting Scott Robinson <quad at jabber.org>:
I didn;t really see any responses which I was waiting for, so here comes my
reply.. ;-P
> Jabber (etherx and jabber-transport, at this point, has no defined
> method of authenticating the origin of a foreign XML stream. The current
> XML
> streams implementation notes specify the a <stream/> element's "from"
> attribute must resolve to the IP address of the stream's sender.
> Unfortunately, not only does this offer no semblance of security, but in
> fact it causes problems in the implementation of the following:
I had to leave this in, becouse the message is older, and it'll refresh
peoples memories.. ;-P
> a) server clustering
> - Multiple routers hosting the same TLD.
"Feature", not a bug. This allows for clustered servers to all be seen as
one server.
> b) message forwarding / firewalling=20
> - while the content of the stream is intact, any attempt of comparision
> between the stream origin will be bogus.
Jabber message forwarding is handled differently. Streams, IMHO, should
never be 'forwarded'. The data inside may be, but not the stream..
> <needs>
> At a minimum, a modification of the XML streams specification to allow for
> full knowledge of stream information. Currently the stream holds the
> information of where it is physically coming from and what its virtual
> inte=
> nded
> destination is. The addition of the origin of the contained data and
> (though
> intrisically repetitive) intended physical destination is would at least
> give the full knowledge that any router should be given.
I agree fully. Currently, we only know who the stream is coming from, and
who it's going to, but not the origin. In order to have any sort of
validation, this is the first thing needed..
> What it boils down to is a semblance of security. Even given base TCP/IP
> configuration, we're back to the SMTP relay problem. Does a router accept
> data from "geocities.com" when the stream wants to tell everyone it's from
> "microsoft.com"? Given host information, the only solution is to lock down
> all the routers and be paranoid. (relay only from your own domain)
Yep, limiting factor for sure.
> Paranoia doesn't give us a kind and gentle world. Caution and knowledge
> does. What I propose is a distributed digital signature system. While
> imperfect in its security, it does offer (in Thomas Charron's words) "99.9%
> of the script kiddies" a run for their money.
HeHe.. I'm in print.. ;-P
> With a set of "full knowledge" and transport-reserved additions to etherx,
> a
> transport could use a simple digital signature system to give full security
> from known hosts-keys and partial from introduced.
The problem I see here is, how do we handle the keys? I know this has been
hashed out before, but hopefully this will reach a wider audience.
> The implementation is simple. The virtual originator of a stream must sign
> its contents with its domain's secret key. The virtual destination, having
> received the stream, verifies the digitally signed stream with the virtual
> origin's domain public key.
How do we store/retrieve the public keys? If the XML stream is being
tampered with, aka, spoofed out, how can we ensure that the public key is also
not in turn spoofed?
> The only real catch is the network-transparancy of Jabber itself.
> Transports
> are not supposed to assume direct network access to other transports, and
> all communications must be done through etherx. In a sane implementation of
> the digital signature system, the virtual destination transport must be
> able
> to retrieve and cache the virtual origin's public key. The single security
> flaw enters with IPv4, in that etherx could never guarantee the physical
> security of the connection to the virtual origin's own etherx.
Well stated. For those unaware of the conversations on IRC, this was a major
limiting factor. We CANNOT ASSUME direct accessibility of the transport that
sent the message. Heck, the transport that sent it could be talking to clients
via IPX on an internal Novell network, and has no way to inately talk IP.
> It is my hope I've sparked a few ideas of some of the people on this list,
> or at least more clearly stated my case to those "in the loop." ;) In my
> mind, Jabber cannot be an insecure system. It would be a waste of effort on
> our part because we would easily be trumped by a later system which could
> offer what we are doing + security.
I hope we do. I'm going to take the liberty to also forward this to jdev.
It may be improper, but perhaps people on jdev do not know of the security
list, and this may get a few more minds working on it. To those reading this
from jdev, please subscribe to security at jabber.org at
http://mailman.jabber.org/listinfo/security
> To quote Jeremie, "Security on Jabber! go go go!"
> </closeure>
security at jabber.org. The script kiddies nightmware... ;-P
---
Thomas Charron
<< Wanted: One decent sig >>
<< Preferably litle used >>
<< and stored in garage. ?>>
More information about the JDev
mailing list