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

From: "Linn, John" <[email-masked]>
Date: Fri, 14 Nov 1997 09:35:51 -0500

Martin wrote:

> Linn, John wrote:
> > 
> > ISSUES PENDING re 2078bis-01: 
> > 
> > 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?
> 
> 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
> 
This clarification of point (b) makes sense to me.  Any disagreement?

> > 
> > 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.]
> 
...

>   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.
> 
I assume that this should be true, given the existing assumptions about
behavior upon GSS_S_COMPLETE and GSS_S_FAILURE (independent of presence
or absence of a supplementary status bit).  

> > 
> > CHANGES MADE in 2078bis-01:
> > 
> > [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.
> 
> 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 :-)
> 
This edit was to fix a defect in the -00 text, not to permit "default"
to be returned as an output mech_type (which has always been precluded,
and remains so).  Specifically, the words in -00 said that the *only*
circumstance under which a caller should receive an output mech_type
different than that which was input was the case of a negotiating
mechanism.  The fix was to state that, in addition to negotiating
mechanisms, callers should also expect to receive a different value than
they specified if their specified input was "default".

> > 
> > [BIS1-7] If negotiated mechanism mech_type passed to 
> > GSS_Canonicalize_name(), stated that GSS_S_BAD_MECH status is to be 
> > returned.
> 
> 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.
> 
This sounds compatibility-safe if restricted only to the case when the
type of name being imported is the exported name type.  Comments,
anyone?

> > 
> > [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. 
> 
> 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.
> 
This was part of the point (sorry if my wording above was obtuse), at
least within the scope of INITIATE and BOTH credentials as noted above.
I propose to clarify that, for all credential usage types, that the
explicit name returned by:

gss_inquire_cred(gss_acquire_cred(empty name))

should, if presented to gss_acquire_cred() or gss_add_cred(), be treated
equivalently to calling gss_acquire_cred() or gss_add_cred() with the
empty name argument.  

> 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.
> 
> 
I believe this inherently, but am not sure that a further statement is
necessary.  It's clear that the input name is intended as a selector for
the principal identity under which credentials are to be established.
The intent of the quoted paragraph wasn't to change this fact, just to
comment about the possibility that an implementation might need to make
a local choice if more than one credential element matches the requested
identity; since all such credential elements would match the same
explicitly provided name, the name doesn't disambiguate among them.

> -Martin
--jl

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 Nov 1997 16:44:49 +0100 (MEZ)

Linn, John wrote:
> 
> > > Can we constrain the circumstances under which supplementary info bits
> > > no 2078bis action.]

I don't think so.  See the description of the major status code
GSS_S_DUPLICATE_TOKEN and GSS_S_OLD_TOKEN in Cbind-04 in Sections
7.1.  gss_accept_sec_context  and  7.19.  gss_init_sec_context
where it says "This is a fatal error during context establishment."

This is copied from high-level and unchanged from RFC1508/1509.
For me, it is not obvious that the C-Bindings require the informatory
status bit to be paired with GSS_S_FAILURE or any other routine error.

It's funny: the GSS_S_COMPLETE is considered Informatory in 1508/2078*,
but it certainly is not "informatory" in C-Bindings -- there, it is
currently defined as the absence of status indicators:

   The routine documentation also uses the name GSS_S_COMPLETE, which is a
   zero value, to indicate an absence of any API errors or supplementary
   information bits.

The application cannot decide whether an informatory status is
*conciously* combined with GSS_S_COMPLETE, or if the mechanism
implementor didn't add a routine error because he thought he
didn't have to.

Acutally, I'd rather like to see a definition that says "a routine
is considered successful when no routine error is returned.
When only informatory status bits are returned, it is at the
discretion of the application how to proceed."

-Martin

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 15 Nov 1997 21:02:25 -0500

From: "Linn, John" <[email-masked]>
   Date: Fri, 14 Nov 1997 09:35:51 -0500

Seems fine to me.  I'm currently returning GSS_S_BAD_NAME, but
GSS_S_BAD_MECH would be more descriptive.

						- Ted