CURRENT_MEETING_REPORT_ Reported by John Linn/OpenVision Minutes of the Common Authentication Technology Working Group (CAT) The minutes were compiled by John Linn (OpenVision) based on notes taken by John Linn and Richard Graveman (Bellcore). The CAT Working Group met for two sessions at the Stockholm IETF. Topics related to active documents included GSS-V2 (to receive another set of specific revisions at the Internet-Draft level, and then to be recommended for advancement to Proposed Standards), IDUP (where revised interface specifications and a new mechanism specification were discussed, with standards advancement to be considered at the Dallas IETF), GSS-API Negotiation Mechanism (new draft discussed), Kerberos mechanism and extensions (status and comments discussed, new drafts to follow), FTP Security (to be recommended for advancement to Proposed Standard after inclusion of clarifying revisions), and a presentation of a new mechanism based on FIPS PUB JJJ cryptography. Presentations on work in progress included GSS-API integration into World Wide Web browsers and servers, loadable GSS-API multi-mechanism support, and discussion of use of RFC 1731 as a generic framework for integration of security tokens into text-based applications. The group also discussed a range of candidate follow-on topic areas related to authorization, and identified a subset with apparent common value and feasibility for proposals and work by group members. General Discussion FTP security: All technical issues known to be pending against the current FTP security specification (draft-ietf-cat-ftpsec-08.txt) have been resolved. A new version, including a clarifying protocol flow diagram, will be issued after the meeting and placed in working group Last Call for advancement to Proposed Standard. The alternate proposal, draft-ietf-cat-altftp-00.txt, has been retracted from standards-track contention. Telnet/GSS-API: A Telnet/GSS-API draft has been produced by Trusted Information Systems (TIS), announced on the telnet-ietf list and providing authentication and encryption. One technical issue is that the ``must encrypt'' bit is sent in the clear. A procedural issue is that no forum is currently active in the IETF to resolve issues related to this draft: the former TELNET Working Group had been shut down and a new telnet security working group was going to be started under Ted Ts'o's leadership, but this has not yet taken place. Ted solicited volunteers to assist on this. The telnet mailing list, telnet-ietf@cray.com, will be revised for discussion of this draft. Base GSS-API-V2 Discussion The documents are draft-ietf-cat-gssv2-03.txt and draft-ietf-cat-gssv2-cbind-01.txt. It appears that we are quite close to preparing GSS-V2 to be recommended for advancement; one more pair of Internet-Drafts is anticipated following discussion at the meeting. Summary of GSS-V2 function changes made vs. RFC 1508: o Credential management: Add_cred(), refined discussion of credential semantics, especially with regard to multi-mechanism issues and default references o Name object routines: Import/Export_name_object() o Status queries: Inquire_context(), Inquire_names_for_mech(), Inquire_cred_by_mech() o Buffering support: Wrap_size_limit() o Context export: Import/Export_sec_context() o Anonymity support o Generic host-based service name type o Additional OID support facilities o New GSS_S_GAP_TOKEN status for sequence integrity; additional choices for some calls among existing major_status codes There was apparent consensus among the attendees at the meeting that these changes constitute incremental modifications in response to implementation experience, and the fact that GSS-V2 is backward-compatible for GSS-V1 callers was recognized as significant; the current belief, however, is that GSS-V2 will enter the standards track at the Proposed Standard rather than Draft Standard level because of the fact that implementations are lagging the specifications and that we are not now in a position to demonstrate multiple, interoperable GSS-V2 implementations. GSS-V2 Status and Issues: No criticisms of the current content were posted during recent working group ``pseudo-last call''. The following points need to be reflected in the high-level specification: o Add_cred(): high-level specification needs specific changes to align with C bindings, regarding the following: copy vs. in-place credential modifications; returning of separate times for initiate, accept usage; clarification that mech_set describes full accumulated set. o Acquire and insert OID assignments. o Make sure that return of a token from GSS_Delete_sec_context() can, like token return from GSS_Init_sec_context() and GSS_Accept_sec_context(), be optional from the viewpoint of a mechanism as well as of a caller. o Reflect credential element terminology per revised C bindings. o Discussion later in the meeting regarding the FIPS JJJ mechanism proposal pointed out that GSS-V2 should state that mechanisms providing no per-message services should return errors if GSS_Wrap() or GSS_GetMIC() is called, rather than quietly returning tokens that actually provide no protection. o Include ``prot_ready_state'' facility (see next section, ``CONTINUE_DEFERRED Proposal''). o Incorporate clarifying text regarding possible combinations of anon_state and mutual_state, describing the four possible cases: - anon_state == FALSE, mutual_state == FALSE: initiator authenticated to target. - anon_state == FALSE, mutual_state == TRUE: initiator authenticated to target, target authenticated to initiator. - anon_state == TRUE, mutual_state == FALSE: initiator authenticated as anonymous principal to target. - anon_state == TRUE, mutual_state == TRUE: initiator authenticated as anonymous principal to target, target authenticated to initiator. Note: authentication as the anonymous principal does not necessarily imply that credentials are not required in order to establish a context. CONTINUE_DEFERRED Proposal Bob Blakely (IBM) presented a summary of a paper previously distributed to the mailing list, suggesting a GSS-API interface extension to enable protection and buffering of data messages for later transfer while a security context's establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases where the caller side already possesses the necessary session key to enable this processing. Citing a specific example, Bob noted that such a facility would be useful in order to apply lightweight Kerberos authenticators for high transaction rate LU 6.2 applications. Following some controversy, apparent consensus was reached among attendees that a modification towards this goal is acceptable as an addition to the GSS-V2 specification. Following some refinement, the current specific proposal is that a new state Boolean (similar to anon_state), called prot_ready_state, be added to the return signatures of GSS_Init_sec_context() and GSS_Accept_sec_context(). This state Boolean is valid when the major_status is either GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE. Callers of GSS-API (both initiators and acceptors) can assume that per-message protection (via GSS_Wrap/Unwrap and GSS_Get_MIC/Verify_MIC) is available and ready for use if either: prot_ready_state == TRUE, or major_status == GSS_S_COMPLETE, though mutual authentication (if requested) cannot be guaranteed until GSS_S_COMPLETE is returned. This achieves full, transparent backward compatibility for GSS-API V1 callers, who need not even know of the existence of prot_ready_state, and who will get the expected behavior from GSS_S_COMPLETE, but who will not be able to use per-message protection before GSS_S_COMPLETE is returned. It is not a requirement that GSS-V2 mechanisms ever return TRUE prot_ready_state before completion of context establishment (indeed, some mechanisms will not evolve usable message protection keys, especially at the context acceptor, before context establishment is complete). It is expected but not required that GSS-V2 mechanisms will return TRUE prot_ready_state upon completion of context establishment if they support per-message protection at all (however GSS-V2 applications should not assume that TRUE prot_ready_state will always be returned together with the GSS_S_COMPLETE major_status, since GSS-V2 implementations may continue to support GSS-V1 mechanism code, which will never return TRUE prot_ready_state). Store-and-Forward Support (Including IDUP) This topic discussed the active IDUP drafts draft-ietf-cat-idup-gss-02.txt, draft-ietf-cat-idup-cbind-01.txt, and draft-ietf-cat-pim-00.txt. BNR is implementing IDUP with IDUP-PEM, and intending to follow with an implementation layered on MSP; presentations on the IDUP topic were given by Carlisle Adams and Dragan Grebovich of BNR. It was suggested that the drafts be evaluated at the Dallas meeting for advancement purposes, and that those members of the set judged to be ready then be recommended to advance to Proposed Standards. Changes in the IDUP drafts were summarized. The lifetime of an IDUP environment is tied to the lifetime of the credentials which establish it. Multiple stages of protection exist, and protected and unprotected cases are distinguished. Receipt (receiver controlled) and evidence (for non-repudiation) facilities, with associated generate and process calls, are new. No receipt_token is now emitted by End_Unprotect. A straw poll suggested that about 10-15 attending working group members, a significant constituency of interest, have been reading the emerging IDUP drafts, even though on-list discussion has been relatively quiet. Denis Pinkas (Bull) had made prior comments by e-mail, and Dave Solo (BBN) expressed the following concerns at the meeting: concern with the split of token and protected data into separate objects as implying the need for protocol parsing by callers and possible conflict with MSP; non-support for labeling and assured freshness; desire for greater evidence support below the interface in a mechanism-independent manner. IDUP C-bindings: A new Internet-Draft was issued after the Danvers meeting, aligned with GSS-V1 rather than GSS-V2; it was suggested and accepted that support for at least the GSS-V2 Add_cred call would be valuable in support of multi-mechanism credential sharing between IDUP and GSS implementations. Credential management is currently unchanged from GSS-V1. New major_status codes were added for evidence and receipt processing. IDUP processing is divided into four stages: acquire credential, establish security environment, per-unit protection, and completion. Groups of function calls operate on credentials, environments, per-IDU processing, special-purpose (receipt, evidence), and support functions. Environment-related changes are small in this draft; per-IDU calls include small changes for protection and unprotection; no recent changes have been made in credential or support calls. The goal of the PEM IDUP mechanism is to support IDUP using PEM data elements, not (necessarily) to emit a full PEM message verbatim. IDUP-PEM creates a PEM header, optionally encrypting the IDU. An IDUP-PEM caller must do any canonicalization, application of delimiters, and PEM 6-bit encoding; IDUP does the security part of PEM. Bob Blakley stated that it is desirable to decouple security from the rest of the application, leaving integration into a specific protocol up to the applications, but observed that the IDUP-PEM approach requires that the application be aware of the underlying mechanism. Open question for list discussion: is IDUP-PEM suitable as a basis to implement MOSS? Loadable Multi-Mechanism Support Bob Blakley presented the proposal. This proposal is motivated by a desire to support and dynamically configure GSS-API installations with independent modules corresponding to multiple mechanisms, making it possible to install new mechanisms without recompiling or relinking applications. Operating systems could be shipped with a multi-mechanism support framework, and mechanism modules could be provided separately and loaded. A PostScript document was distributed to the list before the meeting; Bob plans to follow with an Internet-Draft version reflecting comments. In the proposal, a set of new calls add, delete, and replace mechanisms and add name types. These calls comprise a management interface, ordinarily called at system startup and by callers separate from the applications which will later call GSS-API services; they are not intended for use once mechanisms, credentials, and contexts are active within a system. One element in the proposal, a facility to indicate supported name types, is useful to GSS-API callers and is provided in the GSS-V2 specification. It was suggested that an implementation of the GSS-API Negotiation Mechanism, which dispatches to other mechanism modules in any event, might be an appropriate module to export the management interface. Questions came up about the scope of the proposal (single process vs. entire system), about whether its feasibility is OS-dependent, and about how much of its functionality could be achieved by using dynamic linking. Bob Blakley stated that he had planned an implementation based on OS/2's framework-layer dispatch facility, within which each application links to its own copy of a framework library; it appeared, by analogy, that comparable UNIX integration in a multi-process environment would require kernel modifications. Two issues were raised: the current proposal is based on GSS-V1 specification, and an observation that there may be export control issues with the ``plug in'' capability. As with many export discussions, this one terminated inconclusively: suggestions included restricting the strength of cryptography which a mechanism module provides for GSS_Wrap() and masking the confidentiality request indicator within the framework layer if required. GSS-API Integration Into World Wide Web Browsers and Servers Doug Rosenthal (EINet) presented this talk, similar to one which he had given earlier in the week at the Web Transaction Security Working Group (WTS) meeting. He observed that the Web is one, but not the only, application important for electronic commerce; he believes that use of common security technologies and credentials across Web and other applications is a valuable goal. Web-applicable GSS services are authentication, confidentiality, integrity, and (potentially) signatures; he observed that credential sharing between GSS and IDUP mechanisms provides important value which can be exploited through GSS-API integration, as will availability of the GSS-API Negotiation Mechanism. For Web integration, Doug's approach uses a new URL type (gss-http); entire transactions are protected. A URL is used to identify the target service by name. EINet is integrating GSS-API with winWeb and macWeb browsers and NCSA httpd server, using BNR's SPKM toolkit. The pilot implementation uses EINet CA services; work is underway on adding access control on authenticated user IDs. Kerberos integration, and an Internet-Draft on the integration approach, are planned. Doug asserted that SSL's cryptography could be used to construct a GSS-API mechanism. S-HTTP is Web-specific, so did not appear to be a candidate GSS mechanism, although S-HTTP could conceivably be written with GSS-API. The current approach is GSS-based rather than GSS-IDUP, and Doug believes that most current Web requirements can be satisfied with GSS. Coexistence with IDUP will be valuable to secure other applications (e.g., mail) using common credentials. GSS-API Negotiation Mechanism An Internet-Draft (draft-ietf-cat-snego-00.txt) on a Simple GSS-API Negotiation Mechanism has been posted, and Denis Pinkas led its discussion. An OID identifies a mechanism, and mechanism designers may optionally define subordinate OID arcs to indicate options (e.g., algorithm choices) for use within their mechanisms; mechanism specifications are to define behavior for the default option (mechanism OID alone) and for any options subordinate to the mechanism. An annex to the Internet-Draft defines additional interface calls to allow callers to set and query the sets of mechanisms and options which are to be input to the negotiations in which they participate. A new token (the negotiation token) is used; the negotiation mechanism, like other mechanisms, is itself identified with an OID. The negotiation model is two-way: the initiator proposes one or more mechanism/option sets; the target accepts no more than one set and may optionally return data specific to the selected mechanism along with its reply. The target's preferences have precedence within the set proposed by the initiator. The negotiation itself is not protected and thus subject to attack. Bob Blakley pointed out that initiators should therefore make sure that the value selected by the target was represented in the list which the initiator proposed. Ted Ts'o pointed out that with use of options lists may get long; also, mechanism designers may take the use of negotiation into account or ignore it and design their mechanisms for stand-alone use. Bob Blakley suggested that a ``template'' of mechanism options would be useful. Kerberos Mechanism and Kerberos Extensions The RFC 1510 etype/keytype issue has been resolved, and no significant discussions are currently active against this specification. Looking towards advancement of RFC 1510 (Kerberos) to Draft Standard, Cliff Neuman (ISI) will issue a revised Internet-Draft (planned for August), including a few clarifications plus the new text regarding keytype. Public-Key Cryptography for Initial Authentication in Kerberos (draft-ietf-cat-pk-init-00): Several points need to be resolved on this draft before advancement. Comments are being discussed re underlying assumptions; corrections and protocol changes have been proposed. Issues include how a key is to be derived for generation of a response. ISI is working on a prototype; a new version Internet-Draft is planned for August. Integrating One-time Passwords with Kerberos (draft-ietf-cat-kerberos-passwords-01.txt): This draft's implementation (at CyberSafe) is pending and it was suggested that advancement consideration be deferred pending implementation results. The draft was stated to be independent of one-time password (OTP) method, but Denis Pinkas observed a need for coordination with the OTP working group regarding S/Key support and discussion is ongoing on the list. Kerberos V5 GSS-API Mechanism (draft-ietf-cat-kerb5gss-02.txt): the following issues/points are to be confirmed and discussed as needed by e-mail, as input to preparation of a revised Internet-Draft: o Delegation (presumption: unsupported within specification) o Possible need for additional text regarding context expiration semantics o Phrasing of sequence indicator (text proposed to list) o CONF_FLAG, INTEG_FLAG usage in protocol (text proposed to list) o Principal object name type (per list discussion, to be implementation defined, using local object definition and caveating non-portability) o Documented procedure for processing host-based service name o Discuss use of MD2.5 integrity, given recent results and discussion in IPSEC FIPS PUB JJJ GSS-API Mechanism Sandra Murphy (TIS) presented the Internet-Draft, draft-ietf-cat-fipsjjjgss-00.txt. This mechanism specification is based on public-key cryptographic authentication per ISO 9798, specifically as refined by the document known as FIPS PUB JJJ and issued in the 6 June 1995 US Federal Register, with a 90-day comment period. (The document is also available on the Web, at http://csrc.ncsl.nist.gov/ps/pkauth.ps and .txt.) The mechanism specification supports unilateral or mutual authentication; random numbers are used as challenges, authentication requests may be explicit or implicit, and certificates may optionally be transferred. The mechanism design is stand-alone (i.e., does not rely on use in conjunction with the GSS-API Negotiation Mechanism or equivalent), but some option negotiation facilities (e.g., choice of signature algorithm) are incorporated within the mechanism. Six token types are used. The question arose: why not use SPKM instead of JJJ (in other words, if one is to employ cryptography per FIPS-PUB-JJJ, why define a new mechanism for this purpose rather than placing the cryptography within the SPKM framework)? Several differences were noted. The JJJ mechanism, unlike SPKM, generates no session key and therefore does not support per-message services; SPKM does not provide a ``no per-message service'' option. SPKM, unlike JJJ, assumes that all implementations can perform mutual authentication. The text fields defined in FIPS-PUB-JJJ cannot be represented in SPKM tokens; these fields are inaccessible to callers within the scope of the interface, but may be important for use and internal consumption within mechanism implementations. It was noted that the FIPS JJJ mechanism specification orders data elements per ISO 9798 and that SPKM does not, but this issue did not appear to be a critical conformance requirement since ISO 9798 does not specify concrete syntax. Ted Ts'o suggested that all capabilities of the FIPS JJJ mechanism were apparently subsumed as subsets of SPKM, so perceived no reason to pursue standardization of the JJJ mechanism within the IETF. Bob Blakley asserted that availability of a FIPS JJJ mechanism specification as an Internet standards-track document would be a benign result. No motion or decision regarding standards advancement was pursued during the session. Denis Pinkas noted a potential compatibility problem between negotiation as defined for the JJJ mechanism and the GSS-API semantics of mutual_state; Sandra believed that the specifications were compatible in this area; more review and clarification is needed here. Simple Authentication and Session Layer (SASL) The presentation was given by J. Myers (CMU). This proposal is a generalization of RFC 1731 (currently Proposed Standard) facilities for IMAP4 authentication mechanisms, providing a generic framework for integrating security tokens into a range of text-based command stream applications. In addition to IMAP, the technique has been applied to and/or proposed for FTP, POP3, SMTP, LDAP, and other protocols. At the SASL level, recognized ``mechanisms'' include Kerberos V4, GSS-API, and S/Key. SASL steps are: (1) identify mechanism; (2) authenticate (negotiate protection, buffer size, pass authorization userID); and (3) establish protection (optionally): integrity or privacy, can perform compression as well. SASL per-protocol integration profiles contain: (1) server authentication identity, e.g., POP; (2) command to start authentication; (3) defined method to exchange tokens (applying base64 encoding if needed); (4) defined method to abort exchange; and (5) identification of where protected stream starts. Work is pending to generalize RFC 1731 into SASL: (1) change name; (2) remove IMAP4-centrism; (3) document profiling requirements; (4) establish or adopt registry of mechanisms; and (5) include the session layer protocol definition. John Linn stated that SASL appeared to be an appropriate item for discussion within CAT, as well as within groups representing potential SASL consumers, and asked about implementation status. Kerberos V4 is being used, but Kerberos V5 and GSS-API have not yet been tested. It was suggested that future mechanisms should preferably be added under GSS-API rather than at the SASL level. As a security integration vehicle, SASL might also have relevant interest to the SSL community. Authorization We discussed the scope of follow-on work in the area of authorization, placing priority on items implementable and broadly useful. Several candidate topics were identified. The following set appeared to offer the most likely prospects for tangible near-term work building on the current CAT technology base and offering benefit to a wide constituent community, and specific proposals were solicited over the upcoming months: o Authorization query interface (e.g., based on an ACL associated with an object). o Attribute definitions, applicable to principals, contexts, and data. (Existing mechanisms, such as Kerberos and SPKM, include facilities to transfer authorization data objects, but those objects' content is not currently defined within the mechanisms.) Specific examples of interest include a canonical form of principal identifier and indications of a principal's group affiliations. o Credential and/or context annotation. o Attribute extraction from contexts. It was noted that OSF's DCE-RFC 5 specifies some relevant GSS-API extensions within the DCE environment; Bob Blakley agreed to investigate releasability of this specification to the CAT Working Group. Ted Ts'o proposed the idea of a GSS_Export_name() routine, which would accept an internal name and emit a canonicalized binary name representation. The intended use of its output would be as a lookup key to be applied against an ACL in a mechanism-independent manner. If names are to be used across mechanisms, or if authentication and authorization mechanisms are to be mixed and matched, added complexity arises and more definitions are needed than are presently available. John Linn asked whether this could be accomplished with GSS_Export_name_object() along with a newly-defined canonical name type; Ted believed that buffer management facilities in GSS_Export_name_object() were inappropriate, but more thought and discussion on the list is needed here. Additional areas were identified, but appeared to be longer-term topics, pervasive attributes, or items of more limited interest: o Compound principal support, identifying intermediary entities as well as initiators. o Delegation constraints and controls (asserted as hard to specify). o Additional outputs from authentication (e.g., time of day, routes traversed), if a set of generic interest can be defined. o Facilities for policy management and query interfaces (asserted as hard to specify). o Facilities for interdomain operation (pervasive attribute). o Ability to support capability-based mechanisms (pervasive attribute). Working Documents and Next Steps o RFCs 1508, 1509 (GSS-API, C Bindings) are Proposed Standards. GSS-V2 Internet Drafts prepared (draft-ietf-cat-gssv2-03.txt, draft-ietf-cat-gssv2-cbind-01.txt). Working group last call is planned to be issued early in August, targeting recommendation for new Proposed Standards. o RFC 1510 (Kerberos) is a Proposed Standard. Cliff Neuman to revise to new Internet-Draft in August, incorporating various clarifications and specifying resolution of keytype issue. The result to be considered for advancement to Draft Standard. o Internet-Draft: draft-ietf-cat-kerb5gss-02.txt (Kerberos GSS-API mechanism). A new Internet-Draft is planned for August. It will then be reviewed for advancement. o Internet-Draft: draft-ietf-cat-kerberos-pk-init-00.txt (Kerberos Public-Key Initial Authentication). Reference implementation in progress. Pending issues to be resolved, and implementation results gained, before advancement. A new Internet-Draft planned for August. o Internet-Draft: draft-ietf-cat-kerberos-passwords-01.txt (Kerberos One-Time Passwords). Advancement decision pending on reference implementation results, resolution of ongoing e-mail discussion, possible coordination with OTP S/Key activities. o Internet-Draft: draft-ietf-cat-wingss-00.txt (GSS-API V1 MS Windows DLL interface). A new Internet-Draft is planned for August, including changes for 32-bit support. It will then to be reviewed for advancement. The new Internet-Draft will reflect GSS-V2 assuming that GSS-V2 is stable. o Internet-Draft: draft-ietf-cat-ftpsec-08.txt (FTP security). Successor Internet-Draft to be issued in August, incorporating protocol flow diagram. It will then be placed in working group last call for advancement to Proposed Standard. o Internet-Draft: draft-ietf-cat-snego-00.txt (GSS-API Negotiation Mechanism). No decision has been made regarding advancement of this document. o Internet-Draft: draft-ietf-cat-spkmgss-04.txt (SPKM). The document is in IETF Last Call for advancement to Proposed Standard. Need to correct stated use of BER encoding to DER, include assigned OIDs. The changes are to be reflected in the new Internet-Draft after the Last Call period is completed. o Internet-Drafts: draft-ietf-cat-idup-gss-02.txt, draft-ietf-cat-idup-cbind-01.txt (IDUP and C bindings). Revised versions of these documents are expected in advance of the Dallas meeting. They are to be considered, along with other IDUP drafts, for advancement as of Dallas meeting. o Internet-Draft: draft-ietf-cat-pim-00.txt (PEM-based IDUP mechanism). To be considered, along with other IDUP drafts, for advancement as of the December IETF meeting. o Internet-Draft: draft-ietf-cat-fipsjjjgss-00.txt (FIPS JJJ GSS-API mechanism). No decision has been made regarding advancement of this document.