Re: gskeykex - Delete_sec_context() on re-key

[David Leonard <David.Leonard%quest.com@localhost>]

On Wed, 31 Aug 2005, Jeffrey Hutzelman wrote:

> On Thursday, September 01, 2005 11:43:52 AM +1000 David Leonard
> <David.Leonard%quest.com@localhost> wrote:
> > I was reading through the secsh-gsskeyex draft again and it struck
> > me that when re-keying there is no message provision for passing back the
> > possible token generated by a call to GSS_Delete_sec_context().
> 
> That's correct.  When you're done with a context, which in this protocol means
> pretty much as soon as key exchange has completed successfully, you can just
> call GSS_Delete_sec_context() without an output token buffer, regardless of
> whether you are the client or server.  The only purpose of an output token
> from this call is to signal _via a context token_ that the context should be
> destroyed.  In this protocol, you don't need to do that, because you always
> know out-of-band when the context can be deleted.

Ah okay, that makes sense. Some text in RFC 2743 clarifies this too: 
and that the token parameter was retained for backward compat. that's
a relief.

> > The result is that the protocol will leak unreachable context
> > over a long session.
> 
> Only if you fail to call GSS_Delete_sec_context() with a context when you are
> done using it.  Note that you do _not_ need to keep the context around for the
> life of the session -- it's only used during key exchange.

It's also used in keyex authentication. So the server does have to keep
the first context around for that. Interestingly, every other context is
short-lived so that should be okay: max of two contexts.
Consider this example session:

    C: KEXGSS_INIT
    S: gss_accept_sec_ctx .. etc .. success -> context #1 (keep)
    ...
    C: USERAUTH gssapi-with-mic
    S: gss_accept_sec_ctx .. etc.. fail (say) -> context #2 (del/incomplete)
    ...
    <re-key>
    C: KEXGSS_INIT
    S: gss_accept_sec_ctx .. etc .. success -> context #3 (can be deleted)
    ...
    C: USERAUTH gsskeyex
	"4. The GSSAPI context used with this method is
	 always that established during an initial GSSAPI-based
	 key exchange. [...] The client SHOULD NOT try this method
	 more than once"
    S: gss_verify_mic .. etc.. <- context #1 (can now be deleted)

Even without the re-key in the middle it shows how the initial kexgss 
context must be preserved until a gsskeyex is attempted.

--
David Leonard
Vintela Resource Central software engineer
Quest Software; Brisbane, Australia; www.quest.com
Phone: (US) +1 801 655 2755 
       (AU) +61 7 3023 5133