Notes from Common Authentication Technology (CAT) meeting, Munich IETF, 13 August 1997, compiled by John Linn (with thanks to Rich Graveman (Bellcore) for access to his notes from the session and to Cliff Neuman (ISI) for providing copies of his presentation slides in text form). (This version contains a few detail-level clarifications relative to the previous draft sent to the mailing list, per comments received from WG members.) The CAT WG met for one session at the Munich IETF. REVIEW OF ONGOING WORK ITEMS: FTP SECURITY FTP Security (draft-ietf-cat-ftpsec-09) is in IESG hands and had been inadvertently delayed in its IESG consideration, but is reportedly on the agenda to be considered for Proposed Standard status at the next IESG conference call. REVIEW OF ONGOING WORK ITEMS: GSS-V2 AND C BINDINGS Re GSS-V2, the proposed approach is to integrate the RFC2078bis changes list into an updated GSS-V2 base Internet-Draft during September, and then (following a WG Last-Call period) to submit the resulting RFC2078bis and the GSS C bindings as an aligned set to the IESG, requesting their advancement to Proposed Standards; this proposed approach was acceptable to session attendees. No more than very minor changes to the C bindings are anticipated. REVIEW OF ONGOING WORK ITEMS: SNEGO Approximately 6 attendees indicated that they had reviewed draft-ietf-cat-snego-06; approximately 15 indicated familiarity with this or previous snego versions. It had been believed that draft-ietf-cat-snego-06 represented WG consensus for advancement, but Marc Horowitz (Cygnus) and Bill Sommerfeld (HP) indicated a position that draft-ietf-cat-snego-06 does not reflect previously established WG consensus in certain areas, and were to detail the specifics of their dissent to the WG list during the IETF meeting week. No other snego-related comments were indicated in the session. Follow-up discussion is underway on the mailing list. FTP AND DSA, KEA/SKIPJACK William Nace (NSA) presented a pair of recently-distributed documents, concerning, respectively, FTP with DSA (draft-ietf-cat-ftpdsaauth-00-txt), and FTP with KEA/Skipjack algorithms (draft-ietf-cat-ftpkeaskj-00.txt). Other contributors include Peter Yee and Russ Housley. Given the status of KEA/Skipjack (currently classified), the document authors are targeting this document for informational status. Discussion within the session suggested informational status for the DSA document as well, but (given the fact of unconstrained DSA specification) the DSA document could be admissible for subsequent standards-track consideration by the WG. Approximately three attendees indicated familiarity with the drafts; a concern was indicated that the algorithms applied may constitute national-level solutions. The DSA draft provides FIPS-196 authentication for FTP. Unilateral DSA signature-based authentication was discussed in the session, though support for both unilateral and mutual cases is defined within the specification. The KEA/Skipjack draft provides confidentiality for both the data and command streams; labels are also implemented. Encrypted data are base-64 encoded. KERBEROS PK-INIT AND PK-CROSS Brian Tung (ISI) presented and discussed the recently-revised kerberos-pk-init and kerberos-pk-cross drafts. Brian noted that Kerberos open issues are being identified at http://gost.isi.edu/info/kerberos. KERBEROS PK-INIT AND PK-CROSS: PK-INIT Approximately 4 attendees indicated they had read pk-init-04; approximately 15 were familiar with one or more pk-init versions. Document contributors include Ari Medvinsky and Matt Hur (CyberSafe), Jon Trostle (Novell), Brian Tung and Cliff Neuman (ISI), and John Wray (Digital). In draft-ietf-cat-kerberos-pk-init-04, a convention was added for translating between X.500 and Kerberos names. Mike Swift (Microsoft) questioned why base-64 encoding was applied in name translation rather than using the new name type being defined in 1510bis. Ted Ts'o (MIT) observed that the base-64 approach avoids the need to recognize X.500 semantics within Kerberos. In pk-init-04, a client's realm comes from a certificate, not a KDC. A client's principal name also comes from a certificate. A KDC's principal name was added as an X.509 v3 attribute. Diffie-Hellman specification was imported from PKCS #3, specification was added for checksummed encryption, and more specific errors were defined. Support within pk-init for SPEKE, an algorithm with which approximately 3 attendees indicated familarity, had been proposed on the mailing list. Ted Ts'o believed that SPEKE was patent-pending, but terms were unknown; Cliff Neuman believed that patent or patent-pending status should not be a bar to consideration as long as an algorithm's implementation is not mandatory for conformance with the specification. Brian Tung is to continue discussion of SPEKE on the mailing list. Mike Swift observed that Microsoft's CAPI supports PKCS formats rather than bare-level public-key encryption, and would like to be able to support pk-init functions with PKCS-level objects. Ted Ts'o agreed that this suggestion appeared reasonable, noting the broad existing base of code supporting PKCS formats. Brian Tung will raise this issue to the list for further discussion. A suggestion was made that use of X.509 AltSubjectName be considered. KERBEROS PK-INIT AND PK-CROSS: PK-CROSS Brian Tung described draft-ietf-cat-kerberos-pk-cross-02 as including minor changes relative to its predecessor. Approximately 2 attendees indicated that they had read pk-cross-02; approximately 7 indicated familiarity with one or more pk-cross revisions. In pk-cross-02, the remote realm now determines the lifetime of a shared key. Matt Hur has suggested using pk-init to do pk-cross, which would be a major change. Mike Swift noted that Microsoft was evaluating usage of DNS as a means to locate KDCs; this was considered to be a form of existing practice which may warrant codification in RFC1510bis. Mike Swift also reiterated his recommendation, as made relevant to pk-init, to allow public-key operations to be performed using PKCS objects. KERBEROS-REVISIONS (RFC1510BIS) Cliff Neuman (ISI) discussed status and issues relative to the Kerberos RFC1510bis document, draft-ietf-cat-kerberos-revisions-00. Approximately 4 attendees indicated that they had reviewed this draft. Changes and issues had previously been summarized to the CAT list. It was noted in discussion that the currently pending issues list includes the addition of key derivation procedures for 3DES support. Document-related comments were solicited, to krb-protocol@mit.edu for protocol-related issues and via http://gost.isi.edu/info/kerberos (as also used for pk-init, pk-cross, and pktapp). An HTML/SGML version is in progress, targeted for completion by 1 September; its content will correspond to a new I-D (kerberos-revisions-01) to be submitted. As revisions of the HTML versions proceed, corresponding I-Ds will also be issued and will remain authoritative. Major changes considered since the kerberos-revisions-00 I-D, and discussed at the session, are: - Authorization data field: Elements are of type AuthorizationData (new terminology). New element types include: kdc-issued (checksummed with application server's key, vouched for by the KDC of that application server's realm), intended-for-server and intended-for-application-class (identifying targets or sets thereof for which a ticket is intended), if-relevant, and Boolean combinations of authorization elements ("or" is currently proposed; "and" was considered appropriate as well). If a kdc-issued element occurs in an inter-realm environment, a receiving KDC reads and (if acceptable) reissues the element; it is not passed through without reissuance and, were a passed-through element to occur, that element would be ignored. Each of the intended-for-server, intended-for-application-class, and if-relevant attribute types carries a sequence of elements. If intended-for-server or intended-for-application-class attributes are not understood at a targeted recipient, their enclosing ticket is to be rejected; if received elsewhere, they may be ignored. If if-relevant attributes are not understood at a targeted recipient, they may be ignored. In the interests of simplicity, and without perceived loss of needed function, it was agreed in discussion that kdc-issued should be limited to appear at the top nesting level only, and should not nest recursively. Backwards compatibility with existing code incapable of recognizing these newly-defined elements was considered important; Cliff Neuman is to propose text to the mailing list discussing the circumstances under which these elements should be included. One suggestion was that they be included at the level of a ticket element. - Extensions field to ticket: This is an optional sequence, allowing additional data to be linked to the ticket so that it follows the ticket throughout the system. It is located in a ticket's cleartext portion at the end of the ticket, is typed opaque, is linked from within the authorization data field, and contains a flag as to whether it is OK to be removed. It can be used for PK-CROSS to distribute the inter-realm key, or can be used to distribute authorization data which is integrity protected but not confidential, plaintext ticket data, or accompanying authorization credentials. Placement of the extensions field in the ticket's cleartext portion allows unnecessary encryption of ancillary data to be avoided. - Optional client version in pre-auth: This identifies the version of kinit, in a manner considered analogous to an HTTP version string. The intended concept is to use this for backwards compatibility when changes are made. These numbers are not registered and vendor dependent; vendors or users of this field are admonished to pick version identifiers unlikely to conflict with those of other vendors. No corresponding server version identfier is provided, so as not to advertise known and exploitable bugs. RFC2078BIS, RFC1964 ISSUES John Linn led discussion on some specific issues related to RFC2078bis and RFC1964. Specific items cited: Re sequence number setup in RFC1964, John Wray's working proposal for the context acceptor to use the initiator's ISN in the single-hop case was accepted (recognizing that a separate reflection indicator is included in the protocol). Re gss_display_status and CONTINUE_NEEDED: some clarification was desired as to whether these can be used together or not. Some existing implementations return CONTINUE_NEEDED when iterating through successive messages returned from gss_display_status, but this had not been contemplated in RFC-2078. The sense of the discussion was that CONTINUE_NEEDED should be returned only by gss_init_sec_context and gss_accept_sec_context; this intent (along with commentary on the residual portability issue) should be cited in RFC-2078bis and defensive callers should ignore CONTINUE_NEEDED if returned by calls other than gss_init_sec_context and gss_accept_sec_context. If a name of the type GSS_C_NT_EXPORT_NAME is imported with an unrecognized mechanism (OID) in the framing defined by Section 3.2, GSS_S_BAD_MECH is to be returned." RFC-2078 contains MIT arc OIDs for some, but not all, of the generic name types; this was considered benign and the sense of the discussion was to retain these OIDs to avoid backward compatibility issues. For the case of host-based service, where an IANA arc OID had been assigned for use in preference to its predecessor MIT arc OID, it was recommended that both OIDs be accepted with equivalent effect but that the MIT arc OID be emitted on output; the sense of discussion was to reverse the prior recommendation preferring the IANA arc OID over the MIT arc OID representing the same type, in order to avoid backward compatibility issues with existing implementations. RFC-2078bis needs (per discussion re snego) to add facilities for informatory conf_req, integ_req inputs to gss_init_sec_context. The conjunction of supplementary info bits and non-zero routine errors was discussed briefly. The goal is to tighten up the list of possible cases. This topic was deferred to discussion on the list. RFC1964 EXTENSIONS Mike Swift solicited interest in two possible areas of extension to RFC-1964, user-user authentication and initial authentication via a dial-up access server. Mike noted that user-user authentication would be useful for DCOM, and suggested support for Kerberos user-user authentication as a submechanism within RFC-1964. Marc Horowitz believed that it would be more appropriately supported as a separate mechanism with its own OID; snego could be used to select between RFC-1964 Kerberos and a user-user mechanism. Generic resolution of name discovery for the user-user environment was believed to be a difficult issue, but there appeared to be interest in investigating and potentially drafting a specification for user-user authentication support. Mike also solicited interest in specification of initial authentication via a dial-up server (as in pktapp), where an initial request is forwarded through an access server. Ted Ts'o commented that Derek Atkins' Charon thesis had addressed essentially this problem some years previously. OTHER DISCUSSION Bengt Ackzell (Generic Systems) noted that, per the Memphis CAT minutes, IDUP had been planned for placement into WG Last Call following the Munich meeting if no comments were pending. Recent IDUP on-list discussion has been quiet, the base specification has not been recently revised, and issuance of corresponding C bindings remains pending. Upon further review, it appeared that further revision or on-list discussion of pending comments was needed before proceeding. --jl