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

From: "Linn, John" <[email-masked]>
Date: Thu, 12 Feb 1998 09:38:26 -0500

Ted writes, excerpting: 

>    (1) GSS_S_FAILURE: Allowed as of RFC-1508.  Not particularly
>    informative.
> 
> 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.
> 
GSS_S_FAILURE is consistent with the current spec, representing an
undifferentiated (at the major_status level) error on a recognized
context, and seems appropriate to me.  To remove possible ambiguity
about what to report when a per-message call hits a context which is
recognized but whose underlying data has become unusable for whatever
reason, this discussion makes me wonder whether the description of
GSS_S_NO_CONTEXT, which now says "... no valid context was recognized
..." should become "... no context was recognized ..."; thoughts,
anyone?

> 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.
> 
This argument makes sense to me. 

> My two cents....
> 						- Ted
--jl

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Feb 1998 21:47:38 +0100 (MET)

Since I originally asked for the alternative major_status,
I want to officially cancel my request here and now.

Linn, John writes:
> > 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
> > seems sufficient to me.

We had a discussion on this list a while ago on the consequences
of requiring credentials access for message protection, and the
side effects of this on the semantics of export/import of a
security context.  This discussion resulted from the fact that
RFC 2025 (SPKM = the Simple Public Key gss-api Mechanism) specifies
the use of RSA-based digital signatures as the only mandatory and
therefore default MIC algorithm.

I'm convinced by now that this was a bad choice for SPKM, since
it raises major portability problems without adding real value.
The "feature" of digital signatures for message integrity would
only be usable for mech-specific (i.e. non-portable) applications
anyway, so leaving the major_status as GSS_S_FAILURE and requiring
the application to check the mech-specific minor error code should
be ok -- if the application *REALLY* cares to deal with *THIS*
situation "somewhat more gracefully" than simply aborting the
connection.

Btw. I would consider it inappropriate if the gssapi mechanism returned
GSS_C_INDEFINITE as the lifetime during context establishment and
later GSS_S_*_EXPIRED from any of the message protection calls...
(CREDENTIALS_EXPIRED being obsoleted for message protection in v2).

-Martin

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 12 Feb 1998 20:22:58 -0500

From: "Linn, John" <[email-masked]>
   Date: Thu, 12 Feb 1998 09:38:26 -0500

This seems reasonable.

						- Ted