[Huh, so the mailing list is configured to remove all other to/cc
addresses.]

On Thu, Sep 23, 2010 at 10:55:39PM +0100, Simon Wilkinson wrote:
> > 
> > - no standard APIs, abstract or otherwise, exist for SASL[*]
> 
> In the world that I think Moonshot is, at least initially, interested
> in, there is a defacto standard API. The majority of the open source
> mail, LDAP, and XMPP clients all make use of the Cyrus SASL API.

Yes.

> This is both a blessing and a curse for us. It's a blessing, because
> Cyrus's dynamically loadable security modules means that we should
> just be able to drop in a GS2 module built against a suitable GSSAPI
> library, and Moonshot will "just work" with a wide range of
> applications. It's a curse, because none of those applications will
> actually be able to display any kind of UI, and unless they're very
> well written may well get confused by things like multiple round
> trips.

For UI issues (and exposing more GSS objects), you'll probably have to
submit patches to Cyrus SASL upstream.

Although, keep in mind that the GSS-API has no prompting in it.  We've
talked before about adding an API for acquiring "initial" credentials,
complete with prompting support.  Maybe it's time for that?  But in any
case, some OSes have managed to make the UI issues in the GSS-API
completely hidden from the application (call gss_acquire_cred(), the
user gets a dialog for their password/PIN/whatever if they didn't
already have creds).

> I spent a lot of time a few years ago going around applications and
> modifying them so that they didn't assume that every SASL module
> behaved like DIGEST-MD5. I think that, in the course, of that, I added
> sufficient generality that GS2 should just be able to drop in.

Really, apps assumed DIGEST-MD5 behavior?  *sigh*

> Which leads me on to the point made earlier in this thread about
> getting access to GSS name extensions. It's one thing convincing
> applications to fix their SASL support, because it is obviously broken
> according to the documentation provided by the API vendor. It's much
> harder to get open source application developers to take code specific
> to unusual authentication methods and, even if they do take it, harder
> still to stop other developers from breaking it. Bear in mind that
> most of these developers consider Kerberos to be an unusual niche
> technology that it's not really worth their while to support, and it's
> really worth our while trying to be as generic as possible in the
> early days.

Actually, SASL/GSSAPI support is getting fairly universal.  Lots of MUAs
have it, and IIRC even pidgin supports it.  GS2 is only a mechanism name
choice away, and since most of these apps just pick one from the server
list of mechanisms...  The main problem here is going to be giving users
a choice of mechanism in UIs.

Nico
--