Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/cat/cat-minutes-96dec.txt

Text File | 1997-01-30 | 26KB | 505 lines

Editor's note:  These minutes have not been edited.

[Note to WG members: some points have been added here relative to the
draft version which I sent to the list on Tuesday, reflecting comments
and notes received from attendees.]

CAT WG MINUTES, 1996 SAN JOSE IETF

Reported by John Linn (OpenVision).

GENERAL SUMMARY

The Common Authentication Technology (CAT) WG met for two sessions at
the 1996 San Jose IETF.  The primary topic of the first session was
resolution of outstanding issues affecting the GSS-V2 C bindings
document.  Almost all issues were resolved.  Following on-list
confirmation of one working position reached at the meeting, we
anticipate that one further revised I-D will be produced and targeted
for WG Last Call.  Specific points and corrections to be made to the
high-level GSS-V2 document will be captured in an errata document, to be
reflected when that document is proposed for advancement to Draft.  The
Simple Negotiation (SNEGO) document was also discussed, and an
alternative approach in which the negotiation is protected against
active attack was requested and development of a proposal was
volunteered; further consideration of SNEGO's standards advancement was
deferred until February 1997, anticipating that SNEGO and the alternate
proposal will be compared at that time.

The recently-updated FTP security I-D will be placed into WG Last Call
for advancement to Proposed Standard following the meeting.
Presentations were received on the new Kerberos pk-cross I-D, new key
derivation I-D's, and the recently-updated Kerberos pk-init, SESAME
mechanism, and gss-idup I-Ds, engendering several active discussions.
Revisions for pk-init, pk-cross, gss-idup, and key derivation I-Ds are
planned in response to comments. An update to RFC-1510 is anticipated by
15 January 1997, and its planned content areas were summarized. Although
not official CAT WG work items, brief status talks were also received on
SASL and Ident extensions.

GSS-V2 C BINDINGS

Following agenda review, most of the first session was devoted to
discussion of the GSS-V2 C bindings document.  The discussion was led
by John Wray (Digital), the document's editor, who summarized known
issues and then revisited those requiring further discussion.  The
most contentious topic was memory allocation of OIDs (the
"GSS_Release_OID" issue).

Working rules of engagement were noted for resolution of GSS C
bindings issues.  Desirably, approaches which do not impact the
high-level specification are to be preferred.  Any changes needed to
the high-level specification will be recorded in a working errata
document, and reflected into the specification at its next standards
action (i.e., when advancement to Draft Standard is contemplated).  It
was observed in discussion that most such changes encountered were
clarifications applicable to "corner cases", not inconsistent with the
high-level specification's current status as soon-to-be Proposed
Standard.

The following point was noted in opening discussion of the C bindings
document: the current C bindings draft states that credential elements
cannot be added to the default credential (gss_add_cred() description
discusses behavior in this case); this needs to be flagged in errata
for the high-level specification. Following is a list of further
issues discussed.  No new issues were opened at the meeting beyond
those which are enumerated here and which had previously been opened
by E-mail.

#1: A tightened description had been requested about the behavior of
gss_import_name() with GSS_C_NULL_OID as input.  Ted Ts'o had noted a
presumption that use of the host-based service name form would result
but John Wray disagreed, stating that this behavior shouldn't be
constrained and that a local GSS implementation should be free to
interpret a default name type based on local information. Marc
Horowitz stated that host-based service is the common case, but that
this won't necessarily hold universally.  Bill Sommerfeld noted that
different existing implementations behave differently (e.g., observed
in DCE experience).

The following possibilities exist: Prohibit, define strictly, leave as
a local matter (making clear that different mechanisms and different
instances of the same mechanism may interpret differently).  Our
working agreement (impacting both C bindings and high-level
specifications) is as follows: State that GSS-V2 mechanism specs shall
define the behavior of the GSS_C_NULL_OID type for their mechanisms;
these may, and likely will, be partly and algorithmically dependent on
local information.

#2: Changes as summarized on the mailing list re
gss_inquire_mechs_for_name() and nametype OIDs have been incorporated.

