Re: scram-sha-1-plus

[Simon Josefsson]

Hi Jeremy,

I'm making another attempt at releasing a new stable GNU SASL version,
and this issue has been the main blocker.  It should now be fixed though
(see below), and I'm preparing a new release candidate, but I'm replying
on this thread for future reference.

Simon Josefsson <simon@josefsson.org> writes:

>>> Looking at the code, the GS2 and GSSAPI server plugins have the same
>>> "problem" today: they retrieve the GSASL_SERVICE and GSASL_HOSTNAME
>>> properties during gsasl_server_start().  I suspect there aren't any
>>> applications out there that want to provide different answers to these
>>> callbacks depending on the session, so this was never a problem for
>>> anyone.  They are application-global and static.
>>
>> You're probably right about those being application-static - though
>> I could imagine a application wanting to offer multiple services...
>> POP and IMAP for a start, if not also SMTP.
>
> Yes, GS2/GSSAPI should be redesigned too.

Agreed.

>>>> To keep the current early check, I think you would have to split the
>>>> session startup into two calls, so the the application gets a session-
>>>> context before the time it needs to provide the channel-binding data.
>>> 
>>> Yes, this would solve the generic problem, however we still have the
>>> problem with gsasl_client_suggest_mechanism() -- that function should
>>> recommend SCRAM-SHA-1-PLUS (or GS2-KRB5-PLUS) if the TLS channel binding
>>> is available but not otherwise.  How to implement that?
>>
>> I think that facility should be session-dependent, because sessions
>> differ.  Specifically, it should take a session-context handle not
>> a toplevel context handle for the API.
>
> Good point.  Ideally there should be a new guessing function that works
> on the session-level.

I agree -- it can be added later on, if there is demand for it.  I don't
think a lot of GNU SASL clients actually use
gsasl_client_suggest_mechanism().

>> However, if you took the "split into two" choice:
>>
>> 1) API call: application gets fresh, bare, session-context
>> 2) application couples that with the TLS channel in app-level data
>>    struct.
>> 3) Optionally, app sets channel-binding data
>> 4) API call: with session-context, start requested METHOD
>>    (triggers prop callback if needed for channel-binding data)
>>
>> - then if the app did indeed do (3), it could use a "suggestions"
>> call for the session-context before doing (4).
>>
>> Since I don't need "suggestions" I've not thought too hard about it,
>> but does that satisfy the need?
>
> Yes.  We could introduce new gsasl_init_session() and a
> gsasl_start_client/server().
>
> However that is an API change and if the only real advantage is to fix
> gsasl_client_suggest_mechanism() properly I would prefer to resolve this
> in a more non-intrusive way to get 1.10.0 out.  Leaving the
> gsasl_client_suggest_mechanism() problem aside, I think if we move the
> uses of callbacks from start() into the first step() call, everything
> works right?  Then modulo memory allocation problems
> gsasl_client_start() will always get you a Gsasl_session handle.  You
> can do gsasl_property_set() on it before doing the gsasl_step() calls.

This is what I ended up doing:

https://git.savannah.gnu.org/cgit/gsasl.git/commit/?id=bd3cf2729b6ea02f8941f5f3b80d7c9ac748aee9

/Simon

signature.asc
Description: PGP signature