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

From: "Linn, John" <[email-masked]>
Date: Tue, 8 Dec 1998 07:54:19 -0500

Thanks to all who have responded to this message. Based on the state of the
discussion, it's my current sense that we should probably proceed with the
recommended action for 2078bis and with choice (2) for the C bindings, as
choice (2) appears to be the general preference, is compatible with known
existing code, and I'm unaware of anyone to whom it's unacceptable.  Does
anyone object strongly, or shall we plan to proceed in this direction?

--jl

> ----------
> From: 	Linn, John
> Sent: 	Thursday, December 03, 1998 9:46 AM
> To: 	'CAT-WG List'; Linn, John
> Subject: 	Late-to-light GSSV2 misalignment - review solicited [Was:
> RE: IESG request for GSSV2 documents planned]
> 
> 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: "Linn, John" <[email-masked]>
Date: Wed, 16 Dec 1998 08:55:17 -0500

CAT/GSSV2 fanciers:

I've just sent a revision of 2078bis to Internet-Drafts, to become
2078bis-08.  Consistent with this discussion, its changes are confined to
revising the annotation on acquire_cred's desired_mechs parameter to state
that NULL rather than empty set is to be used to specify default, and a
corresponding comment in the "changes from 2078" appendix.  I'll plan to
send this version to the IESG along with a correspondingly updated C
bindings spec once both documents are available.

--jl

> ----------
> From: 	Linn, John
> Sent: 	Tuesday, December 08, 1998 7:25 AM
> To: 	[email-masked]; Linn, John
> Subject: 	RE: Late-to-light GSSV2 misalignment - review solicited
> [Was: RE: IESG request for GSSV2 documents planned]
> 
> Thanks to all who have responded to this message. Based on the state of
> the discussion, it's my current sense that we should probably proceed with
> the recommended action for 2078bis and with choice (2) for the C bindings,
> as choice (2) appears to be the general preference, is compatible with
> known existing code, and I'm unaware of anyone to whom it's unacceptable.
> Does anyone object strongly, or shall we plan to proceed in this
> direction?
> 
> --jl
> 
> 	----------
> 	From: 	Linn, John
> 	Subject: 	Late-to-light GSSV2 misalignment - review solicited
> [Was: RE: IESG request for GSSV2 documents planned]
> 
> 	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
> 	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?]
> 
> 	(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
> 	(2) Replace the current statement in cbind-08 with an explicit
> statement that behavior upon receipt of an empty set is undefined by the