CURRENT_MEETING_REPORT_ Reported by John Linn/OpenVision Minutes of the Common Authentication Technology Working Group (CAT) Liaison Report Piers McMahon (ICL) stated that the X/Open Security Working Group has been working on conformance statements and verification procedures for GSS-API implementations, and that a description of results and issues in this area will be forwarded to the CAT list. Two specific points (channel binding structures and authoritative indicators of services available on a security context) were raised and discussed in conjunction with the base GSS-API and C bindings therefor. Working Group Charter The group reviewed the draft, updated charter of the CAT Working Group, broadened to include, among other points, scope compatible with IDUP (although not constrained to preclude future work towards return of evidence objects for enhanced non-repudiation) and with future authorization support facilities. The text will be re-sent to the Security Area Director for approval by the IESG. Active Working Group Documents FTP Security draft-ietf-cat-ftpsec-06.txt Marc Horowitz (OpenVision) is the new draft author. A revised draft is planned for distribution in April, with a target of 1 May for working group last call in advance of recommendation of that draft for advancement to Proposed Standard. Denis Pinkas (Bull) asked whether FTP security was able to provide authentication in only the server-client direction, without also authenticating the client to the server. Marc Horowitz stated that this is an issue at the level of the underlying GSS-API mechanism rather than the FTPsec specification, and noted that many GSS-API mechanisms cannot support this service selection. The revised FTPsec draft will clarify the relation between FTPsec and the GSS-V2 anonymity support. Changes between -05 and -06 of the draft: Much of the text has been rewritten and reorganized for clarity. The CONF command, 633 reply code, and E data channel protection level were added to support confidentiality without integrity. Most policy restrictions have been relaxed. In particular, neither encryption nor integrity is required, and each can be used independently. The GSSAPI authentication mechanism has been updated to reflect work on those documents. Line breaks in multiline protected replies are no longer required to be on the same line boundaries as in the plaintext reply. Some reply codes have been changed due to redundancy, or poor construction according to the rules in RFC 959, Sec. 4.2: 402 (MIC or ENC not supported) replaced by 533 (Command protection level denied for policy reasons); 231 (USER authorized, need dummy password) replaced by 232 (User logged in, authorized by authentication data exchange); 333 (after ADAT exchange, USER requires PASS) replaced by 331 (USER required PASS, from RFC 959); 502 (Command channel must be protected) replaced by 533; 500 (MIC or ENC before ADAT exchange complete) replaced by 503 (Bad sequence of commands, from RFC 959); 504 (PROT before PBSZ) replaced by 503; 504 (PBSZ not representable in 32 bits) replaced by 501 (Syntax error in parameters or arguments, from RFC 959). Base GSS-API and C Bindings draft-ietf-cat-gssv2-01.txt draft-ietf-cat-gssv2-cbind-00.txt The sense of the group was that backward compatibility with GSS-V1 applications was an important goal, and that call signatures of routines extant in GSS-V1 should be preserved. John Wray (DEC) stated that the current C bindings draft contains three changes which could affect backward compatibility, leading to discussion. Discussion specifically considered flag bits and use of OM_unit32 types. Shawn Mamros (FTP) observed that source code compatibility, the basis assumed by at least most current implementors, has already been achieved. Piers McMahon suggested that current caller behavior should (for cases where changes arise in GSS-V2) be permitted but deprecated. Specific proposal and discussion of wording was remanded to the mailing list. Extended controversy emerged about the proposal for structure and interpretation of Quality of Protection (QOP) parameters, as made by Carlisle Adams (BNR) on the mailing list and provisionally included in draft-ietf-cat-gssv2-01.txt. Specific contention arose around the proposed interpretations for mechanism-independent Type Specifier values for confidentiality and integrity; unless common agreement on these values can be achieved, the application portability benefit of QOP structure is limited. A straw poll at the meeting showed roughly equal sentiment for rolling back to the text in draft-cat-gssv2-00, for proceeding with the text in draft-cat-gssv2-01, and for proceeding with the structure in draft-cat-gssv2-01 but with revised values. Pending further discussion, the relevant text in draft-cat-gssv2-01.txt will be rolled back to the corresponding material from draft-cat-gssv2-00.txt. Regarding OID support routines, the group agreed to incorporate the set as proposed by John Wray, augmented by functions as proposed by Dennis Glatting (CyberSAFE) for conversion of OIDs to and from string representations. John Wray described the approach for anonymity support as included in the current drafts. A question was raised as to whether credentials could be acquired under the ``anonymous'' name and used; this case may, but need not, be supported by a particular mechanism. John next introduced issues of semantics for default and dual-mode credentials, brought into sharp focus through consideration of GSS_Add_cred(). It was recommended that we recognize that default behavior may differ depending on whether credential usage for context initiation or acceptance is being considered. A specific proposal was made to the mailing list and is currently being discussed. John led a discussion on GSS_Process_context_token(), recommending that a currently-proposed, and backward-incompatible, change to GSS_Process_context_token(), be expunged. He suggested that GSS_Process_context_token() be retained as defined in RFCs 1508/1509 for compatibility, but deprecated for future use in favor of new GSS_Refresh_sec_context() and GSS_Maintain_sec_context() routines. An alternative approach, accomplishing context renewal with GSS_Init_sec_context(), GSS_Accept_sec_context(), and/or variants thereof, was also discussed at the meeting. Subsequent e-mail identified an issue with this alternative and reiterated the Refresh/Maintain proposal; specifics are currently under discussion. It was agreed that the specifications should comment that interface implementations need to be self-initializing. Currently, the level of cross-mechanism support available for applications using address specifiers within channel bindings is limited. There are two candidate approaches to improve this situation: (1) deprecate use of channel bindings except for application-provided data, or (2) document, for a selected set of address types, the address structures to be used with those address types. Per (2), the address type list from RFC 1510 was nominated for consideration, and an implementor survey is now ongoing by e-mail to determine what types are currently supported and with which structures. It had been observed that cases can exist within which the service availability flags returned by GSS_Init_sec_context() and GSS_Accept_sec_context() are non-authoritative, e.g., when context establishment is accomplished through transfer of a single token from initiator to target without a means for the target to return a token to the initiator indicating inability to support an optional service. This was agreed to be an undesirable result; mechanisms should return authoritative flags, either as a result of exchanging indicator-bearing tokens to report service availability or by using separate mechanism IDs to represent different service selection options. Unless both peers to a context are known to be able to support an optional service (e.g., confidentiality), that service's unavailability should be indicated on both sides. Discussion of Parse_token() facilities in SPKM and IDUP (see also sections dealing with those drafts for related discussions) led to discussion of whether such a facility could be feasibly implemented within existing GSS-API mechanisms. Parse_token(), as currently implemented, is intended to support demultiplexing in a multi-context environment and does not perform cryptographic validation. For a token to be parsed successfully, it must be associated with a determinable mechanism, either via an explicit tag, an mech_type input argument (not currently included, but suggested as a useful option), or implicitly (e.g., support within a particular implementation for only one mechanism with untagged tokens). The Kerberos mechanism tags all tokens; the SESAME mechanism does not tag non-initial tokens; categorization of other mechanisms (e.g., KryptoKnight) was unknown and was solicited on the mailing list. Implementors are also being surveyed to ascertain the feasibility of implementing a Parse_token() function within their mechanisms. SPKM: Simple Public Key Mechanism draft-ietf-cat-spkmgss-02.txt Carlisle Adams gave a presentation on the updated SPKM draft. Changes from prior drafts include an added SPKM_Parse_token() facility useful for disambiguation in environments where multiple contexts are simultaneously active, specification of mandatory algorithm sets for interoperability, support for additional name types, and facilities enabling a context initiator to request that a target return certification data and/or generate a context's key. Sequence numbers are now optional and unencrypted (although integrity-protected), and algorithm IDs in per-message tokens are optional. SPKM uses the GSS_Process_context_token() facility as described in RFC 1508, so would be affected by an incompatible change to this call. Delegation is not supported. The BNR implementation of SPKM is complete and is in the process of incorporation into a commercial product. Don Stephenson (Sun) indicated that an implementation at Sun was also planned. The GSS-API sample application from the MIT Kerberos distribution has been successfully tested atop this implementation. Public domain implementation activities are underway at the University of New Brunswick and are being initiated at the Queensland Institute of Technology (target date: September 1995). The specification is considered to be stable at this time, pending resolution of an identified issue concerning X9.44 replay protection, and was placed in working group last call on 5 April 1995 for advancement recommendation to Proposed Standard. IDUP: Independent Data Unit Protection draft-ietf-cat-idup-gss-01.txt draft-ietf-cat-idup-cbind-00.txt Carlisle Adams and Dragan Grebovich (BNR) gave presentations on the revised IDUP (renamed from IOP) and associated C bindings specifications. To avoid confusion with the base GSS-API security context construct, the IDUP ``context'' has been renamed to an ``environment.'' Even when encryption is provided, IDUP does not encapsulate its data buffers into tokens; this allows messages to be split into multiple buffers but remains controversial, and further e-mail discussion was solicited. IDUP allows support for non-repudiation via digital signature, but does not currently offer calls for processing of provable evidences. New calls added in this version: IDUP_Process_receipt(), IDUP_Parse_token(); IDUP_Extract_prot_token() was deleted. BNR is currently developing a commercial IDUP implementation, layered on PEM; public-domain implementation activities are encouraged. Some GSS-API major_status values are irrelevant to IDUP, and some new major_status values are defined. Credentials can be shared between GSS-API and IDUP GSS-API Negotiated Mechanism This document is not yet an Internet-Draft. Doug Rosenthal (MCC) summarized ongoing work on a ``negotiated'' pseudo-mechanism for GSS-API, which could be configured as the default mechanism or requested explicitly by passing its mech_type OID to GSS_Init_sec_context(). At the Toronto CAT meeting, desires were expressed for negotiation at the level of mechanism selection, to simplify interoperability between peers. The facility being considered can also support negotiation of options within a mechanism. Non-intrusiveness to the current GSS-API is a goal. Denis Pinkas and Eric Baize (Bull) issued a draft proposal to the list, and comments were received; Denis and Doug intend to issue a revised proposal as an Internet-Draft in advance of the July IETF. One open issue: how to arbitrate different preference-ordered mechanism/option lists provided by negotiating peers. Kerberos (RFC 1510) Cliff Neuman (ISI) has a list of errata against RFC 1510; the document is fairly stable with no major discussion topics. One issue is relevant to advancing the document to Draft Standard: the document specifies that support for MD5 is mandatory, and CRC support optional, but few implementations support MD5 and only CRC is the current practice for interoperability. Cliff will send a message to the list summarizing the situation, as a basis for action and/or as input to an advancement recommendation. Kerberos GSS-API Mechanism draft-ietf-cat-kerb5gss-02.txt One issue is known to be active against the Kerberos V5 GSS-API mechanism Internet-Draft: the fact that no specific behavior is documented for implementations electing to support the (optional) delegation facility. Initial sense was that this document was ready for advancement to Proposed Standard. GSS-API Windows Bindings draft-ietf-cat-wingss-00.txt Piers McMahon submitted and discussed this Internet-Draft, related to GSS-API usage on Windows 3.1 and successor versions. It is being used in MIT-directed Cygnus Kerberos porting activities. Shawn Mamros observed that the Internet-Draft's structure alignment convention (4 bytes) diverges from common Windows and WinSock 2-byte practice. Piers responded that the intent was to support both 16-bit and 32-bit environments; given, however, a recognition that DLLs for these environments would likely diverge in any event, it was not seen as harmful to document them separately with different alignment conventions. A revised Internet-Draft will incorporate this change. Kerberos Extensions: Public-Key Initial Authentication draft-ietf-cat-kerberos-pk-init-00.txt Cliff Neuman led a discussion on this Internet-Draft, reporting that some comments had been received by e-mail and soliciting further review and discussion, especially regarding naming and trust path issues. Implementation activities are currently underway, but not yet complete; SESAME has implemented functionality similar to parts of the proposal. The draft's goal is to enable secure recovery from KDC compromise; its authors believe that its relatively simple extensions for initial authentication provide perhaps 80% of the benefits which public-key cryptography can offer to Kerberos. In the proposed approach, users are registered with public keys in order to prove (via preauthentication) their identity to the KDC. Use of a public-key algorithm capable of encryption (e.g., RSA, elliptic curve) rather than a signature-only algorithm is required. Denis Pinkas expressed concern about the export implications of the implied requirement for use of a strong-length encryption key, but others observed that the usage described would likely qualify as ``encryption in support of authentication.'' Users' private keys can, as one option, be stored (password-encrypted) on the Kerberos server. Kerberos Extensions: Kerberos One-Time Passwords draft-ietf-cat-kerberos-passwords-00.txt Glen Zorn (CyberSAFE) led a discussion on this Internet-Draft; a working update to the draft was sent by e-mail to the CAT list during the IETF week. Some questions are embedded in the e-mailed version; a follow-up Internet-Draft will intercept outstanding issues. Glen solicited review and discussion, specifically flagging a need for qualified review of the proposed ASN.1 syntax. Identified changes include renamed protocol fields, inclusion of a previously-missing field for transfer of a passcode, and support for a list of identified KDCs and for redirection among them. Device IDs are to be registered via IANA. Public-key passcode encryption will be treated in a separate document. It is believed that this document represents the first appearance of user-displayed text within a Kerberos protocol, thereby raising internationalization issues: as an approach, it was proposed that a language identifier be configured for each registered user. Topic for investigation: is the GeneralString type sufficiently general to accommodate variant character sets? Secure Socket Layer (SSL) Presentation Taher Elgamal (NetScape) gave a presentation on Secure Socket Layer (SSL), developed by NetScape. A protocol description document is available, but was not in Internet-Drafts as of the time of the meeting. A reference implementation (SSLref) is available from NetScape. SSL requires TCP or other reliable transport and provides an socket-derived API; it is intended as a means to protect a range of application-layer protocols. SSL provides transaction-oriented privacy, authentication, and integrity services; it does not provide non-repudiation. Encryption is always performed; 40-bit exportable algorithms are supported and indicated with different algorithm identifiers. Service negotiation facilities are included within the SSL protocol; it was observed that key size negotiation was not itself cryptographically protected. Supported algorithms include DES, RC2, RC4, IDEA, triple DES, RSA, master-key seeded MD5, and MAC. Separate session keys are used in the client-server and server-client directions; this property was described as desirable for use with RC4. In the interests of performance, key generation is performed using MD5 and a single master key may be reused for generation of per-connection session keys for multiple TCP connections. Perfect forward secrecy is not provided. SSL is based on (X.509) public-key certificates; a server-side certificate is required but a client-side certificate (and, therefore, client authentication to a server) is optional. A client must possess an issuer's public key via out-of-band means in order to validate a server's certificate. In the current protocol, only a single level of certification is supported; it was stated, however, that this limitation is not fundamental and that support for certificate chains could be incorporated. Certificate revocation lists (CRLs) are not supported. Indicated future plans for SSL include Diffie-Hellman key negotiation, improved certificate management (chains, larger RSA keys, PKCS #7 and PEM formats), and responses to requests from individuals, organizations, and standards groups. Audience questions sought to position SSL relative to existing IETF Security Area activities. Relative to IPsec, Taher stated that SSL does not provide functions which IPsec omits, but offers the virtues of being available today and of being performable within an application. Relative to CAT, he observed that SSL was simpler; it was also observed that SSL might be supportable as a CAT mechanism. Piers McMahon commented that SSL was very much like the SOCKS protocol under discussion in the AFT Working Group, with the exception that SSL, unlike SOCKS, requires use of new port numbers. Actions Initiated and Pending o SPKM draft (draft-ietf-cat-spkmgss-02.txt) is out for working group last call (to close 13 April) for advancement to Proposed Standard; one issue concerning replay protection is being checked. o Resend revised working group charter to be submitted for IESG approval. o FTP security Internet-Draft (draft-ietf-cat-ftpsec-06.txt) pending specific edit, then to be released for working group last call for advancement to Proposed Standard. o Updated drafts for GSS-V2 and GSS-V2 C bindings are targeted for mid-May, then to be released for working group last call for advancement as Proposed or Draft Standards. o Denis Pinkas to send summary of QOP position. o Denis Pinkas and Doug Rosenthal to issue revised negotiated mechanism Internet-Draft in advance of July meeting. o Revised GSS-API Windows bindings Internet-Draft pending. o Cliff Neuman to send summary of RFC 1510 checksum issue.