This is a discussion on Re: Sequence numbering after export and import of context - Kerberos ; 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 ...
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) ->
> 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.