2.6.2 Common Authentication Technology (cat)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

John Linn <linn@rsa.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

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 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

CAT-WG meeting minutes, Orlando IETF, 7 December 1998, reported by John Linn (RSA Laboratories).

GENERAL DISCUSSION

The CAT WG met for one session at the Orlando IETF, with approximately 80 attendees. IESG activities on submitted WG documents were reviewed briefly (SNEGO to Proposed, IDUP to Informational), and an action as proposed and discussed on the mailing list to resolve a recently-detected GSSV2 misalignment in advance of IESG submission was presented without objection.

KERBEROS PKINIT/PKCROSS WG LAST-CALL DISCUSSION

Significant discussion, led at the meeting by Brian Tung (ISI), took place in response to the recent PKINIT/PKCROSS WG Last-Call. It was accepted that consideration of PKCROSS advancement is to be deferred pending resolution of an issue (also involving Kerberos-Revisions) on usage of ticket extensions.

At the meeting, significant sentiment was indicated that CMS constructs be included in PKINIT by reference rather than by value, to ensure continuing alignment between WGs' activities and usability by PKINIT of S/MIME toolkit code. An argument was made, however, that existing PKINIT code would motivate keeping PKINIT as currently written. PKINIT uses CMS' EnvelopedData construct, which has changed in the CMS specification relative to PKCS#7 V.

1.5. Ted Ts'o (MIT) pointed out that a normative reference to CMS would imply the need for PKINIT to await RFC publication of CMS. Russ Housley (Spyrus; S/MIME WG chair) anticipated that pending CMS issues would be reconciled within the IETF meeting week and that CMS should go to IETF Last-Call within December. Jeff Schiller (MIT; security co-AD) suggested that PKINIT's CMS citations be changed to "by-reference", with subsequent recourse to "by-value" only if needed.

Marc Horowitz (Stonecast) raised additional PKINIT issues: he considered it desirable to be able to use Diffie-Hellman without PKI, and to support public keys for application servers. It was suggested that these be considered in separate drafts. Ted Ts'o proposed that they could comprise additional PKINIT modes, and Marc stated that he may pursue a Diffie-Hellman proposal. Cliff Neuman (ISI) recommended that the PKINIT specification should emphasize PKINIT's widely implemented modes, with other modes and new proposals to be placed in separate specifications; he observed, e.g., that a subset of PKINIT modes are implemented by Microsoft and CyberSafe.

PKINIT discussion reached the following working conclusions. PKINIT is to be restructured, with the digital signature and private key storage facilities to be placed into separate drafts. Current "by-value" references to CMS constructs will be replaced with references to the CMS draft. The "by-value" references will be restored only if dictated by CMS' advancement schedule; it is planned that a final determination will be made no later than the March 1999 IETF meeting.

GAA AND XGSS

A comparative presentation surveyed the relationship between GAA and XGSS documents; approximately 15 attendees indicated interest in progressing authorization activities within the CAT WG, with no opposition indicated, and a GAA document revision is planned.

Denis Pinkas (Bull) presented a comparison between the approaches in the GAA (draft-ietf-cat-acc-cntrl-frmw-01.txt) and XGSS (draft-ietf-cat-xgssapi-acc-cntrl-03.txt) drafts. The ISO access control framework includes an Access Decision Function (ADF), an Access Enforcement Function (AEF), and Access Decision Information (ADI), which were described as a basis for comparison between the approaches. GAA has 2 APIs: get_object_policy_info, providing ADI results used as inputs to check_authorization, which performs ADF. XGSS has more interfaces: get_sec_controls, get_sec_attributes, get_received_creds, set_cred_attributes, set_cred_controls, and compound_creds. Conclusion: GAA and XGSS are complementary. An application can call for an authorization check using gaa_check_authorization or can use get_sec_attributes as the basis to perform its own authorization checking. In both approaches, one could consistently use get_sec_controls, set_cred_attributes, set_cred_controls, and compound_creds. Denis observed that both approaches solve portions of the overall authorization problem, noting as an example that a GAA target must manage associated authorization data, typically in a mechanism-dependent way.

