Cyrus SASL Libary

(1) 什么是SASL和Cyrus SASL

SASL (Simple Authentication Security Layer) is an Internet standards-track method for remote computers to authenticate. The Cyrus SASL library makes supporting various SASL mechanisms easy for both client and server writers.

The Cyrus project is the implementation of an enterprise mail system by the Carnegie Mellon University Computing Services Department. We are interested in scalable, easy to administer systems.

(2) Cyrus SASL组成部分

SASL是一个胶合(glue)库，通过这个库把应用层  与 形式多样的认证系统整合在一起。这有点类似于 PAM，但是后者是认证方式，决定什么人可以访问什么服务，而SASL是认证过程，侧重于信任建立过程，这个过程可以调用PAM来建立信任关系。

应用层

应用层是SASL库的使用者，既可以是客户应用程序，也可以是服务应用程序，或者两者都是（在代理的情况下）。应用层负责SASL认证协商的连线和传达，具体的认证交给SASL库。应用层的例子有Cyrus IMAPd，OpenLDAP，Sendmail，Mutt，sieveshell，cyradm等。

SASL胶合层(Glue Layer)

负责如下的工作：
加载插件；
从应用层获取必要的认证属性，以选择适当的认证机制（或者限制可用的认证机制）；
给应用层列出可用的插件；
为特定的认证请求选择最好的认证机制；
在应用层和被选的认证机制间路由认证数据；
为应用层提供SASL协商信息，比如认证的用户，请求的认证ID，安全层的强度等。

SASL还提供一些别的服务给应用层和插件，一些是常用的工具，比如MIME Base64编码解码，随机数生成；还有一些是和认证相关的，比如口令验证服务。

最后，SASL还允许应用层和认证机制层访问两种特殊类型的插件：Auxiliary Property或者 auxprop插件，它提供了简单的数据库接口，可返回用户属性，比如口令，home目录，邮件地址等；Username Canoicalization，提供了一个站点相关的用户正名服务（使用户名称规范化），或者其他的任务．

SASL认证机制（SASL Mechanisms）

有三种类型的机制：
Password Verification Mechanisms　– 接收远程的口令，传递给SASL胶合层，由口令验证器验证，这种机制的例子有PLAIN；
Shared Secret Mechanisms – 不是直接传递口令明文，而是服务方发起一个认证，客户证明自己知道这个口令，这需要服务方和客户方都保存有口令．这种机制的例子有CRAM-MD5，DIGEST-MD5以及SRP；
Kerberos Mechanisms – 使用信任的第三方来验证客户。

Auxiliary Property(auxprop)

为胶合层提供数据库服务，Cyrus SASL支持两种auxprop插件：SASLdb和SQL。auxprop通常用于共享密码机制。

Username Canonicalization

不是很常用，一般用于为应用层提供用户的规范名称。

口令验证服务

根据用户名和口令的明文，判断是否验证正确。口令验证服务器通过SASL选项pwcheck_method来选择，有两类主要的口令验证器：
auxprop – 使用auxprop插件获取口令，比较和用户提供的口令是否相符；
saslauthd – 呼叫saslauthd服务进程，验证用户。saslauthd支持很多识别方式，比如PAM，LDAP，Kerberos数据库等。

(3) SASL 术语

认证ID(Authentication identifier)和授权ID(Authorization identifier)

userid(user id, authorization id) – 用户ID，授权ID，说明执行操作的授权个体。
authid(authentication id) – 认证ID，证明某人确系某人。

比如小王休假，小李暂时接替他的工作。那么为了有小王的权限，小李认证时使用自己的帐号，即authid，执行具体的操作时需要有小王的user id，这样才能做他的工作。

一般userid和authid是相同的。

Realms

A realm is an abstract set of users and certain mechanisms authenticate users in a certain realm.

最简单的情况是单服务单机器的情况，realm就是FQDN(Full-qualified domain name)，如果应用层没有提供，则很多SASL机制采用默认的。

如果要多机共享口令，则通常选择域名，比如CMU.EDU。单个站点也可以支持多个不同的realms。为了把不同realm的用户加入sasldb，可以在saslpasswd2命令中用u选项，SQL插件通过宏’%r’在查询串中加入realm。

(4) SASL工作流程

PLAIN机制，sasl_checkpass()，以及明文口令

