Network Working Group C. Newman Internet Draft Innosoft Document: draft-newman-auth-mandatory-00.txt April 1998 Expires in six months The Mandatory-to-Implement Authentication Problem Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo defines the ``mandatory-to-implement authentication mechanism'' problem (at the per-TCP-connection level), describes the requirements necessary for a solution, and identifies the mechanisms which meet a significant subset of the requirements. It is hoped this will help the IETF come to an understanding of the problem and a rough consensus on a solution. 1. The Mandatory-To-Implement Problem Almost every IETF protocol needs authentication. In order for a randomly selected client and server pair to interoperate, there must be a mandatory-to-implement authentication mechanism (not necessarily mandatory to use). It is desirable that as many protocols as possible use the same mandatory-to-implement authentication mechanism as this reduces complexity for an Internet host with multiple services. Finally, there is a strong consensus in the IETF that plain-text passwords over an unencrypted channel are no longer acceptable for this purpose. Newman [Page 1] Internet Draft The Mandatory Authentication Problem April 1998 We need to select a default mandatory-to-implement authentication mechanism for protocols above the TCP layer which will be used unless special circumstances or threats on a particular protocol dictate otherwise. This is most urgent for the LDAPv3 [LDAPv3] protocol, but IMAP [IMAP4] and other protocols will likely follow soon. If this decision continues to be deferred, it will continue to delay forward progress in the applications area and other areas and cause more non-interoperable digest-based authentication mechanisms to be deployed. This problem is not addressed by the IAB security workshop report [IAB-SEC], other than to reinforce the first requirement below. 2. Current Practice in the Field To this date and for the foreseeable future, most IETF protocols in the field require the implementation of unencrypted plain-text passwords for interoperable authentication. There is a strong consensus in the IETF that this is no longer acceptable. The HTTP [HTTP] protocol has reached a point where clients need to implement an additional security mechanism in order to access a large number of useful services. This mechanism is an SSL security layer using RSA and RC4 with a 40-bit key. Due to the Danvers doctrine (relating to 40-bit), IETF policy (relating to trade secrets) and the Munich decision (relating to patented public key technology), such a solution is completely unacceptable for standardization. Some limited success has been achieved deploying APOP [POP3], CHAP [CHAP] and CRAM-MD5 (simple hash-based challenge response protocols). Mechanisms of this class have already been added to many IETF protocols (POP3, HTTP, PPP, SNMPv3 [SNMPv3-USM], ACAP), although most of these variants are incompatible with each other on the server side unless the server stores the user's plain-text password. A few other mechanisms have achieved limited success at sites with skilled technical staff or sites where users tolerate inconvenient requirements from computing staff. 3. Requirements for a Mandatory-to-Implement Mechanism No mechanism can meet all these requirements completely and different people in the IETF will have different opinions about the relative importance of these requirements. However, it is assumed the IETF has a common goal of getting mechanisms superior to unencrypted plain-text passwords widely deployed in the real world. Newman [Page 2] Internet Draft The Mandatory Authentication Problem April 1998 This common goal can guide us through the engineering tradeoffs which must be made. No Passwords on Unencrypted Channels Must not use passwords on unencrypted channels becuase they are susceptible to passive eavesdropping and replay attacks. Follow IETF Doctrine Must not use patented technology, trade secret technology or export-crippled technology. Simplicity Must not be more complex than the protocol it is serving. DISCUSSION: Software vendors are trying to sell a specific product rather than an authentication service. An authentication mechanism which is more complicated than the primary goal of the software vendor is likely to be ignored for practical commercial reasons. Software vendors also need to understand the code and services they use well enough to provide technical support and bug fixes, thus freely available libraries only partially address this requirement. No Mandatory External Services Must not require the presence of an external authentication server or service. DISCUSSION: Vendors who market a single service usually need a "plug-and-play" installation and some are forbidden by philosophy, policy or charter to bundle external servers. A mechanism which requires an external authentication server is unlikely to be used by default from such vendors and thus would be counter-productive as a mandatory-to-implement mechanism. A mechanism which can take advantage of an external server or service when present, but works fine without one is acceptable and likely desirable. Backwards Compatibility Must interoperate with deployed password-based authentication infrastructures. DISCUSSION: Server vendors and customers usually have an investment in authentication backend technology. Many rely on the technology offered by operating system services. If servers from multiple vendors are run on the same machine, it is usually a requirement that they share the same backend technology. This requirement is fully met by mechanisms which utilize backend authentication technology directly and is Newman [Page 3] Internet Draft The Mandatory Authentication Problem April 1998 partially met when a mechanism is combined with a way to gracefully transition from a legacy backend technology. Scalability and Performance Should be suitable for use on a highly loaded server. DISCUSSION: If authentication becomes the limiting factor on the scalability of a service on a single server, then the server vendor will likely offer a simpler mechanism in order to improve scalability and customers may disable the slower mechanism to increase capacity. The following characteristics are not requirements, but are highly desirable features: No Plain-text Equivalent Verifiers Plain-text equivalent verifiers are undesirable. DISCUSSION: Plain-text equivalent verifiers are a serious security flaw on servers which allow interactive login by average users (the percentage of servers in this class is falling, but is still significant). In addition, customers may be reluctant to replace current plain-text password systems with a plain-text equivalent system on the grounds it sacrifices server security for wire security. Integrity Protection Mutual authentication and session integrity protection are highly desirable for the longer term. DISCUSSION: Although it is not currently a requirement by the majority of users or by the IESG, it will soon be necessary to have session integrity protection available to reduce the harm that TCP session hijacking can cause. A mandatory-to-implement mechanism without this as an optional feature will have a limited lifetime. 4. Simple Taxonomy of Authentication Mechanisms Here is a simple taxonomy of authentication mechanisms which is helpful for studying the solution space of this problem. Lightweight A lightweight authentication mechanism is any mechanism which requires no more than a cryptographic hash function such as MD5 and basic operations. This class of mechanism is most popular with client vendors and has been widely used in recent IETF protocols due to the simplicity requirement. Newman [Page 4] Internet Draft The Mandatory Authentication Problem April 1998 Backwards Compatible A backwards compatible mechanism results in the server gaining access to the user's password for verification against an arbitrary authentication database. This class of mechanism is most popular with server vendors and is necessary to support servers which use operating system authentication services and sites which have a significant investment in any existing authentication backend technology. Strong A mechanism is strong (in this taxonomy) if it is not subject to any form of passive attack (including dictionary attack), provides mutual authentication and session integrity protection, and does not grant the server the ability to impersonate the user to other servers. It should be clear that deployability requires the default mandatory-to-implement mechanism be selected from one of the first two classes. Otherwise the IETF's decision is likely to be ignored by the majority of client and server vendors. 5. Candidates Available Today There is no candidate from the "backwards compatibility" class on the standards track today. The following mechanism from the "lightweight" class is the only general-purpose mechanism close to meeting the requirements that's currently standards track: CRAM-MD5 This uses a simple challenge response model and the HMAC-MD5 algorithm. One IMAP client/server vendor claims 90% of his customers have switched from plain-text to CRAM-MD5. CRAM-MD5 meets all the requirements except the backwards compatibility requirement (which can be partially addressed by making the transition from plain-text backends graceful). However, CRAM-MD5 has plain-text equivalent verifiers and has a limited lifetime due to the lack of a session integrity protection feature. A work-in-progress called SCRAM-MD5 suggests a way to upgrade CRAM-MD5 to provide session integrity and reduce the plain-text equivalence problem. 6. Candidates Available Soon Two candidates will be available soon, one from the backwards compatible class and one from the lightweight class: passwords under TLS Newman [Page 5] Internet Draft The Mandatory Authentication Problem April 1998 TLS [TLS] will soon be standards track (pending completion of PKIX part 1). Use of plain-text passwords under a TLS layer qualifies as a backwards compatible mechanism. Unfortunately, this is also a very complex mechanism. Following all the normative references (references necessary to write an implementation from scratch) results in hundreds of pages of dense specification. This makes TLS fail the "simplicity" requirement. The mandatory-to-implement TLS cipher suite is also rather slow which makes it a poor choice from the "scalability and performance" perspective. In addition, deployment experience with SSL indicates that export-crippled technology gets more widely deployed with this usage model than full-strength encryption. It is undesirable for this trend to continue. OTP This uses the iterated hash function model. Although OTP [OTP] has never been formally integrated into another protocol specification, the SASL mechanism work necessary to do so is nearing completion [OTP-SASL]. OTP doesn't have CRAM-MD5's plain-text equivalence problem, but it requires the server to update the authentication database with each connection, which could cause scaling problems for any disk I/O bound servers. OTP has no session integrity protection feature, so OTP would have a limited lifetime as a mandatory-to-implement mechanism. 7. Candidates in Internet Drafts At least three candidates are in Internet drafts. PASSDSS This [PASSDSS] is a relatively simple mechanism from the backwards-compatible class. It was first available as an Internet draft in January and was reviewed privately for a couple months prior. It uses secure-shell technology under SASL for simple integration. The specification including all normative references is probably under 100 pages. The current version fails the "scalability and performance" requirement because it lacks session key caching. Otherwise the specification is complete and an experimental implementation exists. El-gamal password An El-gamal password-based mechanism [ELGAMAL-AUTH] was proposed in an Internet draft in February. The mechanism is also from the backwards-compatible class and should be a bit faster and simpler than PASSDSS, but it needs a lot of specification refinement. It also has similar problems meeting the scalability and performance requirement. It is Newman [Page 6] Internet Draft The Mandatory Authentication Problem April 1998 likely to take some time and effort for this to be precisely specified. SCRAM-MD5 The SCRAM-MD5 mechanism [SCRAM-MD5] is from the lightweight class and is designed as an upgrade to CRAM-MD5 with fewer drawbacks and more features. This proposal was first mentioned on a mailing list last June and was first published as an Internet draft in September. The current specification is complete and experimental implementations exist. As these candidates are individual submissions, they are unlikely to move forward in the current IETF political climate without active assistance from IETF leadership or a working group. 8. Suggested Actions for the IETF Regardless of what mechanism is selected as the default mandatory-to-implement mechanism, there will always be exceptions requiring something else. In addition, real-world customers are likely to demand mechanisms from all three classes for different situations. The IETF should continue to standardize mechanisms from all three classes which maximally meet the requirements above. There are two ways this problem could be addressed. Either the IAB deliberates on the problem and makes a recommendation for a solution to the IETF, or a WG is formed to refine this problem statement and adopt the most promising candidate solution if necessary. A previous BOF on this topic (AAARG) resulted in failure which may have been due to a lack of understanding, conflicting personalities, the difficulty of the problem, or a combination thereof. The IAB path would be faster and if the IAB recommendation fails to achieve IETF rough concensus, the WG option remains an alternative. 9. Out of Scope Issues IP-level security [IPAUTH, IPESP] is out-of-scope for this problem because support for IP-level security must be widely deployed by TCP stack vendors before it is viable to most vendors of higher-level protocols. Object-level security [MIME-SEC] is out-of-scope for this problem because it is a different layer. The IETF is currently developing two candidates to address the simpler, but related problem at that level. Connection privacy issues are complex and would detract from the Newman [Page 7] Internet Draft The Mandatory Authentication Problem April 1998 immediate authentication problem. Thus they are out-of-scope. Mechanisms designed for use by a single protocol are out-of-scope as they do not address the general problem. 10. References [ACAP] Newman, Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, Innosoft, Netscape, November 1997. [CHAP] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, DayDreamer, August 1996. [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, MCI, September 1997. [ELGAMAL-AUTH] Overell, P., "ROAMING-ELGAMAL SASL Authentication Mechanism", Work in Progress. [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, January 1997. [HTTP-DIGEST] Franks, Hallam-Baker, Hostetler, Leach, Luotonen, Sink, Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, Northwestern University, CERN, Spyglass, Microsoft, Netscape, Open Market, January 1997. [IAB-SEC] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, AT&T Labs Research, April 1998. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [IPAUTH] Atkinson, "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995. [IPESP] Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, Naval Research Laboratory, August 1995. [LDAPv3] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, Critical Angle Inc., Netscape Communications Corp, Isode Limited, December 1997. [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted Information Systems, CyberCash, Innosoft International, October 1995. Newman [Page 8] Internet Draft The Mandatory Authentication Problem April 1998 [PASSDSS] Newman, "DSS Secured Password Authentication Mechanism", Work in progress. [OTP] Haller, Metz, Nesser, Straw, "A One-Time Password System", RFC 2289, Bellcore, Kaman Sciences Corporation, Nesser & Nesser Consulting, February 1998. [OTP-SASL] Newman, "One Time Password SASL Mechanism", Work in progress. [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC 2222, Netscape Communications, October 1997. [SCRAM-MD5] Newman, "Salted Challenge Response Authentication Mechanism (SCRAM)", Work in progress. [SNMPv3-USM] Blumenthal, U., Wijnen, B., "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in progress. 11. Author's Address Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman [Page 9]