#3: A contentious issue, impacting both C bindings and high-level
specifications, concerns treatment of OID management routines and
memory allocation issues.  Extensive follow-up E-mail discussion had
ensued, including suggestions to eliminate dynamic OIDs and various
calls. The basic question is: which OIDs and OID sets must callers
release?  Ted Ts'o related history: many GSS-V1 calls return OIDs,
which are static.  In the GSS-V1 spec, no routines returned dynamic
OIDs, though dynamic OID sets were returned.  GSS-V2 added new
convenience routines which returned dynamic OIDs, introducing the
possibility that both types of OIDs could exist.  By implication,
either the caller application or the GSS_Release_OID implementation
needs to be able to distinguish one type of OID from the other.  This
is difficult in multi-mechanism implementations since the glue layer
can't tell about the static OIDs within individual mechanisms.  If the
new convenience functions were to be removed, these issues would
become moot.

A slide was presented summarizing the three proposals which had been
presented by E-mail before the meeting:

#3-1. Delete gss_release_oid(), specify that all OID sets (but not
OIDs) returned by GSS calls must be released, replace gss_str_to_oid()
with gss_add_oid_set_member_str(). (Withdrawn in favor of #3-3.)

#3-2. Redefine OID and OID set structures, state that all GSS-returned
OIDs and OID sets must be released, make return of all OIDs and OID
sets optional to callers.  (Rejected for lack of backwards
compatibility with GSS-V1.).

#3-3. Remove gss_str_to_oid(), gss_oid_to_str(), and gss_release_oid()
from specifications.  (Dennis Glatting (CyberSAFE) had commented on
the mailing list that he'd seen value in the routines which this
proposal would remove; Ted Ts'o indicated skepticism as to these
routines' value but recognizes the argument and suggested that these
routines be moved into a new, separate mechanism-independent
convenience function document.)

Several additional proposals emerged during meeting discussion:

#3-4. Ted Ts'o introduced this proposal: retain dynamic OIDs, and make
applications responsible for knowing which OIDs to release as a
function of which routine they came from (or, per Bob Blakley (IBM),
based on different types).

#3-5. John Wray noted that the current spec (given specified
constraints) could be implemented as is.

#3-6. Define new "dynamic OID" types for these routines.

#3-7. Cache results of gss_str_to_oid().

A straw poll was taken of attendees to determine which of these
approaches they would consider tolerable: #3-1 (withdrawn); #3-2: 5,
#3-3: 10, #3-4: 9, #3-5: 1; #3-6: 9; #3-7: 1.  Based on this sampling,
it appeared that approaches #3-3, #3-4, and #3-6 were preferred, but
the latter two were new and therefore had not been previously reviewed
for broader implications. It was noted that adoption of #3-3 could
cleanly be accompanied by separate libraries (outside GSS-API) which
would provide these functions using their own allocation conventions;
in particular, it was considered desirable and possible that such
libraries could be made generally available by MIT. No attendees
indicated strong opposition to #3-3; the working position from meeting
discussion was to adopt this approach, but confirmation on the mailing
list is required.

#4: New text has been added about behavior re empty strings, and empty
OIDs.

#5: New text has been added on gss_acquire_cred and gss_add_cred
behavior.

#6: Clarification had been requested re empty tokens and on the
circumstances under which tokens may be returned.  This has been
handled in the C bindings draft and is an issue for the high-level
specification errata.

#7: New text has been added concerning the modifiability of the
default credential.

#8: Clarifications had been requested about which GSS-returned objects
must be released by a caller, and under what circumstances.  Some text
has been added to the bindings draft on this topic; further treatment
will be required to respond to the resolution of issue #3 above.

#9: A facility had been requested which, subsequent to context
establishment, could obtain any incoming delegated credential.  This
is particularly applicable to callers of gss_import_sec_context(),
which otherwise have no means within GSS-API to obtain delegated
credentials.  It was accepted in discussion that this should be
considered as a "2.1" issue (for both high-level and C bindings
specifications), to be supplied as a separate function, and that it
should not hold up V2 progression, and that a
"get_delegated_cred_from_context()" approach would be used rather than
a more generalized credential transfer facility which could open
broader policy issues.

#10: An explicit statement had been requested (for inclusion within
the high-level specification) that "release" routines can be omitted
in environments where they are not required. Bill Sommerfeld and
others noted in discussion that, even in garbage-collected
environments, an explicit release routine might be desired in order to
ensure that possibly-sensitive data is flushed.  Bob Blakley
considered such data flushing to be, instead, something which should
be handled within the mechanism.  Bill Sommerfeld agreed to propose
brief draft text on these issues for inclusion in the high-level
specification errata.

#11: Constraints had been requested on GSS_S_BAD_NAMETYPE returns from
name-related routines including gss_display_name() and
gss_compare_name(). These have been accepted and reflected in the C
bindings draft; the high-level specification needs to be aligned.

