Subject: GSS_S_NO_CRED on per-msg calls? [Was: RE: draft-ietf-cat-rfc2078b is-02.txt enroute]

From: "Linn, John" <[email-masked]>
Date: Wed, 4 Feb 1998 09:29:06 -0500

I wrote on 29 January, excerpting: 

> [From DC minutes] "An additional RFC2078bis topic had been identified
> for discussion, but was not considered within the time available and
> therefore remains outstanding: should GSS_S_NO_CRED be returned by
> per-message calls if credential elements are needed but unavailable in
> order to complete an operation?"  
> 
How shall we close this?  We've been trending towards decoupling
contexts from the credentials which established them (e.g., by the
fairly recent removal of CREDENTIALS_EXPIRED as a major_status return
from per-message calls).  Some mechanisms, however, can require ongoing
access to long-term keys or other credential element contents in order
to perform per-message operations, and it's necessary to return some
error status if they're not available.  Looking at the presently-defined
major_status values (with a definite preference for avoiding extending
that list at this late point), I can envision the following
possibilities and attendant implications:

(1) GSS_S_FAILURE: Allowed as of RFC-1508.  Not particularly
informative.

(2) GSS_S_NO_CRED: Not allowed as of RFC-1508.  Would specifically
distinguish the case of inaccessible credential elements which are
required for operations on an associated context.

(3) GSS_S_NO_CONTEXT: Allowed as of RFC-1508.  Arguably consistent with
a model where context elements are considered to subsume all data
required to perform per-message operations, even if those elements
include credential elements by copying or reference; in this view, a
context lacking such elements could be described as invalid for use, and
the description of this code says "... no valid context was recognized
...".  Use of this code doesn't, however, distinguish this case from
attempted use of a context that never existed at all. 

(4) Add no new text to specify behavior or new codes for this case,
preserving a status quo which (I believe) allows mechanism implementors
to choose either (1) or (3) to describe this case. 

Comments, anyone?

--jl

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 11 Feb 1998 16:23:05 -0500

From: "Linn, John" <[email-masked]>
   Date: Wed, 4 Feb 1998 09:29:06 -0500

Given that I believe the requirement of long-term credential elements
for per-message calls is a bad idea --- it means that applications can
get unexpected, random failures based on the disappearance of long-term
credentials which is not related to the context expiration time, I would
argue for simply leaving it as GSS_S_FAILURE, since you can always have
a mechanism-specific minor status code to describe to the user what went
wrong.   Since there isn't much an application can do in this case to
recover if the long-term credentials are gone, using GSS_S_FAILURE seesm
sufficient to me.

Using GSS_S_NO_CRED would mean that it has two very distinct meanings
depending on whether it is being returned in context establishment calls
or in per-message calls, and that seems like something that should be
avoided if we can at all help it.

My two cents....

						- Ted