[standards-jig] Small Footprint Clients and Authentication

Tijl Houtbeckers thoutbeckers at splendo.com
Fri May 30 13:09:31 UTC 2003

Evan Prodromou <evan at prodromou.san-francisco.ca.us> wrote on 30-5-2003 
>>>>>> "TH" == Tijl Houtbeckers <thoutbeckers at splendo.com> writes:
>    TH> Writing of J2ME as a platform would be a very bad
>    TH> decision. I'll post a little more J2ME phones/specs later as I
>    TH> promised, but I can say this now. [...]
>Hele goed! I now know 100% more about developing for phones than I did
>before reading this email.
>For my own curiosity: aren't there built-in authentication mechanisms
>for phones? I thought there were embedded ID chips and all that
>jazz. I mean, I got my phone, it's got a phone number, everybody I
>call knows who I am, my cellular carrier knows I'm not a phreaker or
>something, yadda yadda. I thought there was some kind of identity
>built into the system.

I think I already noted in a post before, that if you work together 
with the operators you can enhance authentication. However, you really 
do need the operators for this. Though some devices (and only some) 
make it possible to retrieve the unique EMI number of a device, this 
can be spoofed just as easily as anything else. 

>If I were getting paid to develop Jabber apps for phones, and I had
>control over the Jabber server, I'd figger out some way to use that
>embedded ID for celly authentication. Forget all that chatty
>DIGEST-MD5 hoohaw!

It's too bad having control over the jabber server is not enough. 
Currently you'd really need the operators for this, and they're kind of 
reluctant to cooperate on that kind of thing. It would be doable if you 
work with just a few operators maybe. 

I think for the short term future the best option will be external 
HTTPS authentication. That still keeps your password vonurable to 
interception by admins (though it won't have to be stored in plain text 
ofcourse), but would prevent sniffing. HTTPS is already supported by 
some J2ME devices, and support for it is required in the MIDP 2.0 spec. 

So the question is, is a SASL mechanism for external HTTPS that much 
weaker as DIGEST-MD5 that clients who use HTTPS shouldn't be called 
XMPP compliant because they're supposivly too insecure? 

Why was "MUST" choosen in the XMPP spec? So that there will be minimal 
security, or that "chat"-clients that implement DIGEST-MD5 will always 
be able to log into a public server? In that case, it think it should, 
er.. MUST, be immidiatly changed to SHOULD, as happend with x:data and 
the PubSub JEP. 

I still think in the end this requirment can make for some bizare 
situations, if you make an XMPP server or client for wich DIGEST-MD5 is 
not secure enough at all, you still *have* to implement it, but block 
all usage of it?? I guess we'll see what happens if Robert brings it up 
with the XMPP workgroup. Currently it doesn't even let you combine 
DIGEST-MD5 and TLS for confidentiality and authentication!? 

MIDP 2.0 devices and MIDP 1.0 with HTTPS support (will) generaly have 
more space available for applications than those that don't, but even 
then I'd rather go with HTTPS than MD5, the extra room could be used 
for better things if you ask me! 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list