Subject: some gssapi error handling clarifications

From: Martin Rex <[email-masked]>
Date: Wed, 29 Oct 1997 23:58:21 +0100 (MEZ)

I have recently been trying to map an existing authentication scheme into
a gssapi mechanism and ran into problems how to deal with certain
error conditions:

- what is supposed to happen when an application calls
  gss_accept_sec_context() or gss_init_sec_context() with the
  handle of an already fully established security context.

  I'd like to require the gssapi mechanism to return an error,
  and I think this should go into the documentation.
  GSS_S_FAILURE is the closest among the currently defined
  major status codes -- should there be a new one?

- what is supposed to happen when an application calls
  gss_accept_sec_context() or gss_init_sec_context() and supplies
  an explicit credentials handle on the first call, and
  GSS_C_NO_CREDENTIAL or a different credential for the
  continuation call(s)?

  I'd like to require the gssapi mechanism to notice and error
  for at least the two obvious cases:

   - the gss_cred_id_t changes between initial and continuation calls.

   - the non-NULL gss_cred_id_t has been released between calls.
     (well, at least for the language environments where 
      and cases when this is **easy** to recognize).

  or do folks feel that the existence of GSS_S_DEFECTIVE_CREDENTIALS
  makes consistency checks on the credentials an implicit compliance
  requirement? (I don't think so).

-Martin

---

From: Marc Horowitz <[email-masked]>
Date: 30 Oct 1997 16:42:21 -0500

>> a gssapi mechanism and ran into problems how to deal with certain

For what it's worth, this snippet of code from the krb5 gss mech
implementation handles both error conditions:

      /* make sure the context is non-established, and that certain
	 arguments are unchanged */

      if ((ctx->established) ||
	  (((gss_cred_id_t) cred) != claimant_cred_handle) ||
	  ((req_flags & GSS_C_MUTUAL_FLAG) == 0)) {
	 (void)krb5_gss_delete_sec_context(minor_status, 
					   context_handle, NULL);
	 /* XXX this minor status is wrong if an arg was changed */
	 *minor_status = KG_CONTEXT_ESTABLISHED;
	 return(GSS_S_FAILURE);
      }

I'm not convinced that a new major error code is necessary, but it's
certainly the case that the failure is mechanism-independent.  It does
seem that this error would indicate a bug in the application, which
means that normal users would never see it, and couldn't do anything
about it if they did.  Allocating a new error code for a "can't
happen" scenario does seem a little wasteful.

WRT changing the cred handle, I would say that the spec should state
that the caller must always pass the same credential to the function,
but be silent about what checks the library must make.  "Be liberal in
what you accept, and conservative in what you send."

		Marc

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 30 Oct 1997 19:54:39 -0500

From: Martin Rex <[email-masked]>
   Date: Wed, 29 Oct 1997 23:58:21 +0100 (MEZ)

This seems reasonable to me.  Passing in an already established security
context is a programming bug, so it shouldn't happen to users running a
fully debugged application.  Using a generic error like GSS_S_FAILURE
seems reasonable to me.

I think it's clear that we need to make sure it is clear that the
application must always pass the same credentials (and other
init/accept_sec_context arguments) between the initial and the
continuation call(s).  

I don't know that we want to make the library enforce such things.  To
me, this falls in the same category as somehow who passes an invalid
pointer which points off into invalid memory.  It's a bug, and it may
cause the program to segmentation fault or GPF; I don't think it should
be up to the library to validate pointers for validity before using
them.  Similarly, if the application program does something which
violates the spec, the results can be "undefined" without mandating that
the library check and do something special.

						- Ted