Sequence numbering after export and import of context

[Markus Moeller]

I haven't used much shared memory. How would it work with shared memory ?  I 
would have thought gss_init_sec_context/gss_accept-sec_context just gets a 
pointer and the underlying gss functions allocate the memory somewhere, not 
necessarily in the shared memory area ?  How can you force the gss functions 
to use the shared memory ?

Thank you
Markus

"Michael B Allen" <ioplex at gmail.com> wrote in message 
news:78c6bd860810052101u252e873co8d7114b57796aacc at mail.gmail.com...
> On Sun, Oct 5, 2008 at 10:38 PM, Nicolas Williams
> <Nicolas.Williams at sun.com> wrote:
>> On Sun, Oct 05, 2008 at 11:13:00PM +0100, Markus Moeller wrote:
>>> Thank you for the replies.
>>>
>>> I get an GSS: error: "The token was a duplicate of an earlier token" and
>>> debugging on the client shows that it received seq 0 but expected 1.  So 
>>> I
>>> need to dig a bit further what my server processes do. Is the following 
>>> OK :
>>>
>>> client <-> server main process establishes context -> export_context
>>> client <-> child 1 import_context -> unwrap + wrap (seq 0) ->
>>> export_context
>>> client <-> child 2 import_context -> unwrap + wrap (seq 1)-> cleanup
>>
>> Do I understand correctly that you're importing a given exported
>> security context token twice?
>>
>> If so, then "no, that's not supported."  RFC2743 is quite clear on this.
>>
>> And it makes sense too: there may be no way for "child 1" and "child 2"
>> to keep their sequence number windows in sync and perform as well as if
>> they did not even try to keep them in sync.  Also, the spec allows the
>> second GSS_Import_sec_context() function call to fail, and it is
>> possible to imagine implementations where such a failure would occur.
>>
>> Heck, even if an implementation supported multiple imports of one
>> exported security context token you'd still have problems because
>> whatever the per-message token sequence number window size is, if one
>> process consumes/produces per-message tokens at a sufficiently different
>> rate than the other then you'll still get sequencing errors.
>>
>> You could cheat and not request sequencing, but there's no guarantee
>> that that will work either -- as long as you're importing the same
>> exported security context token more than once then you're in trouble,
>> and if it works it will be an accident of the mechanism's implementation
>> and so your application will not be portable.
>
> Personally I think the whole export / import of security contexts is a
> little awkward. Instead of moving the context we just put all IO
> buffers in shared memory and have one process running the muxer loop
> (although the reason for doing this has nothing to do with GSSAPI).
>
> Mike
>
> -- 
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> http://www.ioplex.com/
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>