auxprop – 根据auxiliary property插件提供的userPassword属性验证用户，数据库通常保存在/etc/sasldb2；
saslauthd – 通过saslauthd验证用户，-a选项指示saslauthd的具体机制，-n指示saslauthd的线程数；
Courier-IMAP – 通过Courier-IMAP的authdaemond检查口令，类似于saslauthd；
pwcheck – 使用独立的辅助服务进程来验证；
write your own – 自己写一个验证方式。

共享密码机制

CRAM-MD5和DIGEST-MD5使用这种机制，注意，这些方式不能使用saslauthd。如果不想用这些方式，可从插件目录移走这些插件，或者用mech_list禁用它们。

为了简单起见，SASL库把口令的明文形式保存在/etc/sasldb2中。

Kerberos mechanisms

The Cyrus SASL library also comes with two mechanisms that make use of Kerberos: KERBEROS_V4, which should be able to use any Kerberos v4 implementation, and GSSAPI (tested against MIT Kerberos 5, Heimdal Kerberos 5 and CyberSafe Kerberos 5). These mechanisms make use of the kerberos infrastructure and thus have no password database.
Applications that wish to use a kerberos mechanism will need access to a service key, stored either in a “srvtab” file (Kerberos 4) or a “keytab” file (Kerberos 5). Currently, the keytab file location is not configurable and defaults to the system default (probably /etc/krb5.keytab).

The Kerberos 4 srvtab file location is configurable; by default it is /etc/srvtab, but this is modifiable by the “srvtab” option. Different SASL applications can use different srvtab files.

A SASL application must be able to read its srvtab or keytab file.

OTP机制和基于OPIE的OTP

The Cyrus SASL library also supports the One-Time-Password (OTP) mechanism. This mechanism is similar to CRAM-MD5 and DIGEST-MD5 in that is uses a shared secret and a challenge/response exchange. However, OTP is more secure than the other shared secret mechanisms in that the secret is used to generate a sequence of one-time (single use) passwords which prevents reply attacks, and that secret need not be stored on the system. These one-time passwords are stored in the /etc/sasldb2 database. See the Shared secrets mechanisms section for a discussion of the /etc/sasldb2 database.

For sites with an existing OTP infrastructure using OPIE, Cyrus SASL can be configured to use OPIE v2.4 instead of using its own database and server-side routines. OPIE should be configured with the –disable-user-locking option if the SASL server application will not be running as “root”.
OPIE uses its own “opiekeys” database for storing the data necessary for generating the server challenges. The location of the opiekeys file is configurable in SASL; by default it is /etc/opiekeys, but this is modifiable by the “opiekeys” option.

A SASL server application must be able to read and write the opiekeys file.

(5) 如何配置选项

缺省配置文件保存在/usr/lib/sasl2/App.conf里，这里App.conf为应用层名字，比如Sendmail为/usr/lib/sasl2/Sendmail.conf。

标准的Cyrus SASL配置文件类似于：

srvtab: /var/app/srvtag
pwcheck_method: saslauthd

应用层可重新定义SASL库的选项，这因应用层而异，比如Cyrus imapd保存配置文件为/etc/imapd.conf。

(6) Cyrus SASL 测试

Cyrus SASL库带了两个测试程序：sasl2-sample-server和sasl2-samle-client，分别对应着服务程序和客户程序，可对SASL的配置进行测试。两个程序都带了三个参数：

-p TCP监听或者连接的端口号，缺省为12345
-s 服务名称，缺省为rcmd
-m 认证的机制

此外sasl2-sample-client还要求有一个服务程序主机名称或者IP地址的参数。

首先我们给测试服务程序提供一个配置文件，sample.conf，保存在/usr/lib/sasl2目录下，内容如下：

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: plain login ntlm cram-md5 digest-md5

然后我们给sasl2db(在/etc/sasldb2)添加测试帐号，比如marchday：

[root@research sasl2]# saslpasswd2 -c marchday
Password: 
Again (for verification):

然后我们启动服务程序：

$ sasl2-sample-server -p 9000

打开另一个终端窗口，进行测试：

$ sasl2-sample-client -p 9000 -m PLAIN localhost

如果没别的问题，应该可以看到successful authentication。^_^

你还可以测试别的Mechanisms，这里就不再举例了。

参考资料：
http://www.sendmail.org/~ca/email/cyrus/sysadmin.html

http://asg.web.cmu.edu/sasl/
Cyrus SASL Library Documatation

以Sendmail为例：