[standards-jig] Small Footprint Clients and Authentication

Tijl Houtbeckers thoutbeckers at splendo.com
Thu May 29 16:55:47 UTC 2003


Peter Saint-Andre <stpeter at jabber.org> wrote on 29-5-2003 18:35:19:

>I see several issues here:
>
>1. There are no SASL-aware servers to test against. SASL-aware servers
>will not be widespread on the Jabber network for some time to come. But
>we want to do compliance testing rather soon, and it's unrealistic to
>expect clients to do only SASL authentication when SASL-aware servers
>are not available (or widely available). In fact, this would break the
>network and would render our compliance testing meaningless.

First of all, I have no objection to edigest being a new non-SASL 
standard. I always say choice is good. Yes, in standards too! Not when 
you have two standards that to do exact same thing, wich is not really 
the case here. 

However, the arguments used up to here are a complete reversal of the 
outcome of the IBB discussion. I think the two situations are very 
comparable. Go with a mechanism that is unsupported in the real world, 
but what will be the future standard (in the case of IBB the standards 
were/are(!) still not here, and SASL is very well defined by now I 
asume), or go with a mechanism that works now, does the job, and 
requires significantly less updating in clients. 

We all know the outcome of the IBB discussion, I don't particulary 
agree with it and will have to go down the non-standards path for now 
(because I work with small footprint devices, exactly your argument 
below) but it is pretty clear what the council seems to think on this! 

However, I still think this next argument is more important..

>2. The argument has been made to me that small-footprint clients can do
>jabber:iq:auth but not SASL. I don't know whether that is true or not.
>It may be immaterial given the facts outlined in point #1.

but, even though I work with (very) small footprint devices I can't 
really give an answer here (yet) because of the limited resources of my 
devices I use plaintext authentication when space is really restricted. 
That already means I can't do SASL and won't be able to do so for years 
to come in many devices. However, I don't use digest or edigest in this 
case either, so it's less relevant for the edigest discussion. 

It is however very relevant for the iq:auth vs. SASL discussion. I'm 
not very up to date on SASL yet, but from what I've read here it 
*requires* support for MD5. This would mean that once iq:auth will be 
deprecated the requirments to implement jabber will be significantly 
greater. Ofcourse, most future new phones will have improved 
capabilities, though in the near future a lot of low-end models will 
receive the same limited capabilities as I'm talking about now, and 
they will be around for years. Furthermore, I'd like to point out 
phones are not the only market for small-footprint devices, there's the 
embedded market for example. 

As I already noted in another post, a lot of phones that come in the 
market have an improved API for more secure methods of authenticating 
(for example out of band HTTPS), but I can't think of one API extension 
in wich I will be able to use MD5. Even *if* with updated storage 
capabilities I could squeeze an MD5/SASL implementation combined with a 
jabber messenger into the device, that doesn't mean I wouldn't rather 
spend that space on other things, or leave it free for other 
applications. 

I'll see if I can find some time in the next days to provide some 
examples on how much spaces these methods (and an estimate of SASL) 
would approximaltly take up in J2ME, and post some device-specs to go 
along with them. 

>3. Both jabber:iq:auth and jabber:iq:register should be reviewed every
>six months by the Jabber Council for possible deprecation (please see
>Section 8 of JEP-0001 for details). I think they cannot be deprecated
>now but should be deprecated in the future. Exactly when they will be
>deprecated will be up to the Jabber Council, but I would expect that
>this will not happen for another 12 to 18 months, depending on how
>quickly the transition to SASL-aware servers occurs.

In any case, small-footprint devices will be around for years. And in 
12-28 months there will most likely still be new simulair small-
footprint devices coming onto the market. 

>4. The addition of the "edigest" method is intended to move the old
>jabber:iq:auth protocol closer to the level of password security (in
>storage) provided by MD5. It is not really even a new method, but a
>better implementation of the existing digest method. I think JEP-0078 
>won't be deprecated for at least 18 months, and I also think that 
>people using this method don't particularly want their passwords to be 
>stored in the clear all that time (they should not have been stored 
>that way since 1999 either, but that is another issue).

As noted, edigiest is not meant to deprecate normal digest. You really 
should see it as just an alternative method. 

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list