Subject: SASL ABI?

From: "Rob Earhart" <[email-masked]>
Date: Tue, 12 May 1998 17:06:24 -0400

We're looking into implementing a SASL API, and realized that it'd be good
to have some sort of SASL configuration/ABI definition to answer questions
like

	Where do modules live?
	How do we access them on a given system?
	Where does site-configuration live?
	What's the format of the site-configuration?

  Configuration's useful because we'd like to be able to have sites be able
to say things like "Use Kerberos for IMAP connections on-site, and anything
but plaintext off-site," - that is, we think it's useful for sites to be
able to define their own security policies on a per-protocol basis (and to
be able to write/purchase additional security plugins for existing
applications).

  So has anyone looked into this?  Any thoughts/comments?  It doesn't seem
like this'd be too hard to define, but I think it'd be a good idea to define
it in a standard way if we're going to do it at all, and if someone's done
it already I'd rather reuse existing work, if possible.  :-)

  )Rob

---

From: Chris Newman <[email-masked]>
Date: Wed, 13 May 1998 14:46:16 -0700 (PDT)

> it already I'd rather reuse existing work, if possible.  :-)

I've been working on all these issues, at least for our product.

The important thing for the ABI is to have the exact API with parameter
sizes, and the shared library compiliation options.

As for config files, I'm not sure it's worth the work to document a common
format.  Different products have different configuration models.  I'd be
glad to share what we're doing as the design of config files for this is
quite tricky (I had to go through a couple cycles of implement &
re-design).

Our current model for the server side is as follows:

There's a mapping table and security config file. The mapping table has
the following structure:

 TCP|local-ip|local-port|remote-ip|remote-port   $Y<ruleset>|<user-domain>
 TCP|local-ip|local-port|remote-ip|remote-port   $N<refusal string>

$N means refuse connections, dumping the refusal string down the port
before closing it.  $Y means accept connections with "ruleset" as the name
of the security ruleset to use and "user-domain" as the user namespace to
use (for support of multiple domains on the same host). 

The security config we're using is broken into sections by security
ruleset and authentication source:

[RULESET=default]
ENABLE=<plugin-name>/<mechanism>,...
...
[AUTH_SOURCE=plugin-name]
IMAGE=<filename>
FUNCTION=<entry_point_name>
...

Each plugin serves an authentication source, and provides one or more SASL
mechanisms.  Authentication sources can be built-in or dynamically loaded
as specified by the [AUTH_SOURCE=...] section of the config file.

I believe this is sufficiently flexible and extensible, but I'm not sure
others will want to use the same syntax and certainly won't want the same 
locations for the config file.

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Wed, 13 May 1998 14:46:16 -0700 (PDT)

[RULESET=default]

		- Chris