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


Common Authentication Technology (CAT) minutes, Los Angeles IETF, March 1996, reported by John Linn (OpenVision): 

SUMMARY

The CAT WG met for two sessions at the Los Angeles IETF. Status of documents was discussed. Two I-Ds (SPKM and Kerberos mechanisms) are currently at the IESG being considered for advancement to Proposed Standard. Several other active I-Ds have received variable levels of discussion within the WG. Specific discussion topics at the meeting included two activities re public-key login with Kerberos: a presentation on DCE public-key Kerberos login work, and discussion of work and issues re the "pk-init" Internet-Draft. Other topics included discussion of the status of the negotiation GSS-API mechanism, issues re GSS-V2 and the Kerberos V5 GSS-API mechanism, contrasts between non-repudiation as defined in CORBA vs. IDUP, and a brief presentation on a smartcard-based GSS-API mechanism developed at the Union Bank of Switzerland.

Two clarifying and constraining comments will be drafted for inclusion in the Kerberos V5 GSS-API mechanism draft, currently in IETF Last-Call. A revised GSS-V2 draft, reflecting comments received during the WG review period and discussed at the meeting, will be edited and released after the meeting (working target: during March), and the result will be placed into WG Last-Call. 

GENERAL DISCUSSION

The status of WG drafts was reviewed. John Linn encouraged review and comment on all drafts, and reminded attendees of RFC-1602's community and consensus requirements for standards-track advancement. 

Cliff Neuman (ISI) is in the process of revising RFC-1510 to reflect errata and implementation experience. The result will be reflected in a new Internet-Draft, to be considered as a candidate for advancement to Draft Standard.

Re draft-ietf-cat-kerberos-passwords-02.txt, an updated version is planned before the current draft expires from the I-D repository. Denis Pinkas (Bull) stated that comments which he had made against this draft had not yet been resolved.

In the second session, Denis presented a brief report from the RADIUS meeting, which was investigating RADIUS extensions. Denis suggested incorporation of GSS tokens into RADIUS and provided a copy of the GSS-V2 spec to the RADIUS chair, but noted that the fact that current RADIUS tightly limits token sizes is an issue. Glen Zorn (Microsoft) commented that he did not believe GSS-API was a clean, appropriate fit into the RADIUS model, and Denis suggested off-line follow-up on this topic.

DCE WORK ON KERBEROS PUBLIC-KEY LOGIN

Bill Sommerfeld (HP) presented a discussion of DCE 1.2.2 public-key login, based on Kerberos V5. (The DCE Security Service, in addition to Kerberos, also includes a service to manage privileges and UNIX account information.) The approach integrates public-key processing into the Kerberos TGT acquisition protocol. The work was motivated by indicated customer demand for public-key support in DCE. The design prevents disclosure of a KDC's database from allowing an intruder to later impersonate users within a realm.

Bill was asked why the "pk-init" Internet-Draft wasn't used. He commented that it had expired, that it did not appear to have undergone major peer review, that motivating customers did not like its approach, and that his group regarded its use of certificates as unnecessary.

The DCE approach uses Kerberos V5 preauthentication hooks. Public-key and non-public-key users can coexist within a realm. A client's public key is used by the KDC to encrypt a random key used, in turn, to encrypt a session key.

An X.511 bind token is used in preauthentication data. Certificates are not currently employed, but could be incorporated in future. Bill was asked, "Why X.511/ASN.1?" He commented that it existed in non-expired form and that it had been the subject of significant review. The initial version has no algorithm negotiation (currently unnecessary, since there are no current algorithm options to be negotiated), but future negotiation extensions are possible. 

The Personal Security Module (PSM) is a high-level abstraction for a smart card, isolating callers from underlying crypto implementations. This interface was defined partly because crypto-layer APIs have not yet converged: Bill observed that Cryptoki and GCS-API were too low-level. Users have separately-identified keypairs for signature and confidentiality purposes, though it's possible for both keypairs to be the same. Public components are stored in the DCE registry. 

