2.6.3 Common Authentication Technology (cat)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97


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:



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



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



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.



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.



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.



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 96


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



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


Request For Comments:







Generic Security Service API : C-bindings



The Kerberos Network Authentication Service (V5)



DASS - Distributed Authentication Security Service



Common Authentication Technology Overview



The Kerberos Version 5 GSS-API Mechanism



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



Generic Security Service Application Program Interface, Version 2



FTP Security Extensions

Current Meeting Report

Minutes of the Common Authentication Technology (CAT) WG

Recorded by John Linn, RSA Laboratories.

I. Summary

The CAT WG met for 1.5 sessions (one full-length and one short slot) at the DC IETF. A large number of Internet-Drafts were presented and discussed. The WG believes that the final remaining issue with SPNEGO (Simple Protected Negotiation) has now been closed; following specific changes, this draft will be submitted to the IESG to be considered for advancement to Proposed Standard. A WG Last-Call on GSS-IDUP had been recently completed; following review of the most recent draft (which became available on the Internet-Drafts repositories only on the Friday before the IETF) for consistency with Last-Call discussion, it is expected that a subsequent update will be prepared and similarly submitted to the IESG. A number of RFC2078bis issues were discussed; an update (hopefully final) to this draft is planned on/about late January; in conjunction, minor revisions to the GSS C bindings draft are being discussed. A WG Last-Call is planned on draft-ietf-cat-ftpdsaauth-00.txt; draft-ietf-cat-ftpkeasj-00.txt is intended for Informational status. Discussion and review was resolicited on the xgssapi-acc-cntrl draft.

Several Internet-Drafts related to Kerberos technology were discussed. The base Kerberos document (RFC1510bis) is to be revised in January, and the result is anticipated to be a final version; updates to pk-init and pk-cross drafts are also planned in response to discussion. A draft presented on Kerberos anonymous credentials is intended to provide tutorial information, to be applied in conjunction with RFC1510bis; another presented draft provides informational discussion on Kerberos usage with firewalls. Separate drafts on error message processing, usage with TCP, and usage with IPV6 are being subsumed within RFC1510bis. Password change and pktapp drafts are to be reissued; updates are also pending to initial authentication (iakerb) and user-to-user (user2user) drafts.


