Subject: draft-ietf-cat-rfc2078bis-01 enroute

From: "Linn, John" <[email-masked]>
Date: Thu, 13 Nov 1997 10:53:42 -0500

Along with this message, I'm sending an updated 2078bis draft to the I-D
administrators, to become draft-ietf-cat-rfc2078bis-01.txt.  Here's a
list of issues which I believe to be pending and changes made relativeto
draft-ietf-cat-rfc2078bis-00.txt; for changes included in -00 relative
to RFC-2078, please refer to my message to the list on 23 September.
Comments solicited on the listed issues, on any identified issues which
should be flagged against the high-level spec but which don't show up
here, and on the changes indicated as having been made. 

ISSUES PENDING re 2078bis-01: 

On/about 10 October, there was a discussion on the list about what, if
any, statement to include in the high level spec about side effects of
GSS calls.  Ted Ts'o suggested that we should state that no calls have
any kind of side effect other than those explicitly listed in the
specification.  If included, I think such a statement would fit most
appropriately in Section 1.2.6 or 1.2.8; does anyone want to discuss or
comment further on this prospect? 

Alignment re inquire_context "open" parameter, and (if included) 
statement of rules for what returned results must/may be valid. 

Flushing by mechanisms of information related to expired contexts; 
should we state that mechanisms must preserve enough state to  
distinguish a previously valid but now expired context until the caller
calls gss_delete_sec_context()?  The discussion seems to be heading in
this direction, but I'm not sure whether it's closed yet. 

Per [BIS1-4] below, Martin Rex asked (7 Nov) additionally for statements
that (a) pre-existing context is not impacted by passing its handle
erroneously as a continuation call for a separate context establishment
and (b) that behavior is undefined if an application fails to pass the
same context handle to continuation calls in a context establishment
sequence.  Are these OK?

Can we constrain the circumstances under which supplementary info bits
may be set along with a non-zero routine error, and what, if any,
constraints can be imposed on the set of supplementary info bits
returnable from a single call? [No list discussion, so am assuming no 
2078bis action.]

Need either to add "changes from 2078" section, or merge additional 
2078bis changes into the existing "changes from GSS-V1" section.

For gss_acquire_cred(), add GSS_S_NO_CRED as returnable major_status. 
[Done in 2078BIS tentatively, but seems to collide with pre-existing 
description of GSS_S_FAILURE as including authorization failures. Asked
list, 16 Sept 97; also applies to add_cred.]

CHANGES MADE in 2078bis-01:

[BIS1-0] Various editorial and formatting fixes. 

[BIS1-1] Updated [in 2078bis-01] reference to status of Kerberos V5 
mechanism OID, since it's now transitioned to the value intended for use
following advancement of RFC-1964 as Proposed Standard. 

[BIS1-2] Added, in section 1, references to RFC-1964, RFC-2025, and
RFC-2203 as concrete examples of related work to GSS-API; collected 
references into a new section 8, Referenced Documents. 

[BIS1-3] In sec. 1.1.4, clarified negotiating mechanisms paragraph to 
state that callers requesting "default" can receive different indicated
mech_type than the input value for "default", even in the case of a
selected non-negotiating mechanism.

[BIS1-4] Per list discussion 30 Oct, stated that GSS_S_FAILURE is 
returned if GSS_Init or GSS_Accept is passed the handle of a context 
which is already fully established. 

[BIS1-5] In sec. 3.2, corrected comments in example to state that 
MECH_OID_LEN and NAME_LEN are represented most significant byte first;
also swapped bytes consistently. 

[BIS1-6] For the "release" calls agreed as omittable in environments 
where their use would be superfluous, added statements that their 
implementation and invocation can be omitted therein. 

[BIS1-7] If negotiated mechanism mech_type passed to 
GSS_Canonicalize_name(), stated that GSS_S_BAD_MECH status is to be 
returned.

[BIS1-8] For gss_acquire_cred() and gss_add_cred(), aligned with
cbind-04 statement of likely non-support for INITIATE and BOTH
credentials if non-empty name is specified; identified empty name and
also name which would result from  gss_inquire_cred() against default
credential as names for which support is anticipated. 

--jl
John Linn ([email-masked])
RSA Laboratories East, Bedford, MA, USA

---

From: Martin Rex <[email-masked]>
Date: Thu, 13 Nov 1997 21:22:29 +0100 (MEZ)

> same context handle to continuation calls in a context establishment

I'm sorry if my mail wasn't clear on that, (b) should have meant that
behaviour is undefined if an application fails to provide the same
parameters to initial and continuation calls with *the same* handle of a
partially established security context:

   for gss_init_sec_context():       initiator_cred_handle,
                                     target_name,
                                     mech_type,
                                     req_flags,
                                     time_req,
                                     input_chan_bindings

   for gss_accept_sec_context():     acceptor_cred_handle,
                                     input_chan_bindings,
                                     src_name,
                                     delegated_cred_handle

> returnable from a single call? [No list discussion, so am assuming no 

C-Bindings issue:
  Since the GSS_S_CALL_* major status codes do not appear in the
  high level spec at all, I would like to require them being paired
  with a routine error code != GSS_S_COMPLETE.

rfc2078bis and C-Bindings
  I'm still somewhat unhappy with the current classification of
  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN as being informatory or
  fatal depending on the context (i.e. which call returns them).
  Actually, I think the C-Bindings are easier to fix since
  there these infomatory status can be combined with a routine
  error, and I think this really should be done.
  I'd really like to see (GSS_S_DUPLICATE_TOKEN | GSS_S_COMPLETE)
  being handled like a success by the mechanism (i.e. all output
  parameters must be filled in, just like with GSS_S_COMPLETE alone).
  When paired like (GSS_S_DUPLICATE_TOKEN | GSS_S_FAILURE), the
  result is definitely a fatal error.  This removes the
  context-dependence of being fatal/non-fatal for these major_status
  values.

> selected non-negotiating mechanism.

I'm confused.
I thought "default" refers to the magic interpretation of GSS_C_NO_OID,
and since GSS_C_NO_OID is by itself NOT considered a valid OID,
it certainly can not be returned from init/accept_sec_context.

The only gss call allowed to return GSS_C_NO_OID instead of a real
OID is gss_display_name() for names that were imported with nametype
GSS_C_NO_OID. (I asked for that :-)

> GSS_Canonicalize_name(), stated that GSS_S_BAD_MECH status is to be 

With the introduction of gss_export_name() we widened the scope of
possible input to gss_import_name().  Since the exported name does
contain a mechanism OID in its outer generic framing (Section 3.2),
should we add the major status value GSS_S_BAD_MECH to gss_import_name()
for the case when an exported name is imported but the mech-oid is
either not recognized or the format is not defined/implemented?
There is no backwards compatibility problem, since a V1-application
is unlikely to know the GSS_C_NT_EXPORTED_NAME nametype or get its
hands on the image of an exported name.

> credential as names for which support is anticipated. 

What I'm still missing is a paragraph stating:
  gss_acquire_cred() is supposed to work with that explicit name
  which is returned when gss_inquire_cred() is called for a
  credential created with gss_acquire_cred() using an empty name.

Btw. there is a paragraph in rfc2078bis, 2.1.1: GSS_Acquire_cred:

    ...  It is possible that multiple pre-established credentials
   may exist for the same principal identity (for example, as a result
   of multiple user login sessions) when GSS_Acquire_cred() is called;
   the means used in such cases to select a specific credential are
   local matters.

How about adding:
               ... However, an application provided explicit name
   should definitely be considered in this selection.

-Martin