[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
mridul at sun.com
Tue Sep 11 16:30:52 UTC 2007
Ian Paterson wrote:
> Peter Saint-Andre wrote:
>> Back in August I emailed about this issue  with the IETF area
>> directors for applications and security, relevant WG chairs, and
>> interested others. The conclusion was that in rfc3920bis we would make
>> the following changes to the mandatory-to-implement technologies:
>> 1. Remove DIGEST-MD5
> I strongly disagree. Restrained (Web) clients can't implement TLS over
> TCP/IP. So without DIGEST-MD5 the passwords would end up being
> transmitted in the clear!
Run webcontainer in https instead of http ? The tls will come for free
imo, it is much more easier to support TLS + PLAIN than DIGEST MD5 for
constrained clients - use secure transport (handled outside http
client), and use plain.
> Even where TLS is available, SASL PLAIN requires server operators to
> keep copies of all users' passwords. This is a serious (and often
> unnecessary) security weakness.
I am not sure I understand this - why would the password need to be kept
in plain at server for SASL PLAIN ?
You rarely retrieve the plain text passwd and compare it with what user
provided at the server. Typically, server authenticates user to
appropriate backend with the passed in credentials (proxying the auth).
For small deployments, it might be common for the xmpp server to also
manage credentials - but this approach rarely scales.
> TLS + DIGEST-MD5 is stronger than TLS + SASL PLAIN
In what way ? On the wire there is no difference.
If end to end there is tls (from the client to the server), then there
is not much difference between both.
(assuming something stupid is not done at the server)
DIGEST-MD5 on the other hand has a lot of other problems - proxy auth is
something which has bit us quite a lot.
>> 2. Add TLS + SASL PLAIN
> I agree.
> - Ian
More information about the Standards