[jdev] Re: Problem Connecting to GoogleTalk using my custom client

[Tijl Houtbeckers]

On Tue, 25 Oct 2005 19:43:37 +0200, Stephen Pendleton  
<spendleton at movsoftware.com> wrote:

> In practical use, what are the advantages of TLS/SSL with SASL DIGEST-MD5
> versus TLS/SSL with SASL PLAIN authentication? DIGEST-MD5 seems to be  
> such a
> pain to have to add on the client and server sides. I can imagine this is
> why Google didn't implement DIGEST-MD5. Since the stream is already
> encrypted using TLS/SSL does DIGEST-MD5 add some extra security that
> warrants its "must-implement" status?

Well, since (As I understand from this list) Google Talk right now use a  
self signed certificate, it's pretty vonurable to a man in the middle  
attack. Also many (all?)clients do not do any kind of certificate caching  
for known hosts AFAIK.

In the case of PLAIN this means you can obtain the password through a man  
in the middle attack. In the case of DIGEST-MD5 that's not the case.  
However DIGEST-MD5 has to store the password serverside (or use an unsafe  
mechanism for implementing it) so that can also be a risk.

I think it's fair to strongly recommend a server to implement either  
DIGEST-MD5 or PLAIN. Of course then clients SHOULD implement both. I don't  
see why you should REQUIRE a server to expose either, as there are far  
more secure mechanisms. If a less secure method MUST be exposed these  
become pretty useless. So we can say with some certainy that implement  
does not mean expose to the user in all cases. So (and cases like this  
have come up before) in the case of Google, if they implement DIGEST-MD5,  
but never use it, does that suddenly mean they're "XMPP compliant" again?

Even with publicly available software, I don't see why it should be  
REQUIRED to implement either. Let's say I have an existing product that  
works with X.509 certificates, and decide to extend it with some XMPP  
technology. I should somehow hack in some -compared to my product-  
obsoleted authentication when I don't even have a password based  
infrastructure to begin with?

Of course we can say: ah well, who cares wether you can call something  
XMPP compliant or not. But I think the fact this discussion was started  
after what ralphm said, shows how unreasonable this kind of language in  
the RFC is.

> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf  
> Of
> Peter Saint-Andre
> Sent: Tuesday, October 25, 2005 12:46 PM
> To: Jabber software development list
> Subject: Re: [jdev] Re: Problem Connecting to GoogleTalk using my custom
> client
>
>
> Gary Burd wrote:
>> On 10/25/05, Ralph Meijer <jabber.org at ralphm.ik.nu> wrote:
>>> Hmm, so your implementation does not support DIGEST-MD5? Note that
>>> XMPP Core requires implementing this.
>>
>> The Google Talk Service does not support DIGEST-MD5.
>>
>> To implement DIGEST-MD5, a server must store the user's password as
>> plain text or store a specific hash of the user name and password.
>> DIGEST-MD5 might take some work to implement if a server does not
>> store passwords in one of these two formats to begin with.
>
> We have two options:
>
> 1. Accept that Google Talk is not fully compliant with RFC 3920.
>
> 2. In rfc3920bis, change the must-implement to specify something other
> than DIGEST-MD5 (perhaps advisable anyway, given recent demonstration of
> problems with MD5).
>
> Peter
>