[30336] in Kerberos
Re: Sequence numbering after export and import of context
daemon@ATHENA.MIT.EDU (Michael B Allen)
Mon Oct 6 00:02:12 2008
Message-ID: <78c6bd860810052101u252e873co8d7114b57796aacc@mail.gmail.com>
Date: Mon, 6 Oct 2008 00:01:16 -0400
From: "Michael B Allen" <ioplex@gmail.com>
To: "Nicolas Williams" <Nicolas.Williams@sun.com>
In-Reply-To: <20081006023813.GR1157@Sun.COM>
MIME-Version: 1.0
Content-Disposition: inline
Cc: Markus Moeller <huaraz@moeller.plus.com>, kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Sun, Oct 5, 2008 at 10:38 PM, Nicolas Williams
<Nicolas.Williams@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/
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
