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.
Thanks Markus "Nicolas Williams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
