Subject: RE: some gssapi error handling clarifications

From: "Linn, John" <[email-masked]>
Date: Fri, 31 Oct 1997 15:32:09 -0500

Marc writes, excerpting:

> 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.
> 
I propose to make a note for GSS_S_FAILURE if the handle of a fully
established context is passed to GSS_Init_sec_context() or
GSS_Accept_sec_context().  Objections?

> 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."
> 
The text for GSS_Init, and analogously for GSS_Accept, states:

The claimant_cred_handle must
   correspond to the same valid credentials structure on the initial
   call to GSS_Init_sec_context()  and on any successor calls resulting
   from GSS_S_CONTINUE_NEEDED status returns

I believe that the requested silence on library checks has also already
been provided :-)

--jl

John Linn ([email-masked]), writing as an individual from
RSA Laboratories East, Bedford, MA, USA

---

From: Martin Rex <[email-masked]>
Date: Fri, 7 Nov 1997 22:42:03 +0100 (MEZ)

> GSS_Accept_sec_context().  Objections?

Ok.  GSS_FAILURE is fine.
But the fully established context is NOT to be harmed;
especially it shouldn't be deleted in that case.

> I believe that the requested silence on library checks has also already

Ok.

"If the application fails to supply the same values to the continuation
 calls the behaviour is undefined."

-Martin