#12: This issue concerned use of the "const" keyword, usage of which
is new as of the GSS-V2 C bindings. John Wray observed that this
document specifies ANSI C bindings, and that use of const is therefore
appropriate.  Bill Sommerfeld commented that const poisoning can have
pervasive impact within implementations; Ted Ts'o had removed "const"
from the MIT Kerberos implementation after errors were encountered.
Given, however, the fact that the current bindings specification
applies "const" to input pointers only, there was apparent agreement
that its current usage shouldn't cause major problems.  Possible
follow-up list discussion may take place re the separate question of
future use of "const" on outputs.

#13: Changes to gss_release_buffer() text in current C bindings draft,
made in response to comments, were agreed to be sufficient.

#14: This issue concerned the behavior of gss_release_cred(), in
particular the effect of releasing the default credential.  The C
bindings prohibit releasing, while the current high-level
specification allows this case; the working proposal is to align the
high-level specification to match the C bindings.

#15: Deprecation of CREDENTIALS_EXPIRED returns from context-level
calls had been requested and accepted.  This has been done in the C
bindings; the high-level specification will align in its errata to
match.

#16: Text changes in the C bindings document have resolved detailed
points about context expiration policy.

#17: E-mail discussion and text changes in the C bindings document
have clarified and resolved a parameter optionality issue.

#18: The C bindings document's ABI appendix has been revised to
include added text re shared library conventions, and the result was
considered acceptable.

#19: Elaboration and changes had been requested to
GSS_Duplicate_name() and GSS_Canonicalize_name(), aligning the C
bindings with the high-level specification and, in both
specifications, rejecting GSS_S_BAD_NAMETYPE returns as discussed for
#11 above.  These changes were accepted.

#20: Clarification was requested, for the high-level GSS-V2 document,
concerning cases of processing anonymous names.  A statement was
requested that the content of the name string is a "don't care" if its
associated name type indicates "anonymous name".  Further discussion
on this point was remanded to the mailing list.

SIMPLE NEGOTIATION (SNEGO)

Denis Pinkas (Bull) led discussion on the current simple negotiation
(SNEGO) draft, draft-ietf-cat-snego-02.txt.  Approximately 10
attendees indicated familiarity with this draft or its
predecessors. An available implementation exists. There had been some
mailing list discussion over the summer about cryptographic protection
of negotiation.  While the snego design cannot negotiate a result
which is outside either peer's acceptable set, it is not protected
against an active attack forcing less-preferred members of that set to
be selected.  Such protection would add complexity and would require
that a choice be made as to what protection mechanism is to be used
for purposes of protecting the negotiation.  Denis noted, further, the
fact that support for per-message protection is not required in order
to comprise a conformant GSS-API mechanism; the FIPS JJJ mechanism
design which had previously been presented to the CAT WG was cited as
a concrete example of a mechanism providing no per-message protection
services.

John Wray suggested that negotiation proposals could be reconfirmed
(via gss_get_mic() on selection parameters) using the mechanism which
is eventually selected through negotiation.  This led to the
(unreconciled) question: "would you use 40-bit crypto if a statement
protected by 40-bit integrity told you that you had to"?  The
suggested paradigm to comprise a protected negotiation would imply
that SNEGO would need to continue control through more transaction
phases than it does currently. Marc Horowitz proposed to circulate a
draft for such a scheme to the WG during January. Bill Sommerfeld
stated that he doesn't consider unprotected SNEGO to be appropriately
useful.

John Wray raised another issue about the SNEGO draft, suggesting that
intra-mechanism options shouldn't have to be in the original
mechanism's OID tree, in order to allow independent extensions even if
not for standards purposes.  This would imply a change to SNEGO to
allow choice of separate OIDs for options.

Following a straw poll of attendees, our working position is to wait
until February to reconsider SNEGO advancement; at that time, the WG
will compare SNEGO with Marc Horowitz's anticipated draft for
protected negotiation and will decide in which direction to proceed.

RFC-1510 UPDATE, KERBEROS-PASSWORDS I-D

Cliff Neuman (ISI) presented status on the pending RFC-1510 update
(targeted for 15 January) and on the kerberos-passwords draft. The
kerberos-passwords I-D needs to be reviewed for possible alignment
with Cygnus-developed code.  Planned changes to RFC-1510 include:
incorporation of key derivation material, updating of assigned
numbers, description of extensions specified elsewhere (e.g.,
preauthentication data), possible triple-DES support, and updates to
match the accumulated errata list maintained with the MIT Kerberos
distribution.  It needs to be determined whether any of the RFC-1510
changes will imply corresponding changes to RFC-1964, and this
question warrants follow-up mailing list discussion; Marc Horowitz
commented that some new algorithm specifiers may imply a need for such
changes.

