Subject: RE: inquire_context for proto-contexts

From: "Linn, John" <[email-masked]>
Date: Mon, 17 Nov 1997 10:24:56 -0500

The text for gss_accept_sec_context() doesn't cite src_name as one of
the return values which can be returned before GSS_S_COMPLETE.  I can't
recall whether this resulted from explicit discussion of the
return/non-return deallocation ambiguity, but suggest in the interests
of consistency and simplicity that src_name and targ_name are returned
if and only if a context is indicated as fully open. 

--jl

> ----------
> From: 	Theodore Y. Ts'o[SMTP:[email-masked]]
> Sent: 	Saturday, November 15, 1997 8:03 PM
> To: 	Linn, John
> Cc: 	[email-masked]; [email-masked]'
> Subject: 	Re: inquire_context for proto-contexts
> 
>    From: "Linn, John" <[email-masked]>
>    Date: Fri, 7 Nov 1997 09:40:14 -0500
> 
>    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?
> 
> 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
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 Nov 1997 20:00:49 +0100 (MEZ)

> if and only if a context is indicated as fully open. 

Ok with me.

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)

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 ...)

-Martin

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 17 Nov 1997 21:20:17 -0500

From: "Linn, John" <[email-masked]>
   Date: Mon, 17 Nov 1997 10:24:56 -0500
   X-Priority: 3

This seems reasonable to me.

						- Ted