Sequence numbering after export and import of context

[Markus Moeller]

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" <Nicolas.Williams at sun.com> wrote in message 
news:20081006023813.GR1157 at Sun.COM...
> 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 at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>