To: cat-ietf@MIT.EDU
Cc: linn@cam.ov.com
Subject: Upcoming draft-ietf-cat-gssv2-02.txt
Date: Fri, 02 Jun 1995 10:38:31 -0400
From: John Linn <linn@cam.ov.com>

All:

We've had a lot of discussion on the list recently, raising and
resolving a number of issues.  To checkpoint progress on the spec, to
support John Wray's parallel revision work on the C bindings, and to
provide a concrete basis for review and from which to proceed, I'm
about to send a revised Internet-Draft to the I-D editor, which will
become draft-ietf-cat-gssv2-02.txt.

I do *not* believe that this version is ready to be recommended for
standards advancement at this time, and intend that the topics under
"ISSUES PENDING" in the attached list be resolved (either by including
specific text or by deciding that they will not be addressed) in
another I-D to follow in the next few weeks, with that resultant I-D
to be the basis for advancement. 

I appreciate the support of all contributors to the collaborative effort
of creating GSS-V2, and solicit the following:

(1) review and specific comment on the text of the upcoming gssv2-02,
particularly the recent changes noted below under "ACTIONS TAKEN..."
anticipating that its text (modulo issues identified below under
"ISSUES PENDING") will become the basis for advancement.

(2) further progress and proposals to reach consensus on the pending
issues.

Thanks, ...

--jl

I. ISSUES PENDING:

I.1: Ongoing discussion re pros and cons of including
GSS_Get_mechs_for_name(); possible rename to
GSS_Inquire_mechs_for_name().  Based on the discussion following the
concrete proposal I circulated on 26 May, I think we're approaching
rough but relative consensus on including this facility for an
internal name (note that this cannot always be accomplished indirectly
via GSS_Acquire_cred(): consider, e.g., the fact that the name being
processed may refer to an entity in a remote domain, to be used as a
target_name argument to GSS_Init_sec_context() and for which local
credentials cannot be acquired), but the additional ability to provide
this operation for a non-imported external name remains more
contentious.

I.2: Proposed addition of gss_indicate_cred_mechs() and
gss_inquire_cred_by_mech() routines, associated deprecation of
GSS_Inquire_cred() (or at least clear and specific documentation of
the constraints applicable to use of its results in multi-mechanism
environments) because of ambiguity in interpreting multi-mechanism
credentials, per John Wray's 10 April E-mail and subsequent
discussion.  As I review it, the sense of the thread isn't conclusive,
but leans toward acceptance of the proposal. [Aired to list, 26 May.]

I.3: Related to the topics in the two preceding paragraphs, is there
(additionally or alternatively) a need for a facility which, when
passed a mech_type OID, returns the set of name type OIDs supported by
that mechanism?

I.4: Consideration of Ted Ts'o's proposed revision (26 May) to text of
GSS_Export_sec_context() and GSS_Import_sec_context().

I.5: Proposal for context renewal facility, per John Wray's (separate)
E-mail of 10 April.  This proposal also subsumes the prior suggestion
of having GSS_Process_context_token() become able to return an output
token: the existing routine and its signature would remain unchanged
but be deprecated, and a new GSS_Maintain_sec_context() routine would
subsume and generalize its function, returning an output token if
needed.  There wasn't much follow-up discussion about whether or not
this facility should be included. [Aired to list, 26 May.]

