[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 |
Folks,
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:
https://github.com/Exim/exim/compare/master...gsasl
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
configuration.
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
missing?"
(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
"gsasl_exim.c".
(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
fields.
Thanks for reading,
-Phil
----------------------8< cut here: exim.conf >8-------------------------
begin authenticators
auth_cram:
driver = gsasl
public_name = CRAM-MD5
server_password =
${lookup{$auth1}lsearch{RUNAUTHDIR/mail-passwords}{$value}fail}
server_set_id = ${quote:$auth1}
server_condition = yes
auth_diggity:
driver = gsasl
public_name = DIGEST-MD5
server_password =
${lookup{$auth1}lsearch{RUNAUTHDIR/mail-passwords}{$value}fail}
server_set_id = ${quote:$auth1}
server_condition = yes
server_realm = SPODHUIS.ORG
auth_plain:
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------------------------------
--
https://twitter.com/syscomet
pgpWhrUh8Gy05.pgp
Description: PGP signature
- Server querying of mechanism needed properties,
Phil Pennock <=