idnits 2.17.00 (12 Aug 2021) /tmp/idnits19046/draft-rescorla-auth-mech-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 Abstract 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 787: '...ich uses this mechanism MUST specify a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 596 has weird spacing: '...y using a...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'REF' is mentioned on line 1424, but not defined -- Looks like a reference, but probably isn't: '0' on line 320 == Missing Reference: 'RFC822' is mentioned on line 501, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RFC 2109' is mentioned on line 876, but not defined ** Obsolete undefined reference: RFC 2109 (Obsoleted by RFC 2965) == Missing Reference: 'RFC 2808' is mentioned on line 1034, but not defined == Missing Reference: 'RFC 2831' is mentioned on line 1035, but not defined ** Obsolete undefined reference: RFC 2831 (Obsoleted by RFC 6331) -- Possible downref: Non-RFC (?) normative reference: ref. 'TODO' Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 E. Rescorla 3 INTERNET-DRAFT RTFM, Inc. 4 March 2003 (Expires September 2002) 6 A Survey of Authentication Mechanisms 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 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 months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 1. Introduction 29 Authentication is perhaps the most basic security problem for design- 30 ers of network protocols. Even the early Internet protocols such as 31 TELNET and FTP, which provided no other security services, made pro- 32 vision for user authentication. Unfortunately, these early authenti- 33 cation systems were wholly inadequate for the Internet Threat Model 34 [REF] and a vast array of other authentication mechanisms have been 35 introduced in an attempt to close these holes. 37 The most striking thing about these security mechanisms is how many 38 of them are essentially similar. There are only 7 basic classes of 39 authentication protocol but there are a large number of slightly dif- 40 ferent protocols with essentially the same security properties. This 41 memo surveys the space of authentication mechanisms, describes the 42 basic classes and provides examples of protocols which fit into each 43 class. 45 2. The Authentication Problem 47 The authentication problem is simple to describe but hard to solve: 48 Two parties are communicating and one wishes to establish its iden- 49 tity to another. The basic scenario is exemplified by TELNET. A 50 client (on behalf of a user) wishes to remotely access resources on a 51 TELNET server. The user has an account on the server and the server 52 remembers the user's authentication information but the client itself 53 may have no long-term storage and only limited computational capabil- 54 ities. The client side of the credentials must be able to be carried 55 by the user, either on a small device or in his memory. 57 2.1. Authorization vs. Authentication 59 AUTHORIZATION is the process by which one determines whether an 60 authenticated party has permission to access a particular resource or 61 service. Although tightly bound, it is important to realize that 62 authentication and authorization are two separate mechanisms. Perhaps 63 because of this tight coupling, authentication is sometimes mistak- 64 enly thought to imply authorization. Authentication simply identifies 65 a party, authorization defines whether they can perform a certain 66 action. 68 Authorization necessarily relies on authentication, but authentica- 69 tion alone does not imply authorization. Rather, before granting per- 70 mission to perform an action, the authorization mechanism must be 71 consulted to determine whether that action is permitted. This docu- 72 ment is solely concerned with authentication. 74 2.2. Standard Material Something you have, something you know... 76 [TODO] 78 3. Description of Authentication Mechanisms 80 The next seven sections each describe a single class of authentica- 81 tion technology. In each case, we first describe the technology in 82 general, with possible subsections describing security or implementa- 83 tion issues that are generic to this technology. Once we have 84 described the technology in general we then provide one or more case 85 studies: descriptions of specific protocols which use this authenti- 86 cation technology and the various security or implementation issues 87 that are specific to that protocol. Thus, each section follows the 88 following pattern. 90 A Mechanism 91 (Description) 92 A.x risk 93 (description and countermeasures) 94 A.y risk 95 (description and countermeasures) 96 A.z Case Study: Specific Protocol 97 (description of the protocol) 98 A.z.x Protocol Specific problems. 99 A.w List of Protocols/Systems tha use this mechanism 101 4. Passwords In The Clear 103 The most commonly used form of authentication is for the client to 104 provide a username/password pair to the server in the clear (e.g. 105 over a TCP channel). The server then verifies the password against 106 the user's stored credentials. If they match, the server allows the 107 client to access the resource. 109 The most primitive approach is for the server to simply store the 110 user's username and password in a file on the server's disk. This has 111 the serious problem that if the password file is somehow compromised, 112 the attacker has immediate access to all user passwords and can log 113 in as any user. The standard approach, first used by XXX, is to store 114 a message digest of the password instead of the password itself. When 115 the server needs to verify a password, it digests the password and 116 compares the digest against the stored digest. Since a message digest 117 is used, the server cannot recover the user's password from the pass- 118 word file. 120 4.1. Password Sniffing 122 The simplest attack against passwords in the clear is simple password 123 sniffing. The attacker arranges to intercept traffic between the 124 client and the server (this is relatively easy, especially if the 125 attacker is on the same network as one of the endpoints). Since the 126 password traverses the network in the clear, the attacker is easily 127 able to recover the password and can use it for any future authenti- 128 cations. 130 4.2. Post-Authentication Hijacking 132 An attacker who can hijack network connections need not know the 133 user's password at all. He can simply wait for the user to complete 134 his authentication and then take over the connection. This attack is 135 more difficult to mount than password sniffing, but as we'll see 136 later, it can be useful when stronger authentication schemes are 137 employed. 139 4.3. Online Password Guessing 141 Extensive experience [REF] shows that users choose bad passwords. 142 Common choices include the user's real name, login name, date of 143 birth, and simple dictionary words. An attacker with no special capa- 144 bilities can therefore attack a server by simply trying known or com- 145 mon usernames and common passwords. This technique was used to great 146 effect by the Morris worm [REF]. 148 The standard countermeasure to this attack is to make it difficult 149 for the attacker to try a large number of passwords. This can be done 150 by incorporating a LIMITED TRY capability. After some number of 151 failed attempts, the system simply locks the account and the user 152 cannot log in even with the correct password. Unfortunately, simple 153 limited try provides the attacker with an easy denial-of-service 154 (DoS) attack--he can lock any account simply by performing failed 155 logins. 157 A superior approach is to incorporate a delay. For instance, the sys- 158 tem might allow the user to immediately try 3 passwords, but after 159 three failures lock the account for 10 seconds, increasing the delay 160 (up to some fixed maximum) for each failure. This is a less effective 161 countermeasure than simple LIMITED TRY but resists the DoS attack 162 better. 164 4.4. Offline Dictionary Attack 166 Even if digested password files are used, it still often possible for 167 an attacker who recovers the password file to discover user's pass- 168 words. The attacker can mount an OFFLINE DICTIONARY ATTACK on the 169 password file. A dictionary attack uses the fact that users tend to 170 choose words rather than random strings in order to narrow the scope 171 of exhaustive search. The attacker simply runs through each word (and 172 common variations) in sequence, comparing the digest of the trial 173 word against the digest in the password file. There are a number of 174 programs available to mount this sort of attack, including [REF]. 176 4.4.1. Shadow Passwords 178 There are four basic countermeasures to offline dictionary attack. 179 The first is to deny attackers the password digest. In the original 180 UNIX systems, reading the password file was the only way to get 181 information about users and therefore the password file had to be 182 publicly readable. Later systems introduced SHADOW PASSWORDS, whereby 183 the password file contained a dummy password and a second copy of the 184 password file containing the encrypted passwords was unreadable 185 except to root. Thus, unprivileged user processes would consult the 186 ordinary password file (now containing dummy passwords) to get user 187 information (such as name, home directory, etc) but only privileged 188 processes can read the encrypted passwords. Of course, sometimes an 189 attacker can convince a privileged process (via bugs) to give him a 190 copy of the file, thus allowing him to attack it. 192 4.4.2. Iteration 194 The second type of countermeasure is to make search slower. One 195 approach is to simply make the hash function slower. The original 196 UNIX crypt() function did this by repeating the basic operation 197 (based on DES) 25 times. (The designers also slightly modified the 198 operation so that it couldn't be done with ordinary DES hardware.) 199 The idea here is that noone will notice a second or so delay on login 200 but that making each guess take a second will seriously slow down an 201 attacker. To compensate for the speed of modern computers, rather 202 more iterations are currently required each year. 204 4.4.3. Salting 206 If a simple hash of the password is stored in the password file, then 207 an attacker can attack all the passwords in the file in parallel. He 208 simply generates the hash of each candidate and then compares it 209 against each stored hash. In order to prevent this attack, many sys- 210 tems SALT the hash with some random value (which is different for 211 each user). Thus, instead of storing simply H(password) they store 212 salt || H(salt || password), with the result that even two users who 213 have the same password will in general not have the same stored pass- 214 word hash. One interesting innovation is to use a secret salt. This 215 requires the attacker to try all possible salts, automatically slow- 216 ing down the process (thereby making iteration unnecessary). 218 4.4.4. Stronger Passwords 220 The reason that dictionary attacks are so easy is that users choose 221 bad passwords. Even the 8 character UNIX password space allows 2^56 222 possible passwords--a search space that is impractical for most 223 attackers to search. One obvious countermeasure is to force users to 224 choose good passwords. This can be done reactively by running a pass- 225 word cracker on your system or proactively by forcing users to use 226 good passwords when they set them. It's also possible to force users 227 to use randomly generated passwords. Unfortunately, unguessable pass- 228 words are often less memorable, causing users to write them down. 229 It's not clear that this is an improvement. Security-conscious people 230 are often willing to use complex mnemonics to help remember random 231 passwords but ordinary users are not. One welcome innovation on this 232 front is the replacement of the old UNIX DES-based crypt() function 233 with an MD5-based function that accepts longer passwords, allowing 234 the user to have a meaningful but still harder to guess password. 236 4.5. Case Study: HTTP Basic Authentication 238 HTTP basic authentication [REF] is the original HTTP authentication 239 mechanism. It's a simple username/password scheme. The server prompts 240 the client with a request for authentication (in a WWW-Authenticate 241 header). The client responds with the password in an Authorization 242 header. The password is base-64 encoded but this doesn't provide any 243 security, just protection from damage in transport. 245 4.5.1. Password Caching 247 Any reasonable Web page fetch consists of a number of HTTP fetches, 248 each of which may requires HTTP authentication. Requiring the user to 249 type in his password for each such fetch would be prohibitively 250 intrusive. Accordingly, web clients typically cache the user's pass- 251 word for some time (generally for the lifetime of the browser pro- 252 cess.) 254 In some cases, the browser will cache password on disk so that the 255 user never has to type in the password again. This practice intro- 256 duces a new security problem: protection of the user's cached pass- 257 words. These passwords can be encrypted on disk (under another pass- 258 word) but users often find this inconvenient and so the passwords are 259 often stored on the disk in the clear. This is dangerous on multi- 260 user machines, even ones which provide strong file permissions, since 261 administrators can still read such cache files. 263 4.5.2. Pro-active authentication 265 Requesting a page, receiving an authentication challenge and re- 266 requesting with a password introduces an extra round-trip. This 267 latency can be quite significant if the original request was large, 268 such as with a file PUT. Thus, many clients pro-actively send their 269 cached passwords whenever accessing any URL deeper than the URL for 270 which they were originally prompted. 272 4.6. List of Systems that Use Passwords in the Clear 274 TELNET 275 HTTP (basic authentication) 276 SASL (password mode) 277 RLOGIN 278 POP (among others) 279 IMAP (among others) 280 (too many others to mention) 282 5. One Time Passwords 284 The simplest approach to preventing sniffing attacks on passwords is 285 to use ONE TIME PASSWORDS. In it's basic form, the user is provided 286 with a list of passwords, each of which can only be used once, making 287 replay attack impossible. The passwords are still transmitted in the 288 clear, but since each one can only be used once, a sniffed password 289 cannot be used as an authenticator. 291 The major use of one-time password systems is to improve the security 292 of protocols which previously used password authentication. One-time 293 password schemes can be designed such that they require no changes to 294 the client software and only minimal changes to the server software. 295 The user generally needs to have either a physical password list or a 296 token that computes the password, but the client software does not 297 need to be replaced and the wire protocol is unchanged. 299 None of the one-time password schemes are very useful for automated 300 authentication, since they only provide a limited number of keys. 301 Using automated authentication with S/Key or OTP it is easy to 302 quickly use up a large number of keys. SecureID provides an essen- 303 tially infinite number of keys but they are changed too infrequently 304 to be usable in most automated systems. 306 As with ordinary passwords, one time password mechanisms are subject 307 to a number of active attacks. However, even if the attacker captures 308 a specific authenticator via an active attack, he can use it only 309 once, not indefinitely. [TODO: Are SecureID keys marked unusable so 310 they can't be used again during the 30s window? I imagine so...] 312 5.1. Case Study: S/Key and OTP 314 S/Key [REF], invented by Neil Haller and Karn, is a straightforward 315 one time password system that uses some clever implementation tricks. 316 One-Time Passwords (OTP) [REF] is the successor protocol to S/Key, 317 standardized by the IETF. In S/Key, the one time passwords are con- 318 structed by iteratively hashing a public seed and a secret. Thus: 320 P[0] = H(Seed,Secret) 321 P[i] = H(P[i-1]). 323 Passwords are used in reverse order. This allows the server to simply 324 store the last password that it received (P[i]). The client will next 325 authenticate with P[i-1]. The server can verify a password by hashing 326 it and checking to see if it matches the stored password. Once 327 authentication is complete, the server simply deletes the old pass- 328 word and stores the new one. 330 S/Key uses a special password encoding that's designed to make it 331 easy for users to type passwords without errors. The 64-bit one-time 332 password is broken up into a sequence of six 11-bit values (with the 333 remaining two bits being used as a checksum). Each 11-bit value is 334 used as an index into a fixed dictionary of 2048 short words. Thus, a 335 password might look like: 337 INCH SEA ANNE LONG AHEM TOUR 339 This encoding is intended to be easier to type than base64 or hex- 340 adecimal. (Though hexadecimal is accepted as well). 342 S/Key can be used in two modes. In the first, the client is simply 343 provided with a list of passwords on a piece of paper. He uses one at 344 a time and crosses them off as he goes. In this case, the Secret is 345 usually cryptographically random. In the second, the client has a 346 token or a computer program that he uses to calculate the appropriate 347 S/Key key. In this case, the Secret is generally some user-memorable 348 password which the user keys into the program or token. 350 S/Key scheme has a number of nice properties. First, the password 351 file need not be kept secret, since going from P[i] to P[i-1] 352 requires reversing the message digest, which is believed to be compu- 353 tationally infeasible. (Note: if a text password is used as the 354 secret then the password file is still subject to dictionary attack, 355 but a passive attacker who recovers ANY S/Key authenticator can mount 356 a dictionary attack on it (by iteratively hashing the potential 357 seed), so it's not that important to keep the password file per se 358 protected). 360 Second, it's easy for the user to rekey: He simply creates a new 361 Secret, generates a set of keys and sends the last one to the server. 362 Note that it's of course possible for an active attacker to hijack a 363 connection and rekey with a key of his choice, thus one time pass- 364 words are in general a poor choice when active attack is part of the 365 threat model. 367 5.1.1. Race Conditions 369 S/Key has an interesting security flaw: Consider a protocol where 370 passwords are transmitted one character at a time. A passive attacker 371 might wait for the victim to log in and then create his own login 372 connection at the same time. The attacker would then echo the 373 victim's password character for character, until there was only one 374 character left. At this point the attacker would simply guess the 375 last character and then complete the authentication. This attack is 376 relatively simple to mount because nearly all the words in the S/Key 377 dictionary are 4-characters long and the number of words with any 378 given 3-letter prefix is generally quite small (2 or 3). 380 The standard countermeasure to this attack is to only allow one pend- 381 ing authentication for a given user at any given time. In order to 382 prevent DoS attacks, there must be at timeout on any such pending 383 connection. OTP implementations are required to implement this or 384 some other countermeasure. 386 5.2. Case Study: SecureID 388 Probably the most commonly deployed commercial one time password 389 implementation is SecureID, sold by Security Dynamics (now part of 390 RSA Security). Instead of using a fixed list of keys, SecureID uses a 391 time-dependent key. The user has a token with an LCD displaying a 392 pseudo-random number. That number changes every 30 seconds and is 393 synchronized with an authentication server located at the server. 395 In order to authenticate the user enters both his password and the 396 time-dependent key (they can be concatenated so that this is trans- 397 parent to the client program.) The server verifies the password and 398 checks that the time-dependent key is correct for the current time 399 and only then allows login. It's clearly possible for an attacker to 400 capture the password and replay it but without the token he (theoret- 401 ically) can't generate the right time-dependent key. 403 [TODO: Talk about the algorithm being exposed and potentially compro- 404 mised]. 406 5.3. List of One-Time Password Systems 408 Note: any system that uses passwords can be adapted to use one-time 409 passwords. 411 S/Key [REF] 412 OTP [REF] 413 SecureID [REF] 415 6. Challenge/Response 417 CHALLENGE/RESPONSE mechanisms fix the sniffing problem associated 418 with ordinary passwords. The basic idea is simple: the verifying 419 party provides a random (or at least unique) challenge and the 420 authenticating party returns some function of the shared key and the 421 challenge. Generally this function is some sort of message digest. In 422 the simplest form it is H(challenge || key). A better design is prob- 423 ably to use HMAC [REF], which has stronger security guarantees. 425 Challenge/response mechanisms are resistant to simple sniffing 426 attacks but in general have all the other security problems of ordi- 427 nary password systems. Additionally, they are vulnerable to another 428 form of offline dictionary attack and are more vulnerable to password 429 file compromise than correctly implemented password in the clear sys- 430 tems. 432 Challenge/response mechanisms can be completely hardened against 433 offline dictionary attacks by the use of a sufficiently large ran- 434 domly-generated shared key instead of a password. Such a password is 435 of course difficult for a user to memorize but is quite useful if it 436 can be statically configured on both sides of a connection. 438 Unlike simple password mechanisms, challenge/response mechanisms can 439 be designed which provide both mutual authentication and secure key 440 exchange. Such systems can be made resistant to most forms of active 441 attack, and depending on the strength of the shared key, passive 442 attacks as well. 444 6.1. Offline Attacks on Challenge/Response 446 Although a passive attacker cannot mount an ordinary sniffing attack, 447 he can combine sniffing with an offline dictionary attack. The 448 attacker simply captures a single challenge/response exchange and 449 then dictionary searches the password space until he finds a password 450 that produces the correct response for a given challenge. With high 451 probability (though not certainty) this will be the correct password. 452 This problem is inherent in all simple challenge response mechanisms 453 and cannot be fixed without public-key technology. 455 6.2. Password File Compromise 457 Challenge/response mechanisms also introduce a new problem: PASSWORD 458 EQUIVALENCE. In order to locally compute (for verification purposes) 459 the appropriate response for a given challenge, the server must store 460 the user's password locally. Thus, if the password file is compro- 461 mised, the attacker can directly log in to the server, without even 462 needing to crack the password file. We'll call this property WEAK 463 PASSWORD EQUIVALENCE. 465 A more serious variant of the same problem occurs if users use the 466 same password on multiple systems. Compromise of one system can thus 467 lead to compromise of many. This is called STRONG PASSWORD EQUIVA- 468 LENCE. This risk should not be overstated--compromise of an ordinary 469 password system can still lead to attack if the attacker completely 470 compromises the system and can capture people's passwords when they 471 login--but is nevertheless worse in challenge/response than with 472 ordinary passwords. The standard countermeasure is to use a two-stage 473 digesting process, such as: 475 STORED = H(PASSWORD || SALT) 476 RESPONSE = H(STORED || CHALLENGE) 478 The server stores STORED instead of the password. (Making STORED 479 effectively the password). The server then gives the client both SALT 480 and CHALLENGE, allowing the client to compute RESPONSE from the pass- 481 word alone. Note that the two-stage process only prevents compromise 482 of one system from affecting others. Compromise of a password file 483 still allows immediate access to the target system. 485 6.3. Case Study: CRAM-MD5 487 CRAM-MD5 [REF] is a challenge/response authentication extension for 488 IMAP [REF]. CRAM-MD5 is a classic challenge/response system: the 489 server provides a presumably random challenge and the client trans- 490 mits an HMAC of the challenge using the shared key as the HMAC key. 491 The interaction looks like this: 493 1 S: * OK IMAP4 Server 494 2 C: A0001 AUTHENTICATE CRAM-MD5 495 3 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ 496 4 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 497 5 S: A0001 OK CRAM authentication successful 499 The second message from the server (message 3) is the base-64 encod- 500 ing of the string "<1896.697170952@postoffice.reston.mci.net>". This 501 string must be in the form of an RFC 822 msg-id [RFC822] and is 502 intended to be globally unique. The client's response (message 4) is 503 computed using HMAC-MD5(password,challenge) and then base-64 encoded 504 for transmission in message 4. 506 CRAM-MD5 is an improvement on the password-in-the-clear mechanisms 507 that it replaces but still has all the security flaws of basic chal- 508 lenge/response mechanisms. In particular, it is vulnerable to post- 509 authentication hijacking and is strongly password equivalent. 511 CRAM-MD5 has some interesting security properties with respect to 512 server password file compromise. The RFC encourages servers to store 513 a pre-initialized HMAC context rather than than the client's pass- 514 word. Since the password has already gone through the MD5 compression 515 function, it is believed to be infeasible to recover the password 516 from the context. However, since the HMAC context is sufficient to 517 compute any response without knowing the key, an attacker who recov- 518 ers the context can impersonate the client without knowing the key. 519 This context will be the same for all servers which share the same 520 password. The result of these facts is that an attacker who recovers 521 the password file from such a server can attack any other server 522 which (1) uses CRAM-MD5 and (2) has a user with the same password. 523 However, it cannot attack other users with the same password on 524 machines with a different authentication mechanism (since that would 525 require direct access to the password rather than the HMAC context). 527 6.4. Case Study: HTTP Digest 529 HTTP Digest Authentication [REF] is a replacement for HTTP's [REF] 530 notoriously weak Basic Authentication mechanism, which used passwords 531 in the clear. Digest Authentication is a challenge/response mechanism 532 with some additional features to prevent hijacking attacks and remove 533 strong password equivalence, as well as to reduce round trip time for 534 multiple requests. 536 The basic Digest Authentication interaction takes two round trips. In 537 the first, the client requests some document and is rejected. The 538 server's rejection (a 401 Unauthorized) contains an indication that 539 it supports Digest Authentication, a realm string, and a random chal- 540 lenge. The client's subsequent request includes a message digest over 541 the password, the challenge, and part of the HTTP Request. 543 HTTP Digest offers two types of integrity check (called "qop" for 544 quality of protection). The "auth" scheme covers only the request 545 URI. The "auth-int" scheme protects the URI and the message body, but 546 not the message headers since they may be changed in transit by prox- 547 ies or other intermediaries. Negotiation of the qop is simple: the 548 server offers a set of acceptable qop values and the client chooses 549 one. 551 6.4.1. Message Integrity 553 As previously noted, simple challenge/response schemes without asso- 554 ciated channel security allow an attacker to hijack the connection 555 after authentication has occurred. Since each HTTP request must be 556 individually authenticated, an attacker who takes over the channel 557 cannot transmit new unauthenticated requests over that channel. How- 558 ever, an attacker might attempt to intercept an authenticated request 559 and mount a cut-and-paste attack, leaving the authenticator but 560 changing the contents. This attack is prevented by including the URI 561 in the message digest. 563 Unfortunately, the URI isn't the only piece of security relevant 564 information in the HTTP request. Both the headers and the body are 565 potentially sensitive. For instance, if HTTP POST is used, FORM input 566 values will be in the message body. The auth-int qop value protects 567 this information, but it is not widely deployed. None of the qop val- 568 ues protects the headers. 570 It's worth noting that Digest provides protection only for the 571 request. No authentication is provided for the server, nor is message 572 integrity provided for the response. It's technically possible to 573 provide this feature using a shared key, as is done in S-HTTP [REF], 574 but Digest doesn't do so. 576 Digest deployment has been somewhat spotty. The popular Netscape Nav- 577 igator 4 versions do not support it, nor did Internet Explorer prior 578 to version XXX. The fact that there have recently been some reports 579 of incompatibilities between various implementations suggests that 580 only minimal testing has so far occurred. 582 6.4.2. Replay Attack 584 Many HTTP requests are idempotent. In such cases, replay attacks are 585 not a problem since the attacker doesn't get any information that he 586 would not get by sniffing the original request. However, many HTTP 587 transactions have side effects and in such cases preventing replay is 588 important. Unfortunately, the conventional approach of requiring a 589 separate challenge/response exchange for each authentication would 590 double the number of round-trips for each transaction. 592 HTTP Digest provides two features to avoid these round trips. First, 593 the server can provide a new nonce in a response header. This nonce 594 must be used for the next client request. This feature interacts 595 poorly with request pipelining so HTTP Digest also allows the client 596 to issue multiple requests using a given server challenge by using a 597 request sequence number (the "nonce-count"). [TODO: How widely is 598 this stuff implemented] 600 6.4.3. Downgrade Attack 602 HTTP Digest suffers from two types of downgrade attack. In the first 603 type of attack, the attacker forces the peers to agree on Basic 604 authentication rather than on Digest. There is no realistic way to 605 protect against this attack, other than simply refusing to accept 606 Basic at all. 608 In the second Downgrade attack, the attacker forces the peers to 609 negotiate a qop of "auth" instead of "auth-int". The downgrade attack 610 would then presumably be followed by an integrity attack on the 611 client request. This attack could be prevented by requiring the 612 client to include a digest of the server's offered qop values in the 613 client's authenticator. However, that is not the case with the cur- 614 rent scheme. 616 6.5. List of Challenge-Response Systems 618 APOP [REF] 619 ACAP [REF] 620 HTTP Digest [REF] 621 AKA [REF] 622 CRAM-MD5 [REF] 623 Kerberos [REF] 625 7. Anonymous Key Exchange 627 All three of the mechanisms mentioned so far can be hardened against 628 passive attacks by the use of anonymous key exchange. Essentially, 629 the client and server arrange for a secure channel using some anony- 630 mous public key algorithm (such as anonymous DH or RSA without cer- 631 tificates) and then carry out the same communication over that chan- 632 nel that they would previously have done in the clear. This prevents 633 a passive attacker from sniffing the password (with passwords in the 634 clear) or the authenticator (with one time passwords or chal- 635 lenge/response). (It's technically possible to just protect the pass- 636 word, but not generally done). 638 How much security you believe that anonymous key exchange adds to 639 your protocol depends on your threat model. Since the initial key 640 exchange is completely anonymous, an active attacker can mount a man- 641 in-the-middle (MITM) attack and obtain a password or authenticator. 642 Active attacks are generally more difficult to mount than passive 643 attacks but by no means impossible. [REF] 645 All of these mechanisms use public key cryptography to perform the 646 initial anonymous key exchange. As a result, performance can be unac- 647 ceptably slow if the clients are heavily constrained. Most servers 648 are fast enough to keep up with the normal number of required authen- 649 tications and hardware acceleration solutions are readily available. 651 7.1. Case Study: SSH Password Authentication 653 Secure Shell (SSH) provides a number of authentication mechanisms, 654 but the first step is always to establish a secure channel between 655 the client and the server. SSH is designed not to require certifi- 656 cates: the server merely provides a raw public key to the client. As 657 a countermeasure to man-in-the-middle attack, the SSH client caches 658 the server's public key and generates a warning or error (depending 659 on the implementation) if that key changes. 661 In theory, caching the public key protects against MITM attack at any 662 time other than the initial connection to the server. In practice, 663 when users encounter the error that the key has changed, they often 664 simply override the warning or delete the cache entry when the error 665 occurs, assuming, correctly, that the likely case is that the server 666 administrator has just reset the public key (e.g. by reinstalling the 667 software without preserving the old key). 669 A very careful user can obtain complete security against MITM attacks 670 by obtaining the server's key fingerprint (a message digest of the 671 key) out of band and comparing that to the fingerprint of the key the 672 server offers. 674 SSH bootstraps off of the system's login mechanisms so it will sup- 675 port either passwords in the clear or one time password authentica- 676 tion. Note that in either case if an attacker mounts a successful man 677 in the middle attack, he will be able to hijack the connection post- 678 authentication, just as he would have if the transaction was per- 679 formed in the clear. This vulnerability can be alleviated with care- 680 ful protocol design, as we'll see in the next case study. 682 7.2. Case Study: TLS Anonymous DH + Passwords 684 [TODO] 686 7.3. List of Anonymous Key Exchange Mechanisms 688 SSH (password mode) [REF] 689 SSL/TLS (anonymous keying) [REF] 690 ??? 692 8. Zero-Knowledge Password Proofs 694 All of the mechanisms mentioned so far depend on some sort of shared 695 key. If that shared key is a user-derived password, then it's possi- 696 ble for the attacker to mount an offline dictionary attack on the 697 password, either completely passively (as with CRAM-MD5) or with a 698 single MITM attack (as with TLS anonymous DH). However, a rather 699 clever class of protocols known as Zero Knowledge Password Proofs 700 (ZKPPs) makes it possible to use user-generated passwords without 701 fear of offline dictionary attack 703 The earliest (and simplest) ZKPP is EKE [REF], designed by Steve 704 Bellovin and James Merritt. The basic idea behind EKE is simple. A DH 705 exchange is performed but the exponentials are encrypted under the 706 password. Since the exponentials are essentially random, it's not 707 possible to dictionary attack the password. The protocol looks like 708 this: 710 Client Server 711 ------ ------ 712 Name, E(Password, Ya)) -> 713 <- E(Password, Yb),E(K,Challenge-b) 714 E(K,Challenge-a || Challenge-b) -> 715 <- E(K, Challenge-a) 717 Where K is the DH shared secret == g(Xa * Xb) mod p 719 Note that EKE as described above is insecure against password file 720 compromise, since the server must store the password. Augmented EKE 721 [REF] describes a protocol that is secure against this. A large num- 722 ber of other ZKPPs have been proposed, including PDM [REF], SPEKE 723 [REF], and SRP[REF]. These protocols are all roughly equivalent, 724 offering slightly different combinations of security, performance, 725 and message count. 727 8.1. Intellectual Property 729 From a technical perspective, ZKPPs dominate the anonymous key 730 exchange mechanisms described in Section XXX. Their performance is 731 roughly equivalent and their security guarantees are superior. Never- 732 theless, none of the ZKPPs have achieved widespread deployment. The 733 reason for this appears to be intellectual property. The original EKE 734 work was patented (as of this writing the patent is held by Lucent). 735 All of the variations are either themselves patented or claimed to be 736 covered by some patent or other. There is no ZKPP that is widely 737 agreed upon to be unencumbered or available under a royalty free 738 license. 740 8.2. List of Zero Knowledge Password Proof Systems 742 EKE [REF] 743 A-EKE [REF] 744 SPEKE [REF] 745 SRP [REF] 747 9. Server Certificates plus Client Authentication 749 If you can authenticate one side of the connection (typically the 750 server) then it becomes far easier to provide strong authentication. 751 Anonymous key exchange, cleartext passwords, one time passwords, and 752 challenge/response protocols can all run over an authenticated and 753 encrypted channel. In such a system, there's no need to worry about 754 active attack, so the authentication protocols don't need to be hard- 755 ened against it. 757 Providing an encrypted channel with authentication for the server 758 dramatically reduces the security advantage enjoyed by more compli- 759 cated schemes over simple passwords. Since the marginal security ben- 760 efit of such systems is so modest when compared to the increased 761 implementation and deployment complexity, common practice when server 762 authentication is available is to use simple passwords over the 763 encrypted channel. 765 In addition to making the overall authentication problem simpler, 766 hosting one's application protocol over an encrypted and authenti- 767 cated channel has a number of other security benefits. First, a prop- 768 erly designed channel security protocol removes the threat of post- 769 authentication hijacking (described in Section XXX). Second, it pro- 770 vides confidentiality and message integrity for the rest of the 771 application traffic, which is in general a good thing. 773 The primary difficulty with this approach is that providing 774 certificate-based server authentication is not straightforward. The 775 first problem is that the server machine must have a certificate, 776 which entails some inconvenience and cost. Self-signed certificates 777 aren't acceptable in this case (rather, they reduce you to the anony- 778 mous key exchange scenario described in Section XXX). 780 The more serious problem is establishing what the server side iden- 781 tity in the certificate ought to be. Common practice (stemming from 782 practice in HTTPS [REF]) is to have the server's certificate contain 783 the server's fully qualified domain name (FQDN), either in the Common 784 Name or subjectAltName fields, but this is unacceptable if the server 785 does not have a domain name. One can also put the server's IP address 786 in the subjectAltName, but this is inappropriate if that IP address 787 might change. Any protocol which uses this mechanism MUST specify a 788 mechanism for determining the server's expected domain name. 790 9.1. Case Study: Passwords over HTTPS 792 Despite the existence of Digest Authentication, the dominant form of 793 strong HTTP authentication is passwords with HTTP over SSL (HTTPS). 794 As mentioned above, this mechanism has superior security properties 795 to Digest (provided that the server has a real certificate) and is 796 easier to deploy, especially if the server wants to use SSL/TLS for 797 channel security in any case. 799 There are actually two ways to use passwords over HTTPS. The first is 800 to use HTTP's built in authentication mechanisms (either Digest or 801 Basic) over an HTTPS connection. The second is to perform password 802 authentication at the application layer, using an HTML form to prompt 803 for the password. The form method is far more popular, primarily 804 because it allows the application designer far greater control over 805 when and how authentication occurs. In particular, the designer can 806 give the password dialog any look he chooses. 808 In general, if form-based authentication is used, the only available 809 option is to use simple passwords, since HTML has no facilities for 810 performing arbitrary computation or challenge/response passwords. 811 Theoretically, one could perform these operations in a JavaScript or 812 Java program, but in practice this is generally not done. 814 9.1.1. Authentication State 816 When Basic or Digest Authentication is used, the client can simply 817 transmit an authenticator with every request. However, if authentica- 818 tion is performed using an HTML form, this approach is impractical, 819 since it would require client interaction for every page fetch. Three 820 approaches for solving this problem are generally proposed. 822 9.1.1.1. The Token Problem 824 In general, all HTTP authentication state carrying schemes involve 825 providing the client with some token which it can then present to 826 authenticate future requests. This token must be constructed in such 827 a fashion that it is impossible for the client to tamper with it and 828 obtain access to resources that they would not otherwise be able to 829 access. 831 There are two basic techniques for constructing tokens. The first is 832 to have the token be self-authenticating, e.g. by having it be the 833 user's information signed or MAC-ed with a key known only to the 834 server. The second is to have it be an index into some database of 835 authenticated users stored on the server. Note that these indices 836 must be unpredictable to prevent one user from guessing another 837 user's token. The self-authenticating approach has the advantage that 838 it does not require persistent storage on the server but the disad- 839 vantage that there is no way to mark a token invalid or update it 840 (although they can of course contain an expiry time). When multiple 841 servers are involved, self-authenticating tokens have the additional 842 advantage that they do not require inter-server communication. 844 9.1.1.2. URL Rewriting 846 The most general but also most difficult approach is to dynamically 847 rewrite all URLs provided to the client after authentication has 848 occurred. One might, for instance, pass all pages through a CGI 849 script, where the arguments include the real page to be accessed and 850 the authenticator token. an example of such a URL is: 852 http://www.example.com/cgi-bin/gw.pl?authenticator 853 =MjFkNWQyOGRjYjlmM2IwMmJjMzk0NGFhODg0YTQ4YTcK?page=foo.html 855 The CGI script would then use the authenticator argument to determine 856 the client identity, recover the actual target page and perform the 857 authentication checks. Using a CGI script this way is inconvenient 858 since it requires replicating the server's access control infrastruc- 859 ture. A less intrusive approach involves having a server plugin 860 unwrap the target URL early in the server's processing pipeline, 861 before the access control checks are performed. This allows the 862 server to perform it's normal authentication checks based on the 863 unwrapped identity. 865 The primary difficulty with URL rewriting is that it all pages must 866 be dynamically generated. Either each page must be generated by a 867 script which embeds the appropriate URLs or the server must postpro- 868 cess pages to embed them. Either approach makes the system more com- 869 plex and therefore adds instability. However, before the introduction 870 of cookies, URL rewriting was essentially the only option for token 871 passing. 873 9.1.1.3. Cookies 875 The inconvenience of URL rewriting lead to the introduction of HTTP 876 Cookies [RFC 2109]. Essentially, an HTTP cookie is a token issued by 877 the server and transmitted by the client with requests. The cookies 878 can be labeled to be transmitted only when resources matching various 879 prefixes are dereferenced, including resources on another server. 880 Browsers generally persistently cache cookies between invocations. 882 Cookies are the method of choice for carrying HTTP state information 883 and can be used to carry all kinds of state besides authentication 884 information. Note, however, that since cookies can be used to trans- 885 mit information from one server to another, they have been the focus 886 of privacy concerns [REF]. Accordingly, some users choose not to 887 accept or transmit cookies. 889 9.1.1.4. HTTPS Session Binding 891 Each TLS/SSL session has a session identifier, which is used for 892 resuming the session without a full handshake. These session IDs are 893 unique for any given server, so server administrators often think to 894 use the session ID as a search key for the user's information. This 895 is a bad idea. The fundamental problem is that there's no guarantee 896 that any given session will be resumed. The client need not offer to 897 resume a session and the server need not accept, or may flush its 898 session cache at any time. Thus, using the session ID as a persistent 899 identifier is unwise. 901 9.2. List of Server Certificate Systems 903 Lots of protocols over SSL/TLS [REF] 904 IPsec (under some conditions) [REF] 906 10. Mutual Public Key Authentication 908 If both client and server have certificates, then the peers can use 909 mutual certificate authentication. This is done by having both client 910 and server establish that they know the private keys corresponding to 911 their certificates. A wide variety of protocols offer this function- 912 ality, including SSL, IPsec, and SSH (SSH actually offers mutual 913 authentication with pre-arranged public keys). 915 The two most important advantages of public key authentication are 916 that it has no password equivalence and that it can allow authentica- 917 tion between parties who have no prior arrangement. 919 10.1. Password Equivalence 921 With public key authentication, the server knows only the client's 922 public key. It is therefore incapable of forging any kind of authen- 923 tication message from the client. Similarly, knowledge of the public 924 key does not allow an attacker to authenticate to the server. Accord- 925 ingly, public key techniques never store a password equivalent on the 926 server. 928 10.2. Authentication between Unknown Parties 930 One advantage of certificate-based public key authentication systems 931 --as opposed to those using pre-arranged public keys--is that it 932 allows authentication between parties who have had no prior contact. 933 Authentication of servers with which one has had no prior arrangement 934 happens all the time in the HTTPS context: the user wishes to connect 935 to a host at a given URL and is able to verify that the server 936 certificate matches that URL. 938 In addition to strict identity verification, it's possible to use 939 certificates to carry authorization information. This allows a cen- 940 tral authority to make both authentication and access control deci- 941 sions for distributed servers merely by issuing certificates. [REF: 942 Policymaker?] describes such a system. 944 10.3. Key Storage 946 The primary security problem with public key authentication protocol 947 (assuming the basic protocol is designed correctly) is protecting the 948 client's public key. Generally, the server's public key can be pro- 949 tected by hardening the server, but the user often needs to be able 950 to carry his private key around. This can be done in essentially two 951 ways: with a token or by generating the key from a password. 953 10.4. Tokens 955 The general idea of a secure token is relatively simple: you have a 956 tamper-resistant and portable token which carries your private key 957 (and probably your certificate). The token can be interfaced to a 958 computer, typically through a USB jack or a smartcard interface. The 959 private key is generally protected by a PIN, but of course this PIN 960 is known to any computer on which the token is used, since the PIN is 961 sent to the token by the computer. The primary threat to tokens is 962 loss or theft. It's not generally economical to make such tokens com- 963 pletely tamper-proof, so a lost token in the hands of a dedicated 964 attacker means a lost private key. 966 10.5. Password Derived Keys 968 It's generally possible to derive a user's private key from a rela- 969 tively short password, simply by using the password to seed a crypto- 970 graphically secure PRNG which is used to generate the private key. 971 Unfortunately, this technique is susceptible to dictionary attack, 972 since an attacker can dictionary search the password space until he 973 finds a password that generates a key pair that matches the signa- 974 ture. Protocols can be designed to resist this attack by exchanging 975 the signed client response under the server's private key, but many 976 protocols (notably SSL) do not. Accordingly, password derived keys 977 should be viewed as a mechanism for using shared keys with public- 978 key-only protocols, not as a fully public key system. 980 10.6. Case Study: SMTP over TLS 982 [TODO] 984 10.7. List of Mutual Public Key Systems 986 SSL/TLS (client auth mode) [REF] 987 IPsec [REF] 988 S/MIME [REF] 989 11. Generic Authentication Mechanisms 991 An approach that has lately gained currency is to use a generic 992 authentication negotiation system. Examples of such systems include 993 SASL [REF] and EAP [REF]. The general idea is that one has a protocol 994 framework which doesn't provide any authentication features per se 995 but instead allows you to negotiate the authentication mechanisms you 996 wish to use. SASL, for instance, allows the negotiation of CRAM-MD5 997 (a digest-based challenge/response mechanism), SRP, and TLS among 998 other mechanisms. 1000 Generic authentication mechanisms are attractive to application pro- 1001 tocol designers because they allow them--in theory--to add security 1002 to their protocols without having to directly deal with the security 1003 issues. They simply specify that one should use a given framework. 1004 They're attractive to security mechanism designers because it's rela- 1005 tively easy to add new mechanisms. 1007 11.1. Downgrade Attacks 1009 The most serious problem with generic authentication mechanisms is 1010 their susceptibility to DOWNGRADE ATTACK, in which the attacker 1011 interferes with the negotiation to force the parties to negotiate a 1012 weaker mechanism than they otherwise would. Consider a set of peers, 1013 each of which supports both challenge/response and simple passwords. 1014 An attacker can force them into using a simple password and then cap- 1015 ture that password. 1017 The standard countermeasure to downgrade attack is to authenticate a 1018 message digest of the offered mechanisms. Unfortunately, this protec- 1019 tion is only as strong as the weakest common mechanism. If this mech- 1020 anism is a simple password then no protection against downgrade 1021 attack is possible. The possibility of downgrade attack requires that 1022 users of generic security mechanisms carefully profile the mechanisms 1023 they offer to ensure that they are all adequately strong. 1025 11.2. Integration with Applications 1027 [TODO] 1029 11.3. Multiple Equivalent Mechanisms 1031 The ease of adding new security mechanisms to generic authentication 1032 layers means that a given authentication layer may have a number of 1033 different mechanisms with essentially similar characteristics. For 1034 instance, SASL has mechanisms for SecureID [RFC 2808], OTP [RFC 1035 2245], and Digest Authentication [RFC 2831]. In addition, there is 1036 currently an Internet-Draft for CRAM-MD5 support in SASL. With the 1037 exception of Digest, all of these mechanisms offer essentially the 1038 same security properties (Digest also allows the negotiation of a 1039 shared key for session encryption). 1041 So, why the proliferation of superficially redundant mechanisms? From 1042 a security perspective, they could all be replaced by Digest. The 1043 reason appears to be legacy authentication mechanisms. Many environ- 1044 ments already have S/Key or SecureID installed and the administrators 1045 don't want to replace them. This inevitably creates pressure to add 1046 every conceivable security mechanism to one's generic framework. 1048 While the desire to support legacy authentication systems is under- 1049 standable, it should be resisted to the extent possible. Having mul- 1050 tiple equivalent mechanisms dramatically increases both implementa- 1051 tion complexity and interoperability problems. When designing a new 1052 system, designers should choose a very small number of authentication 1053 mechanisms, with no more than one of any given class. 1055 11.4. Excessive Layering 1057 Many of the legacy authentication mechanisms that users and adminis- 1058 trators wish to support are themselves generic frameworks of one kind 1059 or another. For instance, SASL allows the use of GSSAPI, which itself 1060 is a generic framework for a number of mechanisms. This sort of lay- 1061 ering dramatically increases both implementation and deployment com- 1062 plexity. For instance, GSSAPI contains mechanisms that are essen- 1063 tially equivalent to Kerberos, but SASL also supports Kerberos 1064 directly. Under what conditions should clients use Kerberos directly 1065 and under which should they use it through GSSAPI? 1067 Another example of the same problem is the Extensible Authentication 1068 Protocol (EAP) [REF], an authentication framework originally designed 1069 for PPP [REF]. Note that PPP itself allows multiple authentication 1070 mechanisms, so PPP must first negotiate EAP. EAP then negotiates the 1071 individual mechanisms. To make matters worse, one of the EAP mecha- 1072 nisms is TLS [REF] which can negotiate it's own authentication mecha- 1073 nisms. Three levels of indirection seems a bit much. 1075 In accordance with the principle of having as few mechanisms as pos- 1076 sible, frameworks should avoid mechanisms that are themselves frame- 1077 works, in favor of using the second framework's mechanisms directly. 1078 "We'll build ours on top of theirs" is a bad policy. 1080 11.5. List of Generic Authentication Systems 1082 GSS-API [REF] 1083 SASL [REF] 1084 EAP [REF] 1085 12. Sharing Authentication Information 1087 In many cases, users will use the same authentication data for a 1088 large number of services. For instance, users may expect to use the 1089 same username/password pair for TELNET, IMAP, and FTP. In such cases, 1090 it is generally desirable for all such services to share a single set 1091 of authentication data. For instance, TELNET, IMAP, and FTP typically 1092 all share the same password database. 1094 12.1. Authentication Services 1096 This problem is made more difficult if the services which must share 1097 authentication data reside on different machines. This problem is 1098 typically solved (when it is solved, as opposed to simply ignored) by 1099 having some unique system which has the credentials. Such a machine 1100 may either provide authentication as service (as in Kerberos) or sim- 1101 ply provide credentials to authorized machines (YP, NIS). In either 1102 case, this protocol needs to be secured. 1104 12.2. Single Sign-On 1106 A related problem is that users don't necessarily want to have to 1107 manually authenticate each time some service wants authentication. 1108 Rather, they want to authenticate once and have software take care of 1109 the rest. This capability is called SINGLE SIGN-ON. If all authenti- 1110 cation will be performed by one program, this can be fixed simply by 1111 having the program cache the user's credentials. If credentials need 1112 to be shared across multiple services then it's necessary to have 1113 some way to pass them from the progam which first authenticates to 1114 others (or to have some central credential manager). This service is 1115 generally called SINGLE SIGN-ON. 1116 As a special case, consider the case where mutually suspicious sys- 1117 tems all want to allow a user to authenticate with a single set of 1118 credentials. If certificate-based authentication is being used, this 1119 is relatively straightforward. In the case where passwords are being 1120 used, the typical solution is to have some third party authentication 1121 service which authenticates the user and then vouches for the user to 1122 the services. Microsoft Passport is one such provider. 1124 12.3. Case Study: RADIUS 1126 [TODO] 1128 12.4. Case Study: Kerberos 1130 Kerberos [REF] is a popular authentication/single sign-on service, 1131 especially in academic environments. Kerberos is based on the Need- 1132 ham-Schroeder authentication protocol. The authentication server role 1133 is played by a Key Distribution Center (KDC). When a client first 1134 signs on the client proves its identity to the KDC, usually by means 1135 of a password shared with the KDC. 1136 Kerberos is unusual in that the authentication service is provided 1137 to the client rather than the server. When a client wishes to commu- 1138 nicate with a server, it first contacts the KDC and acquires a 1139 TICKET. That ticket contains a new symmetric key encrypted for both 1140 the client and server. The client can transmit the ticket to the 1141 server and use it both to prove its identity and establish a secure 1142 channel. 1144 12.5. List of Authentication Server Systems 1146 Kerberos [REF] 1147 RADIUS [REF] 1148 DIAMETER [REF] 1149 ??? 1151 13. Guidance for Protocol Designers 1153 Adding authentication to protocols is difficult and is made even more 1154 difficult by the large number of options. This section attempts to 1155 provide some guidance to protocol designers. No single document can 1156 tell you how to build a secure system, but the following guidelines 1157 provide generally good advice. If you feel you need to violate one of 1158 these rules of thumb, make sure you know why you're doing it. 1160 13.1. Know what you're trying to do 1162 The first thing to do is figure out what the security problem you're 1163 trying to solve is. Questions to ask include. 1165 13.1.1. What's my threat model? 1167 Sorting out the threat model is always the first step in deciding 1168 what sorts of security mechanisms to use. In the case of authentica- 1169 tion you must consider, at minimum. eP 1171 1. What will be the result of various forms of attack? 1172 2. Does the threat model include active attack. (Hint: it should.) 1173 3. Do I need protection for my data or just the authentication. 1174 (Hint: probably you do). 1175 4. How valuable is the data being secured? Are exhaustive computational 1176 attacks practical? 1177 5. How competent are my users going to be? 1178 13.1.2. How many users will this system have? 1180 In general, the difficulty of managing a system scales with (or 1181 greater than) the number of users. This means that mechanisms which 1182 are practical with a small number of users may simply have too much 1183 overhead with a large number of users. For example, many token-based 1184 solutions charge by the token, which may be a prohibitive expense if 1185 there are many users. 1187 13.1.3. What's my protocol architecture? 1189 In some systems (e.g. POP, IMAP, TELNET), clients connect directly to 1190 the server. In others (e.g. HTTP, SIP, RSVP, BGP), authentication may 1191 need to be established over multiple hops when the entities have no 1192 independent authentication. Each case requires a different strategy. 1193 See Section XXX for more discussion on this topic. 1195 13.1.4. Do I need to share authentication data 1197 If authentication data needs to be shared, especially between multi- 1198 ple servers, it's generally worth considering some sort of authenti- 1199 cation server or using certificates. 1201 13.2. Use As Few Mechanisms as You Can 1203 Preferably, systems should have only one form of authentication. The 1204 more methods of authentication a system allows, the more things there 1205 are to go wrong. Remember that a chain is only as strong as its weak- 1206 est link. In general, there are two reasons why systems allow more 1207 than one authentication mechanism. The first is that you're 1208 retrofitting a system which already has a large number of authentica- 1209 tion mechanisms which cannot be displaced. The second is that users 1210 have widely different environments which for some reason cannot use 1211 the same authentication mechanism conveniently (e.g. some users have 1212 tokens and some do not). 1214 Naturally, designers need to take such considerations into account 1215 but they should take reasonable steps to minimize the number of mech- 1216 anisms. Designers should take special care to minimize the number of 1217 equivalent mechanisms. For instance, a system that provides a chal- 1218 lenge/response mechanism and a public key based mechanism is a rea- 1219 sonable design, one that provides three different challenge/response 1220 mechanisms is not. 1222 This doesn't mean that designers should not use security frameworks 1223 where multiple mechanisms are appropriate, but it does mean that they 1224 should be avoided unless necessary. Where generic security frameworks 1225 are used, they supported mechanisms should be carefully profiled to a 1226 minimal set. 1228 13.3. Avoid simple passwords 1230 It's widely known that simple plaintext passwords are unsafe, but 1231 what's less widely known is that merely providing such a scheme can 1232 weaken systems even if stronger mechanisms are present. Consider the 1233 case where a system uses a negotiation framework that allows pass- 1234 words. A downgrade attack can force the user to reveal his password 1235 even if both client and server support stronger mechanisms. Accord- 1236 ingly, designers should avoid deploying simple password mechanisms if 1237 at all possible, not just provide stronger mechanisms. 1239 13.4. Avoid inventing something new 1241 Despite the large number of mechanisms we've discussed, this document 1242 describes only a small number of the available authentication mecha- 1243 nisms. There are very few situations in which designers cannot use 1244 some preexisting mechanism. This is vastly preferable to designing 1245 their own version of one of the standard mechanisms. In particular, 1246 designers should avoid designing their own channel security systems. 1247 If you want a channel security system, use IPsec or SSL. 1249 13.5. Use the strongest mechanisms you can 1251 Having the strongest security you can apropos is generally a good 1252 plan. It's particularly good advice here, since passwords in the 1253 clear, one-time passwords, challenge-response and zero-knowledge 1254 password proofs all require the user to have the same kind of creden- 1255 tial: a password. (Note that some OTP schemes such as SecureID 1256 require a token.) When designing a new system, the ability to provide 1257 a familiar interface to a user is valuable, minimizing additional 1258 work for client and server implementors is not. 1260 13.6. Consider providing message integrity 1262 Although most of the authentication mechanisms we've described are 1263 themselves resistant to active attacks, many are subject to hijacking 1264 after authentication has completed. If your threat model includes 1265 active attack (it should), you should strongly consider providing 1266 message integrity for all of your protocol messages in order to pre- 1267 vent hijacking. 1269 14. Scenarios 1271 Despite the proliferation of authentication mechanisms, there are 1272 generally one or two optimal mechanisms for each scenario. We attempt 1273 to describe those mechanisms here. This section is divided into two 1274 parts, attacking the problem from different angles. In the first, we 1275 consider the various kinds of capabilities entities might have and 1276 the best mechanisms to use with those credentials. In the second part 1277 we discuss a number of different protocol architectures and the 1278 potential mechanisms which can be used with those architectures. 1280 14.1. Capability Considerations 1282 There are three primary authentication scenarios: 1283 (1) Neither side has a public/private key pair. 1284 (2) The server has an authenticated key pair (either via a 1285 certificate or prior arrangement). 1286 (3) Both sides have authenticated key pairs 1288 Despite the proliferation of authentication mechanisms, there are 1289 only one or two best mechanisms for each scenario. We describe them 1290 here. 1292 14.1.1. Neither side has a public/private key pair 1294 Three basic strategies are suitable for the situation where neither 1295 side has a key pair: challenge/response, one-time passwords, and 1296 ZKPPs. The only situation in which OTP systems are superior to chal- 1297 lenge/response systems is when adapting a legacy system in which it 1298 is difficult to change the client software. If the client software 1299 can be changed, challenge/response offers roughly equivalent security 1300 with significantly less management complexity. ZKPP proofs are tech- 1301 nically superior to challenge/response but intellectual property con- 1302 siderations make them unsuitable for Internet standardization unless 1303 no other option is available. 1305 These considerations make challenge/response the best choice for this 1306 scenario. If at all possible, it should be performed under cover of 1307 an anonymous key exchange, as described in section XXX. With this 1308 adaptation, an attacker needs to mount an active attack in order to 1309 dictionary search the password space. 1311 14.1.2. The server has an authenticated key pair 1313 If the server has a key pair which the client can authenticate, then 1314 simple username/password encrypted under the server's public key is 1315 the preferred authentication mechanism. Challenge/response is in fact 1316 weaker in this case because it is is password equivalent. Once confi- 1317 dentiality is provided, OTP and ZKPP systems offer significant addi- 1318 tional management complexity for marginal security benefit. 1320 14.1.3. Both sides have authenticated key pairs 1322 If both sides have key pairs, the optimal mechanism is mutual public 1323 key authentication. 1325 14.2. Architectural Considerations 1327 In this section, we consider XXX different network architecturs and 1328 the authentication mechanisms that are most suitable for each. 1330 14.2.1. Simple Client/Server 1332 The simplest authentication scenario is where the client and the 1333 server are connected by some interactive connection. Mercifully, this 1334 situation is quite common in such protocols as IMAP, TELNET, etc. In 1335 the simple client/server case, mostly any authentication mechanism 1336 can be employed and so the choice depends on other factors, such as 1337 what credentials are available and the degree of security required. 1339 14.2.2. Proxied Client/Server 1341 It's quite common for client/server communication to be propagated 1342 through some gateway, as happens with HTTP. This situation has two 1343 potential authentication problems. 1345 1. How does the client authenticate to the proxy so that the 1346 proxy knows to serve it. 1347 2. How does the client authenticate to the server with the 1348 proxy in the way. 1350 The problem of authenticating to the proxy looks essentially like the 1351 ordinary client/server authentication problem (except in the case 1352 where there are multiple proxies in which case authenticating to any- 1353 thing other than the first hop proxy looks rather like problem 2.) 1355 The problem of authenticating through the proxy is rather more diffi- 1356 cult. The obstacle is that neither client nor server may not trust 1357 the proxy. They therefore need to provide an authentication method 1358 (preferably with message integrity) that doesn't require trusting the 1359 proxy. This rules out simple passwords and makes one-time passwords 1360 extremely questionable. There are three basic strategies available. 1362 14.2.2.1. Tunnel 1364 If the client and the server establish a tunnel through the proxy 1365 then they can behave as if this was an ordinary client/server trans- 1366 action. Although this rather obviates the point of having a proxy, 1367 it's still a popular strategy and is used with HTTPS. [REF] Since the 1368 proxy is untrusted, the application protocol must either be run over 1369 a secure channel or hardened against active attacks. 1371 14.2.2.2. Challenge/Response 1373 A shared symmetric key between client and server can be used for 1374 authentication even in the face of a proxy by using standard chal- 1375 lenge/response methods (with appropriate protocol modifications to 1376 distinguish between protocol data units (PDUs) directed towards the 1377 proxy and those directed towards endpoints.) These methods should 1378 include integrity protection for the individual PDUs. 1380 On a small scale, this technique works (it's what's used in HTTP when 1381 HTTPS is not used) but it quickly becomes unwieldy. If there are a 1382 large chain of proxies each of which wishes to authenticate the 1383 client, server, other proxies or all three, an enormous number of 1384 pairwise keys need to be established and maintained. In a protocol 1385 where long proxy chains are expected, symmetric key based authentica- 1386 tion is probably impractical. 1388 A variant of this technique is to use a message-based system with 1389 symmetric keying such as S/MIME. All PDUs can then be encapsulated in 1390 secure messages. Recursive encapsulation can be used to provide 1391 authentication to proxies. 1393 14.2.2.3. Digital Signatures 1395 The final approach is to use public-key based digital signatures. 1396 Each endpoint signs each message (possibly with some set of nonces to 1397 prevent replay attack). The disadvantage of this approach is that it 1398 requires a PKI. The advantage is that it doesn't require pairwise 1399 keys. Each proxy in the chain can validate the client and the server 1400 based solely on their signatures. 1402 14.2.3. Store and Forward 1404 A number of important IETF protocols, most importantly, e-mail, are 1405 of the store and forward messaging variety. Such protocols have 1406 roughly the same security options as proxied protocols except that 1407 tunnelling is no longer possible. Additionally, since store and for- 1408 ward protocols are non-interactive, many of the usual chal- 1409 lenge/response techniques for preventing replay attack no longer work 1410 and so care must be taken to either make one's system idempotent or 1411 introduce a specific anti-replay mechanism. The standard technique 1412 for store-and-forward situations is message security a la S/MIME. 1414 14.2.4. Multicast 1416 A number of IETF protocols have the property that multicast or broad- 1417 cast message integrity needs to be provided. For example, routing and 1418 DNS both require the ability for a single sender to broadcast authen- 1419 ticated and integrity protected messages to a large number of 1420 receivers. There are two relevant cases: In the first, all members of 1421 the group are trusted and so it's feasible to have some group key 1422 which is used for authenticating all transmissions. This group key 1423 may be manually configured or established via some protocol such as 1424 GKMP [REF]. 1426 In the second case, individual group members are not trusted not to 1427 forge messages. such systems, it's not really practical to use sym- 1428 metric key systems because the sender would need to agree on a key 1429 with each recipient (there may not even be a return channel). The 1430 only really practical approach in these multicast situations is for 1431 the sender to digitally sign each transmission with its private key. 1433 Acknowledgments 1435 Early versions of this document were reviewed by Fred Baker, Lisa 1436 Dusseault, Ted Hardie, and Mike St. Johns. 1438 References 1439 [TODO] 1441 Security Considerations 1443 This document describes a number of security mechanisms. 1445 Author's Address 1446 Eric Rescorla 1447 RTFM, Inc. 1448 2064 Edgewood Drive 1449 Palo Alto, CA 94303 1450 Phone: (650)-320-8549 1451 Table of Contents 1453 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1454 2. The Authentication Problem . . . . . . . . . . . . . . . . . . . 2 1455 2.1. Authorization vs. Authentication . . . . . . . . . . . . . . . 2 1456 2.2. Standard Material Something you have, something you know... 1457 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1458 3. Description of Authentication Mechanisms . . . . . . . . . . . . 2 1459 4. Passwords In The Clear . . . . . . . . . . . . . . . . . . . . . 3 1460 4.1. Password Sniffing . . . . . . . . . . . . . . . . . . . . . . . 3 1461 4.2. Post-Authentication Hijacking . . . . . . . . . . . . . . . . . 3 1462 4.3. Online Password Guessing . . . . . . . . . . . . . . . . . . . 4 1463 4.4. Offline Dictionary Attack . . . . . . . . . . . . . . . . . . . 4 1464 4.4.1. Shadow Passwords . . . . . . . . . . . . . . . . . . . . . . 4 1465 4.4.2. Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1466 4.4.3. Salting . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1467 4.4.4. Stronger Passwords . . . . . . . . . . . . . . . . . . . . . 5 1468 4.5. Case Study: HTTP Basic Authentication . . . . . . . . . . . . . 6 1469 4.5.1. Password Caching . . . . . . . . . . . . . . . . . . . . . . 6 1470 4.5.2. Pro-active authentication . . . . . . . . . . . . . . . . . . 6 1471 4.6. List of Systems that Use Passwords in the Clear . . . . . . . . 6 1472 5. One Time Passwords . . . . . . . . . . . . . . . . . . . . . . . 7 1473 5.1. Case Study: S/Key and OTP . . . . . . . . . . . . . . . . . . . 7 1474 5.1.1. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 8 1475 5.2. Case Study: SecureID . . . . . . . . . . . . . . . . . . . . . 9 1476 5.3. List of One-Time Password Systems . . . . . . . . . . . . . . . 9 1477 6. Challenge/Response . . . . . . . . . . . . . . . . . . . . . . . 9 1478 6.1. Offline Attacks on Challenge/Response . . . . . . . . . . . . . 10 1479 6.2. Password File Compromise . . . . . . . . . . . . . . . . . . . 10 1480 6.3. Case Study: CRAM-MD5 . . . . . . . . . . . . . . . . . . . . . 11 1481 6.4. Case Study: HTTP Digest . . . . . . . . . . . . . . . . . . . . 12 1482 6.4.1. Message Integrity . . . . . . . . . . . . . . . . . . . . . . 12 1483 6.4.2. Replay Attack . . . . . . . . . . . . . . . . . . . . . . . . 13 1484 6.4.3. Downgrade Attack . . . . . . . . . . . . . . . . . . . . . . 13 1485 6.5. List of Challenge-Response Systems . . . . . . . . . . . . . . 14 1486 7. Anonymous Key Exchange . . . . . . . . . . . . . . . . . . . . . 14 1487 7.1. Case Study: SSH Password Authentication . . . . . . . . . . . . 14 1488 7.2. Case Study: TLS Anonymous DH + Passwords . . . . . . . . . . . 15 1489 7.3. List of Anonymous Key Exchange Mechanisms . . . . . . . . . . . 15 1490 8. Zero-Knowledge Password Proofs . . . . . . . . . . . . . . . . . 15 1491 8.1. Intellectual Property . . . . . . . . . . . . . . . . . . . . . 16 1492 8.2. List of Zero Knowledge Password Proof Systems . . . . . . . . . 16 1493 9. Server Certificates plus Client Authentication . . . . . . . . . 16 1494 9.1. Case Study: Passwords over HTTPS . . . . . . . . . . . . . . . 17 1495 9.1.1. Authentication State . . . . . . . . . . . . . . . . . . . . 18 1496 9.1.1.1. The Token Problem . . . . . . . . . . . . . . . . . . . . . 18 1497 9.1.1.2. URL Rewriting . . . . . . . . . . . . . . . . . . . . . . . 18 1498 9.1.1.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1499 9.1.1.4. HTTPS Session Binding . . . . . . . . . . . . . . . . . . . 19 1500 9.2. List of Server Certificate Systems . . . . . . . . . . . . . . 20 1501 10. Mutual Public Key Authentication . . . . . . . . . . . . . . . . 20 1502 10.1. Password Equivalence . . . . . . . . . . . . . . . . . . . . . 20 1503 10.2. Authentication between Unknown Parties . . . . . . . . . . . . 20 1504 10.3. Key Storage . . . . . . . . . . . . . . . . . . . . . . . . . 21 1505 10.4. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1506 10.5. Password Derived Keys . . . . . . . . . . . . . . . . . . . . 21 1507 10.6. Case Study: SMTP over TLS . . . . . . . . . . . . . . . . . . 21 1508 10.7. List of Mutual Public Key Systems . . . . . . . . . . . . . . 21 1509 11. Generic Authentication Mechanisms . . . . . . . . . . . . . . . 22 1510 11.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . . . 22 1511 11.2. Integration with Applications . . . . . . . . . . . . . . . . 22 1512 11.3. Multiple Equivalent Mechanisms . . . . . . . . . . . . . . . . 22 1513 11.4. Excessive Layering . . . . . . . . . . . . . . . . . . . . . . 23 1514 11.5. List of Generic Authentication Systems . . . . . . . . . . . . 23 1515 12. Sharing Authentication Information . . . . . . . . . . . . . . . 24 1516 12.1. Authentication Services . . . . . . . . . . . . . . . . . . . 24 1517 12.2. Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . 24 1518 12.3. Case Study: RADIUS . . . . . . . . . . . . . . . . . . . . . . 24 1519 12.4. Case Study: Kerberos . . . . . . . . . . . . . . . . . . . . . 24 1520 12.5. List of Authentication Server Systems . . . . . . . . . . . . 25 1521 13. Guidance for Protocol Designers . . . . . . . . . . . . . . . . 25 1522 13.1. Know what you're trying to do . . . . . . . . . . . . . . . . 25 1523 13.1.1. What's my threat model? . . . . . . . . . . . . . . . . . . 25 1524 13.1.2. How many users will this system have? . . . . . . . . . . . 26 1525 13.1.3. What's my protocol architecture? . . . . . . . . . . . . . 26 1526 13.1.4. Do I need to share authentication data . . . . . . . . . . . 26 1527 13.2. Use As Few Mechanisms as You Can . . . . . . . . . . . . . . . 26 1528 13.3. Avoid simple passwords . . . . . . . . . . . . . . . . . . . . 27 1529 13.4. Avoid inventing something new . . . . . . . . . . . . . . . . 27 1530 13.5. Use the strongest mechanisms you can . . . . . . . . . . . . . 27 1531 13.6. Consider providing message integrity . . . . . . . . . . . . . 27 1532 14. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1533 14.1. Capability Considerations . . . . . . . . . . . . . . . . . . 28 1534 14.1.1. Neither side has a public/private key pair . . . . . . . . . 28 1535 14.1.2. The server has an authenticated key pair . . . . . . . . . . 28 1536 14.1.3. Both sides have authenticated key pairs . . . . . . . . . . 29 1537 14.2. Architectural Considerations . . . . . . . . . . . . . . . . . 29 1538 14.2.1. Simple Client/Server . . . . . . . . . . . . . . . . . . . . 29 1539 14.2.2. Proxied Client/Server . . . . . . . . . . . . . . . . . . . 29 1540 14.2.2.1. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1541 14.2.2.2. Challenge/Response . . . . . . . . . . . . . . . . . . . . 30 1542 14.2.2.3. Digital Signatures . . . . . . . . . . . . . . . . . . . . 30 1543 14.2.3. Store and Forward . . . . . . . . . . . . . . . . . . . . . 30 1544 14.2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 31 1545 14.2.4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 1546 14.2.4. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 1547 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 31 1548 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 31