Subject: inquire_context for proto-contexts

From: Martin Rex <[email-masked]>
Date: Thu, 6 Nov 1997 22:52:37 +0100 (MEZ)

Although gss_inquire_context() is supposed to work on partly
established security contexts, little is said about which return
parameters need to be filled in by the gssapi mechanism in
that case.

Btw. the C-Bindings has a parameter "open" (Boolean) which requires
this call to work on partly established security context --  this
parameter doesn't appear in the high level spec.  I think it's ok to
have it work on partly established contexts, but the implications
for this case should be outlined.

The problem with availability/unavailability of context information
is especially obvious for multi-mechanism negotiation or SPNEGOtiation.

The only information that is guaranteed to be available for a proto
context is "locally_initiated" and "open" (the latter missing in rfc2078).
Some of the information may be present, but it may still be "unverified";
like "mutual_state" or "src_name" for the acceptor.  Other may still be
affected by further negotiation roundtrips ("mech_type", "src_name" for
the initiator, deleg_state ).

gss_inquire_context()

   Ouputs:

   o  src_name INTERNAL NAME,  -- name of context initiator,
                               -- guaranteed to be MN

   o  targ_name INTERNAL NAME,  -- name of context target,
                                -- guaranteed to be MN

   o  lifetime_rec INTEGER -- in seconds, or reserved value for
      INDEFINITE,

   o  mech_type OBJECT IDENTIFIER, -- the mechanism supporting this
      security context

   o  deleg_state BOOLEAN,

   o  mutual_state BOOLEAN,

   o  replay_det_state BOOLEAN,

   o  sequence_state BOOLEAN,

   o  anon_state BOOLEAN,

   o  trans_state BOOLEAN,

   o  prot_ready_state BOOLEAN,

   o  conf_avail BOOLEAN,

   o  integ_avail BOOLEAN,

   o  locally_initiated BOOLEAN, -- TRUE if initiator, FALSE if acceptor

-Martin

---

From: "Linn, John" <[email-masked]>
Date: Fri, 21 Nov 1997 12:02:15 -0500

Martin wrote, excerpting: 

> I'm still curious about the semantics when dealing with once-valid
> now-expired security contexts when calling gss_inquire_context()
> 
> How about the removal of GSS_C_CONTEXT_EXPIRED (since it is classified
> a fatal routine error) and indicating this situation via the value
> of the return parameter context_lifetime only?
> (i.e. by
>    # define GSS_C_EXPIRED   0
>  analogous to GSS_C_INDEFINITE)
> 
This sounds like a reasonable approach to me.  Comments, anyone? 

> It should be explicitly stated that gss_inquire_context() must
> continue
> to succeed with GSS_S_COMPLETE and its output values after a security
> context has transited from "valid" to "expired" until the application
> calls delete_sec_context() for this handle.  (add your comments for
> the garbage collecting language environments ...)
> 
I believe that this reflects the state of discussion.

--jl