Subject: RE: inquire_context for proto-contexts

From: "Linn, John" <[email-masked]>
Date: Fri, 7 Nov 1997 09:40:14 -0500

Martin writes:

> 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.
> 
I haven't checked the archives, but am not sure whether we've explicitly
discussed the question of whether/how gss_inquire_context() is expected
to operate with a partly established context.  The high-level spec is
silent on the issue; we should, I believe, align between 2078bis and the
C bindings regarding the presence/absence/semantics of the "open"
parameter.  

> 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 ).
> 
Considering this on the fly, it strikes me that we've already addressed
these issues in conjunction with gss_init_sec_context() and
gss_accept_sec_context(), and that perhaps we could consistently reuse
the solutions derived there as follows:

Include an "open" Boolean parameter, considering that its two states
represent: (0) that the last gss_init or gss_accept call performed at
the local endpoint against this context returned GSS_S_CONTINUE_NEEDED
or (1) that the last gss_init or gss_accept call performed at the local
endpoint against this context returned GSS_S_COMPLETE.  (I believe that
this is equivalent to the semantics as described in
draft-ietf-cat-gssv2-cbind-04.).  If (1), all gss_inquire_context()
outputs are valid.  For (0), state that the rules as described per
gss_init and gss_accept for status indications along with
partly-established contexts apply. 

Would this be workable and palatable?

--jl

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 15 Nov 1997 20:03:10 -0500

From: "Linn, John" <[email-masked]>
   Date: Fri, 7 Nov 1997 09:40:14 -0500

What does "valid" mean in this context?  Does this mean that the
returned value may not yet be verified?  Does it mean that
gss_inquire_context will not try to fill in the value at all?  

This last is important for things like src_name and targ_name, since the
caller may need to deallocate memory if they are filled in by the
gss_inquire_context.   

If we do allow gss_inquire_context to fill in src_name and targ_name
while returning 0 for open, then we would also need to mandate that if
gss_inquire_context does not have the source or target name yet, it
should pass GSS_C_NO_NAME, so it is unambiguous to the caller whether or
not the name needs to be deallocated.

						- Ted