CURRENT MEETING REPORT Minutes of the Common Authentication Technology Working Group (cat) Reported by John Linn, Open Vision Summary The CAT WG met for two sessions in Dallas. Presentations included talks on the SESAME GSS--API mechanism, the Kerberos Single--Use Authentication Mechanism (SAM) draft, Kerberos Public--Key Extensions, IDUP, Simple Authentication and Session Layer (SASL), authorization and delegation control extensions (xgssapi), and GSS-- API/Web integration (a work item within the WTS WG). Other discussion topics included pending issues on GSS--V2; all known pending issues were closed or triggered action items, and an additional Internet- -Draft version is planned for January as a basis for advancement to Proposed Standard. Following active business on Internet--Drafts, a brief summary of Microsoft's adaptation of GSS--API for Windows NT was presented. Working Documents and Next Steps RFCs 1508, 1509 (GSS--API, C Bindings): Proposed Standards. GSS--V2 Internet Drafts prepared (draft--ietf--cat--gssv2--04.txt, draft--ietf-- cat--gssv2--cbind--01.txt). Targeting new high--level Internet--Draft as basis for advancement to Proposed Standard. RFC 1510 (Kerberos): Proposed Standard. Pending minor revision as I-- D before advancement to Draft Standard. I--D draft--ietf--cat--kerb5gss--03.txt (Kerberos GSS--API mechanism). Internet--Draft revision planned before considering advancement to Proposed. I--D draft--ietf--cat--kerberos--pk--init--00.txt (Kerberos Public--Key Initial Authentication). Internet--Draft revision planned before considering advancement to Proposed. I--D draft--ietf--cat--kerberos--passwords--02.txt (Kerberos Single-- Use Authentication Mechanisms). Internet--Draft revision planned before considering advancement to Proposed. I--D draft--ietf--cat--wingss--00.txt (GSS--API V1 MS Windows DLL interface). 32--bit Internet--Draft revision pending. I--D draft--ietf--cat--ftpsec--08.txt (FTP security). Internet--Draft revision with state diagram pending. I--D draft--ietf--cat--snego--00.txt (GSS--API Negotiated Mechanism). I--D draft--ietf--cat--spkmgss--04.txt (SPKM). This document was placed into IETF last call during the summer; some IESG technical comments are pending. The document had been recommended by the IESG in August for Experimental status per RFC--1602 Intellectual Property Rights (IPR) issues related to use of the RSA algorithm; given the recent fact of RSA's publishing a public statement of license terms (posted on http://www.rsa.com), it is currently expected that the SPKM document will be reconsidered and advanced to Proposed Standard. I--Ds draft--ietf--cat--idup--gss--02.txt, draft--ietf--cat--idup--cbind- - 01.txt (IDUP and C bindings). New, revised high--level I--D became available after the meeting. I--D draft--ietf--cat--pim--00.txt (PEM--based IDUP mechanism). I--D draft--ietf--cat--sesamemech--00.txt (SESAME GSS--API mechanism). Newly presented at meeting. I--D draft--ietf--cat--xgssapi--acc--cntrl--00.txt (Authorization/Delegation extensions). Newly presented at meeting. Reference Implementation Status In addition to status of active drafts, status of available reference code was discussed. Reference code is currently available for Kerberos and for the Kerberos GSS--API mechanism (per GSS--V1); a partial GSS-- V2 Kerberos mechanism implementation (including context import/export and credential support extensions, and based on the --02 or --03 version of the GSS--V2 document) has been developed at MIT and is available as a snapshot. Reference code is planned to be available shortly (January 1996) for the SESAME mechanism; this code base will have some differences from the I--D specification, as documented in an annex to the I--D. Reference code is planned for early in 1996 for the SPKM mechanism. No reference implementations are currently available for the GSS--API Negotiated Mechanism, for IDUP, PIM, or for the xgssapi authorization and delegation extensions. Reference code currently exists for Kerberos Public--Key Initial Authentication, but revisions are planned as a result of issues being discussed. No reference code is currently available for Kerberos SAM, but it will be developed and made available subsequently. Cygnus has developed an implementation of FTP security which will be incorporated into a subsequent MIT Kerberos distribution; another FTP security implementation (based on Kerberos V4) has been done at CMU and can be located on http://andrew2.andrew.cmu.edu/dist. Sesame GSS--API Mechanism Stephen Farrell, Software and Systems Engineering, Ltd. (stephen.farrell@sse.ie), presented this draft (draft--ietf--cat-- sesamemech--00.txt) and discussion. An overall goal of Project SESAME is ease of cross--platform administration; it was noted that porting has been carried out to a large range of platform environments. Privilege Attribute Certificates (PACs) are carried in GSS--API context establishment tokens. Within context acceptor systems, a target access enforcement function is distinguished and implemented (on UNIX platforms) by a separate daemon. Three key distribution schemes are supported: (1) intra--domain using Kerberos per RFC--1510 and capable of supporting RFC--1510 clients, (2) inter--domain with modified Kerberos, and (3) asymmetric keying using SPKM technology, but not strictly interoperable with SPKM endpoints. Context token contents include (non--exhaustive list): PAC, target key block, dialogue key package (dialogue keys being formed by key offsetting from a context's session key), context identifier. PAC contents include PAC id, validity specifiers, miscellaneous attributes, privileges, PAC protection mechanisms, a crypto check value, Primary Principal ID (PPID), Control Value/Protection Value (CV/PV), target qualifier attributes, and delegation qualifier attributes. A PAC's protection value is a one--way function of its control value. PACs may be protected using multiple methods, and accepted if any of those methods can be successfully validated by a target recipient. An Application Trust Group (ATG) is a named group of applications which are equivalently trusted. Reference code will be available within about a month, probably from an ftp site in Belgium. Stephen will post a pointer when it becomes available, as well as a citation to a Web site with further information. BASE GSS--API--V2 Discussion (draft--ietf--cat--gssv2--04.txt, draft--ietf--cat--gssv2--cbind--01.txt). GSS--V2 issues pending and discussed: (P1) Adjust discussion of canonicalized name routines to match state-- of--list once converged. The issue had been summarized by Martin Rex as follows: "The list hasn't reached consensus on re--importability of the flat binary name produced by gss_export_name() (i.e. write--only ACLs). The necessary provisions for re--importability would be either a default name type for the flat binary representation, or the addition of another argument that returns the required nametype. (I assume that re--import should be done via gss_import_name(), which wants that gss_name_t.). If consensus on re--importability can not be achieved, then the lack of re--importability should be documented." Reimportability engendered some controversy, but its value was recognized. As a result, the working proposal from discussion at the meeting (subject, like other meeting discussion, to reconsideration on the mailing list) was as follows: The output of GSS_Export_name() is to be reimportable by GSS_Import_name(). Each GSS--V2 mechanism specification should define the format of the object which GSS_Export_name() produces for that mechanism, said object to be self--describing and to include the mechanism's OID internally for tagging purposes. Ted Ts'o offered to propose a candidate format to the list. For some mechanisms, it may be appropriate for the format to be extensible to include data items other than names (e.g., privileges). (P2) Treatment of multiply--imported context tokens. CONCLUSION: Don't impose strict requirement that conformant GSS implementations must detect attempts to import a given context token more than once, but permit GSS implementations to return an error if they detect and reject an attempted multiple import. Portable applications must not assume that multiply--importable tokens are supported. (P3) Closure on what, if any, specific proposal for a MIC token analog to GSS_Wrap_size_limit() should be included. CONCLUSION: Bill Sommerfeld will reinitiate this discussion on the list. If the result converges by the end of December, it will be included in GSS--V2. (P4) Are we promoting name types (e.g., USERNAME) other than host- -based service to GSS level? CONCLUSION: The mechanism-- independent forms will be promoted to GSS level. (P5) Need to acquire/insert IANA OID assignments for anonymous and host--based service name types. (Note: (P4) will imply the need to broaden this list.) (P6) Per Raj Srinivasan, 1 November: return of confidentiality QOP bits by GSS_GetMIC(), GSS_VerifyMIC(), functions which never provide a confidentiality service. CONCLUSION: Revise text to state that implementations of these routines should not return non--zero values in confidentiality QOP fields. (P7) Per John Myers: for protocol elements in host--based service names, should the existing IANA Protocols and Service Names registry be used or should another registry be established? Complexities related to this issue include: Kerberos's use of the "host" principal to accept contexts for a number of protocols, and usage of a single principal to correspond to multiple versions of a service protocol (e.g., "pop" vs. "pop3"). CONCLUSION: A new, case--sensitive IANA registry appears to be needed; John Myers drafted text after the meeting for review on the list as justification to be presented to the IANA. (P8) Per John Wray, 13 October, should align high--level spec and C bindings re described printable format for OID representations. CONCLUSION: Adopt within the high--level spec John's proposal as currently included in the C bindings, to use the numeric ASN.1 syntax format (curly-- brace enclosed, space--delimited, as in "{2 16 840 1 113687 1 2 1}"). (P9) Per list discussion 12--18 October, will revise context token wrapper syntax in GSS--V2 spec so that the actual octets, not the ASN.1, are definitional. Per meeting discussion, words will be added to the GSS--V2 spec about presentation of an invalid token for a context not disrupting the context's state. Another issue: is it possible to make subsequent calls on a context after, e.g., a memory failure? Desirably, it should at least be possible to delete the context. While particulars in this area are probably mechanism or implementation specific, it would be useful to recommend that failures don't result in allocating memory (with attendant risk of memory leakage). Proposed text, communicating the general message, "even after error, can continue making calls on context," will be posted to the list for discussion and intended inclusion in the top--level GSS--V2 draft. Ted Ts'o raised a point re the GSS--V2 C bindings: there's a 32--bit assumption which needs to be rechecked (GSS_C_INDEFINITE). Simon Cooper (SGI) raised a set of issues which he saw as relevant to GSS--API usage in Web environments. He asked whether it was possible for contexts to be cached for use over UDP; this can be done but is not a facility guaranteed for all mechanisms. Simon also indicated a desire to be able to bind context identification to tokens, e.g., in framing material. This is analogous to the facility provided by SPKM_Parse_token. Parse_token is, however, hard to implement for some mechanisms which don't maintain linked list of contexts, and had previously been excluded from the GSS--V2 specification partly because of this fact. In addition to these functions and other GSS--V2 features, an ability to control emitted token size was requested. Concern was also raised about flushing of inactive contexts. Kerberos Single--use Authentication Mechanisms (draft--ietf--cat--kerberos--passwords--02.txt) (C. Neuman/G. Zorn) Glen Zorn (CyberSAFE) led discussion on this Internet--Draft, renamed from Kerberos One--Time Passwords. A facility has been added to this version for transport of public--key information, and code corresponding to the SAM spec is planned for inclusion in Kerberos V5 beta 6. Glen noted that he and Cliff Neuman consider the SAM spec to be solid at this point and that its public--key hooks will be sufficient, although the Kerberos public--key specification has not yet stabilized. Glen indicated a desire to reach consensus on SAM at the meeting or shortly thereafter. Denis Pinkas (Bull) indicated a concern that specifications should not presume comprehensive multi--method support when a particular method is dominant in the design. Denis also disagreed with the spec's recommendation re Kerberos password entry; he wishes to support a 10--character passphrase as recommended in the OTP WG. Glen noted that SAM's OTPZ--mode operation can be supported without a Kerberos password, but SAM's base OTP mode requires the Kerberos password. John Linn requested clarification as to whether a client may or may not continue a SAM exchange with a different KDC than that with which the exchange was initiated. Denis, Cliff, and Glen reported at the second CAT session that they had had follow--up discussion re SAM following the presentation, and that they will investigate a generic way to accomodate Denis' requirements in another version of the spec. Kerberos Public--key Extensions (draft--ietf--cat--kerberos--pk--init--00.txt, expired) (C. Neuman) Cliff Neuman led discussion on the Kerberos public--key extensions Internet--Draft, on which related work is underway at ISI (with information available on http://nii.isi.edu/info/Kerberos). The current code uses PGP; it is hoped that a version can be integrated into the next MIT Kerberos release. A revised Internet--Draft is planned for January 1996, given resolution of issues under discussion. One issue discussed was the certificate format(s) to be used to certify the KDC. A proposed approach was to use X.509V3, with a request to be made to the PKIX WG to specify a name type to represent a Kerberos principal name as an X.509V3 private type. Alternatively, the KDC may be certified within any of the infrastructures through which the users it serves are validated. Ted Ts'o asked for clarification of the requirements being addressed. The presumed goal is to achieve single login, using Kerberos as appropriate, within an environment where users are registered in a public key infrastructure. Another issue was whether or not certifiers of KDCs should be indicated in the Kerberos transited realms field. It was asserted that such information might be too complex to be useful to most targets, and that avoidance of such complexity was one reason why name subordination has been used within certification infrastructures. Another issue: Should a private key--based exchange, like that in SPX's LEAF, be supported? Denis Pinkas reiterated a request for changes in the interests of export, so that a user need not apply a high--strength private key for encryption (vs. signature); Cliff Neuman commented that this would require invasive Kerberos changes beyond the scope of preauthentication, but Denis observed that this goal could be satisfied if session key generation were performed by users. RFC--1510 Revisions Cliff Neuman commented about the status of the RFC--1510 update. The revision has new checksum identifiers and preauthentication codes, includes means for notifying clients re the set of methods supported by servers, and is slated for mid--January. Independent Data Unit Protection (IDUP) Discussion of revised IDUP drafts (draft--ietf--cat--idup--gss--02.txt, draft--ietf--cat--idup--cbind--01.txt, and draft--ietf--cat--pim-- 00.txt). (C. Adams, D. Grebovich). Carlisle Adams (BNR) presented discussion on an idup--gss--03 update, which was in transit and reached the I--D directories after the meeting. He commented that the new version includes sweeping changes in call structure, changing parameters, removing "evidence" calls, and adding capabilities for encapsulation and single--call processing of a self--contained message. Carlisle asserted that the structure is now much more general, and should simplify future inclusion of new services. Discussion on idup--gss--03 was eagerly solicited; to this point, relatively little E--mail debate has taken place on the IDUP documents. Parameter bundles are a notational convenience to simplify presentation of calls in the spec and to simplify application use of the calls (e.g., via convenient defaulting). Some bundles have mechanism-- defined structure and are opaque to callers, but others have defined, application--parseable structure. Bundles can contain both input and output elements, and can can be nested within other bundles. All services use General_Service_Data bundle, some also use others, e.g., Service_Creation_Info or Service_Verification_Info. The new IDUP version removes the distinction between "protection" and "evidence", returning to a generalized concept of "protection". Three types of protection and unprotection operations are defined: unsolicited services, solicited services, solicitation of a service. There are 10 IDUP--defined services, identified by OIDs. "Unsolicited" refers to a local request, "Solicited" to action triggered by remotely-- received token. An originator, e.g., performs unsolicited encrypt and sign operations, soliciting a receipt from a target. To process a received token, unprotect is called once for token parsing (omittable if needed data can be otherwise determined), and a second call performs the actual validation. Suggestion at meeting: use message hash as hint to identify messages corresponding to signatures. Carlisle believes that the document should now be stable, and said that the C bindings and PIM are being aligned and will be submitted in January or February. Denis Pinkas noted related work: the Object Management Group (OMG) has issued an RFT for object--oriented non-- repudiation technology (addressing just evidence processing, not other services), with submissions to be provided 18 December and reviewed by January; work is in progress to align this submission with Carlisle's work. John Myers asked why the IDUP work was taking place in the IETF, given the fact of pre--existing store--and--forward messaging security protocols, and questioned the value of an API--based approach in a non- -interactive, non--negotiating protocol environment. Several attendees saw value in IDUP, and commented that the justification for IDUP is closely analogous to the justification for base GSS. It was also noted that GSS--API existed and was applied in interactive environments before the negotiated mechanism approach was proposed. Simple Authentication and Session Layer (SASL) (draft--myers--auth--sasl--00.txt) (J. Myers) John Myers (CMU) presented a discussion on SASL, a framework for adding security into protocols. Generalized from IMAP, SASL is a small layer which is recommended for layering over GSS--API, also supporting Kerberos V4 and S/KEY (OTP) and encoding bits indicating protection service availability. SASL's use is currently specified for POP, IMAP, and John has implemented it with Kerberos V4; it is being considered for the next LDAP revision and by an ad--hoc non--IETF LPR--ng (printing protocol -- next generation) group. Issues: registries to be used for service names and SASL mechanism names. John wants to issue a new draft, and then go to last call. GSS--API/Web Integration (draft--ietf--wts--gssapi--00.txt) (D. Rosenthal) Doug Rosenthal (rosenthal@tradewave.com) gave a presentation on a proposed approach for GSS/Web integration. Although this presentation was given to the CAT WG for informational purposes, the draft is a work item of the Web Transaction Security (WTS) WG and any decision on its potential advancement will be made within the WTS WG. Doug noted that the proposal's objectives were to meet WTS WG requirements, to leverage existing IETF security work, to support a variety of security technologies, and to enable API sharing between Web and non--Web secure applications. As described, the proposal defines a new URL type, establishes a security context per Web transaction, encapsulates HTTP, and can be used to support access control enforcement. Informal testing didn't show major performance problems from context setup, Doug reported, but quantitative values have not been presented and would be valuable. No context caching is currently performed above the mechanism level, but this could be considered as a future optimization. An IANA service port has been assigned, and WinWeb and MacWeb browsers have been integrated with PK--based (SPKM) GSS toolkit. Doug's plans include deployment with a commercial CA service to gain experience and evolve the specification. It was reported that a concern had been raised at the WTS meeting about the feasibility of API usage, given the fact of multi--language Web development environments. John Myers observed that the proposal appears to duplicate SASL work, which could potentially replace it. GSS--API Authorization and Delegation Extensions (draft--ietf--cat--xgssapi--acc--cntrl--00.txt) (D. Pinkas/T. Parker) Denis Pinkas (Bull) presented a discussion on a proposed set authorization/delegation extensions, called XGSS--APIs. These extensions, based on an X/Open snapshot document, provide support for exchanging attributes, constructing related authorization functions, and for providing delegation controls. They extend GSS to allow authorization based on attributes beyond just username; as in DCE, groups are accomodated. An audit identity, explicitly not to be used for authorization decisions, is supported. An xgssapi security attribute contains attributeType, definingAuthority, and securityValue (with interpretation qualified by type). Attributes are divided into principal attributes, privilege attributes, qualifier attributes, and miscellaneous attributes. There are attribute handling support functions (GSS_Set_cred_attributes, GSS_Get_sec_attributes), an acceptor support function (GSS_Get_received_creds), and acceptor control functions (GSS_Set_cred_controls, GSS_Get_sec_controls, GSS_Compound_creds). Denis noted that the proposed extensions assume a push model of privileges, and cited a goal to migrate to support for role--based authorization decisions. John Myers perceived the proposal as complex from an applications programmer's viewpoint; he expects to write his own authorization service but would like to receive groups as well as the individual entity names which GSS--API now provides, and would be satisfied to receive the groups as (separately--typed) elements of a set of names associated with a context. Glen Zorn also observed that the proposal appeared complex and suggested its division into different documents: a framework, separated C bindings, and a worked instantiation within a mechanism. Concerns were raised about the extent to which the proposal could be implemented in multiple mechanisms; Denis commented that DCE could support some of the described functions. Ted Ts'o asked whether attribute extensions were intended to be portable across supporting mechanisms. Generally, it was considered that cross-- mechanism attribute definition for a core set of attributes is highly desirable. Microsoft GSSs--related Interface Following discussion of Internet--Drafts, Richard Ward presented a brief summary on ongoing GSS--related work at Microsoft. A "Windows--ized" GSS--V1 implementation is incorporated in Windows NT 3.5.1. Its interface specification ("Security Support Provider Interface") is not currently on--line, but hardcopies were provided at the meeting and the document is available on request to Richard, within the Win32 SDK, and/or via a to--be--provided FTP pointer. A primary goal motivating changes was to to provide stream support, enabling use of the interface to support caller protocols like SSL and PCT which define their own record blocking. Richard encouraged the GSS--compatible connection--oriented usage mode for future applications, but was constrained to satisfy this compatibility requirement. The Microsoft implementation has an additional descriptor in buffers, which allows continuation buffers to be represented and processed. Although a particular caller may require the use of a specific compatible provider mechanism (for compatibility with the caller's protocol format specification), such a provider can also be reused by other callers which do not constrain the structure of their GSS tokens. Richard intends to prepare an Internet--Draft describing the extensions and changes to GSS--V2 which the Microsoft interface embodies.