Subject: draft-ietf-cat-rfc2078bis-02.txt enroute

From: "Linn, John" <[email-masked]>
Date: Thu, 29 Jan 1998 14:29:42 -0500

CAT/2078bis fanciers:

Along with this message, and per plan as declared at the DC meeting, I'm
sending a new revision of 2078bis to the secretariat, to become
draft-ietf-cat-rfc2078bis-02.txt, largely to respond to discussion at
the December CAT meeting refining and closing specific points re GSS-V2,
whose scope has been stable for some time.  I believe that we're very
close to convergence, but a few points (noted below) remain pending.
Please review the changes as summarized below, and identify any other
issues requiring resolution before submission of GSS-V2 Update 1 to the
IESG on behalf of the WG, to be considered for the status of a new
Proposed Standard to succeed RFC-2078.  I hope that we can achieve
closure on the remaining points shortly (in particular, by Friday, 5
February), as input to revising the document specifically against those
points and submitting the result to a CAT-WG Last-Call period to begin
later in February and to conclude before the March-April IETF meeting in
Los Angeles. 

Remaining open points are as follows:

[From DC minutes] "It was recognized that current GSS-API specifications
do not prescribe the error which should be returned if a reflected token
(a token received by the endpoint which generated it) is detected.  Many
existing mechanisms' protocols include provisions for detecting such
tokens, and it seems reasonable that a major_status code should be
selected to indicate this situation."  Martin Rex posted a comment about
this issue to the list on 8 December, proposing use of
GSS_S_DUPLICATE_TOKEN if a per-message call detects a reflected token
and recommending that such detection be mandated when the replay
detection service is provided, but I don't believe that follow-up
discussion ensued.  

[From DC minutes] "An additional RFC2078bis topic had been identified
for discussion, but was not considered within the time available and
therefore remains outstanding: should GSS_S_NO_CRED be returned by
per-message calls if credential elements are needed but unavailable in
order to complete an operation?"  

List discussion (21-26 January) included suggestions for (a) facilities
to indicate QoP preferences during context initiation and (b) new calls
coupling per-message protection with transmission of protected data over
the network protocol stack to the context's peer. I believe that
inclusion of (a) would violate the backward compatibility assumptions
which have guided us in scoping GSS-V2 changes, and that (b) would
represent a demonstrably contentious scope change at this time.  My
working assumption, therefore, is that consensus does not now exist for
reflection of these suggestions within rfc2078bis. 

List discussion, 15-20 January, re GSS-API per-message protection
negotiation; needs closure and evaluation of any resulting consideration
within documents. 

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

Changes made in 2078bis-02 relative to 2078bis-01 are as follows:

Re GSS_Inquire_sec_context(), stated that src_name and targ_name are not
returned unless the context being reported is in GSS_S_COMPLETE state,
to avoid ambiguity as to whether or not a name object is being returned
(and, therefore, whether or not the caller needs to release it).  [Done
in 2078bis-02]

Per 21 Nov discussion, removed CONTEXT_EXPIRED as error from
inquire_context, replacing with EXPIRED lifetime return value.  Stated
obligation to maintain inquirable context data on expired context until
released by caller, even though underlying crypto elements may be
deleted.  [Done in 2078bis-02]

The sense of December meeting attendees confirmed that
GSS_Inquire_context() would be aligned with the C bindings to add a
result value indicating whether or not a context was fully open.
Expired contexts are to be indicated with a reserved "lifetime" value
rather than by returning the fatal CONTEXT_EXPIRED error.  [Reflected in
2078bis-02]

Attendees confirmed list discussion regarding the indication of
informational sequencing errors along with GSS_S_COMPLETE and
GSS_S_FAILURE major_status: consistent with the C bindings, 2078bis will
reflect that the sequencing error status codes may be indicated along
with either COMPLETE or FAILURE for per-message calls; while this is
syntactically possible for context establishment calls as well, return
of sequencing error status along with COMPLETE (or CONTINUE_NEEDED) will
remain semantically prohibited during the context establishment phase.
[Reflected in 2078bis-02, sec. 1.2.1.1]