The approach is currently defined in OSF RFC 68.2 and can be received by non-OSF members by request to Anne Anderson at HP. If interest exists, it could be published as an IETF Internet-Draft. It will be implemented in OSF DCE 1.2.2, hopefully by late 1996; this initial version will not include smartcard drivers and will depend on BSAFE. 

It was noted in discussion that pk-init doesn't strictly require certificates. Denis Pinkas reiterated in the context of the HP proposal a suggestion which he had also made for pk-init: that unnecessary usage of unnecessary strong encryption keys for user data be avoided. Cliff Neuman noted that it would be good to harmonize pk-init with this work, if possible; it was announced at the second session that Bill and pk-init authors had made encouraging progress in discussing this prospect, with further anticipated progress to be reported to the list.

DRAFT-IETF-CAT-PK-INIT AND RELATED WORK

Brian Tung (ISI) gave a presentation on the pk-init work (with which Cliff Neuman and John Wray (DEC) are also involved), for which a "-01" revised Internet-Draft will be issued shortly (stated goal: by 15 March). Brian described the pk-init approach as offering "Low pain, high gain", and as requiring minimal protocol changes. Motivations include simple key management, simple recovery, and resistance to dictionary attacks. Implementation status: available for V5 beta 4.3 (from ftp://prospero.isi.edu/pub/pk_init/distribution, based on -00 pk-init draft), with V5 beta 6 patches submitted to MIT and reflecting some of the changes which will be inclued in the -01 draft. 

Supported scenarios include key pair registered with KDC (with private component either stored on local disk or stashed on KDC), and key pair registered with external service. X.509 certificates are used. Several issues had been raised at the Dallas meeting, and further discussion was solicited: format of kdc-cert, format of transited realm, and a request for separate keys for integrity and encryption for export reasons.

Requests were made for rationale discussion about security issues with different operating modes, and about return vs. non-return of private key for other uses. Regarding liaison between pk-init and the HP-DCE public key login work, Cliff Neuman stated that it might be possible for pk-init to reflect HP-provided change requests in the interests of alignment. Bill Sommerfeld asserted that protocol format definition is critical, but certificate handling issues more deferrable; Cliff responded that use of a certificate is particularly valuable for the KDC.

SIMPLE NEGOTIATION GSS-API MECHANISM

Denis Pinkas gave a presentation on the negotiation mechanism's status. A second I-D has been produced, and a reference implementation is available (of the negotiation mechanism per se, not in conjunction with other mechanisms: see ftp://ftp.enst-bretagne.fr/pub/security/gssneg.tar.gz). The reference implementation uses ASCII configuration files to identify supported/accepted mechanism OIDs. A question was raised as to how the snego reference implementation could be coupled with mechanism modules; Ted Ts'o (MIT) mentioned parallels with GSS-API mechanism glue layer code.

The current specification appeared (to the set of attendees who had been tracking its progress) largely stable. Denis accepted John Linn's comment about multi-level option hierarchies as posted to the mailing list (though did not perceive ambiguity in the current wording) and solicited text for inclusion.

KERBEROS V5 GSS-API MECHANISM

When the meeting took place, this document (draft-ietf-cat-kerb5gss-06.txt) was in IETF-level Last-Call for advancement to Proposed Standard. Two issues were raised and discussed at the meeting and by E-mail between sessions. 

The first issue relates to behavior of Kerberos mechanism implementations when type BOTH credentials (credentials structures supporting both initiation and acceptance of security contexts) are employed, an area which currently varies among implementations and on which the current draft is silent. Ted Ts'o and Bill Sommerfeld agreed to draft and circulate text on this topic on the CAT list for discussion and, if accepted, inclusion within the document. A goal of convergence in two weeks (i.e., by Tuesday, 19 March) was cited. 

The second issue concerned clarification on how interoperable delegation was to be implemented for the mechanism. Per E-mail to the list from Dan Nessett (Sun), a statement will be added saying that a TGT will be transferred within the KRB_CRED message with its FORWARDABLE flag set.

GSS-API VERSION 2

John Linn presented summaries of the changes made in draft-ietf-cat-gssv2-05.txt and currently outstanding issues. A comment was made that the new Implementation Robustness section was suitable and appropriate to respond to concerns against an earlier draft. It was agreed that GSS_Export_name() should be able to return a GSS_S_NAME_NOT_MN status if passed an input name which is not an MN, but that return of this status should not be required for all non-MN input cases. It was agreed that no new requirement would be imposed constraining the pair of GSS_Compare_name() inputs to contain at least one MN.

Ted Ts'o had posted to the list a proposal for a new GSS_Duplicate_name() call, in order to avoid the prospect of referencing pointers aliased at name objects which might previously have been freed. This proposal was motivated by work with the multi-mechanism glue layer (which checks the set of name types supported by its underlying mechanisms). The call's inclusion is motivated by a need to operate in environments which do not perform automatic garbage collection, and a desire for GSS-API to be relatively self-sufficient in managing its objects. Following some discussion on the necessity for this call relative to duplication facilities on other objects, the group agreed to accept inclusion of a GSS_Duplicate_name() call, with Ted Ts'o accepting the action of revising the text to explicitly allow implementations which use reference counting rather than copying in order to support the facility.

In discussion of GSS_Duplicate_name(), Dennis Glatting (CyberSAFE) posed the question of whether a facility for duplication of credentials should also be included. It was noted that, while potentially useful, this could be difficult to support within some implementations given side effects of some operations (e.g., GSS_Add_cred()) on credentials. It was suggested that duplication of credentials should be functionally equivalent to calling acquire_cred twice. It was initially suggested that duplication facilities for all GSS objects, not just credentials and names, should be evaluated for inclusion in GSS-V2. Following discussion in the second session, however, it was agreed that new duplication facilities other than GSS_Duplicate_name() would not be pursued at this time. 

Dennis Glatting commented on a set of common threads collected from customer inputs (also discussed in E-mail to the list). He noted the fact that CyberSAFE allows memory-based replay caches, and that use of such caches appears, undesirably, as memory leakage from the viewpoint of customers' memory analysis tools. To respond to this concern, he suggested inclusion of gss_open() and gss_close() routines, previously suggested to the WG though controversial in discussion, which would be used optionally by use by applications wishing to delimit their use of GSS-API resources. John Myers (CMU) commented that this appeared to be an inappropriate solution and asserted that a gss_close() routine wasn't needed. Ted Ts'o observed that Purify doesn't flag as memory leaks objects which are pointed to by statics, and also pointed out that addition of a context variable to GSS calls would be useful but would be backward-incompatible, and therefore inconsistent with agreed GSS-V2 scope.

Dennis also observed the current fact that the only QOP value portable across mechanisms is "default", implying that use of other values must be hard-coded or configured in a mechanism-specific fashion. (Earlier WG discussion on broader mechanism-independent definition of QOP values had failed to converge, leaving this as the current status.) On a separate point, Dennis re-iterated the value of the parse_token() facility which had been proposed by Carlisle Adams (BNR) within SPKM but which had not reached cross-mechanism WG consensus. 

Denis Pinkas presented a set of GSS-V2 comments: 

Major points:

Re naming section, particularly discussion of relation among naming-related routines, Denis requested a dataflow diagram and associated commentary.

Denis believed that the exported object format described in Section 4.2 is missing a slot for an OID. Ted Ts'o replied that, since some mechs may use implicit typing, the top-level specification need not specify the presence of an OID. Ted accepted an action to provide rationale text discussing why no typing is required at the mechanism-independent level.

Denis commented that he thought a name_type for GSS_Export_name() was missing. In discussion, it was agreed that no name_type was intended at this level; Ted accepted an action to tighten commentary in this area.

Denis requested that Annex A re PACs should be dropped (suggestion accepted by John Linn) or revised.

Minor points:

Denis suggested deletion of GSS_Inquire_mechs_for_name(), arguing that it did not appear easily implementable in a cross-vendor fashion. The mechanism glue layer in the MIT implementation constructs a table by calls to GSS_Inquire_names_for_mech(); GSS_Inquire_mechs_for_name() is not strictly necessary given GSS_Inquire_names_for_mech(), but is convenient for applications. As a higher-level comment, it was noted that the primary goal is an API for use by applications, not an internal glue layer interface. GSS_Inquire_mechs_for_name() was retained.

More explanation was requested to motivate the need for a anonymous name OID.

Editorial comments:

Requested revision of references to the term "signature". 

Requested addition of table of contents. 

Requested movement of Sec. 3 into annex; since section 4's content is normative, it was suggested that it should come first. 

GSS_Import_name: output_name -> output_name_string [Note: output of import_name is an internal name, not a string, so this comment needs clarification.]

Host-based service name editorial comment. [Note: Comment needs to be restated.]

CORBA/IDUP NON-REPUDIATION

The authors of the IDUP and PIM specifications, as cited by Dragan Grebovich (TimeStep) had believed that the IDUP documents had converged to a stable state, but Denis Pinkas voiced concerns in a presentation.

Denis observed that IDUP deals with non-repudiation as well as other services, and that Object Management Group (OMG) CORBA (based on a joint proposal submitted by a number of companies) also handles non-repudiation. Per Denis, non-repudiation provides evidence of actions which cannot be repudiated later. In CORBA, non-repudiation evidence is provided in the form of a token. Most common types are non-repudiation of creation, non-repudiation of receipt; these are differentiated from ISO origin vs. delivery constructs, because CORBA is more concerned with an object's creator than with its sender. Distribution status of OMG documents to non-OMG members is unknown, but Denis will investigate.

Supported OMG operations include: set_NR_features, get_NR_features, generate_token, get_token_details (yielding parameter set validated by evidence), verify_evidence, and form_complete_evidence (collects information in a package to guarantee veriability in arbitrary future). Non-repudiation policies have IDs and versions. A "conditionally valid" status can be returned if, e.g., the time period when the evidence generator may declare his/her key invalid has not yet expired, or if trusted time is required for strong validation but is not available. Policies define rules for generation, validation, and adjudication of disputes. Policy management interfaces are also incorporated.

Denis stated that he has been working with Carlisle Adams on alignment with IDUP, but that due to various time constraints the alignment has not yet been accomplished. Warwick Ford (BNR) commented that it was not clear what changes would be motivated on IDUP. Denis observed that the IDUP document was dealing with: (1) confidentiality and integrity, and (2) non-repudiation. He asserted that aspect (1) was relatively stable, with only a few minor changes needed, but that for (2) better alignment with the CORBA specification would be highly desirable. Based on this observation, he suggested that, if a need existed to have (1) available very soon, then a split between (1) and (2) would be possible; as an alternative, he suggested that the IDUP document be delayed in the interests of polishing (2). 

Denis asserted that use of a single IDUP call with many options (using the parameter bundling concept) was not necessary and was leading to overcomplication. Considering the simultaneous need for (1) and (2) to be an infrequent case (an assumption which proved controversial in discussion), Denis noted that two consecutive calls could be applied to accomodate this case, and further stated that this partitioning would greatly simplify understanding and ease alignment with the CORBA specification which deals only with non-repudiation. Consensus on requisite or appropriate action was not clearly apparent. Limited on-list IDUP discussion had taken place, and Carlisle Adams, author of the base IDUP specification, was not available at the IETF session to respond directly.

UNION BANK OF SWITZERLAND SMARTCARD GSS-API IMPLEMENTATION 

Harald von Fellenberg, Union Bank of Switzerland, gave a brief presentation on a smart card implementation which performs node and personal identification. Their installation is in the process of moving from a mainframe to a distributed environment. The approach uses an interface modeled after GSS; GSS glue code has been completed to layer above UBS's own calls and to expose a GSS interface to calling applications. Siemens chipcards are used on client and server sides, providing both user-host and host-host authentication, with an "Authenti-Box" for servers and a "Persauth" element for a personal chipcard. They are also interested in SKIP protection of network traffic and in coupling key management with smart cards. An attendee from Boeing stated that Boeing is also active in smart card usage, and both he and Harald stressed the operational importance of single sign-on.