Re: [kitten] GSS-API and timeouts

[Simo Sorce <[e-mail]>]

On Wed, 2012-04-04 at 16:43 +0200, Simon Josefsson wrote:
> When implementing the GSS-API part of OPENID20/SAML20 I noticed that the
> processes can hang waiting for a long time.  Server may want to wait one
> minute or more to allow a user to finish the IdP authentication.
> 
> I think Nico discussed asynchronous GSS-API before.  However it is a
> significant amount of work to specify and implement.  I think it is
> simpler for applications to create a separate process or thread for the
> GSS-API part, and to enforce its own timeouts.  Sometimes there are
> other reasons for having separate processes/threads anyway.
> 
> Still, even an asynchronous interface may want to use some timeouts
> where authentication is no longer expected to ever finish.  So it is not
> clear that an asynchronous interface is the solution to this problem.
> 
> Does anyone have any thoughts on what a reasonable timeout should be?
> 
> Or should GSS-API initiators and acceptors never timeout, but just hang
> indefinitely in case the authentication eventually completes?
> 
> Of course, we could have a new GSS-API interface to enforce a timeout.
> For example:
> 
>      OM_uint32
>      gss_sec_context_timeout (OM_uint32 *minor_status,
>                               OM_uint32 timeout);
> 
> or something more general, in case there are similar concerns for other
> functions:
> 
> 
>      OM_uint32
>      gss_set_timeouts (OM_uint32 *minor_status,
>                        OM_uint32 sec_context_timeout,
>                        OM_uint32 micwrap_timeout);
> 
> FWIW, in my implementation I'll probably use a 5 minute timeout or
> something like that.

The problem I see with this kind of calls is that they affect the whole
process. What if you have 2 libraries with conflicting needs and both
use gssapi ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York