Re: [kitten] GSS-API and timeouts

[William Mills <[e-mail]>]

>________________________________
> From: Simon Josefsson <[e-mail]>
>To: William Mills <[e-mail]> 
>Cc: "[e-mail]" <[e-mail]> 
>Sent: Wednesday, April 4, 2012 10:15 AM
>Subject: Re: GSS-API and timeouts
> 
>William Mills <[e-mail]> 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
>

Yes, but if you can support an async style thing then you can just fail
the first auth, hold the connection open, and let the client do a second 

auth.  Server then limits the total number of allowed failed auth transactions.


>>
>>
>>
>>
>>
>>
>>>________________________________
>>> From: Simon Josefsson <[e-mail]>
>>>To: [e-mail] 
>>>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
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/kitten
>>>
>>>
>>>
>> _______________________________________________
>> Kitten mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/kitten
>
>
>