This is a discussion on Re: Sequence numbering after export and import of context - Kerberos ; On Sun, Oct 05, 2008 at 12:09:09PM -0400, Michael B Allen wrote: > On Sun, Oct 5, 2008 at 7:51 AM, Markus Moeller wrote: > > I have an application which initializes the security context in one process > > ...
On Sun, Oct 05, 2008 at 12:09:09PM -0400, Michael B Allen wrote:
> On Sun, Oct 5, 2008 at 7:51 AM, Markus Moeller
> > I have an application which initializes the security context in one process
> > does some gss_wrap/gss_unwrap calls and then exports the context to hand it
> > over to another process which imports the context and continues the
> > gss_wrap/gss_unwrap. Would the second process restart sequencing at 0 or
> > continuing from where the context was exported ?
> I'm not even going to try to come up with a citation but common sense
> would suggest that an imported GSS context must use the sequence
> number of the exported context and must never reset the sequence
> number to 0. I don't see how the peer could even know that the
> sequence number was reset.
RFC2743 (and also RFC2744).
In particular section 1.2.10 (Interprocess Context Transfer) of RFC2743.
It's exactly explicit on this point, but it does say:
Since the security context data structure is expected to contain
sequencing information, it is impractical in general to share a
context between processes.
Which strongly implies that sequencing state is part of the state to be
transferred via exported security context tokens. Besides applications
would definitely break if it weren't so. It can only possibly be the
case that sequencing state must be represented in exported security
(I've not looked too carefully for more explicit requirements w.r.t.
this in the RFC.)