[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]

[Mridul Muralidharan]

Ian Paterson wrote:
> Peter Saint-Andre wrote:
>> Back in August I emailed about this issue [1] 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 
for webclients.
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.

Mridul

>> 2. Add TLS + SASL PLAIN
>>   
> 
> I agree.
> 
> - Ian
>