Editor's note: These minutes have not been edited. COMMON AUTHENTICATION TECHNOLOGY (CAT) MINUTES, Montreal IETF, June 1996, reported by John Linn (OpenVision). The CAT WG met for two sessions at the Montreal IETF, on Wednesday and Thursday. DOCUMENT STATUS REVIEW The status of CAT WG Internet-Drafts was summarized. The former draft-ietf-cat-kerb5gss-07.txt is now RFC-1964. Two CAT WG I-Ds (draft-ietf-cat-spkmgss-06.txt, draft-ietf-cat-gssv2- 06.txt) have completed IETF Last-Call and are now in IESG hands. Jeff Schiller (MIT, Security Area Director) indicated that he expected the IESG to vote on these drafts on 11 July and/or 25 July for advancement to Proposed Standards, and that he anticipated positive results. Regarding SPKM, Jeff noted that the impasse which had placed this draft on hold for an extended period in response to public-key licensing issues appears to have been resolved. One I-D (draft-ietf-cat-snego-01.txt) had been offered for CAT WG Last-Call. This draft, concerning the GSS-API negotiated mechanism, had received only limited review and comment during the WG Last- Call period proposed on the mailing list, and the apparent sense of the meeting was, therefore, that no strong consensus for advancement had yet been achieved. The comment period was extended to 20 July to solicit review by additional WG members, and the draft's status will be reviewed thereafter. A suggestion was made that, if active involvement remains limited, the draft should be considered for Experimental status. Status of other CAT WG I-Ds: - draft-ietf-cat-sesamemech-00.txt: Was to have been revised June 1996, per Tom Parker (ICL)'s 29 May E-mail to CAT list. Approximately 4 attendees indicated familiarity with the draft. Stephen Farrell (SSE) commented that a revision will be issued in approximately 2 weeks, responding to comments which had been received. - draft-ietf-cat-xgssapi-acc-cntrl-00.txt: To be revised June 1996, per Tom Parker's 29 May E-mail to CAT list. Approximately 3 attendees indicated familiarity with the draft. Denis Pinkas (Bull) will send a message to the mailing list, soliciting broader review and comment. - draft-ietf-cat-wingss-00.txt: To be revised by Piers McMahon (ICL) and/or Ted Ts'o (MIT), per 3 June E-mail to CAT list. Ted Ts'o is willing to take this draft and update it to reflect GSS-V2 and to support both Win16 and Win32 environments, assuming that the nroff source can be obtained (John Linn and Ted Ts'o to coordinate with Piers McMahon). - draft-ietf-cat-gssv2-cbind-01.txt: I-D revision in progress; July availability target. - draft-ietf-cat-kerberos-pk-init-01.txt: Revised Internet-Draft posted. Further discussion was held later in the meeting (see separate section of minutes). - draft-ietf-cat-ftpsec-08.txt: I-D revision in progress. I-D currently expired; to be renewed or revised. - Pending revision of RFC-1510. Revision targeted for early July. Further discussion was held later in the meeting (see separate section of minutes). - draft-ietf-cat-kerberos-passwords-xx.txt (draft currently expired.) Approximately 8 attendees indicated familiarity with the draft. Glen Zorn (Microsoft), the draft's editor, indicated that Denis Pinkas' comments were the only ones currently pending against this document, and some mailing list discussion ensued during the meeting week. Denis considers the draft a framework, which is not in itself sufficient to support independent implementations, but Glen believes that the document is suitable as a basis for implementation and essentially ready for advancement. The draft is to be renewed, made available to the list, or revised within two weeks as a basis for continuing discussion. GSS TOKENS IN CONNECTIONLESS ENVIRONMENTS Denis Pinkas gave a presentation on a proposed approach for use of GSS tokens in connectionless environments. His goal was to define procedures for using GSS tokens in a special manner, only for use with mechanisms supporting this optional technique. Use of this approach is restricted to mechanisms which can establish a context with a single context establishment token and which can send a protected message along with that token. Such mechanisms cannot, therefore, engage in challenge/response interactions at context establishment time. It was noted that mechanisms already exist for which single-token context establishment cases can be valid; this facility allows usage of this characteristic, when known, to be optimized. Ted Ts'o criticized such usage as intrinsically non-portable across the general set of GSS-API mechanisms and thereby contributing to mechanism specificity on the part of callers. Considering specifics of Denis' proposal, his suggestion was to send a fixed-length header (64 bits) in front of tokens, to be used as a reference to cached tokens. The header would be a 32-bit Unix time concatenated with a 32-bit random number, and would effectively be used to define a security context and make subsequent references to it. Denis suggested that return of GSS_COMPLETE status from an initial GSS_Init_sec_context() call could be used to recognize a mechanism's inclusion of the caching support facility, without requisite changes to the current GSS-V2 document, but John Linn observed that this would be ambiguous, given the fact of currently-existing mechanisms for which single token context establishment sequences were valid. Marc Horowitz (Cygnus) asked what standards status was desired for this proposal; Denis did not have a specific position on this question. Marc also commented on his perception that the proposal's goal was more appropriately construed as an application issue than a security issue. Ted Ts'o commented that his perception of the proposal's motivation was targeted towards support for an "academic definition of connectionless protocols", and further stated a premise that, by design and intent, replayed context establishment tokens (or references thereto) should be rejected. Bill Sommerfeld (HP) commented that he didn't view the proposal as simplifying to applications, and suggested that GSS usage in connectionless environments requires instead assignment and management of IDs by a layer above. An attendee asked whether a facility such as Denis proposed might be applicable to usage in CGI proxies, but no clear conclusion was apparent; Simon Cooper posed the question of whether GSS-IDUP would be suited to satisfy such requirements. IDUP Carlisle Adams (NorTel) led a discussion on current status and issues for IDUP. Approximately 6 attendees indicated that they were tracking the documents. Related drafts: draft-ietf-cat-idup-gss-05.txt, draft- ietf-cat-idup-cbind-02.txt, and draft-ietf-cat-pim-01.txt. Carlisle provided an overview of IDUP facilities, and then summarized and responded to a set of questions which he'd received about IDUP from various sources. Carlisle's questions and answers about IDUP rationale (paraphrased here by editor): - Q: We already have MOSS, MIME, etc, and applications now using these don't need a new API, so is it useful to define one? A: All of these protocols exist, and don't appear likely to converge, so an API enables useful portability. - Q: I've heard that IETF doesn't do APIs, so why is this a valid activity? A: IDUP's scope is consistent with GSS-API, which is an accepted IETF activity. - Q: I'm just interested in authentication and confidentiality, so why does IDUP provides functionality which I don't really need? A: If not already needed, non-repudiation facilities will be needed soon in order to support electronic commerce. - Q: IDUP looks too complicated. Can't it be simpler? A: In simple cases, many parameters accept default and "don't care" values. David Kurn (Tandem) commented that, in working with IDUP, he had encountered needs to use mechanism-specific facilities more frequently than with base GSS-API; he acknowledged, however, more detailed familiarity with IDUP than with base GSS. Denis Pinkas commented that he would like to remove mechanism-specific parameters from the IDUP specification. Carlisle asserted that selection of the default mechanism allows a sufficiently rich service to be useful. Technical issues were discussed regarding the facts that (1) some IDUP mechs (PGP/MIME, e.g.) do their own transport encoding, and (2) that interoperability between IDUP-based and non-IDUP peers was functionally desirable but might not always be achievable. The current IDUP specification uses the same token framing as is defined for base GSS-API; it was suggested that perhaps IDUP framing should become 7-bit safe. Ted Ts'o requested more clarification about how IDUP mechs are to be used. Minor changes have been made in the idup-05 draft, including new "File_Protect" and "File_Unprotect" calls which reference file handles. Carlisle commented that he had recommended against inclusion of these calls, which were incorporated in response to implementor requests. The apparent sense of attendees was that these file-level calls should be deprecated for standardization purposes. Regarding status of IDUP mechanism specifications, the recent and current P7IM I-D describes one IDUP mechanism. Carlisle suggested that PIM should transition to Experimental status; Informational and/or Historic status was suggested by others. Carlisle stated that a specification for a MOSS IDUP mechanism spec may be coming by December and that implementation work is underway. Nortel has a currently-internal MSP IDUP mechanism spec; some interest was indicated by attendees in publication of this material as an Informational RFC if the text can be made available. Re implementation status: most implementations have been done by Nortel, and are not public domain, but interoperability testing is solicited. Implementation activity re the PEM-based mechanism is on hold, an MSP implementation is complete, and PKCS#7 alpha code is complete; MOSS-based mechanism (not by Nortel) development is in progress. Carlisle anticipates that a PGP mechanism will be done, but this work hasn't started yet. SASL John Myers (CMU) led a discussion on his SASL draft (successor to RFC- 1731), which about 4-5 attendees have been following. SASL adds a command to a protocol to identify a named mechanism (Kerberos V4, GSS-API, SKEY). A SASL server and client exchange a sequence of challenges and responses. Upon completion, the peers have negotiated authentication, an authorization identity (username), protection mechanism, and a buffer size. If a session layer is negotiated, it applies to the rest of the protocol session. Changes since RFC-1731: specification of how to apply to protocols other than IMAP, use of the service name namespace as defined for GSS host-based services, establishment of a first-come, first-serve registry of mechanism names. John Linn's comments on SASL were the only set which had so far been posted to the CAT mailing list. Marc Horowitz asked, "why wasn't SASL being discussed in the TLS WG?" John Myers responded that TLS approaches define and use new port numbers, while SASL (like GSS-API) is intended for integration within a self-contained protocol. Denis Pinkas offered some terminology comments, and referenced the fact that security is explicitly excluded from the ISO session layer and therefore suggested renaming the SASL specification. Usage and implementation: John Myers has done POP3 and IMAP with Kerberos V4; Ted Ts'o said that GSS-ized POP is being considered; someone else commented that he's implemented SASL with an "SSL-like" mechanism; it was reported that Ned Freed was implementing with Diffie-Hellman and that an SKEY implementation has also been done. John Myers commented that several other activities, previously blocked pending advancement of GSS-V2, are now blocking on advancement of the SASL document. KERBEROS V5 BETA 6 UPDATE Ted Ts'o (MIT) presented a status summary of KerberosV5 beta 6, which was released on 6 June 1996. The FTP reference is ftp://athena- dist.mit.edu/pub/kerberos/README_BETA6. This version supports UNIX (with OSF/1, SunOS, Solaris, and SGI known to work) and Win16; Win32 and Macintosh support are on the way but not in beta 6. FSF's autoconf facility is used. Client interfaces are stable; work is currently in progress to incorporate an administration server donated by OpenVision, which will be integrated into the distribution as of beta 7. A Kerberos V4 backward compatibility server is available now, so it is possible to drop in a V5B6 KDC as a replacement for a V4 KDC without making client changes. GSSAPI V2 support is "almost but not quite there"; the most recently added V2 calls are not included. It is still necessary to fix a previously-typo'd reference to an OID (which had been unintentionally usurped from the U.S. General Services Administration (GSA) arc, but which, fortunately, was being transitioned away from). Code for this fix has been written but is not in the beta 6 distribution. Beta 6 has the beginnings, but not the completion, of triple-DES support. SUNSOFT WORK ON GSS-API SECURITY FOR ONC RPC Mike Eisler (SunSoft, mre@eng.sun.com) gave a talk on SunSoft's work on GSS-API Security for ONC RPC, which is being formally discussed within the ONC RPC working group. The new authentication flavor is called RPCSEC_GSS. An Internet-Draft is being written, and the work will also be the subject of a presentation at the USENIX Security Symposium in July. The work was motivated by the fact that previously existing ONC security flavors were weak, and had designed-in (unintended) limitations. The former AUTH_UNIX (now AUTH_SYS) supported only a fixed number of UNIX group IDs (gids), a limitation which conflicted with operating system practice and was not extensible in a standards-compatible fashion, AUTH_DES had too small a key, and neither provided authentication or integrity. Mike believes that a GSS-based solution satisfies requisite requirements. Most GSS-level interfaces are exposed to ONC applications, but the GSS-API channel binding facility wasn't well understood and was therefore omitted. The rpc_gss_seccreate() call takes, among other arguments: name of target service, string name of mechanism, QOP value. Using GSS-V2 calls, a mapping can be accomplished from GSS mechanism-provided names into UIDs; this library may be generalized for broader usage by non- RPC GSS-API callers. The RPCSEC_GSS protocol is session-based like AUTH_DES and AUTH_KERB, and is based on OpenVision's prior AUTH_GSSAPI work. Context setup iterations are supported, with RPC-layer critical sections around GSS calls. Data copies are optimized away for the integrity-only verification case, using gss_sign(). When privacy is provided, gss_seal() is used; both integrity and privacy cases prepend sequence numbers to data. The server side verifies the following data: version number of RPCSEC_GSS, service, context handle, sequence number, checksum, and maintains a sequence number window. The ONC level doesn't pass RPC credentials with replies; the verifier contains a signature (generated with gss_sign()) of a request's sequence number. Mike presented a graph of observed performance; authentication-only was almost the same as AUTH_NONE, integrity (with Kerberos V5, DES_MD5) was about half the authentication-only throughput, and privacy about half the integrity throughput. Mike commented that he would like the GSS-API C bindings to accomodate operations which didn't require buffer copies, and noted that cryptographic processing bandwidth dominates for software implementations but that data copies can assume greater relative significance in hardware-based implementations. Martin Rex (SAP) commented that he would like string-level references to mech OIDs. A general comment was made in discussion that it would be valuable to unify different references to crypto algorithms in different contexts within the IETF. In RPCSEC_GSS, a shorthand table is used to translate text strings into mechanism OIDs. Comment (Marc Horowitz): it would be preferable to use native GSS constants for, e.g., QOP representations. Initially, Sun plans to do its own multi-mechanism packaging, but this might later be generalized to a more general binding facility. KERBEROS PK-INIT DISCUSSION Brian Tung (ISI) led discussion on the Kerberos public-key initial authentication (pk-init) draft, co-authored by Cliff Neuman, Brian Tung, and John Wray. Changes made in the -01 version were summarized. Pending issues include: incorporation of separate keys for encryption and signature (accepted), addition of signature support for DSS, and others. A new draft is to be submitted in 4-6 weeks; other ongoing plans include prototype implementation, integration with Kerberos V5 beta7, attempted demonstration of interoperability with DCE public-key login, targeted advancement to Proposed Standard. Bill Sommerfeld is also implementing pk-init. It was observed that pk-init affects initial ticket acquisition only, and therefore provides (for Kerberos purposes) the same level of single sign- on (SSO) functionality as other login protocols. Currently, a client must sign requests, and must decrypt responses. Brian Tung believes that Denis Pinkas' issues have been addressed; John Linn suggested that a cover message summarizing changes be sent along with (or before) the new I-D. Cliff Neuman requested a WG Last-Call by end of summer. RFC-1510 UPDATE DISCUSSION Cliff Neuman led discussion on the ongoing update to RFC-1510. Identified purposes: integrate previous errata, update assigned numbers, align specification with implementations regarding encryption types, add new encryption types for triple-DES and SHA, explain more clearly often-misunderstood aspects of protocol, highlight often-overlooked areas of protocol, and explain means through which certain hooks are intended to be used by separate specifications. This update will not integrate OTP or PK-INIT, but will list PA-DATA identifiers therefor. Cliff posed the following questions (also to be sent to CAT list, soliciting inputs for phase-in strategies): - Should/must compliant implementations support triple-DES SHA encryption? Serious export problems were noted, suggesting that this shouldn't be a "must". Marc Horowitz asserted that single-DES is sufficient as an interoperability basis. Apparent sense of room: "should". - How much to deprecate single DES MD5, single DES MD4, single-DES CRC? Apparent sense of room: "deprecate MD4, CRC, maintain single DES MD5 as must". - Where all existing implementations implement one of the deprecated methods incorrectly, how do we fix? Draft Internet Standard status requires independent implementation of all features, and many Kerberos implementations share common code. While this characteristic could complicate validation of independence, Jonathan Trostle (CyberSAFE) and Stephen Farrell commented that the CyberSAFE and SESAME implementations of RFC- 1510, respectively, were independent of the MIT code base. Ted Ts'o further commented that Richard Ward at Microsoft was also working on an independent implementation of RFC-1510. Lively discussion ensued about migration to new cryptographic algorithms. One suggestion for a "sunset clause", pre-establishing a date beyond which use of particular algorithms would be discouraged, was made. Glen Zorn argued for backward compatibility as a primary requirement, and that technical decisions should not be driven by export laws. Marc Horowitz asserted that the successor to RFC-1510 shouldn't attempt to rank algorithms by strength. Ted Ts'o noted that the cross- product of all possible algorithm choices, independently defined, would imply a need for large numbers of specifications, given the means through which algorithm usage is structured in Kerberos. This dictated a need for volunteers to specify new e-types. Jonathan Trostle volunteered to provide new e-type definition, and also commented on a possible need for definition of a general intra-Kerberos negotiation facility which is not currently present; Ted questioned the requirement for such a facility. No negotiation extension is currently planned, though the errata will discuss some implementation-level issues, related to key types and e-types, which concern a limited level of negotiation-related function. CANDIDATE FUTURE WORK ITEMS The concluding 15 minutes of the meeting were devoted to discussion of possible future work items for the CAT WG, and determination as to whether corresponding motivated volunteers were available. The following candidate areas were identified. Unless noted otherwise, no volunteers were identified to drive follow-on activities: - Further actions, if any, required to support binary compatibility between GSS-API implementations: it was hoped that the upcoming GSS-V2 C bindings document will satisfy requirements in this area and was encouraged that it be reviewed from this perspective. - Asynchronous version of GSS-API interface - Further work on authorization extensions - Facilities to support installation-level configuration of multi- mechanism support using mechanism modules supplied independently by different providers - Kerberos extension for inter-realm authentication via public-key technology (Brian Tung and Jonathan Trostle interested) - Kerberos extension for intra-mechanism negotiation of algorithms (Jonathan Trostle interested) - Streams-oriented interface: it was suggested that John Myers' SASL interface be reviewed for sufficiency and appropriateness in this area. - SSH GSS-API mechanism definition: given that SSH is becoming a visibly popular technology (and is distributed from crypto-friendly Finland), there might be interest in constructing a GSS-API mechanism layered on SSH's underlying cryptographic technology. Ted Ts'o is discussing this prospect with Tatu Ylonen, keeper of SSH.