Denis Pinkas (Bull), SPNEGO document editor, summarized SPNEGO as having evolved to being protected and more complex. It was believed that exactly one issue remained to be closed: inclusion of mechListMIC in negTokenInit, and whether such inclusion would be mandatory or optional. In the week prior to the meeting, Denis had proposed (in the SPNEGO document's optional API annex) inclusion of a control flag directing whether or not transfer of a MIC to the target was requested. Mike Swift (Microsoft) recommended that SPNEGO should support the sending of a MIC on the last message in an exchange which contains an odd number of messages; Marc Horowitz (Cygnus) agreed, also noting that "single message negotiation" is intrinsically contradictory. It was agreed that all SPNEGO-based context establishment sequences would require at least two messages. Mike Swift observed that this would be sub-optimal for the case of a server which always required SPNEGO but was capable of accepting only one underlying mechanism (e.g., Kerberos). It was noted that use of SPNEGO would add only limited value if only one negotiated result was possible, but some consideration was given to the special case of a single-token exchange.

A proposed resolution and closure to the final issue was reported by Marc Horowitz in the second WG session as follows, based on text which Marc had written between the sessions and had discussed with Denis. In the proposal, an initiator's MIC can optionally be sent to an acceptor; the acceptor sends a MIC if none was sent by the initiator. Denis suggested additional security considerations issue regarding mutual authentication, which he intends to add to the draft. Actions planned: Marc's text will be sent to the list for review, and will be incorporated into a new I-D for submission to the IESG with a recommendation for advancement to Proposed Standard.

III. RFC2078bis/C bindings

Several points related to RFC2078bis and the C bindings were discussed. A revision to RFC2078bis, hoped to be suitable for WG Last-Call, is planned for late January. On-list discussion may suggest a few clarifying revisions to the C bindings. Points discussed re RFC2078bis were as follows:

The sense of attendees confirmed that GSS_Inquire_context() would be aligned with the C bindings to add a result value indicating whether or not a context was fully open. Expired contexts are to be indicated with a reserved "lifetime" value rather than by returning the fatal CONTEXT_EXPIRED error.

Attendees confirmed list discussion regarding the indication of informational sequencing errors along with GSS_S_COMPLETE and GSS_S_FAILURE major_status: consistent with the C bindings, 2078bis will reflect that the sequencing error status codes may be indicated along with either COMPLETE or FAILURE for per-message calls; while this is syntactically possible for context establishment calls as well, return of sequencing error status along with COMPLETE (or CONTINUE_NEEDED) will remain semantically prohibited during the context establishment phase.

Regarding side effects, it was considered appropriate to state that invocation of GSS-API calls incurs no side effects visible at the GSS-API level (it being considered implausibly broad to rule out side effects on other aspects of system behavior).

For GSS_Acquire_cred() and GSS_Add_cred(), GSS_S_NO_CRED, rather than GSS_S_FAILURE as at present, is to be returned if an authorization failure is encountered upon credential acquisition. This decision reconciles previous inconsistent choices in the direction of informative error reporting.

Per a recent suggestion on the mailing list, we considered the prospect that the target_name input parameter to GSS_Init_sec_context() might be made optional. Mike Swift and Martin Rex (SAP) argued that this should be permitted, since not all mechanisms require that a target name be specified in order to authenticate an initiator to a target (and, subsequently, to authenticate the accessed target to the initiator). Ted Ts'o (MIT) observed that use of such a facility would be non-portable to the set of mechanisms which do require a target name in order to construct their tokens, and that its use by applications should therefore be cautioned, but considered (albeit reluctantly) that it was appropriate to allow the name to be optional. The working proposal, therefore (pending further list discussion), was to recommend that mechanisms accept GSS_C_NO_NAME as an input target_name type.

Regarding the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials with explicit names, it was considered that an explicit name as returned from GSS_Inquire_context() should be acceptable as an input to credential acquisition. It is important to recognize that the explicit name which is yielded by resolution of a reference to "default" may change over time, e.g., as a result of local credential element management operations outside GSS-API.

If an exported name object is imported with GSS_Import_name() and the enclosed mechanism type is not recognized or unsupported, it was considered (consistent with list discussion) that GSS_S_BAD_MECH should be returned.

Discussion at the session confirmed that RFC2078bis is to be aligned with the C bindings by removing (rather than deprecating, as is currently the case) GSS_S_CREDENTIALS_EXPIRED as a return value from per-message protection, context_time, and inquire_context calls.

It was recognized that current GSS-API specifications do not prescribe the error which should be returned if a reflected token (a token received by the endpoint which generated it) is detected. Many existing mechanisms' protocols include provisions for detecting such tokens, and it seems reasonable that a major_status code should be selected to indicate this situation. This topic is being discussed on the mailing list.

An additional RFC2078bis topic had been identified for discussion, but was not considered within the time available and therefore remains outstanding: should GSS_S_NO_CRED be returned by per-message calls if credential elements are needed but unavailable in order to complete an operation?


Few attendees had been able to read the most recent draft, since it emerged as an I-D only on the Friday before the meeting. One issue, cited previously on the mailing list, was the question of whether or not IDUP tokens should necessarily be wrapped with a mechanism tag in the manner of GSS tokens. Carlisle Adams (Entrust) believes that use of unframed tokens is sufficient to enable interoperability between IDUP-based and non-IDUP implementations of existing messaging security protocols; Ted Ts'o observed that such interoperability would be a desirable property. Another IDUP draft version is anticipated, reflecting reconciliation of issues raised during the WG Last-Call.

V. Kerberos Anoncred

Ari Medvinsky (Cybersafe), Kerberos/Anoncred: This is an informational draft, related to PKINIT and the Kerberos-revisions draft, describing use of optional flags in 1510bis. Its motivation: users may not be registered with an authentication service, or may be registered and wish to remain anonymous for a particular association, yet may still require an encrypted channel to an end service. Anonymity may be called for, Ari observed, in some applications (e.g., E-commerce).

Case 1: user not registered with authentication service: use REQUEST-ANONYMOUS flag in AS_REQUEST along with PKINIT's Diffie-Hellman option. The KDC returns a ticket with the ANONYMOUS flag set and session key protected via Diffie-Hellman. Case 2: registered user wishes to remain anonymous; ANONYMOUS flag used in AS_REQUEST, but PKINIT Diffie-Hellman option not needed. For either case, client's principal name, as reflected in the ticket, is "anonymous@realm" or other name based on KDC policy. Discussion point: Is it, per Marc Horowitz's suggestion, legitimate to make authorization decisions based on realm ID within name? Cliff Neuman (ISI) thought that this might be appropriate, but there was some controversy about this point, which was remanded to list discussion.

VI. Kerberos Initial Authentication (IAKERB)

Mike Swift led discussion on the Initial Authentication with Kerberos and GSS-API (IAKERB) draft. It addresses the problem that some Kerberos clients (e.g., in dialup initial authentication scenarios, or in some web server access cases) are unable to locate or contact a KDC, while servers generally have good KDC connectivity. Initial credential elements (e.g., passwords, private key for PKINIT) must be provided through an extension. The client sends framed KDC requests to server via GSS-API, which the server forwards to the KDC; tickets and requests don't have addresses, because the server is responsible for KDC communication.

The primary issue considered was that of how IAKERB integrates with the GSS-API Kerberos mechanism per RFC-1964. Ted Ts'o commented that a new mechanism OID is needed in order to identify that an endpoint supports IAKERB. Conceivably, IAKERB might be bundled with User-to-User (both of which precede or encapsulate the scope of the existing Kerberos GSS-API mechanism per RFC-1964), to comprise a successor version of the Kerberos mechanism. Ted Ts'o expressed sentiment in favor of merging IAKERB into the Kerberos mechanism, but was less sure about User-to-User. Further discussion about document relationship and structure was remanded to list. A separate issue was identified: how are initial credentials (principal name, password) established?

VII. Kerberos User-to-User (U2U)

Mike Swift led discussion on the User-to-User Kerberos Authentication using GSSAPI (U2U) draft. It addresses two limitations within the current GSS Kerberos mechanism: that context establishment to servers without accessible passwords (long term keys) cannot be supported, and that a client must know the server's principal name in order to initiate context establishment. In the U2U proposal, an extra round trip (bearing KERB-TGT-REQUEST and KERB-TGT-REPLY elements) is required in order to carry the TGT request transaction. RFC1510's ENC_TKT_IN_SKEY option is used within the KDC request. The client may request a server's principal name and realm.

Denis Pinkas requested additional clarification and/or references concerning the proposal's goals. Two basic issues were raised:

Should the ability for a client not to know a server's principal name in order to initiate a security context be further generalized? Sentiment appeared positive, consistent with discussion of GSS_C_NO_NAME input target_name to GSS_Init_sec_context() as noted above re RFC2078bis. For the case of an initially unnamed target, mutual authentication's semantics would confirm the target identity subsequently returned.

What are the security risks of a server handing out its TGT? The TGT is already (independent of U2U) transported over the net; its availability to requestors via U2U could make its access for password guessing purposes more convenient, but does not expose information not already transmitted.

VIII. Kerberos Public-Key Initial Authentication (PKINIT)

Brian Tung (ISI) led discussion on the Kerberos PKINIT draft. Changes in the most recent draft were relatively minor, including (among others) X.500 name encoding and the addition of 2 new encryption types. At the Munich meeting, Mike Swift had introduced the recommendation that PKINIT employ PKCS objects (subsequently clarified to PKCS#1 rather than PKCS#7) in the interests of compatibility with existing code and infrastructure. Brian's slide summary at the current meeting asserted that a change to PKCS structures would potentially make messages large, introduce unnecessary redundancy, and would introduce incompatibility with existing work using the incumbent PKINIT format. Decision was deferred, partly pending consideration of impact of PKCS#1.

Mike Swift also commented that the current document states that a ticket's realm should be the CA's name, but asserted as a goal that an application server shouldn't encounter different names for PKINIT accessors than for non-PKINIT access. This goal was agreed reasonable, and is achievable through one of various possible means. Mike also noted that existing means are available for putting RFC-822 names into certificates (e.g., AltName, and/or "E=" convention) and suggested that these should be applied.

Denis Pinkas commented that the security considerations section should refer to the possibility that a user's private key may have been retrieved without user knowledge. He also posed the prospect that storage of an encrypted private key on a server may be subject to a Digital Equipment Corporation patent; this question was not immediately answerable and requires follow-up research. He also requested that PKINIT be able to conformantly support user with only a signature-only key; Brian responded that this could be achieved through subset conformance, or through conformance to a separate protocol which could be defined within the document for this purpose.

IX. Kerberos Public-Key Cross-Realm Authentication (PKCROSS)

Brian Tung led discussion on the Kerberos PKCROSS draft. It uses the Kerberos Ticket-Extension field. The local KDC sends a PKINIT request to a remote KDC, and the remote KDC sends back a PKINIT reply, accompanied by a tag and policy information in the Ticket-Extension. The local KDC returns a ticket to the client, also including the TGT from local to remote KDC within a Ticket-Extension. No Ticket-Extensions are ever stripped. Mike Swift noted that it seemed bulky to send a TGT just for the purpose of transporting a session key, but it was observed that a TGT transports policy and validity information as well; more rationale discussion was desired in this area. Ted Ts'o commented that this appeared to be an overloading reuse of the TGT object; Cliff Neuman responded that usage as described was perhaps the fundamental use of a ticket; this dispute was remanded to the list. It was also observed that avoidance of KDC-KDC communications would be attractive.

X. Kerberos Extensions (RFC1510bis)

Cliff Neuman (ISI) led discussion on the Kerberos-revisions draft (rfc1510bis). Editing on this draft is being undertaken in html, and the current version is accessible at http://gost.isi.edu/people/bcn/draft-ietf-cat-kerberos-r-01.html; Cliff considers this html version to be authoritative, and will generate an Internet-Draft from it. He requests that open issues be posted on the web page at ISI.

IPV6 addressing will be included in 1510bis. Regarding support for Kerberos over TCP, Cliff suggests that this be made mandatory as of the next (-2) draft. One issue: whether to include a 32-bit length specifier in network byte order (Cliff's recommendation) or instead to rely solely on ASN.1 length indicators. Statements are also needed about policies for closing outstanding TCP connections with the KDC; it was recognized that the KDC must be free to break connections in order to throttle denial-of-service attacks.

Material from the previously separate key-derivation draft has been incorporated. Cliff noted that procedures as newly incorporated (and, hence, for which no backwards compatibility issues apply) for 3DES encryption do not conform to RFC1510's general structure template, suggesting either that the changes be redefined to conform with the template or that the assumption of template usage should be flushed. Typed e-data was also considered: Munich meeting discussion had suggested merits of typing the field to govern its interpretation.

Regarding anonymous credentials support, fields and flags are defined in 1510bis, and such credentials can be obtained with or without public key. The public key acquisition method is defined in a separate I-D. An anonymity-related issue was discussed, that of whether or not a reserved "anonymous" principal name should be defined. Cliff recommended use of the name "anonymous@anonymous", which (if adopted) would render the "anonymous principal" ticket flag moot and eligible to be removed, though the corresponding request flag would remain. Mike Swift commented that special treatment might need to be specified for authorization data in conjunction with the anonymous principal case. Cliff had noted before the meeting that auth time will be reset on anonymous ticket generation in order to prevent "de-anonymization" by correlation of ticket validity times. Ted Ts'o observed, though, that the presence of transport addresses and other fields can weaken the quality of anonymity offered in any case.

Regarding authorization data, several elements can now be represented, including (among others): KDC-issued, external adata (integrity protected but not confidentiality protected), and-or (now can achieve both AND and OR conjunctions with an and-or, along with the number of elements which must be matched to succeed). Mandatory extensions must be preserved in order to maintain the validity of a ticket. A pksigned element (suggested, but not now an included element) would provide a facility to allow entities other than the KDC to sign with a private key. Ticket extensions carry information to be moved along with the ticket, in its plaintext part, such as: the external adata authorization element, PKCROSS information, and a null extension (helpful in detecting whether ticket extension fields are being stripped).

Cliff identified the following next steps for kerberos-revisions: resolve open issues, fix 3DES specification, action on changes decided at meeting, formatting cleanup, added references, and citations. His intent is to post a revised version in order to enable WG Last-Call in advance of the LA IETF.

A question was raised as to whether any incompatibility issues existed between the specification and the DCE and/or MIT Kerberos implementations relative to the string-to-key algorithm. Ted Ts'o believes that MIT implements RFC-1510's string-to-key algorithm and was unaware of any interoperability issues with it. MIT's implementation also has backwards compatibility provisions with string-to-key as defined in Kerberos Version 4 and in AFS.

XI. Kerberos/IPV6, Kerberos/TCP, Kerberos/Firewalls

Assar Westerlund (SICS) led brief discussion on the Kerberos/TCP and Kerberos/IPV6 drafts, whose scopes are being subsumed into 1510bis. The TCP draft includes a 4 byte length specifier, as recommended (per prior discussion) for 1510bis. Regarding connection closing, it was noted that some but not all implementations drop connections after a request is processed, but that the KDC must be permitted to drop the connection at any time. Cliff will revisit 1510bis wording on this issue.

Assar then led discussion on the Kerberos/Firewalls draft; his goal for this document is an informational RFC about making Kerberos work in firewalled environments; Cliff endorsed placement of this material in a separate document from 1510bis. Some list discussion had taken place about the draft's characterization of firewalls. Ted Ts'o asked for clarification about the implementation impact imposed by the draft's recommendations. One point: use of proxies implies a desire to add an extra set of addresses into tickets to correspond to the proxy (e.g., as discovered by SOCKS); this is further complicated where multiple gateways are involved. Address checking can be disabled, but this renders the usage of tickets more permissive. A further revision to the firewalls draft is planned per list discussion.


Peter Yee (Spyrus) summarized the status of the FTPsec/DSA document: an original draft had been submitted for the Munich IETF, and no outstanding technical issues have been raised. Alignment with RFC2228 is being verified, and an implementation exists (win16 client, SCO server). He considers the document ready for WG Last-Call.

Concerning the FTP Encryption with Skipjack/KEA document, Peter is targeting informational RFC status unless the algorithms it employs are subsequently declassified. Mike Swift asked what advantages this approach offered relative to use of TLS, and Peter replied that this approach allows pre-computation.

XIII. Status Summary on WG Internet-Drafts

We concluded the session with a summary of status and plans for CAT-WG Internet-Drafts, based on a snapshot of the I-D directories as of the week prior to the meeting:

draft-ietf-cat-ftpdsaauth-00.txt (07/21/97): WG Last-Call planned.

draft-ietf-cat-ftpkeasj-00.txt (07/21/97): Targeted for Informational status, possibly to be revisited if algorithms declassified.

draft-ietf-cat-gssv2-cbind-05.txt (11/24/97): minor update may be needed in response to discussion.

draft-ietf-cat-iakerb-00.txt (11/05/97): update pending

draft-ietf-cat-idup-cbind-03.txt (04/16/97): not currently active

draft-ietf-cat-idup-gss-08.txt (10/14/97): minor update (-10 version) to be upcoming in response to WG Last-Call discussion

draft-ietf-cat-kerb-chg-password-00.txt (03/10/97): different implementations have reportedly interoperated; draft to be reissued

draft-ietf-cat-kerberos-anoncred-00.txt (09/22/97): to be released as informational document along with rfc1510bis and PKINIT, on which it depends

draft-ietf-cat-kerberos-err-msg-00.txt (03/26/97): obsolete: subsumed into rfc1510bis

draft-ietf-cat-kerberos-pk-cross-03.txt (11/26/97): further discussion and revision needed

draft-ietf-cat-kerberos-pk-init-05.txt (11/21/97): issues to be discussed; intent for revision and WG Last-Call before LA IETF

draft-ietf-cat-kerberos-revisions-00.txt (07/14/97): intent for revision in January as input to WG Last-Call

draft-ietf-cat-krb5-ipv6-00.txt (10/29/97): subsumed into 1510bis

draft-ietf-cat-krb5-tcp-00.txt (11/24/97): subsumed into 1510bis

draft-ietf-cat-pktapp-00.txt (02/17/97): to be revised and reissued; new version depends on PKINIT and is intended to be informational

draft-ietf-cat-rfc2078bis-01.txt (11/13/97): intent for revision in January, hopefully as input to WG Last-Call

draft-ietf-cat-snego-07.txt (11/18/97): final update to be made in response to issue discussed at meeting, result to be reviewed and forwarded to IESG

draft-ietf-cat-user2user-01.txt (12/01/97): update pending

draft-ietf-cat-xgssapi-acc-cntrl-02.txt (03/24/97): According to Denis Pinkas, this approach currently supports DCE and SESAME; document unchanged; review and discussion was resolicited. It was stated in discussion that the webdav WG is doing definitions of access control APIs.


None Received

Attendees List

go to list

Previous PageNext Page