Mridul Muralidharan wrote: > 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).
The spec dictates what a software implementation must support. Naturally
an implementation may support more than that. In terms of SASL that
means additional mechanisms such as GSSAPI or whatever.
>> How do people feel about the following rules:
>>
>> 1. Clients and servers MUST implement both DIGEST-MD5 and SASL PLAIN.
The text in RFC 3920 says that both DIGEST-MD5 and SASL EXTERNAL are
mandatory-to-implement ("MTI") but does not differentiate between
clients and servers.
No one is arguing for removal of SASL EXTERNAL, but I am proposing that
it should be MTI for server-to-server only.
I am also proposing (based on the IETF discussions) that we add TLS +
SASL PLAIN as MTI for client-to-server.
Then the question is: do we retain DIGEST-MD5 as MTI for
client-to-server? (For our purposes it is useless for s2s.)
Ian says yes. I say "I don't know because it seems that the IETF is
relegating it to historic".
But perhaps if we can document the potential points of ambiguity
regarding implementation (as Ian points out, we have done that for SASL
EXTERNAL) then perhaps we'd be on the road to keeping it.
> DIGEST-MD5 is already mandatory to impl (not deploy), and jabber:iq was
> is the basic compliance suite for servers.
But jabber:iq:auth is truly historical at this point. It comes in handy
for testing, but we're not especially encouraging deployment of it.
> We could add SASL PLAIN instead of jabber:iq ? That will take care of
> this ?
There is nothing to add jabber:iq:auth to, since it was not mentioned in
RFC 3920.
>> 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.
That's a deployment decision.
> We cannot expect to enforce policy on how a deployment should look like
> - that is the deployment administrator's prerogative.
Correct.
> 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 :)
To clear up the confusion for everyone else: typically, a specification
declares what a software implementation must include, that is, what
features are included in code. Whether a given deployment enables those
features in a running service is a matter of local service policy.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
