Subject: Late-to-light GSSV2 misalignment - review solicited [Was: RE: IES G request for GSSV2 documents planned]

From: "Linn, John" <[email-masked]>
Date: Thu, 3 Dec 1998 09:46:00 -0500

CAT/GSSV2 fanciers:

Just as the GSSV2 documents were about to be sent to the IESG, and after the
I-D submission window closed in advance of the Orlando meeting, a specific
misalignment was identified between 2078bis-07 and gssv2-cbind-08,
concerning the desired_mechs input parameter to gss_acquire_cred.  On
investigation, it appears that the high-level and C bindings documents have
been misaligned on this topic since RFCs 1508 and 1509, so backward
compatibility is an important consideration. Since a major goal of the
current document submission is to yield an aligned set of specifications, I
believe that this issue represents a defect which needs to be resolved.
This message discusses the problem and proposes candidate solutions; my
thanks to Martin Rex, Ted Ts'o, and John Wray for their help in identifying
and sorting out the issues.

PROBLEM: In RFC-1508, RFC-2078, and 2078bis, the annotation on
acquire_cred's desired_mechs parameter states that an empty set is to be
used in order to request a default set of mechanisms, but RFC-1509 and
cbind-08 describe GSS_C_NO_OID_SET (corresponding, in 2078bis' terms, to
NULL) as the means to request a default set.  Per cbind-08, an actual OID
set structure with zero members (an empty set) would be interpreted as a
request for a credential without elements for any mechanisms, rather than
for a default set of mechanism elements.  Specific discussion of this point,
differentiating the GSS_C_NO_OID_SET case from the empty set case, wasn't
present in RFC-1509 but was added in a subsequent C bindings draft.  

PROPOSED 2078BIS ACTION: Change 2078bis' annotation on the desired_mechs
parameter to indicate that NULL is to be used as the means to request a
default mechanism set.  This would be consistent with 2078bis' descriptions
of default references for other parameters, and with the C bindings
documents.  [Question: do any existing implementations support only 2078bis'
current text discussing the means for default reference and not that of the
C bindings, rejecting GSS_C_NO_OID_SET for this purpose and accepting only
an actual OID set structure which has no members?]

PROPOSED C BINDINGS ACTIONS: I see two basic alternatives here:

(1) Preserve cbind-08's recommendation for behavior if an empty set is
received for desired_mechs, but augment it with a warning that this behavior
was undefined as of GSS-V1.  [Question: do any existing implementations
create a mechanismless credential for this case, as cbind-08 recommends?]

(2) Replace the current statement in cbind-08 with an explicit statement
that behavior upon receipt of an empty set is undefined by the
specification.  [Comment: at least one existing implementation (MIT
Kerberos) is known not to accept an empty set as a request for the default
mechanism(s), instead returning GSS_S_BAD_MECH; reports on other
implementations' behavior are welcome.]

As a goal, I would like to converge this discussion on the list by Tuesday,
15 December so that the specifications can be revised accordingly and
submitted to the IESG soon after the Orlando meeting.   Discussion
solicited. 

Regards, ...

--jl

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: "David S. Miller" <[email-masked]>
Date: Thu, 03 Dec 1998 11:46:59 -0800

> an actual OID set structure which has no members?]

CyberSafe's Application Security Toolkit does not.  In fact, we reject an empty
OID set with the GSS_S_BAD_MECH major status.

CyberSafe agrees with your proposed action above for 2078.  It's aligned with
the behavior one would expect of optional parameters.

> implementations' behavior are welcome.]

CyberSafe's Application Security Tookit is aligned with MIT in this regard;
we'd tend to favor (2) as the proposed solution here, especially to preserve V1
compatibility.  It seems there are already ways using gss_add_cred() to build a
multimech credential iteratively without first explicitly making an "empty
credential" with gss_acquire_cred().

David

--
David S. Miller    [email-masked]
CyberSafe Corporation   425.391.6000

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 3 Dec 1998 18:23:57 -0500

From: "Linn, John" <[email-masked]>
   Date: Thu, 3 Dec 1998 09:46:00 -0500 

My preference is for (2), obviously.  The current statement in cbind-08
"recommends" (although it provides absolutely no guarantees to the
application) that if an empty set is passed to gss_acquire_creds(), that
the gssapi library should an "empty" credential.  This is presumably a
credential that has an identity associated with it, which would be
returned if gss_inquire_creds were called on it, but which did not have
any authentication credentials associated with a particular mechanism.  

I believe the concept of an "empty" credential is new to GSSAPI V2, and
I'd like to ask implementors of other implementations if they could
investigate what their implementation does if gss_acquire_cred() is
presented with an empty mechanism.  My guess is that very few of them
actually provides an "empty" credential.  They probably either return a
default credential set, as per RFC 1508 and RFC 2078, or they do
something random, like return GSS_S_BAD_MECH, as the krb5 mechanism
does.  (This is probably especially true for single-mechanism
implementations.)

If we go with (1), I think we need to either put language making it
clear that this is a recommendation only, and (therefore makes it
useless for the application, since it can't be reliably depended upon),
OR we have to make it a requirement, and accept that fact that there are
many shipping implementations which currently thought they were GSSAPI
V2 compliant, but which aren't, due to this last minute change.

We can do this, since the document was only in I-D last call, and anyone
implementing a protocol while it is still an I-D is taking a risk.
(Indeed, we can even make incompatible changes at the proposed standard
level, but we'd better have a *really* good reason for it.)  But, if we
make this change, we should definitely do so consciously, knowing that
we will be breaking some shipping implementations.

						- Ted

---

From: Jacques Lebastard <[email-masked]>
Date: Fri, 04 Dec 1998 08:21:48 +0100

> an actual OID set structure which has no members?]

BullSoft GSS-API implementations do not. 

> create a mechanismless credential for this case, as cbind-08 recommends?]

Not here.

> implementations' behavior are welcome.]

BullSoft's implementations behave as MIT's Kerberos : if desired_mechs
does
not include the selected mechanism, the call fails with GSS_S_BAD_MECH.

> submitted to the IESG soon after the Orlando meeting.   Discussion

I'd rather go with (2).

However, if option (1) is selected, it should only affect applications
which
explicitly ask for a mechanism-less credential set (how many
applications
have so much knowledge of such GSS-API subtleties ?). I suspect most of
implemented applications to use GSS_C_NO_OID_SET (or even NULL) when
invoking gss_acquire_cred because they just don't know what security
mechanism(s) is(are) available (and probably don't want to know).
-- 
Jacques LEBASTARD                 mailto:[email-masked]
BullSoft - AccessMaster             http://www.openmaster.com/
Rue Jean Jaures - F3-2G-03           Tel: +33 1 30 80 77 86
F-78340 Les Clayes sous Bois         Fax: +33 1 30 80 77 99
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]