KERBEROS PK-INIT I-D

Brian Tung (ISI) led discussion on the recently revised Kerberos
pk-init draft, co-authored with Cliff Neuman, Jonathan Trostle
(CyberSAFE), and John Wray.  Approximately 8 attendees indicated
familiarity with this draft.  Changes since the version discussed at
the last meeting include addition of KDC recovery facilities and
Diffie-Hellman support.  Alpha-level software exists for use with
Kerberos V5 Beta 6; availability will be announced when
suitable. Future plans, to be addressed in an upcoming -03 draft,
include: reorganization, support for multiple private keys on KDC,
and resolution of other outstanding issues.

Denis Pinkas observed within the draft the presence of three options:
RSA encryption, Diffie-Hellman encryption, and a digital signature
scheme (which is not described as fully as the others).  He opened the
issue of which should be mandatory, and/or whether any should be spun
into separate document(s), recommending the use of a digital signature
method.  Denis believed that the scheme for storage of user private
keys in the KDC may be covered by a Digital patent; John Wray wasn't
aware of such a patent but stated that he would check on this
question.  Denis also asked about the patent status for use of the
Diffie-Hellman approach.

Brian requested that any discussion of the KDC recovery text be taken
outside the meeting, since this text has already been significantly
reorganized relative to the -02 draft and, according to Brian, "may be
dropped".  Some sentiment emerged in discussion that this mode should
be removed.  Bill Sommerfeld commented his perception that the current
protocol has too many options, and also stated that he has implemented
the RSA mode based on the -01 draft and that this implementation will
be in DCE 1.2.2.  Bill had made some suggestions based on his
implementation experience and which are reflected in his
implementation; these may already be incorporated into the -03 version
of the text.

Ted Ts'o observed that pk-init's original requirements weren't clear,
believed that this fact has promoted the current profusion of options,
and asked, "where and how do we go from here?".  The ISI reference
implementation will implement all options, and is targeted to apply
against KV5 1.0.  A new -03 draft will be submitted, after possible
further changes, as a basis for continuing discussion.

KERBEROS PK-CROSS I-D

Brian Tung led a discussion on the new Kerberos pk-cross I-D; the goal
of this scheme is to employ public-key technology in order to
establish Kerberos inter-realm keys "on the fly".  As Bill Sommerfeld
had noted in mailing list discussion, the currently-proposed scheme
does not address replicated KDCs.  An -01 version responding to this
issue and other suggestions (e.g., to improve response time) is
targeted for mid- January. A scheme for transfer of protocol elements
within tickets may be introduced, to get around lack of direct
inter-KDC paths; there was some controversy about this, but a concrete
proposal will be reviewed once it emerges.  Bill Sommerfeld is likely
to join as a new co-author of this draft, and notes that its
implementation can leverage significant common code with pk-init.  An
off-list discussion on pk-cross has been active, which Brian stated
that he would summarize to the CAT-WG mailing list.

SESAME MECHANISM I-D

Denis Pinkas led a discussion on the SESAME mechanism I-D (-01
version): 4 attendees indicated that they had read either the current
or previous version of this draft. A related SESAME architecture
document is available on the Web via
http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt/overview.txt or
(with PostScript and graphics) at
http://www.esat.kuleuven.ac.be/cosic/sesame/doc-ps.html.  Denis cited
the following SESAME goals and characteristics:

- Allows both unilateral and mutual authentication using loosely
synchronized clocks.

- When unilateral authentication used, no additional message is
needed, so an init token, wrapped token, and close token can be
concatenated and transferred in a single message.

- Today's SESAME Privilege Attribute Certificates (PACs) can carry
group memberships and roles; in future, clearances or capabilities can
be supported.

- Uses push model of privilege transfer, described as enabling
principle of least privileges by presenting and disclosing only needed
privileges.

- Privileges are directly guaranteed by original vouching authority,
not translated by intermediaries.

- Privilege transfer scheme is independent of key management scheme.
Multiple key management schemes are supported.

- Delegation control is a central feature: delegation can be
restricted to specific targets or to groups of targets. Denis noted
that XGSS provides an API which be used to modulate this facility.

