[Top][All Lists]

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

Re: scram-sha-1-plus

From: Simon Josefsson
Subject: Re: scram-sha-1-plus
Date: Wed, 23 Dec 2020 16:21:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

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


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

>> 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:


Attachment: signature.asc
Description: PGP signature

reply via email to

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