Multiple-Mechanism Sample Code?

[Dave Cridland]

On Wed Jan  3 21:18:35 2007, Andreas Winkelmann wrote:
> On Wednesday 03 January 2007 21:23, Dave Cridland wrote:
> 
> > > If the Server offers DIGEST-MD5 and PLAIN. And the User/Client 
> trys
> > > wrong Credentials, the Second try will pass in Cleartext the
> > > Internet. I would not like to see that if I just make a Typo in 
> the
> > > Password, you?
> >
> > Well, the client really ought to be warning about this, and 
> checking
> > with the user. Of course, this might need a new API/callback for
> > Cyrus SASL, I can't recall. (All my Cyrus SASL usage is on the
> > server, my client usage uses its own library, which does do 
> warnings).
> 
> Hmm, ok, you have a Server, which does only allow 
> Plaintext-Passwords with SSL/TLS and Shared-Secret Mechanisms 
> without SSL/TLS. The Client connects without TLS and trys 
> DIGEST-MD5, it fails. What shall happen? Cyrus-SASL cannot switch 
> to PLAIN without a heavy Interaction with the Server-Application. 
> At least it has to establish a SSL/TLS-Layer to enable 
> Plaintext-Passwords in the Authentification-Phase. I don't think 
> this hypothetical Situation is a rare exception.
> 
> 
No, and it's not very hard, either. The client application then 
receives the transition request, and assuming the user accepts, 
negotiates TLS, and reauthenticates with PLAIN.


> > > Oh and useless, because why should there be a difference between
> > > one of the Offered Mechanisms? If DIGEST-MD5 with one set of
> > > Credentials fails, why should it succeed with PLAIN? This is 
> only
> > > the case with misconfigured Servers (Offering *-MD5 Mechanisms 
> with
> > > saslauthd for example).
> >
> > Ah... No, there's the transition case. For ACAP, for example, the
> > attempt to authenticate with DIGEST-MD5 might yield a
> > TRANSITION-NEEDED, but (all?) other protocols won't communicate 
> that
> > back to the client, so it's reasonable to try PLAIN.
> >
> > PLAIN might work because SASL can pass the credentials onto the
> > operating system's authentication method, whereas DIGEST-MD5 needs
> > either a copy of the plaintext, or the intemediate hash, in which
> > case that's per-user, not per-site. The simplest way of getting 
> the
> > data needed is to get the user to authenticate once using PLAIN,
> > after which DIGEST-MD5 works.
> 
> I don't know ACAP so good to see this relation, but this sounds 
> like the Cyrus-SASL auto_transition Feature. To "convert" a Crypted 
> Password Storage (shadow/passwd/...) to an UnEncrypted (auxprop) 
> you enable auto_transition and waits until all Accounts/Passwords 
> are created in auxprop. In this Phase you run with 
> Plaintext-Passwords only (mech_list: plain login) though it would 
> be possible to use *-MD5 Mechanisms for the already created 
> Accounts.
> 
> 
Exactly - Cyrus SASL tells the server, and the server can tell the 
client via the application level protocol. ACAP happens to be an 
example of a protocol which allows this, whereas IMAP does not.


> BTW, a failed Authentification with right Credentials has always a 
> bad taste. Looks like a Trojan Horse at the first sight.

No, it's not a matter of the right or wrong credentials, it's a 
matter of the credentials not being validatable.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade