[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]