Cliff Neuman presented additional GAA material. The main GAA change relative to the previous version is that get_object_policy_info is now less ACL-specific. Cliff agrees that GAA and XGSS are complementary, but (consistent with Denis' comments) notes that they don't span the whole authorization space. GAA was intended to fit the model of an existing context, against which target-maintained authorization data is applied. GAA recognizes a target's need to manage policy, but its scope doesn't extend to management interfaces. Relative to GAA, XGSS offers richer functionality in credential management and modulation.

Two GAA questions raised on the mailing list were revisited at the meeting: level of portability offered, and support for POSIX/NT ACLs. A question had been raised on the mailing list as to how much portability is afforded by GAA, given application-specific policies which must be coordinated by generators of credentials. GAA developers have been working with the internet printing protocol as a candidate example user. Cliff Neuman believes that POSIX/NT ACLs should be supportable within GAA, but Denis questioned their suitability to a distributed environment.

A question was raised about the relationship between GAA/XGSS and the AAA work discussed in a separate BOF. It was clear that GAA and XGSS specify services and interfaces, while AAA is emphasizing protocol issues, but the underlying assumed model(s) may differ. Also, the current AAA work appears to be more specific to a particular application. Jeff Schiller stated that he may request liaisons between CAT authorization activities and other WGs such as AAA and LDAP.

Ongoing revisions are planned to GAA. Only minor changes, if any, are currently anticipated to XGSS. GAA has an available prototype implementation. XGSS has an implementation over SESAME as of mid-1998, but this implementation is not publicly available. Ted Ts'o noted that it would be useful to see multiple implementations of either or both GAA and XGSS to validate the approaches' portability beyond an initial mechanism.

KERBEROS-REVISIONS AND OTHER KERBEROS-RELATED DOCUMENTS

An update to the Kerberos-Revisions draft is planned by mid-January, identifying deltas relative to RFC-1510 and also addressing outstanding discussion re inclusion of new fields, ticket extensions, and ASN.1 encoding. Outstanding comments are to be addressed, assigned values for encryption types are to be fixed, and triple-DES specification is to be incorporated. An update to krb5gss-mech2 is planned, once issues including name types are discussed on the WG mailing list. Revision and implementation work are also planned on the Kerberos-Passwords draft.

Ken Hornstein (NRL) presented discussion on the Integrating Single-use Authentication Mechanisms with Kerberos document. A currently-outstanding issue concerns the key which is to be used in checksum construction. Ken wants to do a test implementation before proceeding further with the document, and also to do general style/grammar cleanup. He hopes that the result will be ready to move forward by the next IETF meeting.

Jonathan Trostle (cisco) led discussion on the Extension to Kerberos for Additional Initial Encryption (kerberos-extra-tgt) draft. Comments from WG members re possible progression of this draft within the CAT WG are solicited to the list. As stated, its goal is to strengthen the initial exchange between user and KDC, preventing brute force attacks against passwords. The approach employs keys from a host-level TGT, mixed using HMAC/SHA with a user key, to carry an encrypted session key. It was noted that the approach is dependent on a trustworthy host-level secret, so may be less applicable to shared workstation configurations. A possible alternative strategy using Diffie-Hellman rather than a host-level Kerberos key could be considered, but would be slower. It was also suggested that use of this approach may be appropriately configured on a per-user rather than a per-host basis. No identified implementation plans were apparent for the facility; it was noted, however, that Mike Swift co-authored the draft at Microsoft and that interest may exist there. It was also observed that a similar facility was specified within a DCE RFC and implemented in a product base, approximately four years ago.

Jonathan Trostle led another discussion, on the Public Key for KDC Recovery draft. Comments from WG members re possible progression of this draft within the CAT WG are solicited to the list. Three potential approaches were suggested to support recovery from KDC compromise: (1) use PKINIT universally, (2) use the approach described in the pk-recovery-01 draft, or (3, simpler than (2)) modify the draft to perform PKINIT and specify password change processing. As simplifying assumptions, it can be assumed that all public keys are certified within a PKI and/or that all users are registered with public keys. Brian Tung argued that since recovery operations are rare, the fact that (3) incurs 2 extra round-trips and that users must change passwords doesn't represent a significant burden, and therefore prefers (3) in the interests of simplicity.

PGP-TICKET

A PGP Ticket draft was presented to inform the WG and to solicit possible interest on its advancement within CAT as an authorization mechanism. Comments from WG members re possible progression of this draft within the CAT WG are solicited to the list.

Tony Mione (Rutgers) gave a brief presentation on the PGP Ticket I-D, draft-moscaritalo-mione-pgpticket-01.txt. It is being discussed on the ietf-pgpticket@vmeng.com mailing list; subscription requests can be made to requests@vmeng.com with a Subject field containing "subscribe ietf-pgpticket". PGP Ticket is an authorization mechanism based on Open PGP V4 Standalone Signature Packets. It uses a challenge-response mechanism to ascertain identities, and has some similarities to SPKI certificates. Ticket structure includes predefined subpackets (certificate starting validity, expiration, and issuer), notation subpackets (where "AUTH" describes allowed access types and "SUBJ" identifies the subject's public key), a hash check value, and a signature.

A typical PGP Ticket scenario was described as follows: a user approaches a service administrator for access to a service, the administrator creates a ticket with requested attributes, and the user gains server access by presenting the ticket and responding successfully to a challenge. Client and server systems integrate PGP Ticket processing functions. Tony commented that the proposal may be changed to avoid leaking information about access attempts, and that PGP Ticket could be used for GAA/GSS, FTP, or other prospects. In discussion, it was also suggested that it might be used for calsched and other ACL-consuming applications. It was noted that a PGP ticket may be usable as a capability; it was also noted that ticket revocation is not currently provided and that the issue needs to be considered.

Slides

Generic Authorization and Access control APIs /Extended Generic Security Service APIs