Re: Server querying of mechanism needed properties

[Simon Josefsson]

Phil Pennock <address@hidden> writes:

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

Hi Phil and welcome to the list!  First apologies for slow response, I
wanted to get 1.7.1 out before responding to your e-mail, however after
making the release my spare time went away.

Thanks for working on Exim patches, I'll be happy to help with that and
ultimately to test them (I use exim as the MTA on several machines).  Is
the gsasl patches discussed on some exim mailing list?

> 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 link doesn't work for me.

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

Thank you, this is valuable feedback.  Every new implementer that learns
GSASL will notice new things which are difficult to spot.  If you have
more thoughts or opinions on the interface, even if you don't have any
precise suggestions on how to resolve them, that is appreciated.

>  (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.

Fixed in master now.  I've been thinking of renaming GSASL_AUTHID to
GSASL_USERNAME for some time now, and maybe now is a good time.  The
risk of confusing these two symbols is non-negligible, and USERNAME is a
better word than AUTHID even though it is not as RFC4422-like.

>  (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-*).

Good idea, I hadn't thought of that, but it makes sense.

>      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?"

Yeah, although that is more complex.  But maybe we need to express that
property X, Y Z are _required_ and either property A or B is _required_,
and property G, H and I are _optional_.  There could even be situations
where property P and Q are both optional, but if P is specified so must
Q be.

>  (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".

There is gsasl_property_fast, does it do what you want?  It will return
NULL if the property doesn't have any value, rather than invoking the
callback.

>  (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.

I agree.  However, I believe "realm" is optional in the protocol
though.  Compare RFC 2831:

   realm
      The realm containing the user's account. This directive is
      required if the server provided any realms in the
      "digest-challenge", in which case it may appear exactly once and
      its value SHOULD be one of those realms. If the directive is
      missing, "realm-value" will set to the empty string when computing
      A1 (see below for details).

I hope this helps.

/Simon