Re: [kitten] GSS-API and timeouts

William Mills <wmills@yahoo-inc.com> writes:

> As a result of the OpenID flow/redirect don't you get a complete
> credential that can be used to finish the process?  Can't you connect
> again, get a challenge perhaps, submit that completed credential and
> be done?  That's very similar to what I did in the OAUTH/SASL thing,
> so I'm replaying my one trick :)

The problem is that the browser interaction in OPENID20/SAML20 can take
a long time because it is interactive, and the server doesn't know when
to stop waiting.

/Simon

>
>
>
>
>
>
>>________________________________
>> From: Simon Josefsson <simon@josefsson.org>
>>To: kitten@ietf.org 
>>Sent: Wednesday, April 4, 2012 7:43 AM
>>Subject: [kitten] GSS-API and timeouts
>> 
>>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
>>_______________________________________________
>>Kitten mailing list
>>Kitten@ietf.org
>>https://www.ietf.org/mailman/listinfo/kitten
>>
>>
>>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten