Christopher Audley wrote:
>
> saslauthd is an evolution of pwcheck available with the 1.5.27 and 2.0.x
> versions of the sasl library (available from CVS). Saslauthd basically
> takes the core of pwcheck and adds forking so that each request is handled
> by a different subprocess, and password checking logic modules have been
> added for more methods. Its a start in the right direction, but much more
> needs to be done. For instance, the forking of processes is done after an
> accept, so on servers that see a light load, saslauthd will actually appear
> to be slower than pwcheck. There is also no limit on how many processes
> saslauthd will fork, so it introduces new possibilities for DOS attacks.
>
> To the core sasl library, it looks just like pwcheck. Open a UNIX socket,
> pass in 'username\0password\0' and get back 'OK' or something else.
> saslauthd defaults to putting its socket in a different location from
> pwcheck, but it has a command line switch you can use to emulate pwcheck
> behavior.
>
> Because the protocol is essentially the same as pwcheck, you can lift
> saslauthd from a latter version of SASL and use it with your 1.5.24 SASL
> installation.
Well... This is *most likely* going to change in SASL v2. The current
thinking between myself, Lyndon Nerenberg from Messaging Direct (the
original author of saslauthd), and Rob Siemborski and Larry Greenfield
from CMU, is that the protocol will be changed to use counted length
strings instead of NUL delimited strings, and will be extended to
include the service name and user realm. An example from Lyndon is
below.
Ken
Thus the request would be:
count authid count password count service count realm
and the response:
count result
Where count is a 16 bit unsigned integer in network byte order. E.g., a
client request to authenticate 'lyndon' with password 'foo' to the
'imap'
service with no realm would look like:
C: 00 06 6C 79 6E 64 6F 6E 00 03 66 6F 6F 00 04 69 6D 61 70 00 00
l y n d o n f o o i m a p
S: 00 02 4F 4B
O K
In the request, empty fields are indicated using a zero length (cf the
empty realm in the example above). We should also define the string
content as UTF-8.
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
