idnits 2.17.1 draft-newman-auth-mandatory-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1998) is 9508 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'LDAPv3' on line 380 looks like a reference -- Missing reference section? 'IMAP4' on line 371 looks like a reference -- Missing reference section? 'IAB-SEC' on line 368 looks like a reference -- Missing reference section? 'HTTP' on line 359 looks like a reference -- Missing reference section? 'POP3' on line 397 looks like a reference -- Missing reference section? 'CHAP' on line 350 looks like a reference -- Missing reference section? 'SNMPv3-USM' on line 406 looks like a reference -- Missing reference section? 'TLS' on line 410 looks like a reference -- Missing reference section? 'OTP' on line 391 looks like a reference -- Missing reference section? 'OTP-SASL' on line 395 looks like a reference -- Missing reference section? 'PASSDSS' on line 388 looks like a reference -- Missing reference section? 'ELGAMAL-AUTH' on line 356 looks like a reference -- Missing reference section? 'SCRAM-MD5' on line 403 looks like a reference -- Missing reference section? 'IPAUTH' on line 374 looks like a reference -- Missing reference section? 'IPESP' on line 377 looks like a reference -- Missing reference section? 'MIME-SEC' on line 384 looks like a reference -- Missing reference section? 'ACAP' on line 347 looks like a reference -- Missing reference section? 'CRAM-MD5' on line 353 looks like a reference -- Missing reference section? 'HTTP-DIGEST' on line 363 looks like a reference -- Missing reference section? 'SASL' on line 400 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft Innosoft 4 Document: draft-newman-auth-mandatory-00.txt April 1998 5 Expires in six months 7 The Mandatory-to-Implement Authentication Problem 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 This memo defines the ``mandatory-to-implement authentication 32 mechanism'' problem (at the per-TCP-connection level), describes 33 the requirements necessary for a solution, and identifies the 34 mechanisms which meet a significant subset of the requirements. It 35 is hoped this will help the IETF come to an understanding of the 36 problem and a rough consensus on a solution. 38 1. The Mandatory-To-Implement Problem 40 Almost every IETF protocol needs authentication. In order for a 41 randomly selected client and server pair to interoperate, there 42 must be a mandatory-to-implement authentication mechanism (not 43 necessarily mandatory to use). It is desirable that as many 44 protocols as possible use the same mandatory-to-implement 45 authentication mechanism as this reduces complexity for an Internet 46 host with multiple services. Finally, there is a strong consensus 47 in the IETF that plain-text passwords over an unencrypted channel 48 are no longer acceptable for this purpose. 50 We need to select a default mandatory-to-implement authentication 51 mechanism for protocols above the TCP layer which will be used 52 unless special circumstances or threats on a particular protocol 53 dictate otherwise. This is most urgent for the LDAPv3 [LDAPv3] 54 protocol, but IMAP [IMAP4] and other protocols will likely follow 55 soon. If this decision continues to be deferred, it will continue 56 to delay forward progress in the applications area and other areas 57 and cause more non-interoperable digest-based authentication 58 mechanisms to be deployed. 60 This problem is not addressed by the IAB security workshop report 61 [IAB-SEC], other than to reinforce the first requirement below. 63 2. Current Practice in the Field 65 To this date and for the foreseeable future, most IETF protocols in 66 the field require the implementation of unencrypted plain-text 67 passwords for interoperable authentication. There is a strong 68 consensus in the IETF that this is no longer acceptable. 70 The HTTP [HTTP] protocol has reached a point where clients need to 71 implement an additional security mechanism in order to access a 72 large number of useful services. This mechanism is an SSL security 73 layer using RSA and RC4 with a 40-bit key. Due to the Danvers 74 doctrine (relating to 40-bit), IETF policy (relating to trade 75 secrets) and the Munich decision (relating to patented public key 76 technology), such a solution is completely unacceptable for 77 standardization. 79 Some limited success has been achieved deploying APOP [POP3], CHAP 80 [CHAP] and CRAM-MD5 (simple hash-based challenge response 81 protocols). Mechanisms of this class have already been added to 82 many IETF protocols (POP3, HTTP, PPP, SNMPv3 [SNMPv3-USM], ACAP), 83 although most of these variants are incompatible with each other on 84 the server side unless the server stores the user's plain-text 85 password. 87 A few other mechanisms have achieved limited success at sites with 88 skilled technical staff or sites where users tolerate inconvenient 89 requirements from computing staff. 91 3. Requirements for a Mandatory-to-Implement Mechanism 93 No mechanism can meet all these requirements completely and 94 different people in the IETF will have different opinions about the 95 relative importance of these requirements. However, it is assumed 96 the IETF has a common goal of getting mechanisms superior to 97 unencrypted plain-text passwords widely deployed in the real world. 99 This common goal can guide us through the engineering tradeoffs 100 which must be made. 102 No Passwords on Unencrypted Channels 103 Must not use passwords on unencrypted channels becuase they 104 are susceptible to passive eavesdropping and replay attacks. 106 Follow IETF Doctrine 107 Must not use patented technology, trade secret technology or 108 export-crippled technology. 110 Simplicity 111 Must not be more complex than the protocol it is serving. 113 DISCUSSION: Software vendors are trying to sell a specific 114 product rather than an authentication service. An 115 authentication mechanism which is more complicated than the 116 primary goal of the software vendor is likely to be ignored 117 for practical commercial reasons. Software vendors also need 118 to understand the code and services they use well enough to 119 provide technical support and bug fixes, thus freely available 120 libraries only partially address this requirement. 122 No Mandatory External Services 123 Must not require the presence of an external authentication 124 server or service. 126 DISCUSSION: Vendors who market a single service usually need a 127 "plug-and-play" installation and some are forbidden by 128 philosophy, policy or charter to bundle external servers. A 129 mechanism which requires an external authentication server is 130 unlikely to be used by default from such vendors and thus 131 would be counter-productive as a mandatory-to-implement 132 mechanism. A mechanism which can take advantage of an 133 external server or service when present, but works fine 134 without one is acceptable and likely desirable. 136 Backwards Compatibility 137 Must interoperate with deployed password-based authentication 138 infrastructures. 140 DISCUSSION: Server vendors and customers usually have an 141 investment in authentication backend technology. Many rely on 142 the technology offered by operating system services. If 143 servers from multiple vendors are run on the same machine, it 144 is usually a requirement that they share the same backend 145 technology. This requirement is fully met by mechanisms which 146 utilize backend authentication technology directly and is 147 partially met when a mechanism is combined with a way to 148 gracefully transition from a legacy backend technology. 150 Scalability and Performance 151 Should be suitable for use on a highly loaded server. 153 DISCUSSION: If authentication becomes the limiting factor on 154 the scalability of a service on a single server, then the 155 server vendor will likely offer a simpler mechanism in order 156 to improve scalability and customers may disable the slower 157 mechanism to increase capacity. 159 The following characteristics are not requirements, but are highly 160 desirable features: 162 No Plain-text Equivalent Verifiers 163 Plain-text equivalent verifiers are undesirable. 165 DISCUSSION: Plain-text equivalent verifiers are a serious 166 security flaw on servers which allow interactive login by 167 average users (the percentage of servers in this class is 168 falling, but is still significant). In addition, customers 169 may be reluctant to replace current plain-text password 170 systems with a plain-text equivalent system on the grounds it 171 sacrifices server security for wire security. 173 Integrity Protection 174 Mutual authentication and session integrity protection are 175 highly desirable for the longer term. 177 DISCUSSION: Although it is not currently a requirement by the 178 majority of users or by the IESG, it will soon be necessary to 179 have session integrity protection available to reduce the harm 180 that TCP session hijacking can cause. A 181 mandatory-to-implement mechanism without this as an optional 182 feature will have a limited lifetime. 184 4. Simple Taxonomy of Authentication Mechanisms 186 Here is a simple taxonomy of authentication mechanisms which is 187 helpful for studying the solution space of this problem. 189 Lightweight 190 A lightweight authentication mechanism is any mechanism which 191 requires no more than a cryptographic hash function such as 192 MD5 and basic operations. This class of mechanism is most 193 popular with client vendors and has been widely used in recent 194 IETF protocols due to the simplicity requirement. 196 Backwards Compatible 197 A backwards compatible mechanism results in the server gaining 198 access to the user's password for verification against an 199 arbitrary authentication database. This class of mechanism is 200 most popular with server vendors and is necessary to support 201 servers which use operating system authentication services and 202 sites which have a significant investment in any existing 203 authentication backend technology. 205 Strong 206 A mechanism is strong (in this taxonomy) if it is not subject 207 to any form of passive attack (including dictionary attack), 208 provides mutual authentication and session integrity 209 protection, and does not grant the server the ability to 210 impersonate the user to other servers. 212 It should be clear that deployability requires the default 213 mandatory-to-implement mechanism be selected from one of the first 214 two classes. Otherwise the IETF's decision is likely to be ignored 215 by the majority of client and server vendors. 217 5. Candidates Available Today 219 There is no candidate from the "backwards compatibility" class on 220 the standards track today. The following mechanism from the 221 "lightweight" class is the only general-purpose mechanism close to 222 meeting the requirements that's currently standards track: 224 CRAM-MD5 225 This uses a simple challenge response model and the HMAC-MD5 226 algorithm. One IMAP client/server vendor claims 90% of his 227 customers have switched from plain-text to CRAM-MD5. CRAM-MD5 228 meets all the requirements except the backwards compatibility 229 requirement (which can be partially addressed by making the 230 transition from plain-text backends graceful). 232 However, CRAM-MD5 has plain-text equivalent verifiers and has 233 a limited lifetime due to the lack of a session integrity 234 protection feature. A work-in-progress called SCRAM-MD5 235 suggests a way to upgrade CRAM-MD5 to provide session 236 integrity and reduce the plain-text equivalence problem. 238 6. Candidates Available Soon 240 Two candidates will be available soon, one from the backwards 241 compatible class and one from the lightweight class: 243 passwords under TLS 244 TLS [TLS] will soon be standards track (pending completion of 245 PKIX part 1). Use of plain-text passwords under a TLS layer 246 qualifies as a backwards compatible mechanism. Unfortunately, 247 this is also a very complex mechanism. Following all the 248 normative references (references necessary to write an 249 implementation from scratch) results in hundreds of pages of 250 dense specification. This makes TLS fail the "simplicity" 251 requirement. The mandatory-to-implement TLS cipher suite is 252 also rather slow which makes it a poor choice from the 253 "scalability and performance" perspective. In addition, 254 deployment experience with SSL indicates that export-crippled 255 technology gets more widely deployed with this usage model 256 than full-strength encryption. It is undesirable for this 257 trend to continue. 259 OTP This uses the iterated hash function model. Although OTP 260 [OTP] has never been formally integrated into another protocol 261 specification, the SASL mechanism work necessary to do so is 262 nearing completion [OTP-SASL]. OTP doesn't have CRAM-MD5's 263 plain-text equivalence problem, but it requires the server to 264 update the authentication database with each connection, which 265 could cause scaling problems for any disk I/O bound servers. 266 OTP has no session integrity protection feature, so OTP would 267 have a limited lifetime as a mandatory-to-implement mechanism. 269 7. Candidates in Internet Drafts 271 At least three candidates are in Internet drafts. 273 PASSDSS 274 This [PASSDSS] is a relatively simple mechanism from the 275 backwards-compatible class. It was first available as an 276 Internet draft in January and was reviewed privately for a 277 couple months prior. It uses secure-shell technology under 278 SASL for simple integration. The specification including all 279 normative references is probably under 100 pages. The current 280 version fails the "scalability and performance" requirement 281 because it lacks session key caching. Otherwise the 282 specification is complete and an experimental implementation 283 exists. 285 El-gamal password 286 An El-gamal password-based mechanism [ELGAMAL-AUTH] was 287 proposed in an Internet draft in February. The mechanism is 288 also from the backwards-compatible class and should be a bit 289 faster and simpler than PASSDSS, but it needs a lot of 290 specification refinement. It also has similar problems 291 meeting the scalability and performance requirement. It is 292 likely to take some time and effort for this to be precisely 293 specified. 295 SCRAM-MD5 296 The SCRAM-MD5 mechanism [SCRAM-MD5] is from the lightweight 297 class and is designed as an upgrade to CRAM-MD5 with fewer 298 drawbacks and more features. This proposal was first 299 mentioned on a mailing list last June and was first published 300 as an Internet draft in September. The current specification 301 is complete and experimental implementations exist. 303 As these candidates are individual submissions, they are unlikely 304 to move forward in the current IETF political climate without 305 active assistance from IETF leadership or a working group. 307 8. Suggested Actions for the IETF 309 Regardless of what mechanism is selected as the default 310 mandatory-to-implement mechanism, there will always be exceptions 311 requiring something else. In addition, real-world customers are 312 likely to demand mechanisms from all three classes for different 313 situations. The IETF should continue to standardize mechanisms 314 from all three classes which maximally meet the requirements above. 316 There are two ways this problem could be addressed. Either the IAB 317 deliberates on the problem and makes a recommendation for a 318 solution to the IETF, or a WG is formed to refine this problem 319 statement and adopt the most promising candidate solution if 320 necessary. A previous BOF on this topic (AAARG) resulted in 321 failure which may have been due to a lack of understanding, 322 conflicting personalities, the difficulty of the problem, or a 323 combination thereof. The IAB path would be faster and if the IAB 324 recommendation fails to achieve IETF rough concensus, the WG option 325 remains an alternative. 327 9. Out of Scope Issues 329 IP-level security [IPAUTH, IPESP] is out-of-scope for this problem 330 because support for IP-level security must be widely deployed by 331 TCP stack vendors before it is viable to most vendors of 332 higher-level protocols. 334 Object-level security [MIME-SEC] is out-of-scope for this problem 335 because it is a different layer. The IETF is currently developing 336 two candidates to address the simpler, but related problem at that 337 level. 339 Connection privacy issues are complex and would detract from the 340 immediate authentication problem. Thus they are out-of-scope. 342 Mechanisms designed for use by a single protocol are out-of-scope 343 as they do not address the general problem. 345 10. References 347 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 348 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 350 [CHAP] Simpson, W., "PPP Challenge Handshake Authentication Protocol 351 (CHAP)", RFC 1994, DayDreamer, August 1996. 353 [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 354 for Simple Challenge/Response", RFC 2195, MCI, September 1997. 356 [ELGAMAL-AUTH] Overell, P., "ROAMING-ELGAMAL SASL Authentication 357 Mechanism", Work in Progress. 359 [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext 360 Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, 361 MIT/LCS, January 1997. 363 [HTTP-DIGEST] Franks, Hallam-Baker, Hostetler, Leach, Luotonen, Sink, 364 Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 365 2069, Northwestern University, CERN, Spyglass, Microsoft, Netscape, 366 Open Market, January 1997. 368 [IAB-SEC] Bellovin, S., "Report of the IAB Security Architecture 369 Workshop", RFC 2316, AT&T Labs Research, April 1998. 371 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", 372 RFC 2060, University of Washington, December 1996. 374 [IPAUTH] Atkinson, "IP Authentication Header", RFC 1826, Naval 375 Research Laboratory, August 1995. 377 [IPESP] Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827, 378 Naval Research Laboratory, August 1995. 380 [LDAPv3] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access 381 Protocol (v3)", RFC 2251, Critical Angle Inc., Netscape Communications 382 Corp, Isode Limited, December 1997. 384 [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for 385 MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted 386 Information Systems, CyberCash, Innosoft International, October 1995. 388 [PASSDSS] Newman, "DSS Secured Password Authentication Mechanism", 389 Work in progress. 391 [OTP] Haller, Metz, Nesser, Straw, "A One-Time Password System", RFC 392 2289, Bellcore, Kaman Sciences Corporation, Nesser & Nesser 393 Consulting, February 1998. 395 [OTP-SASL] Newman, "One Time Password SASL Mechanism", Work in progress. 397 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 398 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 400 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC 401 2222, Netscape Communications, October 1997. 403 [SCRAM-MD5] Newman, "Salted Challenge Response Authentication 404 Mechanism (SCRAM)", Work in progress. 406 [SNMPv3-USM] Blumenthal, U., Wijnen, B., "User-based Security Model 407 (USM) for version 3 of the Simple Network Management Protocol 408 (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. 410 [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in progress. 412 11. Author's Address 414 Chris Newman 415 Innosoft International, Inc. 416 1050 Lakes Drive 417 West Covina, CA 91790 USA 419 Email: chris.newman@innosoft.com