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

Mridul Muralidharan mridul at sun.com
Wed Sep 12 21:11:15 UTC 2007


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
> 




More information about the Standards mailing list