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 ietf-sasl@imc.org; with requests to ietf-sasl-request@imc.org; 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.