SESAME's GSS-API mechanism re-uses Kerberos and SPKM structures,
incorporating them into a broader framework; PACs, however, are
SESAME-defined.  Ted Ts'o asked about the desired disposition of the
SESAME mechanism document, which has so far received limited
readership within the CAT WG. John Wray asserted that the current
SESAME mechanism I-D, less the architecture document, did not appear
self-sufficiently complete to enable independent implementations, but
this was debated. Stephen Farrell (SSE) observed that SESAME already
handles many of the goals being addressed by pk-cross.

The question was raised, "What's the state of interoperability between
SESAME and a Kerberos KDC?"  It was stated that, per prior testing, a
SESAME client can obtain tickets from an MIT Kerberos server. Ted
noted that this interoperability is analogous to (though somewhat
different from) the MIT-DCE interoperability case, and that
Microsoft's intended Kerberos usage case presents another variant
which is similar in some respects although, like SESAME, incorporating
different authorization data.  Attending SESAME participants indicated
their openness to make changes if discussed.

GSS-IDUP I-D

Carlisle Adams (Nortel) led discussion on the -06 version of the GSS-
IDUP draft, stating that it was little changed from -05.  He had added
IDUP_SE calls, comprising a simplified API supporting signing and
encryption in single-buffer and multi-buffer modes, intending that
this would become the primary interface for all callers who use just
those functions.  Signing and encryption functions, however, would
also remain accessible through the previously-defined IDUP calls.
From mechanism implementations' perspective, the IDUP_SE calls can be
directly mapped to existing calls.  Carlisle described IDUP_SE as
being suitable for "straightforward" enveloping protocols (S/MIME,
PEM, MOSS, PGP), but not for access to extra facilities such as are
available in MSP.

Most comments which had been received against the previous IDUP draft
related to the parameter bundle construct.  Meeting attendees
requested that "sign-and-encrypt" and "encrypt-and-sign" operations
(in both orders), be provided via IDUP_SE; Carlisle had planned that
this level of flexibility would be provided in the general, non-SE
interface, though it has not yet been incorporated there. It was
observed in discussion that the currently proposed nesting of
signature and encryption is incompatible with current PGP (though this
should change with PGP 3 packet formats) or with MOSS.  Carlisle
accepted an action to add more options for protection modes.  A strong
request was made that compatibility with S/MIME, PEM, MOSS, and PGP
should be possible.

FTP SECURITY AND KEY DERIVATION I-Ds

Marc Horowitz presented status on the recently updated FTP security
Internet-Draft; all but one of its changes relative to its predecessor
are clarifications which do not impact functional behavior.  He noted
that multiple vendors are shipping FTP security implementations. While
relatively few attendees had read the most recent version, a large
number were familiar with earlier versions.  Our working position is
that, following the IETF meeting, the current version is to be placed
into WG Last-Call for advancement to Proposed Standard.  A question
was raised about the position of FTP security, and of
security-integrated versions of other IETF application protocols,
given the alternate prospect of SSL/TLS usage; the intent is that both
types of approaches can proceed in standardization and that the
marketplace (or sectors thereof) can select and adopt as appropriate.

Marc also summarized the status of the recently-released key
derivation Internet-Drafts; some changes will be made based on
comments received from cryptographers, and additional comments (e.g.,
requests for test vectors and improved clarifying text) were made.  It
was also noted that key derivation would be reflected for Kerberos
purposes in the RFC-1510 update, in order to support triple-DES.

OTHER CAT-WG I-Ds

Work on the IDUP C bindings document is currently idle.  The Windows
GSS bindings document is currently in Ted Ts'o's hands, pending
revision work.

SIMPLE AUTHENTICATION AND SESSION LAYER (SASL)

John Myers (CMU) presented brief comments on the latest SASL draft,
which includes description of an IANA registration facility; use of an
"X-" naming scheme had been suggested, but John argued rationale for
use of IANA registration instead. A SASL mailing list has been
established at [e-mail]; with requests to
[e-mail]; it was reported that some level of
discussion had taken place on that list. A Last-Call on SASL, which is
not a formal work item of an IETF WG, will be attempted on that list.
No GSS-API SASL implementation exists currently, but John stated that
he expects this status to change soon.

IDENT EXTENSIONS

A brief discussion was led by Bob Morgan (Stanford) re ident
extensions (draft-morgan-ident-ext-02.txt), an approach layered on
SASL and enabling an application server to call back to a client
system to request that strong authentication corresponding to an
inbound connection be delivered to the server across a path separate
from the connection itself.