CURRENT_MEETING_REPORT_ Reported by John Linn/OpenVision Minutes of the Common Authentication Technology Working Group (CAT) Summary The Common Authentication Technology Working Group (CAT) met for two sessions at the San Jose IETF. The group progressed through a busy agenda, including the following areas: Kerberos One-Time Passwords Internet-Draft and issues; updated Simple Public-Key Mechanisms Internet-Draft and issues; Internet-Draft update to RFC 1508 and issues; status of Windows GSS-API bindings; Independent Object Protection (IOP) Internet-Draft for extensions to GSS-API and issues; issues affecting the update to the FTP security Internet-Draft for its advancement to Proposed Standard; discussion concerning multiple overlay proposals for interfaces to layer atop GSS-API. Revised Internet-Drafts are expected for many of these documents in advance of the Danvers IETF; in particular, a revised FTP security Internet-Draft will be targeted for submission to become a Proposed Standard; depending on implementation results, a version of the SPKM Internet-Draft may also be submitted for advancement. Kerberos V5 One-time Passwords Following agenda discussion, Glen Zorn (CyberSAFE) presented discussion about the Kerberos V5 one-time passwords Internet-Draft (draft-ietf-cat-kerberos-passwords-00.txt) which he had co-authored with Cliff Neuman (ISI). The proposal's goal is to support a range of one-time password schemes through use of the Kerberos V5 preauthentication data (padata) field. The draft considers two cases of one-time password integration, one of which is more secure and easier to support, but is unable to accommodate as broad a range of one-time password technologies. In the less secure, more complex, but more general case, the server is assumed to know passcode values in advance; for the higher security case, the server is not assumed to know passcode values in advance. Ted Ts'o (MIT) observed that the weaker form presumes that peers know the salting value a priori and can perform computations with it; as an alternative, he suggested that the salt value be provided dynamically in a krb_error message. Charlie Kaufman (Iris) noted that Security Dynamics had indicated potential willingness to opening up the structure of their interfaces in order to support operation in the stronger mode. The group agreed that both classes should be supported. It was also believed that more than the 5 passcode type values currently defined in the draft are needed. In detailed discussion, Bill Sommerfeld (Hewlett-Packard) commented that a redirect facility should be available to designate a server address. It was also recognized that the proposal contains no explicit internationalization facilities (e.g., to tag a desired language for user prompt messages). Cliff Neuman expressed a desire to move forward quickly on revision of this specification to another Internet-Draft, and then to advance the result to Proposed Standard status. Cliff asserted that client support for the defined passcode types should be mandatory, though server support would be optional (and often dependent on availability of proprietary vendor code). In response to a query about availability of one-time password code in the MIT Kerberos distribution, Glen Zorn indicated that CyberSAFE would be willing to contribute requisite client-side code, and possibly a server-side S/Key implementation. Piers McMahon (ICL) noted that it would be useful to define a common API for use on the server side; Ted Ts'o observed that maintaining modular structure within the KDC was important. Cliff also commented that additional work was underway on public-key preauthentication, but that it was not yet sufficiently complete or stable to be considered for standardization. Further review of the Internet-Draft and comment on the working group mailing list was solicited. SPKM Paul Van Oorschot (BNR) presented an update on the Simple Public-Key Mechanism (SPKM) proposal, documented in draft-ietf-cat-spkmgss-01.txt and for which Paul gave primary technical credit to Carlisle Adams of BNR. SPKM incorporates digital signature facilities (see also IOP extension proposal, discussed elsewhere in these minutes) as well as base GSS-API services, and can operate in a mode which imposes no requirement for shared secure time. Algorithm IDs provide extensibility, and negotiation facilities are provided for selection of alternate algorithms for confidentiality, integrity, and key establishment within SPKM. QOP values are used to select among different integrity levels, including a level which provides non-repudiation. Changes between the original and current SPKM Internet-Drafts were summarized. Token formats include syntax changes for alignment with Project SESAME. The distinctions between SPKM-1 (random-number based, with 2-step one-way authentication of target to initiator, or 3-step mutual authentication) and SPKM-2 (timestamp-based, with one-step one-way authentication of initiator to target or 2-step mutual authentication) operational modes were clarified. OIDs were changed to Algorithm IDs in order to carry parameters; all tokens are now encoded in ASN.1 BER. Context negotiation within the mechanism now negotiates the key establishment mechanism. SPKM now specifies certificate_data as optional, and allows a source name in a request token as an alternative. The SPKM-REQ now has an optional authorization data field (as in Kerberos V5), and an optional validity period specifier for the context's key. Two new integrity algorithms were added: one which provides single-pass integrity and encryption for data and another based on an encrypted MD5 hash. Some additional minor status values were defined for SPKM. Error handling is enhanced by including a sequence number to identify the token within which a processing error occurred. Some discussion ensued about whether error-reporting tokens were themselves signed objects; signatures are applied but (given the fact that the signatures will not necessarily be verifiable under all failure conditions), their reports are assumed to be accepted whether or not the signature check succeeds. It was observed that this can make implementations vulnerable to disruption through receipt of gratuitous and/or spurious error tokens. Further clarification on error token generation and processing is expected before the next IETF meeting. Several SPKM implementation activities are proceeding. BNR is approaching completion (before the end of 1994) of an implementation including some proprietary facilities and performance optimizations. SESAME is building an implementation of SPKM-2, which is to be publicly available. The University of New Brunswick is developing a public reference SPKM implementation, and additional activity may be underway in Australia. Ted Ts'o suggested that SPKM developers attempt to use the GSS-API sample application as available in the MIT Kerberos V5 distribution as a test vehicle to exercise SPKM and to validate portability. Interoperability testing is planned between now and February 1995, with results to be reported to the CAT list; depending on progress, SPKM may be recommended for advancement to Proposed Standard at, or before, the Danvers IETF meeting. GSS-API Bindings for Microsoft Windows Piers McMahon reported on the status of Windows bindings for GSS-API, which had been the topic of prior mailing list discussion and proposal by Piers. Like RFC 1509, Piers' draft presumes that GSS-API functions operate in a synchronous and potentially blocking mode; the prospect of an alternative asynchronous interface was also agreed to be useful, but would be a separate effort; Shawn Mamros (FTP) indicated possible interest in such an activity. Ted Ts'o noted that MIT will be engaging a developer to build a Kerberos V5 DLL based on Piers' draft. A version of the draft document as discussed in e-mail, reflecting revisions based on comments received, will be sent to Internet-Drafts shortly. GSS-API Overlay Proposals Multiple proposals have been made on alternate interfaces to layer atop GSS-API, providing protected communications sessions, including (at least) Ted Ts'o's CATS, work (by Lam) at the University of Texas at Austin, and an e-mail proposal made by P. Rajaram. Don Stephenson (Sun) was familiar with the UT/Austin work, and may be able to make its code and/or a descriptive USENIX paper available on-line. We collected an informal subgroup (Don Stephenson, John Myers (CMU), Glen Zorn, Ed Reed (Novell), and Ted Ts'o) to work on a consolidated proposal to become an Internet-Draft, drawing on these inputs. GSS-V2: Changes Made In the Internet-Draft A number of changes, included in draft-ietf-cat-gssv2-00.txt, were summarized. These changes are specific and incremental, derived from implementation experience and liaison requests and making only minor modifications to the functional model established in V1, and their inclusion is not perceived as necessitating reset of GSS-API's standards status to Proposed Standard rather than progressing to Draft Standard. o Changed GSS_ prefix for major_status values to GSS_S_. o Added GSS_S_GAP_TOKEN major status to be returned by GSS_VerifyMIC() and GSS_Unwrap() to indicate receipt of a message following skipped predecessor sequenced messages. Rewording in Section 1.2.3 on sequencing indicators. o Added new GSS_S_BAD_QOP major status. o Added description of GSS_S_BAD_MECH return status for GSS_Init_sec_context() and GSS_Accept_sec_context(). o Added non-textual name import and export routines, as proposed in the Kerberos V5 Internet-Draft. Renamed GSS_Import_internal_name() to GSS_Import_name_object() and GSS_Export_internal_name() to GSS_Export_name_object() to avoid terminology confusion; the phrase ``internal name'' is already used to represent the opaque form as supported within a GSS-API implementation, and the input to GSS_Import_name_object is an object tagged externally to GSS-API. o Added GSS_Inquire_context(). o Deprecated GSS_Sign, GSS_Seal, GSS_Verify, GSS_Unseal routine names in favor of successors GSS_GetMIC, GSS_Wrap, GSS_VerifyMIC, GSS_Unwrap. (After some discussion, we resisted the temptation to revisit the function naming question again.) o Added new GSS_Wrap_size_limit() routine to determine how large an input token can be provided to GSS_Wrap() without generating an output token larger than a caller-specified size. o Rewrote description of channel bindings (Sec. 1.1.6) for purposes of clarification. o In routine descriptions, changed types of credential and context handle arguments to CREDENTIAL HANDLE and CONTEXT HANDLE, respectively. GSS-V2: Issues Pending and Discussed This section summarizes topics pending against GSS-V2 and their intended disposition. Further discussion is required to ascertain working group consensus about whether the scope of intended actions on these topics warrants resetting GSS-V2's standards status to Proposed Standard rather than proceeding to Draft status. o Level, if any, to include extension routines for OID and OID set management: John Linn to send message to list, comparing Wray and Glatting proposals; subsequent resolution to be sought on list. o GSS_Add_cred() proposal. Accepted for addition. o ASN.1 syntax for Appendix B, conformantly permitting non-ASN.1 enclosed objects. No information available. o Definition of reserved QOP values to distinguish NO, WEAK, MEDIUM, STRONG levels in a mechanism-independent matter (with mapping to algorithm choices to be mechanism-specified), and to distinguish integrity QOP from confidentiality QOP. Accepted for addition. Additional values designating FAST, SLOW, and (for integrity) NON_REPUDIABLE were suggested and also accepted. o GSS_Delete_sec_context() to be documented as returning a token only if caller requests same by passing a non-NULL buffer to accept it; usage with NULL token and, therefore, without transfer of deletion token to be recommended. o GSS_Process_context_token() changes to distinguish whether or not context remains valid; action: not adopted. o Facilities to enable binary compatibility: believed to require only changes to RFC 1509 (concrete typing of 4 objects), as documented in e-mail from John Wray. Action: Review Wray proposal and assume that it holds, unless list discussion revisits the issue. o Ability for GSS_VerifyMIC() and GSS_Unwrap() to return, in addition to current fatal errors on receipt of unsequenced messages, new advisory codes to report the same conditions. Action: Intend to support. John Linn and Marc Horowitz (OpenVision) to codify proposal to the list. o GSS_Open(), GSS_Close() proposal (added calls to obviate need for constructing self-initializing implementations of other GSS-API routines). Ted Ts'o observed that the strongest portability rules, as he has seen applied in other developments, require that neither static nor global variables be used; conformance to this standard would imply that each GSS-API routine would need to incorporate an added parameter for a caller-provided state block, a pervasive change which the group was not prepared to adopt at this time. The semantics of GSS_Open() and GSS_Close() in terms of objects which could be allocated and freed (with and without maintenance of reference counts) received some debate; resources (e.g., replay caches) potentially sharable across multiple callers were a particular discussion point. Action: discussion remanded to list. o Dual-use (INITIATE and ACCEPT) credentials, within which expiration times and other parameters may differ for directions of use, and extensions (e.g., by new parameter to GSS_Inquire_cred() or new GSS_Inquire_cred_specific() routine in order to preserve GSS_Inquire_cred()'s call signature intact: there was disagreement (as yet unresolved) about what, if any, changes are needed in this area. Action: more discussion needed. FTP Security Sam Sjogren (TGV) led discussion of FTP security, beginning at the end of the first CAT session and finishing at the beginning of the second session. Relatively few of the session's attendees indicated detailed familiarity with the FTP security draft. During the second session, Steve Lunt (J.P. Morgan), author of the current Internet-Draft (draft-ietf-cat-ftpsec-05.txt) joined the discussion via speakerphone. Sam Sjogren and Marc Horowitz intend to handle the next set of revisions to the Internet-Draft, between January 1995 and the next IETF meeting, with the result targeted for recommendation by the working group to Jeff Schiller as Security Area Director for advancement to Proposed Standard. Marc Horowitz noted that the current draft emphasizes client-side behavior and should be enhanced to include more detailed discussion of server-side cases and behavior as well; he has implemented client-side and server-side FTP security code layered atop GSS-API and can contribute to clarifying this discussion. Proposal: Add a new reply code to support OT passwords; the apparent sense of the group was that this was a useful and valid facility, without adverse impact on existing clients and enabling new security-aware clients to accomplish more intelligent behavior. An issue was discussed about the relation between AUTH and USER commands: is it acceptable to perform AUTH more than once (renegotiating) to create a new security context within an FTP session? A window of vulnerability can be constrained by refusing to act on commands which are received outside secure mode. Proposal: a new AUTH will tear down any existing security context and try to initiate a new one; Ted Ts'o notes that this does not work in all cases (e.g., chroot, where you would not be able to go back to prior identity) or on all system types. Marc Horowitz notes that current FTP implementations refuse to accept a new USER command on an existing session; analogously, it would be possible for implementations to reject a new AUTH command once a context is in place. An implementation note on behavior seems important here. Should MIC be required on all commands once security initiated? Diffie-Hellman and one-time password mechanisms cannot accommodate this, for example. Marc believes that it should not be required (if so negotiated, in a tamperproof fashion). Proposal accepted; a server need not require use of MIC'd commands. Use of more verbose error codes was proposed and accepted. Multiline reply format (Jeff Schiller issue): Jeff suggested dropping 1:1 correspondence between number of input versus protected lines, encoding multiline object as an object. Noted that multiline replies, unlike file data, are not generally massive. It was proposed that each line should be represented as a separate GSS-API token, but discussion here was not conclusive. Independent Object Protection (IOP) Paul Van Oorschot proposed GSS-API extensions for use in a store-and-forward environment, per a recent Internet-Draft (draft-ietf-cat-iopgss-00.txt) authored by Carlisle Adams of BNR. Its motivations include the need to protect important applications (e.g., e-mail) which are not session-based, to protect independent message objects, and to operate independently of on-line communication with target. The IOP proposal permits a context, and an object protected in conjunction with that context, to be addressed to and processable by multiple recipients. By intent, IOP contexts impose no expiration times. For the case of mechanisms capable of supporting both base GSS-API and IOP functions, the ability to use common credentials for both classes of operations is a valuable facility. The IOP proposal's security context construct contrasts with that in the base GSS-API: rather than being shared on-line with a peer, independent contexts at initiator and target allow creation and remote recovery of a key. It was suggested that, in order to reduce confusion, another term rather than ``context'' be used to describe the IOP construct. Ted Ts'o and Marc Horowitz expressed elements of an alternate view: that at least some of IOP's goals might be satisfiable within the conventional GSS-API, given a mechanism within which context establishment could be accomplished with exactly one context establishment token from initiator to target, and suitable technology supporting the existing GSS-API per-message calls. An updated draft is expected to include renaming of the IOP context construct and to clarify IOP context expiration semantics. The IOP proposal leaves GSS-API's credential functions unchanged, and adds new IOP_Init_context(), IOP_Accept_context(), and IOP_Delete_context() for management of IOP contexts. New per-object calls IOP_Protect(), IOP_Unprotect() are provided; each operation is subdivided into ``start,'' ``operate,'' and ``end operate'' calls, emitting a prot_token at the start of processing and an optional receipt_token; common routines provide functions analogous to both GSS_Wrap() and GSS_GetMIC(). Continuation facilities seem more important for protection of potentially-large documents than for the session-oriented paradigm in which the base GSS-API operates. Each operation yields a buffer (e.g., of encrypted text), not a token; this aspect of the proposal was controversial. Issues around segmentation of buffer data at peers, and requirements on crypto-algorithm quantization, arise here: tokenizing would help here and will be explored. One new support call, IOP_Extract_Prot_Token(), is added in the proposal. Clarification on buffers and their management is expected in an updated draft. BNR is implementing the IOP proposal, but this implementation is not planned to become public domain; the availability of the specification is intended to encourage independent evaluation and implementation activities. Action Items Pending Check on availability of documents on Stephenson and Rajaram's mechanism negotiation work; also on electronic availability of paper and, possibly, code from UT/Austin re session-oriented overlay for GSS-API. (Don Stephenson). Send summary message re ``Service:'' name prefix issue (Ted Ts'o, to be supported by others with memory of the issue). Status of Active CAT Documents and Advancement Plans GSS-V2: To be revised Internet-Draft before Danvers meeting (John Linn). To plan for advancement from Proposed to Draft standard level, we need a statement proposing how the IETF's independent implementation requirements for advancement to Draft, defined and commonly used for protocols, should be applied for this case of an interface specification; John Linn will draft such a statement. Piers McMahon commented that X/Open has relevant experience in interface validation and is now planning test procedures and suites to validate conformance with GSS-V1. FTP Security: To be revised Internet-Draft early 1995, before Danvers meeting, with result targeted for advancement to Proposed Standard (Sam Sjogren, Marc Horowitz, Steve Lunt). SPKM: Implementation experience pending at BNR and University of New Brunswick (the latter to be freely available reference implementation), possibly also at SESAME; experience to be summarized to list in advance of advancing current or revised Internet-Draft to Proposed Standard, possibly before Danvers meeting (Paul Van Oorschot, for Carlisle Adams). IOP: Internet-Draft to be revised (Paul Van Oorschot, for Carlisle Adams). Kerberos One-Time Passwords: Internet-Draft probably to be revised (Glen Zorn, Cliff Neuman). Kerberos V5 GSS-API mechanism: slight Internet-Draft revision pending (John Linn). Windows GSS-API bindings: to be released as Internet-Draft (Piers McMahon). RFC 1509: Internet-Draft update needed to track 1508 changes, binary portability, and other pending issues (John Wray: John Linn to contact re scope and status of planned RFC 1509 revisions.).