[standards-jig] Small Footprint Clients and Authentication
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
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!
Software Engineer @ Splendo
More information about the Standards