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
