Subject: mastering CONTEXT_EXPIRED

From: Martin Rex <[email-masked]>
Date: Thu, 6 Nov 1997 00:14:13 +0100 (MEZ)

Did anyone besides me implement (or think about) security context refresh
provisions within the "application" wrapping protocol?

I have written a wrapper library around GSS-API for our application
to facilitate the integration of GSS-API into our various communication
protocols.  This wrapper provides a framing protocol for the wire and
simplified dealing with names, error processing, dynamic loading of
mechanisms.  However it doesn't provide transport and is similarly
stateless as the gssapi itself.  But it is able to hide the security
context refresh completely from the application (well, almost -- it
forces the application back into synchronus communication).

Here are my (personal) obervations:

  I call gss_context_time() before every message protection call, so
  this routine should really be low-overhead.

  Since a security context may expire while a protected message
  is "in transit / on the wire", the application will usually
  try to start security context refresh before the context is
  expired.  Accounting for clock skew might still be a good idea
  for some of todays environments.
 
  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.

When the application calls in to export the security context,
it may not be prepared to suddenly do message transport (i.e. the
security context refresh).  When calling message protection
(gss_wrap() or gss_getmic()), then it's easy for a wrapper to
return new context establishment tokens instead of protected
messages.

When calling message unprotection (if context expiration
is enforced), a CONTEXT_EXPIRED will either (a) require a retransmission
of that message under new protection after the security context
has been refreshed, or (b) cause loss of that particular protected
message, or (c) cause an abortion of the communication if the
application layers above can not cope with message loss and
don't implement a retransmission queue.

My wrapper shadows all context characteristics except for expiration
time, so to refresh the security context, I never have to call
inquire_context() -- but if a less complex wrapper didn't shadow
it and wanted to refresh the security context, it wouldn't be
able to verify that the new security context has the exact same
attributes and peers as the expired one.  This may not be an issue
for single process single context applications, but as soon as
one is juggling around with thousands of parallel security contexts 
accross a small team of cooperating processes, then this is an issue.

How about removing the GSS_S_CONTEXT_EXPIRED as a valid
error code from gss_inquire_context and adding 

#define GSS_C_EXPIRED 0 

for returning this information via lifetime_rec only?

-Martin