On Tue, 25 Oct 2005 19:43:37 +0200, Stephen Pendleton
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
