I understand that you need to keep the sequencing and in my case it is the
case. Child 2 will always start after child 1 has finished. So there is a
clear flow order which is just handled by different processes, why I thought
I can re-export/re-import the context. Unfortunately it is an existing
application and not that easy to completely rewrite.


"Nicolas Williams" wrote in message
> 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.
> Nico
> --
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos