RE: C-Bindings/rfc2078bis discuss items

["Linn, John" <jlinn at securitydynamics.com>]

Thanks, Martin, for your detailed review.  Here are my thoughts on the
"discuss" items:

> While re-reading the C-Bindings document I discovered a few small
> issues that do indicate a slight inconsistency in rfc2078bis.
> Since we already had closure (WG last call) on the document,
> these issues should only be addressed when we have immediate and
> obvious consensus in the WG   IF we need to fix anything and how.
> 
> (1) permit GSS_C_NO_NAME as the return parameter "target_name" from
>     gss_inquire_context() (on the initiator side) for an established
>     security context
>     IF  the context was established using GSS_C_NO_NAME for target_name
>         and mutual_req_flag=0 (i.e. target-only authentication)
>         
>     Note that we added the possibility to pass in a target_name
>     of GSS_C_NO_NAME into gss_init_sec_context at the
>     Washington D.C. IETF *with the caveat* that existing implementations
>     will probably not support it, even for target-only authentication.
> 
>     Currently rfc2078bis claims that targ_name will always be valid
>     and a mechanism name (MN) when the call returns GSS_S_COMPLETE
>     and the open flag is TRUE.  GSS_C_NO_NAME doesn't fit this claim.
> 
Good point: the fairly late breaking addition of GSS_C_NO_NAME for
target_name input into gss_init_sec_context() implies a need for some
corresponding action on gss_inquire_context() as well.  I propose the
following specific response: expand gss_inquire_context's discussion of
GSS_S_COMPLETE, final sentence, to indicate that not only "open" must be
true but also that a context peer's name must be known in order for a name
to be returned.  (The description of the return name parameters already says
"if returned", implying an already-existing possibility that it might not
be.)  Any objections?

> (2) use of incomplete security contexts for message (un)protection
>     due to the "prot_ready_state" indicator.
> 
>     The current wording in both rfc2078 (section 1.2.7) says that
>     both: message protection and message UNprotection will become
>     available when prot_ready_state is returned by a context
>     establishment call. 
> 
True.  The existing 2078bis text states that TRUE prot_ready_state is
sufficient to enable usage not only of GSS_Wrap() and GSS_GetMIC() but also
of GSS_Unwrap() and GSS_VerifyMIC().

>     I'm somewhat uncomfortable with message UNprotection being
>     available before the security context is successfully
>     established.  Since we don't make any restrictions on the
>     number of message protection calls an application can do
>     at this stage, the application could theoretically exchange
>     thousands of protected messages before completing completing
>     security context establishment (or even skip context establishment).
> 
>     And what are the semantics when the security context establishment
>     fails after messages have been unprotected and processed?  It's
>     already to late, the gssapi can not roll back application actions
>     based on the unprotected messages.
> 
I'm not sure that I see this as a problem.  If the application uses
per-message unprotection upon TRUE prot_ready_state before GSS_S_COMPLETE,
it's doing so based on the information which is available at that point;
once returned, only mech_type (I believe) is liable to change upon a later
call in the context established sequence.  There's already a warning that
mutual authentication isn't guaranteed until GSS_S_COMPLETE, and the
anonymity service is a special case of its own; applications which require
services or information which aren't guaranteed until GSS_S_COMPLETE are
limited in their ability to exploit the prot_ready_state optimization. 

>     Personally, I would really appreciate if we spec'd that message
>     UNprotection becomes available only after the local security
>     context establishment call has returned GSS_S_COMPLETE.  This
>     should still satisfy Bob Blakley's original requirement,
>     which triggered the inclusion of prot_ready support in 1995.
> 
Rather than introducing a new prohibition at this point (which might be
unnecessarily strict against some valid circumstances), I'd suggest instead
that we assume (strengthening warnings if necessary) that applications
dependent on context data unavailable before GSS_S_COMPLETE will constrain
their use of the prot_ready_state facility accordingly. 

> (3) mech_type return value from gss_init_sec_context() (and
>     gss_accept_sec_context()), especially when a call fails with an error.
> 
>     It has been mostly discussed on the CAT list around March 27th, 1997
>     between Marc Horowitz and John Wray for errors during
>     gss_accept_sec_context(), but not for gss_init_sec_context().
> 
>     The problem gets more complex with the presence of a negotiation
>     mechanism, in which case the returned mech_type from the inital
>     call to gss_init_sec_context() will differ from the mech_type
>     on the final call.
> 
>     How about an alignment to both documents that says basically:
>     whenever a context establishment call fails with a minor_error!=0
>     it shall return an actual_mech_type / mech_type that can be
>     used to translate the minor_status value via
>     gss_display_status( GSS_C_MECH_CODE, minor_status, mech_type )
> 
The current situation for gss_init() and gss_accept() is that mech_type must
be valid on GSS_S_COMPLETE and may also be valid (though potentially
changeable for future calls) along with GSS_S_CONTINUE_NEEDED.  If/when an
OID is returned, the caller isn't expected to release it. Can we state
simply that a mech_type shall also be returned if determinable in
conjunction with fatal error cases, recognizing that there can also be cases
where no supported mechanism can be identified (e.g., upon GSS_S_BAD_MECH)?
Would anyone object to this (or, if so, what about a recommendation rather
than a requirement?)? If the mechanism isn't supported, it doesn't seem
likely that an implementation would generate minor status codes
corresponding to the unsupported mechanism. 

>     This is an exception to the C-Bindings rule that says that
>     (pointer) output parameters will be cleared when a routine
>     returns with a fatal error.
> 
>  
> -Martin
> 
--jl