2.6.2 Common Authentication Technology (cat)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 22-Jan-98

Chair(s):

John Linn <linn@rsa.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:cat-ietf@mit.edu
To Subscribe: cat-ietf-request@mit.edu
Archive: ftp://bitsy.mit.edu/cat-ietf/archive/

Description of Working Group:

The goal of the Common Authentication Technology (CAT) Working Group is to provide distributed security services (including authentication, integrity, and confidentiality) to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms.

By separating security implementation tasks from the tasks of integrating security data elements into caller protocols, those tasks can be partitioned and performed separately by implementors with different areas of expertise. This provides leverage for the IETF community's security-oriented resources, and allows protocol implementors to focus on the functions their protocols are designed to provide rather than on characteristics of security mechanisms. CAT seeks to encourage uniformity and modularity in security approaches, supporting the use of common techniques and accommodating evolution of underlying technologies.

In support of these goals, the working group pursues several interrelated tasks. We have defined a common service interface allowing callers to invoke security services in association-oriented environments, with an associated token format identifying the security mechanism being employed. A revision to this document set is currently being finalized in response to implementation experience. The CAT Working Group also defines underlying mechanisms to provide security services, and supports integration of security services into caller protocols. Related work areas include interface and mechanism extensions under consideration for message protection in store-and-forward environments and for authorization support.

Goals and Milestones:

Done

  

Preliminary BOF session at IETF meeting, discussions with TELNET and Network Printing Working Groups.

Done

  

Distribute Generic Security Service Application Program Interface (GSS-API) documentation through Internet-Draft process.

Done

  

First IETF meeting as full working group: review charter distribute documents, and status of related implementation, integration, and consulting liaison activities. Schedule follow-on tasks, including documentation plan for specific CAT-supporting security mechanisms.

Done

  

Update mechanism-independent Internet-Drafts in response to issues raised, distribute additional mechanism-specific documentation including Distributed Authentication Services architectural description and terms/conditions for use of the technology documented therein.

Done

  

Second IETF meeting: Review distributed documents and status of related activities, continue consulting liaisons. Discuss features and characteristics of underlying mechanisms. Define scope and schedule for follow-on work.

Done

  

Submit service interface specification to the IESG for consideration as a Proposed Standard.

Apr 96

  

Submit GSS-V2 to IESG for consideration as a Proposed Standard.

Jun 96

  

Plan next phase of activities, with particular attention to scope and tasking for authorization, store and forward protection support, and additional mechanisms.

Jun 97

  

Submit revised version of RFC1510 (Kerberos) to IESG for consideration as a Draft Standard.

Jun 97

  

Submit Negotiated Mechanism document to IESG for consideration as a Proposed Standard

Jun 97

  

Issue Internet-Draft representing updated version of RFC-2078, aligned with GSS-V2 C bindings Internet-Draft.

Jun 97

  

Submit GSS-V2 C bindings document to IESG for consideration as a Proposed Standard.

Done

  

Progress Internet-Draft and RFC publication of mechanism-level documents to support independent, interoperable implementations of CAT-supporting mechanisms.

Aug 97

  

Review status of WG Internet-Drafts and plan follow-on activities.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1509

PS

Generic Security Service API : C-bindings

RFC1510

PS

The Kerberos Network Authentication Service (V5)

RFC1507

E

DASS - Distributed Authentication Security Service

RFC1511

  

Common Authentication Technology Overview

RFC1964

PS

The Kerberos Version 5 GSS-API Mechanism

RFC2025

PS

The Simple Public-Key GSS-API Mechanism (SPKM)

RFC2078

PS

Generic Security Service Application Program Interface, Version 2

RFC2228

PS

FTP Security Extensions

Current Meeting Report

Minutes of the Common Authentication Technology (cat) Working Group

Compiled by John Linn (RSA Laboratories).

I. Summary

The CAT WG met for 1.5 sessions at the Los Angeles IETF, with a total of 138 attendees. RFC2078bis final editing changes were agreed by the attendees; following corresponding edits, it will be forwarded to the IESG. Agreement among attendees was also reached to recommend SPNEGO for advancement. IDUP was not discussed in detail, but its most recent update is to be placed into WG Last-Call subsequent to the meeting. Revised PKINIT and PKCROSS drafts were discussed; one particular issue concerned alignment potential between PKINIT and S/MIME's CMS, and a proposal was made to replicate a subset of CMS material within PKINIT. A number of issues were discussed with regard to the kerberos-revisions draft, as input to editing during the meeting week; following subsequent WG Last-Call, it is intended that this draft will be targeted to succeed RFC-1510 at the Proposed Standard level. Given limited demonstrated constituency within the WG, it was proposed that FTPDSAAUTH be considered for Experimental or Informational status. Mike Swift (Microsoft) proposed and led an exploratory discussion on potential futures for CAT technologies and group activities. The updated PKTAPP draft was presented; follow-up discussion is to consider whether to target it (with some revisions as discussed) for Informational status or to combine its material with other drafts. The new PKRECOVERY draft was presented; it was observed that such facilities, if required and specified, might be placed more appropriately within a management protocol. A new version of the kerberos-password-chg draft, responsive to recent comments, will be prepared and submitted for WG Last-Call.

II. WG Last-Called Documents

Discussion began with review and consideration of documents which had been through one or more WG Last-Calls, including 2078bis, spnego, ftpdsaauth, and idup.

WG Last-Called Documents: RFC2078BIS

Regarding rfc2078bis-03, specific edits were agreed, and the resulting document is to be sent to the IESG with a request for advancement to Proposed Standard. The following changes are to be made: addition of a changes section relative to RFC-2078, removal of the CONTEXT_EXPIRED status from gss_import_sec_context(), and inclusion of a conf_req_flag to gss_wrap_size_limit() in order to align with the C bindings. A statement will be added to the citation of GSS_C_NO_NAME within Section 4, underscoring the fact that it is not truly a name type and is applicable as a name reference to only a small and specific set of GSS-API calls. Following discussion, it was agreed without dissent among the set of several participating attendees to state a requirement for full-duplex per-message protection support by mechanisms; given one on-list commentator's request to instead recommend rather than require such support, this working decision as reached at the meeting was considered to constitute rough consensus.

WG Last-Called Documents: SPNEGO

Denis Pinkas (Bull) led discussion on SPNEGO: draft-ietf-cat-snego-08 is the current version of this document. Changes were summarized: the preferredToken element has been changed to mechToken, since it now carries mechanism tokens and not just the initial preferred token, as was originally the case. GSS_S_BAD_SIG, now defined, is used to reflect an incorrect or missing MIC instead of GSS_S_BAD_MECH. Some additional explanations have been added. The document's WG Final-Call had completed quietly, and attendees confirmed group intent to send the document to the IESG with a request for advancement to Proposed Standard. Subsequent to the meeting, the document editor indicated intent to incorporate specific final cleanup edits to the draft, which are to be posted to the list.

WG Last-Called Documents: IDUP

Only limited discussion took place on IDUP at this session, as the document's editor was not available. Re IDUP-10, Denis Pinkas cited one comment which is to be detailed to the list, concerning possible addition of an attribute to represent a user's role. It is planned to initiate a new WG Last-Call on this document within approximately one week after the meeting.

III. PKINIT AND PKCROSS

Brian Tung (ISI) led discussion on Kerberos PKINIT (Public-Key Cryptography for Initial Authentication) and PKCROSS (Public-Key Cryptography for Cross-Realm Authentication). The primary reported changes in pkinit-06 were as follows: a new signature structure definition, aligned with PKCS-1 and discussion in the security considerations section about different trust models and interactions with various levels of cryptographic strength. Reported changes in PKCROSS were minimal, adding commentary about the use of KDC-KDC communications but intending to retain this aspect of the protocol. ISI intends to implement PKINIT by the end of April, subsequently to be incorporated into the MIT Kerberos distribution if accepted by MIT; ISI also plans to release a beta version of PKCROSS (based on PKINIT) sometime after the PKINIT distribution is released. Information is available on http://gost.isi.edu/info/kerberos/, or from Brian at brian@isi.edu.

Greg Clark (Dascom)'s comment re PKINIT: suggested changes (as included within a document which he had posted to the list) to use CMS structures as defined by the S/MIME WG in pre-authentication fields. Greg commented that the DCE community has been working to integrate Kerberos clients with messaging-based PKI toolkits (indicating specific interest in the Entrust implementation and its API), and that it is believed that use of a CMS abstraction layer facilitates exportability. Marc Horowitz (Stonecast) reminded attendees of the pre-existing IETF assumption that protocols should not be perturbed specifically for export purposes. Brian Tung believed that a similar question to prospective CMS usage had been visited previously (ca. Munich) when Mike Swift suggested PKCS-7, at which point such an approach was rejected as heavyweight and outside IETF control. Greg observed that CMS is within IETF control, and believed that it should be easy to incorporate CMS structures as optional elements and that this would simplify or enable support of PKINIT over existing toolkits; Mike Swift observed that PKINIT already provides for optional elements. Matt Hur (CyberSafe) noted that inclusion of CMS elements within the PKINIT specification would imply either that all implementations must support them, or else would impact interoperability. Ari Medvinsky (CyberSafe) commented that PKCS-11 could be accommodated with less significant impact on the PKINIT specification. Mike Swift argued that it would be appropriate to make a general decision as to whether or not to apply PKCS within PKINIT; Brian Tung disagreed, believing that such decisions should be made on a case-by-case, per-object basis.

A side discussion involving 6 interested attendees was proposed at the first session and held between the CAT sessions to discuss PKCS/PKINIT objects. Matt Hur reported the results of this discussion at the second session as follows: its proposal is to define and use portions of PKCS7 (excluding, e.g., CRLs) in PKINIT, but not to reference PKCS7 or CMS so as to avoid dependencies on them as they evolve.

Other PKINIT-related technical issues as noted from the DC meeting, some of which have not yet been addressed, are follows: a goal that an application server should see the same name for PKINIT and non-PKINIT accessors, a potential patent issue regarding encrypted private key storage on a server, and the intended approach for supporting a user with a signature-only key. Newly identified issues include omission of weak keys, key infrastructure requirements, and designation of algorithm identifiers to indicate PKCS objects. Brian intends to issue a new PKINIT draft addressing these issues.

PKCROSS: Mike Swift asserted that if KDC-KDC communication was good for PKCROSS purposes, it would probably also be useful to apply more generally, serving to formalize a general cross-realm approach. It was noted that clients should be aware when shortcuts are applied. Mike also noted that not all ASN.1 toolkits can accommodate use of extensions as specified. An additional PKCROSS-related issues, recorded from the DC meeting, concerned the appropriateness of using a TGT to transport a session key.

IV. KERBEROS-Revisions