I.6: Definition of generic host-based service name type at GSS-API
level? John Linn proposed refinement, 22 May: default the host name,
if omitted, to the name of the local host. [Aired to list, 26 May.
Ted Ts'o endorsed; no other comments received.]

I.7: Include specifics of channel binding address structures for
GSS_C_AF_INET and GSS_C_NULLADDR, as per X/Open?  [C bindings issue.]

I.8: Get an IANA assignment for a GSS_C_NAMETYPE_ANONYMOUS OID.

II. ACTIONS TAKEN IN GSSV2-02 (relative to GSSV2-01):

II.1: GSS_Get_mechs_for_name() call tentatively included (but see also
I.1 above.)

II.2: Added GSS_Export_sec_context() and GSS_Import_sec_context(),
also adding a trans_state value to the context flags and reflecting
same in the routines which process those flags, and new major_status
values GSS_S_UNAUTHORIZED and GSS_S_UNAVAILABLE.  Per C. Adams
comment, made Import, as well as Export, capable of returning
GSS_S_UNAVAILABLE.

II.3: Added (fixing oversights) anon_state return values from
GSS_Accept_sec_context() and GSS_Inquire_context().

II.4: Assigned a working OID for GSS_C_NAMETYPE_ANONYMOUS, in section
1.2.5.  [This should become an IANA-assigned value; see also "ISSUES
PENDING" above.]

II.5: OID set support facilities: Included in support calls section of
V2-02, sections 2.4.11-2.4.16.

II.6: Per E-mail (John Wray, 10 Apr & following discussion), removed
default credential construct, instead describing in terms of default
behavior which may vary for initiator vs. acceptor purposes. [Done in
V2-02, but I couldn't figure out how to state this without recourse to
"default credential elements", and particularly solicit review of such
references.]

II.7: Added commentary (sec. 1.1.1, Credentials) that all elements of
a single credential structure correspond to a common entity.

II.8: Cleanup requirements following failed gss_init_sec_context() or
gss_accept_sec_context(); see Nessett, Wray mail 9-10 May.  [REVISED
V2-02 text under GSS_Init_sec_context() and GSS_Accept_sec_context()
to state that the initial call returns a non-zero handle iff
accompanied by GSS_COMPLETE or CONTINUE_NEEDED, and that once a
non-zero value is received a caller should call Delete_sec_context to
free resources. Sent message to the list 19 May proposing this and
soliciting comments.]

II.9: Marc Horowitz's suggestion (20 April, & following discussion)
about tightening the description of what values are or may be returned
as valid, and therefore need to be freed, along with major_status
other than GSS_S_COMPLETE from context establishment routines.
[Added, in V2-02, comment that mech_type OID is valid only along with
GSS_S_COMPLETE; my 19 May message as cited for previous item sounded
the list for confirmation that this was sufficient and suitable.]

II.10: Piers McMahon's 15 May message re X/Open branding.  [I believe
that the only change this message motivates on the high-level spec is
a comment about concrete channel binding definitions being added to
the C bindings as well as to mechanism specs, and have added this
comment to sec. 1.1.6 of V2-02.  Also sent a message to the list about
divergences between X/Open conformance and IETF permissiveness; no
further discussion suggested additional treatment in the specs.]

II.11: Per April '95 minutes, need comment that interface
implementations have to be self-initializing.  [ADDED IN V2-02: Short
new section 1.2.6, Initialization.]

II.12: Dan Nessett, 3 May 95: says that I-Ds and RFCs are inconsistent
in their description of GSS_Compare_name() semantics.  Should check
and fix if needed.  [TIGHTENED IN V2-02.]

II.13: Per E-mail from Dan Nessett (27 Apr), underscore that the
input_name_type argument only serves to identify the (syntax of?) the
input name, not to type the name returned. [DONE IN V2-02 DESCRIPTION
OF GSS_IMPORT_NAME.]

II.14: Proposed clarification that mechs (in particular example, the
negotiated mechanism) may return an actual mech type which doesn't
correspond to the explicitly-requested input OID.  Per list discussion
including at least Doug Rosenthal, added this comment to the
description of GSS_Init_sec_context(). [DONE IN V2-02]

II.15: Per Dan Nessett (26 Apr), migrate Appendix B/C discussion from
appendixes into the base text. [DONE IN V2-02: App B is now Sec. 4;
App C is now App B and retains a little bit of other discussion, a/o 1
May 95]

II.16: QOP: Sent action proposal to list, 17 March.  [DONE IN V2-02:
Unwound back to previous text per Danvers meeting discussion.]

III. ISSUES RAISED, BUT NOT DRIVING ACTIONS:

III.1: Support for advisory context expiration.  Don't believe that
there was consensus here for change at the GSS-API level; most
discussion was specific to the semantics of the Kerberos mechanism.

III.2: Semantics of GSS_Display_name(): There was some discussion
about the idea that a common display format would be useful, but no
apparent consensus about how to achieve one.

III.3: QOP restructuring for negotiation support: I believe we're not
doing this now, and Doug Rosenthal confirmed to the list that this
would be treated in the subsequent negotiated mechanism I-D.  Denis
Pinkas' 3 March negotiation proposal calls for a new major_status,
GSS_NEGOTIATION_FAILURE.  This is for use iff extension APIs to
modulate negotiation are adopted, so is not apparently a V2 issue.

III.4: What about GSS_Parse_token()? [Sent message to list, 8 May,
seeking closure on the issue. No response as of 17 May; conclude that
it doesn't go into the spec.]