[standards-jig] Security problems with JEP-115

Jacek Konieczny jajcus at bnet.pl
Thu Sep 18 15:46:36 UTC 2003


On Thu, Sep 18, 2003 at 08:52:30AM -0600, Peter Millard wrote:
> > much to large for announcing in <presence/>, but if it would be reduced
> > to some kind of bitmask (values whould have to be registered in JR) then
> > the <presence/> packet whould not be much bigger than those proposed by
> > JEP-115.
> 
> This generates more bandwidth than the current draft,

Lets say we have 200 registered namespaces. If we use simple, not
optimized bitmask we get 25 bytes. It is not much, especially if the 200
namespaces are divided in 50 "bundles".


> and doesn't solve the
> security issues that were brought up.

?

> Sending ALL of your features violates the second requirement. Sending your
> "features" instead of a client identifier don't solve the spoofing issue. The
> other thing I just wanted to point out is that the "spoofing" problem exists in
> almost all client->client protocols we have today:
>     - browse, disco, time, version, etc.

The issue is not that clients spoof its own capabilities - it would be a
problem of client and have nothing to do with security. The problem is
that random client answers on behalf of other client. "Random" is not
precise enough - usually this will be the first client with given
"version tag" which presence is received. And even it is random 
it may spoof the "version tag", and say that "pgp" for such client
is just a file transfer. Each client with the same version tag would be
treated as they don't support what "pgp" really means for the client
software which "version tag" was used. (anybody understands what I am
saying? my English is poor, I know).

> I'm also wondering what some of the other client authors think about this
> protocol. 

I wrote this as a client author. Even if I implement this JEP (eg.
because of massive user request) I would never enable it by default.

But now I got some idea. The problem is that random client may lie about
what some bundle is which would influence how other clients are treated.
So we need some kind of authentication of those bundle names. My
proposal is to use some kind of digest of namespaces supported. Let it
be the first 3 bytes (written hexadecimaly) of MD5 sum of namespaces in
the bundle concatenated using some URL-forbidden character (eg. "\").
It would not be very secure (only 3 bytes of MD5 sum), but the bundle
meaning could not be spoofed that easy - client would just have to check
if the bundle name is really a hash of namespaces sent. The rest of the
JEP would stay unmodified. Maybe mention the threat because of using
just 3 bytes of MD5 sum (there is possibility to find some over
combination of namespaces which would generate the same hash).

Greets,
        Jacek



More information about the Standards mailing list