Re: Sequence numbering after export and import of context
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 ?
"Michael B Allen" <email@example.com> wrote in message
> On Sun, Oct 5, 2008 at 10:38 PM, Nicolas Williams
> <Nicolas.Williams@sun.com> wrote:[color=green]
>> On Sun, Oct 05, 2008 at 11:13:00PM +0100, Markus Moeller wrote:[color=darkred]
>>> 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
>>> 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) ->
>>> client <-> child 2 import_context -> unwrap + wrap (seq 1)-> cleanup[/color]
>> 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.[/color]
> 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).
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> Kerberos mailing list [email]Kerberos@mit.edu[/email]