[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/2] _gsasl_gssapi_server_step: avoid empty challenge
From: |
Simon Josefsson |
Subject: |
Re: [PATCH 2/2] _gsasl_gssapi_server_step: avoid empty challenge |
Date: |
Tue, 18 Oct 2011 19:43:31 +0200 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) |
Andreas Oberritter <address@hidden> writes:
> On 18.10.2011 15:31, Simon Josefsson wrote:
>> Andreas Oberritter <address@hidden> writes:
>>
>>> - advance to step 2 immediately, if step 1 completes
>>> (maj_stat == GSS_S_COMPLETE) without any output data.
>>
>> When is this needed?
>>
>> The spec (RFC 4752) says:
>>
>> The server passes the initial client response to
>> GSS_Accept_sec_context as input_token, setting input_context_handle
>> to 0 (initially), chan_binding of NULL, and a suitable
>> acceptor_cred_handle (see below). If GSS_Accept_sec_context returns
>> GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
>> to the client in challenge and passes the resulting response to
>> another call to GSS_Accept_sec_context, repeating the actions in this
>> paragraph.
>>
>> I think your patches alters the logic compared to the spec. If it is
>> needed, we may want to bring it up on the SASL/KITTEN list for
>> confirmation.
>
> From my POV, there are 3 defined possibilities:
>
> 1.) GSS_Accept_sec_context fails
> -> abort
> 2.) GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED
> -> send (another) challenge (i.e. return output_token to client)
> 3.) GSS_Accept_sec_context returns GSS_S_COMPLETE
> -> proceed to next step (i.e. send QOP and max. length)
>
> By testing GSSAPI with a Kerberos setup, I observed that
> GSS_Accept_sec_context may also return GSS_S_COMPLETE although an
> output_token has been prepared and must be sent to the client (4.). This
> might be erroneous behaviour of the underlying GSS library. I'm not
> sure, which ones I verified it with, either GNU gss, MIT or both.
>
> The current behaviour of gsasl is:
>
> on 1.) abort
> on 2.) return output_token to client
> on 3.) return output_token to client (even though output_token may be empty)
> on 4.) return output_token to client
>
> With my patch, on 3., it will advance to the next step, because
> otherwise an empty challenge will be sent to the client.
>
> After having created the patch and before sending it to you, I verified
> that this matches the behaviour of Cyrus SASL.
I think you are right. The RFC goes on and says later on:
If the last call to GSS_Accept_sec_context returned an output_token,
the server returns it to the client in a challenge and expects a
reply from the client with no data. Whether or not an output_token
I suspect the test whether there is an output_token or not is whether it
is of non-zero length.
I'll take a closer look at the patch tomorrow.
/Simon