Ian Paterson wrote:
Greg Hudson wrote:
On Tue, 2007-09-11 at 19:51 +0100, Dave Cridland wrote:
If I ruled the world, I'd mandate TLS+SCRAM, and have a SHOULD for
TLS+YAP (the latter being plaintext-equiv on the server, but only a
single round-trip, so great for mobiles).
You may be missing the most popular reason for sending plain-text
passwords to the server (over TLS, one hopes): it's the only way for the
server to check the password against an external verifier such as an
LDAP server, AD controller, or Kerberos KDC. (GSSAPI krb5 auth is much
better if you have an AD controller or Kerberos KDC, of course, but I
don't hold out much hope for that being universally implemented in
clients.)
I think Dave is well aware of that benefit. :-)
I agree that servers that support external verification should implement
SASL PLAIN. However, SASL PLAIN's support for external verification
comes at a very significant security cost (since some servers *will* be
compromised). IMHO, the spec should not sacrifice the security of users
of servers that could employ "internal" verification (by requiring
support only for SASL PLAIN).
How do people feel about the following rules:
1. Clients and servers MUST implement both DIGEST-MD5 and SASL PLAIN.
DIGEST-MD5 is already mandatory to impl (not deploy), and jabber:iq was
is the basic compliance suite for servers.
We could add SASL PLAIN instead of jabber:iq ? That will take care of this ?
2. Each server installation MUST include either (but not both)
DIGEST-MD5 (when inner hash verification is available) or SASL PLAIN
(when only external verification is available) in the list of mechanisms
it offers clients.
We cannot expect to enforce policy on how a deployment should look like
- that is the deployment administrator's prerogative.
In our case, depending on the realm used (ldap, access manager, text,
etc) different default auth mechanisms & features are enabled (no
DIGEST-MD5 in ldap case for example).
In context of sasl, new mechanisms can be added (through spi's) or
existing out of the box ones disabled based on the deployment
configuration - and it is essential that we give admin the freedom to
customize it the way he wants.
Btw, we did have some confusion regarding mandatory to implement vs
deploy, but devcon 2006 cleared it up for us :)
- Mridul
- Ian
