Sequence numbering after export and import of context

[Michael B Allen]

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/