Subject: RE: mastering CONTEXT_EXPIRED

From: "Linn, John" <[email-masked]>
Date: Thu, 6 Nov 1997 12:06:05 -0500

Martin writes, excerpting:

>   If I had to call gss_inquire_context() I really wouldn't want it
>   to fail with GSS_S_CONTEXT_EXPIRED (i.e. *not* return both names
>   and the context attributes) -- or it wouldn't be possible to verify
>   that the new security context has exactly the same characteristics
>   and same peers as the old one.
> 
>   Due to the stateless nature of gssapi, it would also be easier if
>   security context transfer with export_sec_context/import_sec_context
>   would ignore the context lifetime and not be allowed to return
>   CONTEXT_EXPIRED.  My implementation is currently unable to refresh
>   an already expired security context when export/import_sec_context()
>   returns CONTEXT_EXPIRED.  I even claim that you have less code and
>   complexity in both, the application and the gssapi mechanism if
>   export/import_sec_context() wouldn't check the context lifetime
>   when implementing security context refresh.
> 
I understand the motivation.  Given, however, a premise that mechanism
implementations shouldn't be required to preserve information about
expired contexts indefinitely, some sort of error must be possible.
Would it be significantly better for the state to transition directly to
GSS_S_NO_CONTEXT, without even a transient interval where
GSS_S_CONTEXT_EXPIRED might be returned? 

--jl

---

From: Martin Rex <[email-masked]>
Date: Thu, 6 Nov 1997 18:48:36 +0100 (MEZ)

> GSS_S_CONTEXT_EXPIRED might be returned? 

*ANY* error from export_context/import_context will stop my code from
attempting a security context refresh.

A security context is not a self-destructing object.  There will be
some piece of information around as long as the handle is valid and
has not been passed to gss_delete_sec_context().  Many gssapi mechanisms
are stateless service provider (libraries) that only get control when
the application calls them.  The referenced context may be long long
expired.  Every attempt to quantify a grace period will fail.

Only gssapi mechanisms with specific architectural characteristics
(TCB) may have an idea about the contexts state while it is exported
anyway.  Context transfer for TCB-oriented gssapi implementations
that "export/import" only a reference to a context in the TCP
is currently underspecified -- and our application does dispose of
exported security contexts by simply memsetting them to zero
on a regular basis.

No matter what the structure of a context is like, the gssapi
implementation must adhere to some of the rules.  If the application
was able to obtain a valid context handle, the handle will have to
remain valid for as long as the application desires -- which may
be even months or years (depending on the OS...).  The context
referenced by that handle may expire or become unusable, the
handle must remain valid and must be passed to gss_delete_sec_context
by the application to be released.  I would consider the major_status
code GSS_C_NO_CONTEXT semantically invalid for "valid handles",
independent of the state or usability of the context.

If the gssapi implementation disposes of cryptographic keys as soon
as it notices that a context expires or becomes unusable, that is
fine.  However I don't see a problem with keeping the flags and
the name of both peers around, since the application is still
supposed to call gss_delete_sec_context() to release any resources
associated with that context handle.

-Martin