Regarding side effects, it was considered appropriate to state that
invocation of GSS-API calls incurs no side effects visible at the
GSS-API level (it being considered implausibly broad to rule out side
effects on other aspects of system behavior).  [Reflected in 2078bis-02,
sec. 1.2.8]

For GSS_Acquire_cred() and GSS_Add_cred(), GSS_S_NO_CRED, rather than
GSS_S_FAILURE as at present, is to be returned if an authorization
failure is encountered upon credential acquisition. This decision
reconciles previous inconsistent choices in the direction of informative
error reporting. [Reflected in 2078bis-02]

In discussion at the DC meeting, the idea of making provision of a
target name to GSS_Init_sec_context() optional was accepted; the
specific working proposal was to recommend that mechanisms accept
GSS_C_NO_NAME as an input target_name type.  [Added this recommendation
in 2078bis-02, in the discussion of GSS_Init_sec_context(); also added a
small GSS_C_NO_NAME section 4.8, alongside the descriptions of other
name types.]

If an exported name object is imported with GSS_Import_name() and the
enclosed mechanism type is not recognized or unsupported, it was
considered (consistent with list discussion) that GSS_S_BAD_MECH should
be returned.  [Reflected in 2078bis-02]

Discussion at the session confirmed that RFC2078bis is to be aligned
with the C bindings by removing (rather than deprecating, as is
currently the case) GSS_S_CREDENTIALS_EXPIRED as a return value from
per-message protection, context_time, and inquire_context calls.
[Reflected in 2078bis-02]

Regarding the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials
with explicit names, it was considered at the DC meeting that an
explicit name as returned from GSS_Inquire_context() should be
acceptable as an input to credential acquisition.  It is important to
recognize that the explicit name which is yielded by resolution of a
reference to "default" may change over time, e.g., as a result of local
credential element management operations outside GSS-API. [Reflected in
2078bis-02, in texts for GSS_Acquire_cred() and GSS_Add_cred().]

--jl

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

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 11 Feb 1998 15:43:54 -0500

From: "Linn, John" <[email-masked]>
   Date: Thu, 29 Jan 1998 14:29:42 -0500

I would suggest the addition of text here noting that GSSAPI V1
mechanisms will almost certainly not support GSS_C_NO_NAME as an input
target name.  Applications who care about portability should be warned
about this.

Also, while we're at it, can we please also add text to the C bindings
specification noting that in gss_init_sec_context, V1 mechanisms were
only required to accept GSS_C_NO_BUFFER?  The V2 C bindings
specification require mechanisms to support either GSS_C_NO_BUFFER or a
zero-length buffer.  One could argue this is a non-backwards compatible
change, but if we're going to keep this change in, application writers
should be warned that if portability with V1 mechanisms is a concern,
they should only use GSS_C_NO_BUFFER.

Implementation note: The original Open Vision implementation and MIT
Kerberos V5 1.0 release only support GSS_C_NO_BUFFER.  Due to complaints
that this differed from the V2 CBindings specification, this was fixed
in the patchlevel 1 of MIT's Kerberos V5.

						- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 11 Feb 1998 15:58:46 -0500

CAT/2078bis fanciers:

I agree that use of GSS_S_DUPLICATE_TOKEN seems appropriate.

Given the mechanism design, it seems reasonable.  However, I don't
believe the mechanism design is at all reasonable (i.e., the assumption
that long-term private keys are required in order to do the per-message
calls, and so that the security context can become useless earlier than
the promised context expiration time, due to the long-term keys
disappearing.)

At the very least I think we need to have some discussion about why this
is a bad idea, since it makes the application writer's job somewhat
difficult, if it has to plan to be able to recover from this
eventuality.

I agree we should not consider these new functionality changes at this
time.

I'm not sure which list discussion you're referring to?  The only thing
I can find in my mail archives from that period is the exportable
encryption and Kerberos discussion.

						- Ted