[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Server querying of mechanism needed properties

From: Phil Pennock
Subject: Server querying of mechanism needed properties
Date: Sun, 5 Feb 2012 21:14:37 -0500


I've implemented GSASL as an authentication driver for Exim; currently
server-only and experimental.

Exim is an MTA (Mail Transfer Agent) with a history of supporting
multiple implementations of functionality, eg OpenSSL + GnuTLS.  In this
case, there are some simple native drivers, Cyrus SASL and now GSASL.

The code changes to Exim, for the curious, can be found at:

This has been tested against GSASL 1.6.1 on FreeBSD and is currently
lacking docs and the test suite additions needed; those will come.

At the bottom of this mail, some sample configuration which may prove
helpful in understanding how the integration is presented to the
mail administrator.  Note that Exim works by letting the administrator
configure per-mechanism rules, with a string-expansion language in the

Some notes on GSASL as someone implementing server-side functionality;
this is intended in the spirit of constructive feedback.

 (1) 5.3 The PLAIN mechanism
     """The callback may inspect the GSASL_AUTHID, GSASL_AUTHID, and
     GSASL_PASSWORD properties"""

     I believe one of those should read GSASL_AUTHZID.

 (2) Since the point of SASL is to abstract knowledge of mechanisms away
     from an application, it would be very useful if GSASL provided a
     means of querying a mechanism for which properties it will require.
     All the properties will need to come from configuration, and it's
     admin-friendly to have start-up sanity checks which can say
     "server_realm is missing and needed for this mechanism".

     I've hard-coded server_realm for DIGEST-MD5 to show you what I
     mean; auth_gsasl_init() in src/src/auths/gsasl_exim.c.  It would be
     better to get back a list of mandatory attributes, so that I can
     use a lookup-table to convert those to Exim names and configuration
     offsets, and end up reporting "you will need server_realm for this
     mechanism DIGEST-SHA256" (inventing a hypothetical example, and yes
     I know that SCRAM-* replaces DIGEST-*).

     Alternatively, given that different callback properties can be
     used, with fallbacks, perhaps a way to query "will this set of
     properties be sufficient for this mechanism; if not what is

 (3) During a callback, it would be good to have a way to ask if a given
     property is available, rather than calling back and needing
     loop-detection: I had to assume that property 0 would never be
     used.  For this, the idea is that when I get a GSASL_PASSWORD
     callback, I again should not need to hardcode into the application
     logic on a per-mechanism basis, to say "it's CRAM-MD5, so
     GSASL_AUTHZID will not be available to me; it's DIGEST-MD5,
     GSASL_REALM is available to me".

     Ideally, there'd be a way to get a list of known established
     identifiers, which don't need an application callback.

     The usage here is to set the $auth<N> variables available in Exim's
     string expansion language.  Currently, lines 499..528 of

 (4) If a property is needed by protocol, I assert that GSASL should be
     returning an error when it can't get the property, rather than
     presenting incomplete data for the wire: if server_realm is
     missing, DIGEST-MD5 processing should error out.  Instead, I got an
     initial challenge with just the nonce, qop, charset and algorithm

Thanks for reading,

----------------------8< cut here: exim.conf >8-------------------------

begin authenticators

  driver        = gsasl
  public_name   = CRAM-MD5
  server_password = 
  server_set_id = ${quote:$auth1}
  server_condition = yes

  driver        = gsasl
  public_name   = DIGEST-MD5
  server_password = 
  server_set_id = ${quote:$auth1}
  server_condition = yes
  server_realm = SPODHUIS.ORG

  driver        = gsasl
  public_name   = PLAIN
  server_set_id = ${quote:$auth1}
  server_condition = ${lookup{$auth1}lsearch{RUNAUTHDIR/mail-passwords}\
                          {${if eq{$value}{$auth3}{yes}{no}}}{no}}

----------------------------8< cut here >8------------------------------

Attachment: pgpWhrUh8Gy05.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]