Following further revision, this document is targeted to cycle in grade, obsoleting RFC-1510 at the level of Proposed Standard. The document can be found on the ISI Kerberos web page (http://gost.isi.edu/info/kerberos -> open issues -> Kerberos revisions), which navigates both to working draft and most recent I-D. Cliff Neuman (ISI) sought to get consensus on changes and make changes between the sessions, targeting WG Last-Call thereafter. A new error was added for RESPONSE_TOO_BIG, in recognition that a KDC may now be returning bigger things than had previously been anticipated. The document has a new description of the DES string-to-key algorithm, which may not match some existing implementations. Some more work is needed with 3DES and string-to-key. MIT's currently-implemented 3DES is unofficial, has not been enabled, and may not be fully functional, so conformance with it isn't considered an issue. Name canonicalization has been discussed privately, but needs to be raised to the list. Mike Swift had raised issues to the Kerberos list concerning name referrals; these also need to be raised to the CAT list.

There had been requests that more preauthentication types be discussed within the basic kerberos-revisions spec; Cliff Neuman believes that this is a good idea. Issue regarding bitstring encoding, raised by Mike Swift: should ASN-named bits be used, or instead should bits be referenced within a bit vector of specified length? Mike noted that the current specification isn't conformant to ASN.1, and suggested that we should resolve the issue by using a fixed number of bits. It was noted that any existing implementations which truncate the number of bits won't interoperate with MIT's implementation. Cliff proposed that at least 32 bits should always be sent, and that receivers of less than 32 bits should assume zero padding for the missing bits. John Wray (Iris) proposed that, if more than 32 bits are needed, valid ASN.1 should be generated per the originally-specified approach. Matt Hur stated that he would like to be able to checksum sub-elements of ticket extensions (per type) rather than, as at present, just the entire extension; thereby, only a subset would need to be carried intact across intermediaries. Mike Swift asked whether DES-MAC-K could be dropped as the mandatory checksum, in the belief that it is not widely used. A need to clarify relation between key types and encryption types was noted.

Cliff Neuman led discussion on the kerberos-revisions draft at the second session: citing the following new url: http://www.kerberos.isi.edu/revisions.html. Various changes were discussed. Implementations must generate at least 32 bits in flag vector, may not generate more unless needed; further interoperability rules were specified and discussed. Mike Swift suggested that ASN-DER be used if more than 32 bits are to be represented, consistent with John Wray's recommendation at the previous session. Revision work is continuing. Name referral discussion is pending, as are string-to-key examples. A new Internet-Draft is to follow, for which Cliff requested informal last-call by interested WG members.

V. FTPDSSAUTH

The FTPDSAAUTH draft is at version 3, with only minor editorial changes made since the previous version. It was noted that an additional editorial change appeared to be needed in order to eliminate references to the FTP Security document as an Internet-Draft rather than its current RFC status. The chair stated that, given limited review participation and demonstrated constituency within the WG (on the list, and with two attendees indicating readership of the FTPDSAAUTH draft) and per guidance received from the AD and RFC-2026, that it appeared appropriate to consider seeking Experimental or Informational status for FTPDSAAUTH. It was observed that this course of action is not prejudicial to later standards-track consideration, should enlarged constituency become apparent. The KEA/Skipjack document is intended for Informational status, and no comments or issues were identified on it.

VI. Futures for GSS-API and CAT-WG:

Mike Swift led discussion on some general questions, including: "What's the future of GSS-API?" He observed that many groups think it's too complex or are not using it for other reasons; for WG deliverables to offer value, they should satisfy other groups' needs. Mike also observed that a variety of schemes are being presented and discussed within the CAT-WG, some of which aren't GSS-based, and suggested that the group might appropriately apply more emphasis to the relation between mechanism facilities under discussion and GSS-API. Marc Horowitz noted that some of the schemes under discussion are for initial authentication, which is explicitly outside GSS-API's scope (though, e.g., it is within the scope of the PAM interface); he noted further that a GSS-API explanatory document would be valuable to provide. John Wray concurred with Marc that an informational RFC on how to use GSS would be valuable; someone noted that IBM had presented such a document within another forum.

John Linn pointed out that it was necessary to distinguish interface complexity versus mechanism availability issues, either or both of which could contribute to limited usage, but which would be appropriately addressed through different means. He also noted that potentially GSS-relevant audiences can be subdivided on two dimensions: integrators versus veneer users versus encapsulators and those who are vs. are not concerned with mechanism independence. In terms of mechanism availability, Mike Swift suggested that CRAM-MD5 might be a good mechanism, observing that most users want authentication primarily and key exchange as a possible additional option. Ted Ts'o (MIT) recalled that OTP was suggested in the past as a candidate mechanism, but that it would be limited in terms of function. Marc Horowitz argued for trying to train people to want something better than existing password practice, and observed that GSS-API is often more useful in a veneer (ONCRPC, sockets) than for access natively and directly from applications.

One attendee stated that his company had built and offered GSS toolkits, but that customers preferred to apply and use SSL. It was noted that SSL is probably the most widely used authentication protocol on the Internet, even though it only provides authentication under certain circumstances and configurations. It was also noted that "GSS isn't part of the picture for IMAP's SASL profiles". Three areas of rationale were stated for interest in SASL vs. GSS-API: simplicity of usage, availability of mechanisms, and scope spanning more broadly into initial authentication facilities; Matt Hur commented, however, a perception that SASL's facilities might be inadequate to satisfy comprehensive needs.

The following ideas were suggested, and any WG members interested in undertaking them are invited to propose specific contributions: a tutorial document with sample code, a "how-to" document for protocol integrators (possibly combinable with the first document), and work on provision of a simple mechanism under GSS-API.

VII. PKTAPP

Alexander (Sasha) Medvinsky (CyberSafe) led discussion on PKTAPP, reviewing the basis for pktapp and the clarifications added to the most recent revision. PKTAPP's described motivation is to create an authentication solution that combines the advantages of public key and Kerberos, retaining the benefits of Kerberos tickets while avoiding the need to contact on-line authorities. The PKTAPP approach uses PKINIT (based on a certificate, acquiring a TGT or an end service ticket) for direct client-to-server authentication, without modification to the PKINIT protocol. PKTAPP defines the construct of a Local Ticket Granting Service (LTGS), which can either be a standalone server (effectively a scaled-down KDC) serving applications on a host [Q: Is the scope of a standalone LTGS necessarily confined to applications on no more than one host?], or which can be integrated with each application service.

When LTGSs are used with PKTAPP for authentication to application services, a central KDC is optional for backward compatibility. An LTGS may, but need not, itself be a Kerberos principal. It was stated that the standalone LTGS approach offers a convenient migration path, and the following attributes were described: client ticket policies can be assigned based on the issuing CA; no LTGS service key is used, but a Kerberos principal entry for the LTGS can still be associated with global restrictions on tickets; the Kerberos principal database must contain application server entries and may also contain client entries shared with the central KDC for backward compatibility.

When the LTGS function is implemented within an application server, direct client-to-server authentication is achieved at the cost of application server modification. The following attributes were described for this approach: application servers would not normally share a distributed principal database; ticket policy can be stored in a directory service and accessed via LDAP; for compatibility with traditional Kerberos, supporting non-PKTAPP clients, it is desirable (though not required) for the application server to also be able to accept tickets issued by a central KDC.

PKTAPP cross-realm authentication was described as follows: an LTGS can issue end service tickets where the client and server reside in different realms, so no cross-realm TGT is required. Application servers also supporting traditional Kerberos are assigned to realms based on a traditional Kerberos model; application servers supporting only PKTAPP clients rely on a different trust model, based on servers' and clients' certifying authorities. Realms can be associated with CA names.

Recognizing the large number of configuration alternatives, Mike Swift asked how clients determine the destination to which AS_REQ requests should be sent. It was noted that the answer depends on configuration; Ted Ts'o observed that this implies a need for coordination facilities not specified within the draft in order to achieve interoperability.

Mike Swift asked a further question: Could PKTAPP be framed within GSS-API? This was considered possible, and the prospect could motivate integrating several drafts (pktapp, u2u, iakerb). Ted Ts'o opened the question of how to proceed, observing that PKTAPP could have its interoperability issues resolved, could be merged with other drafts, and that the result could comprise an informational RFC. Further off-line consideration and a proposal to the list is needed. Ted noted further that discussions are underway for Tom Yu of MIT to assume editorial responsibilities for RFC-1964bis, and that this document might also be a candidate for the alignment activity.

VIII. PK-RECOVERY

Jonathan Trostle (cisco) led discussion on the pk-recovery draft which he had authored. He observed that a Kerberos KDC compromise destroys shared secrets, which are hard to recreate out-of-band. The following environmental assumptions were stated: use of a PKINIT environment, with shared secrets still existing due to older clients and the option for storing encrypted user private keys on the KDC. Optimally, the KDC public key is certified in a PKI with revocation capability; the recovery protocol also works if KDC public keys are root keys. The proposed solution: update KDC root public keys if needed (facilities are proposed so that clients can obtain the next KDC root public key to be used), and then recreate shared user secrets by changing salts: Sha1(salt + RFC1510 shared user key) is the new shared key between the user and the KDC.

The user secret recovery procedure includes a PKINIT-derived exchange. It was further proposed that the protocol be slightly modified in order to also allow the private key which encrypts secret key to be salted and updated within the protocol. It was noted that the approach assumes that application servers must initiate contact with the KDC, following a KDC solicitation therefor. Jeff Schiller (MIT) noted that MIT's KDC has never been compromised, and that this proposal entails significant complexity in order to accommodate. Cliff Neuman concurred with this observation, and further asserted that any recovery provisions shouldn't complicate the common authentication protocol. John Wray asked, given the fact that PKINIT is needed for this facility to work, why not use PKINIT in preference uniformly? Generally, the attendees appeared hesitant to pursue standardization of a protocol facility in this area; potentially, such functions might be recastable as or within an administrative protocol. Denis Pinkas suggested that the set of attack scenarios be re-evaluated.

IX. KERBEROS-CHG-PASSWORDS:

Marc Horowitz has received two sets of comments re the kerberos-chg-passwords draft. He will process the comments and then reissue a new draft before WG Last-Call is initiated. Two implementations exist. Denis Pinkas would like to be able to change a PKINIT private key in a consistent fashion; the question of whether or not to merge such a facility into the chg-passwords document was deferred to offline discussion.

Slides

None Received

Attendees List

go to list