[kitten] GSS-API and timeouts

[Simon Josefsson <[e-mail]>]

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.

/Simon