Sequence numbering after export and import of context

[Michael B Allen]

On Mon, Oct 6, 2008 at 3:11 PM, Markus Moeller <huaraz at moeller.plus.com> wrote:
> 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 ?

Hi Markus,

I'm not talking about putting GSS objects in shared memory (although
it would be dandy if it accepted allocator functions so that that were
possible). The model I'm talking about is quite different from what
you're doing and would require significant reorganization. The model
I'm talking about uses one process dedicated to doing all socket IO
(the "muxer" process) and thus would handle any gss_{wrap/unwrap}
without any context exporting / importing. Now a caller process can
allocate a shared memory buffer, write the message into it and signal
the muxer to take over, write it, read the response and finally notify
the calling process (this isn't exactly how our code works, it's
actually much more complex but the idea is the same).

Anyway, from what I've read in this thread, provided things are
serialized properly, I think what you're doing should work. The
problem could very well be that the export/import feature is a code
path less travelled so there could be bugs. Are you using MIT or
Heimdal or ...?

Mike

> "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
>>
>
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>



-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/