idnits 2.17.1 draft-iab-auth-mech-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 27, 2010) is 5165 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 632 == Outdated reference: A later version (-10) exists of draft-altman-tls-channel-bindings-07 == Outdated reference: A later version (-13) exists of draft-nir-tls-eap-06 -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 3850 (Obsoleted by RFC 5750) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5081 (Obsoleted by RFC 6091) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Intended status: Standards Track G. Lebovitz, Ed. 5 Expires: August 31, 2010 Juniper Networks, Inc. 6 Internet Architecture Board 7 IAB 8 February 27, 2010 10 A Survey of Authentication Mechanisms 11 draft-iab-auth-mech-07.txt 13 Abstract 15 Authentication is a common security issue for the design of Internet 16 protocols. A wide variety of authentication technologies are 17 available. A common problem is knowing which technology to choose or 18 which of a variety of essentially similar implementations of a given 19 technique to choose. This memo provides a survey of available 20 authentication mechanisms and guidance on selecting one for a given 21 protocol. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on August 31, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 2. The Authentication Problem . . . . . . . . . . . . . . . . . . 7 77 2.1. Authorization vs. Authentication . . . . . . . . . . . . . 7 78 2.2. Authentication Building Blocks . . . . . . . . . . . . . . 8 79 2.3. Clients and Servers . . . . . . . . . . . . . . . . . . . 8 80 3. Basic Authentication, Attacks, and Counter Measures . . . . . 9 81 3.1. Password Sniffing . . . . . . . . . . . . . . . . . . . . 9 82 3.2. Post-Authentication Hijacking . . . . . . . . . . . . . . 9 83 3.3. Online Password Guessing (aka Brute Force Attack) . . . . 10 84 3.4. Offline Dictionary Attack . . . . . . . . . . . . . . . . 10 85 3.4.1. Shadow Passwords . . . . . . . . . . . . . . . . . . . 11 86 3.4.2. Iteration . . . . . . . . . . . . . . . . . . . . . . 11 87 3.4.3. Salting . . . . . . . . . . . . . . . . . . . . . . . 11 88 3.4.4. Stronger Passwords . . . . . . . . . . . . . . . . . . 12 89 3.4.5. Encrypted Channel . . . . . . . . . . . . . . . . . . 12 90 3.5. Phishing . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 3.6. Case Study: HTTP Basic Authentication . . . . . . . . . . 13 92 3.6.1. Password Caching . . . . . . . . . . . . . . . . . . . 13 93 3.6.2. Proactive authentication . . . . . . . . . . . . . . . 13 94 3.7. List of Systems that Use Passwords in the Clear . . . . . 13 95 4. One Time Passwords . . . . . . . . . . . . . . . . . . . . . . 14 96 4.1. Case Study: S/Key and OTP . . . . . . . . . . . . . . . . 15 97 4.1.1. Race Conditions . . . . . . . . . . . . . . . . . . . 16 98 4.2. Case Study: SecurID . . . . . . . . . . . . . . . . . . . 17 99 4.3. List of One-Time Password Systems . . . . . . . . . . . . 17 100 5. Challenge/Response . . . . . . . . . . . . . . . . . . . . . . 18 101 5.1. Offline Attacks on Challenge/Response . . . . . . . . . . 19 102 5.2. Password File Compromise . . . . . . . . . . . . . . . . . 19 103 5.3. Case Study: CRAM-MD5 . . . . . . . . . . . . . . . . . . . 20 104 5.4. Case Study: HTTP Digest . . . . . . . . . . . . . . . . . 21 105 5.4.1. Message Integrity . . . . . . . . . . . . . . . . . . 21 106 5.4.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 22 107 5.4.3. Downgrade Attack . . . . . . . . . . . . . . . . . . . 22 108 5.5. List of Challenge-Response Systems . . . . . . . . . . . . 23 109 6. Anonymous Key Exchange . . . . . . . . . . . . . . . . . . . . 23 110 6.1. Case Study: SSH Password Authentication . . . . . . . . . 24 111 6.2. List of Anonymous Key Exchange Mechanisms . . . . . . . . 25 112 7. Zero-Knowledge Password Proofs . . . . . . . . . . . . . . . . 25 113 7.1. Intellectual Property . . . . . . . . . . . . . . . . . . 26 114 7.2. List of Zero Knowledge Password Proof Systems . . . . . . 26 115 8. Server Certificates plus User Authentication . . . . . . . . . 26 116 8.1. Case Study: Passwords over HTTPS . . . . . . . . . . . . . 28 117 8.1.1. Authentication State . . . . . . . . . . . . . . . . . 28 118 8.2. List of Server Certificate Systems . . . . . . . . . . . . 30 119 9. Mutual Public Key Authentication . . . . . . . . . . . . . . . 30 120 9.1. Password Equivalence . . . . . . . . . . . . . . . . . . . 31 121 9.2. Authentication between Unknown Parties . . . . . . . . . . 31 122 9.3. Key Storage . . . . . . . . . . . . . . . . . . . . . . . 32 123 9.4. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 32 124 9.5. Password Derived Keys . . . . . . . . . . . . . . . . . . 32 125 9.6. Case Study: SMTP over TLS . . . . . . . . . . . . . . . . 33 126 9.7. List of Mutual Public Key Systems . . . . . . . . . . . . 33 127 10. Generic Issues . . . . . . . . . . . . . . . . . . . . . . . . 33 128 10.1. Channel Security Protocols . . . . . . . . . . . . . . . . 33 129 10.1.1. Limited Authentication Options . . . . . . . . . . . . 34 130 10.1.2. Limited Application Integration . . . . . . . . . . . 34 131 10.1.3. List of Channel Security Protocols . . . . . . . . . . 34 132 10.2. Authentication Frameworks . . . . . . . . . . . . . . . . 35 133 10.2.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . 37 134 10.2.2. Multiple Equivalent Mechanisms . . . . . . . . . . . . 37 135 10.2.3. Channel Bindings . . . . . . . . . . . . . . . . . . . 40 136 10.2.4. Excessive Layering . . . . . . . . . . . . . . . . . . 41 137 10.2.5. List of Authentication Frameworks . . . . . . . . . . 42 138 11. Sharing Authentication Information . . . . . . . . . . . . . . 42 139 11.1. Authentication Services . . . . . . . . . . . . . . . . . 42 140 11.2. Single Sign-On . . . . . . . . . . . . . . . . . . . . . . 43 141 11.3. Case Study: RADIUS . . . . . . . . . . . . . . . . . . . . 43 142 11.4. Case Study: Kerberos . . . . . . . . . . . . . . . . . . . 44 143 11.5. List of Authentication Server Systems . . . . . . . . . . 44 144 12. Guidance for Protocol Designers . . . . . . . . . . . . . . . 44 145 12.1. Know what you're trying to do . . . . . . . . . . . . . . 44 146 12.1.1. What's my threat model? . . . . . . . . . . . . . . . 45 147 12.1.2. How many users will this system have? . . . . . . . . 45 148 12.1.3. What's my protocol architecture? . . . . . . . . . . . 45 149 12.1.4. Do I need to share authentication data? . . . . . . . 46 150 12.2. Use as few mechanisms as you can . . . . . . . . . . . . . 46 151 12.3. Avoid simple passwords . . . . . . . . . . . . . . . . . . 47 152 12.4. Avoid inventing new frameworks . . . . . . . . . . . . . . 47 153 12.5. Use the strongest mechanisms you can . . . . . . . . . . . 47 154 12.6. Consider providing message integrity . . . . . . . . . . . 48 155 13. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 48 156 13.1. Capability Considerations . . . . . . . . . . . . . . . . 48 157 13.1.1. Neither side has a public/private key pair . . . . . . 49 158 13.1.2. One side has an authenticated key pair . . . . . . . . 49 159 13.1.3. Both sides have authenticated key pairs . . . . . . . 50 160 13.2. Architectural Considerations . . . . . . . . . . . . . . . 50 161 13.2.1. Simple Connection . . . . . . . . . . . . . . . . . . 50 162 13.2.2. Proxied Client/Server . . . . . . . . . . . . . . . . 50 163 13.2.3. Store and Forward . . . . . . . . . . . . . . . . . . 52 164 13.2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . 52 165 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 166 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 167 15.1. Normative References . . . . . . . . . . . . . . . . . . . 53 168 15.2. Informative References . . . . . . . . . . . . . . . . . . 53 170 Appendix A. IAB Members at the time of this writing . . . . . . . 59 171 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 173 1. Introduction 175 Authentication is perhaps the most basic security problem for 176 designers of network protocols. Even the early Internet protocols 177 such as TELNET [RFC0854] and FTP [RFC0959], which provided no other 178 security services, made provision for user authentication. 179 Unfortunately, these early authentication systems were wholly 180 inadequate for the Internet Threat Model [RFC3552] and a vast array 181 of other authentication mechanisms have been introduced in an attempt 182 to close these holes. 184 The most striking thing about these security mechanisms is how many 185 of them are essentially similar. There are only 7 basic classes of 186 authentication protocol but there are a large number of slightly 187 different protocols with essentially the same security properties. 188 This memo surveys the space of authentication mechanisms, describes 189 the basic classes and provides examples of protocols which fit into 190 each class. This document is aimed at protocol designers, more so 191 than system deployers. 193 In section 2 we will review the problem space around authentication. 194 It will define what we are trying to accomplish when using 195 authentication mechanisms, will contrast authorization and 196 authentication, and review the basic building blocks of 197 authentication. 199 In section 3 we introduce basic password authentication systems, 200 describe attacks that formed against them, and the counter measures 201 that addressed such attacks. These descriptions will lay a 202 foundation of understanding and terminology useful for the mechanisms 203 described in the sections that follow section 3. 205 The next six sections, starting with section 4, each describe a 206 single class of authentication technology. In each case, we first 207 describe the technology in general, with possible subsections 208 describing security or implementation issues that are generic to this 209 technology. Once we have described the technology in general we then 210 provide one or more case studies: descriptions of specific protocols 211 which use this authentication technology and the various security or 212 implementation issues that are specific to that protocol. Thus, each 213 section uses the following pattern. 215 A Mechanism 216 (Description) 217 A.x risk 218 (description and countermeasures) 219 A.y risk 220 (description and countermeasures) 221 A.z Case Study: Specific Protocol 222 (description of the protocol) 223 A.z.x Protocol Specific problems. 224 A.w List of known Protocols/Systems that use this mechanism 226 In order to understand the pros and cons of each mechanism, it's 227 important to have a clear idea of the threat model for the 228 environment in which your protocol will be deployed. [RFC3552] 229 provides more information on threat modelling. 231 2. The Authentication Problem 233 The authentication problem is simple to describe but hard to solve: 234 Two parties (or devices/daemons/endpoints/etc.) are communicating and 235 one wishes to establish its identity to another, or establish the 236 identity of another. The basic scenario is exemplified by TELNET 237 [RFC0854]. A client (on behalf of a user) wishes to remotely access 238 resources on a TELNET server. The user has an account on the server 239 and the server remembers the user's authentication information but 240 the client itself may have no long-term storage and only limited 241 computational capabilities. The client side of the credentials must 242 be able to be carried by the user, either on a small device or in his 243 memory. Note that the major technical division here is between 244 situations in which there is any client-side storage (for instance 245 for cryptographic keys) and ones where any authentication material 246 must be memorized. 248 2.1. Authorization vs. Authentication 250 AUTHORIZATION is the process by which one determines whether an 251 authenticated party has permission to access a particular resource or 252 service. Although often tightly bound, it is important to realize 253 that authentication and authorization are two separate mechanisms. 254 Perhaps because of this tight coupling, authentication is sometimes 255 mistakenly thought to imply authorization. Authentication simply 256 validates the identity of a party -- that the party really is who 257 they claim to be; authorization defines whether they can perform a 258 certain action. 260 Authorization necessarily relies on authentication, but 261 authentication alone does not imply authorization. Having already 262 successfully passed some authentication step, but before granting 263 permission to perform an action, the authorization mechanism must be 264 consulted to determine whether that action is permitted. This 265 document is solely concerned with the first step, authentication. 267 2.2. Authentication Building Blocks 269 The classic formulation of authentication is that there are three 270 different elements that can be employed, alone or in combinations 271 together:: 273 1. Something you have--a physical token like a key. 274 2. Something you know-- something known only to you, not recorded 275 anywhere where another could obtain and use it, a secret, e.g., a 276 password 277 3. Something you are--some physical characteristic unique to you, 278 e.g. a thumbprint. 280 The best authentication mechanisms combine two or more of these 281 mechanisms. For instance, if you use a driver's license or a 282 passport to authenticate, that's something you have (the license) and 283 something you are (your resemblance to the picture on the license). 284 In practice, biometric authentication mechanisms work poorly over the 285 Internet. Biometric authentication mechanisms work best where the 286 relying party can directly verify the presence of the person being 287 authenticated. In general this is not possible over the Internet 288 because the relying party does not control the authenticating party's 289 computer. Thus, it is difficult to distinguish real authentications 290 from replay attacks mounted by attackers who have captured the user's 291 biometric information. So the best Internet authentication 292 mechanisms will involve a token plus a secret. 294 2.3. Clients and Servers 296 Most of the protocols which run on the Internet are inherently 297 asymmetric, with one peer taking the role of the client and the other 298 the server. Because the servers are generally fixed machines with a 299 fixed IP address and the clients may have any IP address, many 300 protocols (such as SSH or TLS) operate by attempting to authenticate 301 the server first and, if that succeeds, to then authenticate the 302 client. This occurs because the client wants to disclose it's 303 identity (and certainly its credentials) only to the "real" server, 304 not an imposter. When such systems are used in peer-to-peer 305 contexts, it is still necessary for one peer to take on the client 306 role and one the server. Typically, the party which spoke first (the 307 initiator) is treated as the client. 309 Even protocols which are peer to peer (such as IKE) require one party 310 to speak first. In such cases, it's appropriate to refer to that 311 party as the initiator and the other as the responder. 313 3. Basic Authentication, Attacks, and Counter Measures 315 This section will describe the early forms of authentication systems, 316 the attacks they attracted, and the counter measures taken. These 317 descriptions will lay a foundation of understanding and terminology 318 that is useful for understanding the mechanisms in the sections that 319 follow it. 321 The most basic form of authentication is for the client to provide a 322 username/password pair to the server. The server then verifies the 323 password against the user's stored credentials. If they match, the 324 server allows the client to access the resource. 326 The most primitive approach is for the server to simply store the 327 user's username and password in a file on the server's disk. This 328 has the serious problem that if the password file is somehow 329 compromised, the attacker has immediate access to all user passwords 330 and can log in as any user. The standard approach, first described 331 by Wilkes [Wil68], is to store the output of a one-way function 332 (typically a cryptographic message digest (see [RFC4949] for a 333 definition of terms like this)) of the password instead of the 334 password itself. When the server needs to verify a password, it 335 computes the function using the password as input and compares the 336 output against the stored output. Because the function is one way, 337 the server cannot recover the user's password from the password file. 338 Therefore, anyone gaining access to the password hash file also 339 cannot recover the user's password from the password file. 341 3.1. Password Sniffing 343 The simplest attack against passwords delivered by client is simple 344 password sniffing. The attacker arranges to intercept traffic 345 between the client and the server (this is relatively easy, 346 especially if the attacker is on the same network as one of the 347 endpoints). Since the password traverses the network in the clear, 348 the attacker is easily able to recover the password and can use it 349 for any future authentications. 351 3.2. Post-Authentication Hijacking 353 An attacker who can hijack network connections need not know the 354 user's password at all. He can simply wait for the user to complete 355 his authentication and then take over the connection. This attack is 356 more difficult to mount than password sniffing, but as we'll see 357 later, it can be useful when stronger authentication schemes are 358 employed. 360 This attack can be prevented. The connection must use some form of 361 per-packet (or per segment) cryptographic authentication which can be 362 neither mimicked nor guessed by a man-in-the-middle. More on this 363 later. 365 3.3. Online Password Guessing (aka Brute Force Attack) 367 Extensive experience [Klein90] shows that users choose bad passwords. 368 Common choices include the user's real name, login name, date of 369 birth, and simple dictionary words. An attacker with no special 370 capabilities can therefore attack a server by simply trying known or 371 common usernames and common passwords. This technique was used to 372 great effect by the Morris worm [Worm88] 374 The standard countermeasure to this attack is to make it difficult 375 for the attacker to try a large number of passwords. This can be 376 done by incorporating a LIMITED TRY capability. After some number of 377 failed attempts, the system simply locks the account and the user 378 cannot log in even with the correct password. Unfortunately, simple 379 limited try provides the attacker with an easy denial-of-service 380 (DoS) attack--he can lock any account simply by performing failed 381 logins. 383 A superior approach is to incorporate a delay. For instance, the 384 system might allow the user to immediately try 3 passwords, but after 385 three failures lock the account for 60 seconds, increasing the delay 386 (up to some fixed maximum) for each failure. This is a less 387 effective countermeasure than simple limited try but resists the DoS 388 attack better. 390 3.4. Offline Dictionary Attack 392 Even if digested password files are used, it still often possible for 393 an attacker who recovers the digested password, or password file, to 394 discover user's passwords. The attacker can mount an OFFLINE 395 DICTIONARY ATTACK on the password or password file. A dictionary 396 attack uses the fact that users tend to choose words rather than 397 random strings in order to narrow the scope of exhaustive search. 398 The attacker simply runs through each word (and common variations) in 399 sequence, comparing the digest of the trial word against the digest 400 in the password file. There are a number of programs available to 401 mount this sort of attack, including the classic Crack [Crack] 402 program. 404 An OFFLINE DICTIONARY ATTACK can occur in two ways. First, using 405 sniffing, an attacker who sits along the path of packets between two 406 hosts can observe the transmission, extract a digested password, and 407 work offline to find a matching password. A second variation occurs 408 when an attacker recovers the entire digested password file for a 409 system. 411 There are four basic countermeasures to offline dictionary attack. 413 3.4.1. Shadow Passwords 415 The first countermeasure to an offline dictionary attack is to deny 416 attackers the password digest. In the original UNIX systems, reading 417 the password file was the only way to get information about users and 418 therefore the password file had to be publicly readable. Later 419 systems introduced SHADOW PASSWORDS, whereby the password file 420 contained a dummy password and a second copy of the password file 421 containing the encrypted passwords was unreadable except to root. 422 Thus, unprivileged user processes would consult the ordinary password 423 file (now containing dummy passwords) to get user information (such 424 as name, home directory, etc) but only privileged processes can read 425 the encrypted passwords. Of course, sometimes an attacker can 426 convince a privileged process (via bugs) to give him a copy of the 427 file, thus allowing him to attack it. 429 3.4.2. Iteration 431 The second type of countermeasure is to make search slower. One 432 approach is to simply make the hash function slower. The original 433 UNIX crypt() function did this by repeating the basic operation 434 (based on DES) 25 times. (The designers also slightly modified the 435 operation so that it couldn't be done with ordinary DES hardware.) 436 The idea here is that noone will notice a second or so delay on login 437 but that making each guess take a second will seriously slow down an 438 attacker. To compensate for the speed of modern computers, rather 439 more iterations are currently required each year. 441 3.4.3. Salting 443 If a simple hash of the password is stored in the password file, then 444 an attacker can attack all the passwords in the file in parallel. He 445 simply generates the hash of each candidate and then compares it 446 against each stored hash. In order to prevent this attack, many 447 systems SALT the hash with some random value (which is different for 448 each user). Thus, instead of storing simply H(password) they store 449 salt || H(salt || password), with the result that even two users who 450 have the same password will in general not have the same stored 451 password hash. One interesting innovation is to use a secret salt. 452 This requires the attacker to try all possible salts, automatically 453 slowing down the process (thereby making iteration unnecessary). 455 3.4.4. Stronger Passwords 457 The reason that dictionary attacks are so easy is that users choose 458 bad passwords. Even the 8 character UNIX password space allows 2^56 459 possible passwords--a search space that is impractical for most 460 attackers to search. One obvious countermeasure is to force users to 461 choose stronger passwords. This can be done reactively by running a 462 password cracker on your system or proactively by forcing users to 463 use stronger passwords when they set them. It's also possible to 464 force users to use randomly generated passwords. Unfortunately, 465 unguessable passwords are often less memorable, causing users to 466 write them down. It's not clear that this is an improvement. 467 Security-conscious people are often willing to use complex mnemonics 468 to help remember random passwords but ordinary users are not. One 469 welcome innovation on this front is the replacement of the old UNIX 470 DES-based crypt() function with an MD5-based function that accepts 471 longer passwords, allowing the user to have a meaningful but still 472 harder to guess password. 474 After a lengthy discussion about passwords and their etropy, NIST 475 800-63 [SP800-63], Appendix A, page 52 suggests a system that uses: 477 o a minimum of 8 character passwords, selected by subscribers from 478 an alphabet of 94 printable characters, 479 o required subscribers to include at least one upper case letter, 480 one lower case letter, one number and one special character, and; 481 o Used a dictionary to prevent subscribers from including common 482 words and prevented permutations of the username as a password. 484 3.4.5. Encrypted Channel 486 Another countermeasure is to deny inline attackers a view of the 487 password. TLS is an example of a protocol that provides for this. 488 Using certificates (described in a different section below), the 489 client first verifies the identity of the server, then the two 490 establish an encrypted channel. Once the encryption is in place, the 491 HTTP authentication occurs in which the client's password digest is 492 sent to the server. The TLS encryption prevents an attacker from 493 seeing the authentication digest, and thus from attempting an OFFLINE 494 DICTIONARY ATTACK. 496 3.5. Phishing 498 Even an attacker with no access to the victim's network can capture a 499 user's password with a social engineering attack (often called 500 PHISHING). In the basic attack, the attacker sends the victim an 501 email posing as some site that the victim has a relationship with 502 (e.g., eBay, a bank, a web-based email service, or a corporate IT- 503 Support Helpdesk) and containing a URL [RFC4248], [RFC4266] for the 504 user to dereference. When the user dereferences the URL he is 505 prompted for his password, which he often supplies. (See also 506 [DTH06]). 508 3.6. Case Study: HTTP Basic Authentication 510 HTTP basic authentication [RFC2617] is the original HTTP 511 authentication mechanism. It's a simple username/password scheme. 512 The server prompts the client with a request for authentication (in a 513 WWWAuthenticate header). The client responds with the password in an 514 Authorization header. The password is base-64 encoded but this 515 doesn't provide any security, just protection from damage due to 516 transport reencoding. 518 3.6.1. Password Caching 520 Any reasonable Web page fetch consists of a number of HTTP fetches, 521 each of which may requires HTTP authentication. Requiring the user 522 to type in his password for each such fetch would be prohibitively 523 intrusive. Accordingly, web clients typically cache the user's 524 password for some time (generally for the lifetime of the browser 525 process.) 527 In some cases, the browser will cache password on disk so that the 528 user never has to type in the password again. This practice 529 introduces a new security problem: protection of the user's cached 530 passwords. These passwords can be encrypted on disk (under another 531 password) but users often find this inconvenient and so the passwords 532 are often stored on the disk in the clear. This is dangerous on 533 multiuser machines, even ones which provide strong file permissions, 534 since administrators can still read such cache files. 536 3.6.2. Proactive authentication 538 Requesting a page, receiving an authentication challenge and 539 rerequesting with a password introduces an extra round-trip. This 540 latency can be quite significant if the original request was large, 541 such as with a file PUT. Thus, many clients proactively send their 542 cached passwords whenever accessing any URL deeper than the URL for 543 which they were originally prompted. 545 3.7. List of Systems that Use Passwords in the Clear 546 FTP(when none of GSSAPI-KRB5, SRP, or TLS are negotiated) 547 TELNET (when neither AUTH or STARTTLS are used) 548 HTTP (basic authentication) 549 SASL (password mode) 550 RLOGIN 551 POP (among others mechanisms) 552 IMAP (among other mechanisms) 553 (too many others to mention) 555 The next six sections each describe a single class of authentication 556 technology, according to the format described in the introduction 557 Section 1 559 4. One Time Passwords 561 The simplest approach to preventing sniffing attacks on passwords is 562 to use ONE TIME PASSWORDS. In its basic form, the user is provided 563 with a password (or list of passwords) that can only be used once, 564 making replay attack impossible. The passwords are still transmitted 565 in the clear, but since each one can only be used once, a sniffed 566 password cannot be used as an authenticator. 568 The major use of one-time password systems is to improve the security 569 of protocols which previously used password authentication. One-time 570 password schemes can be designed such that they require no changes to 571 the client software and only minimal changes to the server software. 573 One-time passwords are generally used in one of two ways: a single 574 one-time password used to bootstrap a trust relationship, or a 575 continuous use of one-time passwords, i.e. new one-time password used 576 at each login. 578 A one-time password may be used to bootstrap a trust relationship. 579 For example, a user might be given a single one-time password to 580 access a system. Once authenticated to that system, the user will be 581 asked to supply a new, personalized password that will be used from 582 then on. Similarly, a one-time password can be used to authenticate 583 a first exchange of long-term keys (e.g. asymmetric keys) between two 584 parties. This system is particularly good when many users or end- 585 point machines will be connecting to a well-known, central system, 586 but the user/end-points are not pre-known to the server. An example 587 is a smart-phone-based email client doing a first time registration 588 from the a new smart phone to the provider's server. The phone will 589 ship with the provider's server's IP address, and public key. pre- 590 installed The user will be given the one-time password and enter it 591 via the smart phones UI on the first connection only. The user 592 initiates a secure connection to the server, and uses the server's 593 verification material to confirm the server's identity. It then uses 594 the one-time password to authenticate itself to the server. It will 595 then send it's public key (from a pre-computed asymmetric key pair) 596 to the server, again, authenticated by the one-time password. The 597 server verifies the received messages using the one-time password, 598 and confirms the identity of the host. It can then trust the 599 credentials, the public key, passed to it by the host. Henceforth 600 the two parties will authenticate one to the other using their public 601 keys. The one-time password is expired and discarded. 603 The second main use of one-time passwords occurs when the user 604 (generally) has either a physical password list or a token that 605 computes the password, but the client software does not need to be 606 replaced and the wire protocol is unchanged. 608 The remainder of this section will describe three specific case 609 studies of continuous use one-time password implementations available 610 today: S/Key, OTP and SecurID. None of these one-time password 611 schemes are very useful for automated authentication, since they only 612 provide a limited number of keys. Using automated authentication 613 with S/Key or OTP it is easy to quickly use up a large number of 614 keys. SecurID provides an essentially infinite number of keys but 615 they are changed too infrequently to be usable in most automated 616 systems. 618 As with ordinary passwords, one time password mechanisms are subject 619 to a number of active attacks. However, even if the attacker 620 captures a specific authenticator via an active attack, he can use it 621 only once, not indefinitely. 623 4.1. Case Study: S/Key and OTP 625 S/Key [RFC1760], invented by Neil Haller and Phil Karn, is a 626 straightforward one time password system that uses some clever 627 implementation tricks. One-Time Passwords (OTP) [RFC2289] is the 628 successor protocol to S/Key, standardized by the IETF. In S/Key, the 629 one time passwords are constructed by iteratively hashing a public 630 seed and a secret. Thus: 632 P[0] = H(Seed,Secret) 633 P[i] = H(P[i-1]). 635 Passwords are used in reverse order. This allows the server to 636 simply store the last password that it received (P[i]). The client 637 will next authenticate with P[i-1]. The server can verify a password 638 by hashing it and checking to see if it matches the stored password. 639 Once authentication is complete, the server simply deletes the old 640 password and stores the new one. 642 S/Key uses a special password encoding that's designed to make it 643 easy for users to type passwords without errors. The 64-bit one-time 644 password is broken up into a sequence of six 11-bit values (with the 645 remaining two bits being used as a checksum). Each 11-bit value is 646 used as an index into a fixed dictionary of 2048 short words. Thus, 647 a password might look like: 649 INCH SEA ANNE LONG AHEM TOUR 651 This encoding is intended to be easier to type than base64 or 652 hexadecimal. (Though hexadecimal is defined as well). 654 S/Key can be used in two modes. In the first, the client is simply 655 provided with a list of passwords on a piece of paper. He uses one 656 at a time and crosses them off as he goes. In this case, the Secret 657 is usually cryptographically random. In the second mode, the client 658 has a token or a computer program that he uses to calculate the 659 appropriate S/Key key. In this case, the Secret is generally some 660 user-memorable password which the user keys into the program or 661 token. 663 S/Key scheme has a number of nice properties. First, the password 664 file need not be kept secret, since going from P[i] to P[i-1] 665 requires reversing the message digest, which is believed to be 666 computationally infeasible. (Note: if a text password is used as 667 the secret then the password file is still subject to dictionary 668 attack, but a passive attacker who recovers ANY S/Key authenticator 669 can mount a dictionary attack on it (by iteratively hashing the 670 potential seed), so it's not that important to keep the password file 671 per se secret). 673 Second, it's easy for the user to rekey: He simply creates a new 674 Secret, generates a set of keys and sends the last one to the server. 675 Note that it's of course possible for an active attacker to hijack a 676 connection and rekey with a key of his choice, thus one time 677 passwords are in general a poor choice when active attack is part of 678 the threat model. 680 4.1.1. Race Conditions 682 S/Key has an interesting security flaw: Consider a protocol where 683 passwords are transmitted one character at a time. A passive 684 attacker might wait for the victim to log in and then create his own 685 login connection at the same time. The attacker would then echo the 686 victim's password character for character, until there was only one 687 character left. At this point the attacker would simply guess the 688 last character and then complete the authentication. This attack is 689 relatively simple to mount because nearly all the words in the S/Key 690 dictionary are 4-characters long and the number of words with any 691 given 3-letter prefix is generally quite small (2 or 3). 693 The standard countermeasure to this attack is to only allow one 694 pending authentication for a given user at any given time. In order 695 to prevent DoS attacks, there must be at timeout on any such pending 696 connection. OTP implementations are required to implement this or 697 some other countermeasure. 699 4.2. Case Study: SecurID 701 Probably the most commonly deployed commercial one time password 702 implementation is SecurID, sold by RSA Security Inc. Instead of using 703 a fixed list of keys, SecurID uses a time-dependent, six digit key. 704 The user has a token with an LCD displaying a pseudo-random number. 705 That number changes at an interval between 30 seconds and 2 minutes 706 and is synchronized with an authentication server located at the 707 server. SecurID also has the advantage that it employs two-factor 708 authentication (as describe above Section 2.2), combining something 709 you have, the token, with something only you know, a personal 710 identification string, or PIN. 712 In order to authenticate the user enters both his PIN and the time- 713 dependent key (they can be concatenated so that this is transparent 714 to the client program.) For example where the user's PIN is 715 "2Enl0*/b" and the OTP on the token currently reads "041 980", the 716 user will simply enter in the password field of the application 717 "2EnI0*/b041980". This value will then be used as the password for 718 whatever authentication function the client and server are using. 719 The server verifies the password and checks that the time-dependent 720 key is correct for the current time and only then allows login. If 721 sent in the clear (versus being used in some challenge/response 722 mechanisms; see next section), it's clearly possible for an attacker 723 to capture the password and replay it but without the token he 724 (theoretically) can't generate the right time-dependent key (unless 725 the replay is executed within the same time window as the current 726 value). When sent using a cryptographic message digest function, 727 this weakness is mitigated. 729 4.3. List of One-Time Password Systems 731 Note: any system that uses passwords can be adapted to use one-time 732 passwords. 734 Single One-Time-Password used for bootstrapping 735 S/Key [RFC1760] 736 OTP [RFC2289] 737 SecurID [RFC2808] 739 5. Challenge/Response 741 CHALLENGE/RESPONSE mechanisms fix the sniffing problem associated 742 with ordinary passwords. The basic idea is simple: the verifying 743 party provides a random (or at least unique) challenge and the 744 authenticating party returns some function of the shared key and the 745 challenge. Generally this function is some sort of message digest. 746 In the simplest form it is H(challenge || key), where H is a 747 cryptographic message digest and "||" denotes message concatenation. 748 A better design is probably to use HMAC [RFC2104] which has stronger 749 security guarantees. 751 Challenge/response mechanisms are resistant to simple sniffing 752 attacks but in general have all the other security problems of 753 ordinary password systems. Additionally, they are vulnerable to 754 another form of offline dictionary attack and are more vulnerable to 755 password file compromise than correctly implemented password in the 756 clear systems. 758 Challenge/response mechanisms can be completely hardened against 759 offline dictionary attacks by the use of a sufficiently large 760 randomly-generated shared key instead of a password. Such a password 761 is of course difficult for a user to memorize but is quite useful if 762 it can be statically configured on both sides of a connection. 764 Unlike simple password mechanisms, challenge/response mechanisms can 765 be designed which provide both mutual authentication and secure key 766 exchange. Such systems can be made resistant to most forms of active 767 attack, and depending on the strength of the shared key, passive 768 attacks as well. 770 There also explicit challenge response systems, where users are 771 stepped through a challenge and response exchange where they must use 772 a one-time-password token system. For example, as a user attempts to 773 login to a Telnet session, the server sends a challenge. The user 774 sees this challenge appear on the screen. Holding an electronic one- 775 time-password token, she uses its key pad to key in that challenge. 776 The token responds by displaying a one-time response to that 777 challenge. The user concatenates the token's response with her PIN 778 and sends it back over the Telnet session login. The server checks 779 that both the correct PIN and one-time-password are used. 781 A challenge-response system can also be turned into a secure channel 782 protocol by using the shared key to establish cryptographic keys 783 which are then used to encrypt the traffic. In this context, a 784 CHANNEL is a security association between two endpoints through which 785 further security exchanges may occur. A secure channel would be 786 offer encryption, authentication and integrity-checking on a per- 787 packet basis. TLS-PSK [RFC4279] is one example of such a system. 789 5.1. Offline Attacks on Challenge/Response 791 Although a passive attacker cannot mount an ordinary sniffing attack, 792 he can combine sniffing with an offline dictionary attack. The 793 attacker simply captures a single challenge/response exchange and 794 then dictionary searches the password space until he finds a password 795 that produces the correct response for a given challenge. With high 796 probability (though not certainty) this will be the correct password. 797 This problem is inherent in all simple challenge response mechanisms 798 and cannot be fixed without public-key technology. This problem is 799 inherent unless public-key methods are incorporated within the 800 challenge-response protocol, as will be discussed in Sections 6 and 801 7, or the challenge-response transactions are carried over secure 802 channels (which themselves must be authenticated). 804 5.2. Password File Compromise 806 Challenge/response mechanisms also introduce a new problem: PASSWORD 807 EQUIVALENCE. In order to locally compute (for verification purposes) 808 the appropriate response for a given challenge, the server must store 809 the user's password locally. Thus, if the password file is 810 compromised, the attacker can directly log in to the server, without 811 even needing to crack the password file. We'll call this property 812 WEAK PASSWORD EQUIVALENCE. 814 A more serious variant of the same problem occurs if users use the 815 same password on multiple systems. Compromise of one system can thus 816 lead to compromise of many. This is called STRONG PASSWORD 817 EQUIVALENCE. This risk should not be overstated--compromise of an 818 ordinary password system can still lead to attack if the attacker 819 completely compromises the system and can capture people's passwords 820 when they login--but is nevertheless worse in challenge/response than 821 with ordinary passwords. The standard countermeasure is to use a 822 two-stage digesting process, such as: 824 STORED = H(PASSWORD || SALT) 826 RESPONSE = H(STORED || CHALLENGE) 828 The server stores STORED instead of the password. (Making STORED 829 effectively the password). The server then gives the client both 830 SALT and CHALLENGE, allowing the client to compute RESPONSE from the 831 password alone. Note that the two-stage process only prevents 832 compromise of one system from affecting others. Compromise of a 833 password file still allows immediate access to the target system. 835 SCRAM [I-D.newman-auth-scram] describes one defense against this sort 836 of attack. The server stores a hashed version of the password, and 837 must prove that it knows it using challenge-response. The client 838 then provides the preimage for the hashed password, thus 839 demonstrating that it knew the original password. With this system, 840 an attacker who recovers the password file can immediately 841 impersonate the server to the client, but not the client to the 842 server. However, if he impersonates the server to the client he can 843 capture the preimage and can then impersonate the client to the 844 server. 846 5.3. Case Study: CRAM-MD5 848 CRAM-MD5 [RFC2195] is a challenge/response authentication extension 849 for IMAP [RFC3501] CRAM-MD5 is a classic challenge/response system: 850 the server provides a presumably random challenge and the client 851 transmits an HMAC of the challenge using the shared key as the HMAC 852 key. The interaction looks like this: 854 1 S: * OK IMAP4 Server 855 2 C: A0001 AUTHENTICATE CRAM-MD5 856 3 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ 857 4 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 858 5 S: A0001 OK CRAM authentication successful 860 The second message from the server (message 3) is the base-64 861 encoding of the string "<1896.697170952@postoffice.reston.mci.net>". 862 This string must be in the form of an email address [RFC5322] and is 863 intended to be globally unique. The client's response (message 4) is 864 computed using HMAC-MD5(password,challenge) and then base-64 encoded 865 for transmission in message 4. 867 CRAM-MD5 is an improvement on the password-in-the-clear mechanisms 868 that it replaces but still has all the security flaws of basic 869 challenge/response mechanisms. In particular, it is vulnerable to 870 postauthentication hijacking and is strongly password equivalent. 872 CRAM-MD5 has some interesting security properties with respect to 873 server password file compromise. The RFC encourages servers to store 874 a pre-initialized HMAC context rather than than the client's 875 password. Since the password has already gone through the MD5 876 compression function, it is believed to be infeasible to recover the 877 password from the context. However, since the HMAC context is 878 sufficient to compute any response without knowing the key, an 879 attacker who recovers the context can impersonate the client without 880 knowing the key. This context will be the same for all servers which 881 share the same password. The result of these facts is that an 882 attacker who recovers the password file from such a server can attack 883 any other server which (1) uses CRAM-MD5 and (2) has a user with the 884 same password. However, it cannot attack other users with the same 885 password on machines with a different authentication mechanism (since 886 that would require direct access to the password rather than the HMAC 887 context). 889 5.4. Case Study: HTTP Digest 891 HTTP Digest Authentication [RFC2617] is a replacement for HTTP's 892 notoriously weak Basic Authentication mechanism, which used passwords 893 in the clear. Digest Authentication is a challenge/response 894 mechanism with some additional features to prevent hijacking attacks 895 and remove strong password equivalence, as well as to reduce round 896 trip time for multiple requests. 898 The basic Digest Authentication interaction takes two round trips. 899 In the first, the client requests some document and is rejected. The 900 server's rejection (a 401 Unauthorized) contains an indication that 901 it supports Digest Authentication, a realm string, and a random 902 challenge. The client's subsequent request includes a message digest 903 over the password, the challenge, and part of the HTTP Request. 905 HTTP Digest offers two types of integrity check (the field specifying 906 them is called "qop" for quality of protection). The "auth" scheme 907 covers only the request URI. The "auth-int" scheme protects the URI 908 and the message body, but not the message headers since they may be 909 changed in transit by proxies or other intermediaries. Negotiation 910 of the qop is simple: the server offers a set of acceptable qop 911 values and the client chooses one. 913 5.4.1. Message Integrity 915 As previously noted, simple challenge/response schemes without 916 associated channel security allow an attacker to hijack the 917 connection after authentication has occurred. Since each HTTP 918 request must be individually authenticated, an attacker who takes 919 over the channel cannot transmit new unauthenticated requests over 920 that channel. However, an attacker might attempt to intercept an 921 authenticated request and mount a cut-and-paste attack, leaving the 922 authenticator but changing the contents. This attack is prevented by 923 including the URI in the message digest. 925 Unfortunately, the URI isn't the only piece of security relevant 926 information in the HTTP request. Both the headers and the body are 927 potentially sensitive. For instance, if HTTP POST is used, FORM 928 input values will be in the message body. The auth-int qop value 929 protects this information, but it is not widely deployed. None of 930 the qop values protect the headers. 932 It's worth noting that Digest provides protection only for the 933 request. No authentication is provided for the server, nor is 934 message integrity provided for the response. It's technically 935 possible to provide this feature using a shared key, as is done in 936 S-HTTP [RFC2660], but Digest doesn't do so. 938 Digest deployment has been somewhat spotty in the past. For 939 instance, the popular Netscape Navigator 4 versions did not support 940 it. More recently, Internet Explorer 7.0 +, Mozilla Firefox 2.0+, 941 Netscape 7+ all support digest authentication. SIP [RFC3261] 942 requires Digest authentication and it is near universal there. 944 5.4.2. Replay Attack 946 Many HTTP requests are idempotent. In such cases, replay attacks are 947 not a problem since the attacker doesn't get any information that he 948 would not get by sniffing the original request. However, many HTTP 949 transactions have side effects and in such cases preventing replay is 950 important. Unfortunately, the conventional approach of requiring a 951 separate challenge/response exchange for each authentication would 952 double the number of round-trips for each transaction. 954 HTTP Digest provides two features to avoid these round trips. First, 955 the server can provide a new nonce in a response header. This nonce 956 must be used for the next client request. This feature interacts 957 poorly with request pipelining so HTTP Digest also allows the client 958 to issue multiple requests using a given server challenge by using a 959 request sequence number (the "nonce-count"). 961 5.4.3. Downgrade Attack 963 HTTP Digest suffers from two types of downgrade attack. In the first 964 type of attack, the attacker forces the peers to agree on Basic 965 authentication rather than on Digest. There is no realistic way to 966 protect against this attack, other than simply refusing to send Basic 967 at all--note that the server refusing to accept it does not help, 968 since the attacker can impersonate the server. 970 In the second Downgrade attack, the attacker forces the peers to 971 negotiate a qop of "auth" instead of "auth-int". The downgrade 972 attack would then presumably be followed by an integrity attack on 973 the client request. This attack could be prevented by requiring the 974 client to include a digest of the server's offered qop values in the 975 client's authenticator. However, that is not the case with the 976 current scheme. 978 5.5. List of Challenge-Response Systems 980 APOP [RFC1939] 981 HTTP Digest [RFC2617] 982 AKA [AKA] 983 CRAM-MD5 [RFC2195] 984 Kerberos password-based authentication [RFC4120] 986 6. Anonymous Key Exchange 988 All three of the mechanisms mentioned so far can be hardened against 989 passive attacks by the use of anonymous key exchange. Essentially, 990 the peers arrange for a secure channel using a key establishment 991 mechanism that does not authenticate either side. Public key 992 algorithms such as Diffie-Hellman and RSA can be used in this way. 993 Once the key is established you can encrypt all the traffic. and any 994 data which is transmitted over the channel is secure from 995 eavesdroppers. This includes data such as passwords or 996 authenticators. 998 The problem with this system is that it's subject to what's called a 999 man-in-the-middle (MITM) attack. Because the cryptographic key 1000 establishment mechanism is unauthenticated, it is possible for an 1001 attacker to intercept communications between the peers (say Alice and 1002 Bob) and pose as Alice to Bob and Bob to Alice. The attacker can 1003 then forward traffic between them and get access to whatever's being 1004 encrypted. 1006 The MITM attack on Diffie-Hellman key exchange is shown in the 1007 following figure. Yc, Ya, and Ys are used to denote the client, 1008 attacker, and server public keys respectively. 1010 Client Attacker Server 1011 ------ -------- ----- 1012 Yc -> 1013 Ya -> 1014 <- Ys 1015 <- Ya 1017 At the end of this exchange the client thinks that the server's 1018 public key is Ya and the server thinks that the client's public key 1019 is Ya. However, in reality both have established a shared secret 1020 with the attacker. Thus, when the password is transmitted over 1021 channel the attacker sees it. 1023 So we see that with if only one side of the connection is 1024 CRYPTOGRAPHICALLY authenticated this attack cannot be detected.Thus, 1025 how much security you believe that anonymous key exchange adds to 1026 your protocol depends on your threat model. Active attacks are 1027 generally more difficult to mount than passive attacks but by no 1028 means impossible [Bell89] 1030 All of these mechanisms use public key cryptography to perform the 1031 initial anonymous key exchange. As a result, performance can be 1032 unacceptably slow if one side (e.g., a handheld device) is heavily 1033 constrained. Such concerns were more relevant when the Diffie-Helman 1034 technology first came to commercial maturity in the late 1990s. As 1035 processing speeds increase per Moore's Law, and as smart phones are 1036 given more and more powerful processors, this concern reduces. Most 1037 Internet servers are fast enough to keep up with the normal number of 1038 required authentications and hardware acceleration solutions are 1039 readily available. This is not to say that performance is of now 1040 concern. Moore's law has to some extent been counter-balanced by an 1041 increase in the size of common keys. 2048-bit keys are now quite 1042 common and the potential for even larger keys has lead to an 1043 increased interest in elliptic curve cryptography. 1045 6.1. Case Study: SSH Password Authentication 1047 Secure Shell (SSH) provides a number of authentication mechanisms, 1048 but the first step is always to establish a secure channel between 1049 the client and the server. SSH is designed not to require 1050 certificates: the server merely provides a raw public key to the 1051 client. As a countermeasure to man-in-the-middle attack, the SSH 1052 client caches the server's public key and generates a warning or 1053 error (depending on the implementation) if that key changes. 1055 In theory, caching the public key protects against MITM attack at any 1056 time other than the initial connection to the server. In practice, 1057 when users encounter the error that the key has changed, they may 1058 simply override the warning or delete the cache entry when the error 1059 occurs, assuming, correctly, that the likely case is that the server 1060 administrator has just reset the public key (e.g. by reinstalling the 1061 software without preserving the old key). 1063 A very careful user can obtain complete security against MITM attacks 1064 by obtaining the server's key fingerprint (a message digest of the 1065 key) out of band and comparing that to the fingerprint of the key the 1066 server offers. Machines and their user interfaces can easily be made 1067 to perform this check in a predictable way. For example, if one 1068 machine uses SSH as a secure channel for management of a second 1069 machine, the application on the first machine can prompt the 1070 administrator for the second's fingerprint and not continue until the 1071 string is received. It can then check upon every connection that 1072 what it sees from the second machine matches what was entered. 1074 SSH bootstraps off of the system's login mechanisms so it will 1075 support either passwords in the clear or one time password 1076 authentication. Note that in either case if an attacker mounts a 1077 successful man in the middle attack, he will be able to hijack the 1078 connection post-authentication, just as he would have if the 1079 transaction was performed in the clear. This vulnerability can be 1080 alleviated with careful protocol design, as we'll see in the next 1081 case study. 1083 Another option is to combine a one-time-password with public keys. 1084 In such a system, a host first authenticates itself to the other 1085 using the one-time-password, then, once the first SSH channel is 1086 established, securely passes a public key for long term use. On the 1087 next connection, the public key will be used, and the fingerprint of 1088 that key will be used to validate it. 1090 6.2. List of Anonymous Key Exchange Mechanisms 1092 SSH (password mode) [RFC4251] 1093 IPsec using IKEv2 with unauthenticated public keys, aka BTNS 1094 [RFC5386] 1095 SSL/TLS (anonymous keying) [RFC5246] 1097 7. Zero-Knowledge Password Proofs 1099 All of the mechanisms mentioned so far depend on some sort of shared 1100 key. If that shared key is a user-derived password, then it's 1101 possible for the attacker to mount an offline dictionary attack on 1102 the password, either completely passively (as with CRAM-MD5) or with 1103 a single MITM attack (as with TLS anonymous DH). However, a rather 1104 clever class of protocols known as Zero Knowledge Password Proofs 1105 (ZKPPs) makes it possible to use user-generated passwords without 1106 fear of offline dictionary attack 1108 The earliest (and simplest) ZKPP is EKE [Bell92], designed by Steve 1109 Bellovin and James Merritt. EKE is based on Diffie-Hellman, but 1110 instead of sending the key shares (the public keys) in the clear they 1111 are encrypted using a password. The protocol looks like this. 1113 Client Server 1114 ------ ----- 1115 Name, E(Password, Ya)) -> 1116 <- E(Password, Yb),E(K,Challenge-b) 1117 E(K,Challenge-a || Challenge-b) -> 1118 <- E(K, Challenge-a) 1120 Where K is the DH shared secret == g(Xa * Xb) mod p, E(blah, blah) is 1121 encryption using the elements within the paranthesis, Ya = public key 1122 of client, Yb = public key of server, and Challenge-a and Challenge-b 1123 are random stings. 1125 Note that EKE as described above is insecure against password file 1126 compromise, since the server must store the password. Augmented EKE 1127 [Bell94] describes a protocol that is secure against this. A large 1128 number of other ZKPPs have been proposed, including PDM [KP01], SPEKE 1129 [Jab96], and SRP [RFC2945]. These protocols are all roughly 1130 equivalent, offering slightly different combinations of security, 1131 performance, and message count. 1133 7.1. Intellectual Property 1135 From a technical perspective, ZKPPs dominate the anonymous key 1136 exchange mechanisms described in Section 6. Their performance is 1137 roughly equivalent and their security guarantees are superior. The 1138 major ZKPPs are EKE, A-EKE, SPEKE, and SRP. there are a number of 1139 Intellectual Property Rights in this area, some of which are on file 1140 with the IETF (www.ietf.org/ipr). 1142 7.2. List of Zero Knowledge Password Proof Systems 1144 EKE [Bell92] 1145 A-EKE [Bell94] 1146 PDM [KP01] 1147 SPEKE [Jab96] 1148 SRP [RFC2945] 1150 8. Server Certificates plus User Authentication 1152 If you can authenticate one side of the connection (typically a 1153 server) then it becomes far easier to provide strong authentication. 1154 Anonymous key exchange, cleartext passwords, one time passwords, and 1155 challenge/response protocols can all run over an authenticated and 1156 encrypted channel. In such a system, there's no need to worry about 1157 active attack, so the authentication protocols don't need to be 1158 hardened against it. 1160 Providing an encrypted channel with authentication for the server 1161 dramatically reduces the security advantage enjoyed by more 1162 complicated schemes over simple passwords. Since the marginal 1163 security benefit of such systems is so modest when compared to the 1164 increased implementation and deployment complexity, common practice 1165 when server authentication is available is to first establish the 1166 encrypted channel, and then send simple passwords over the encrypted 1167 channel. This includes systems such as passwords over SSL/TLS and 1168 passwords over IPsec VPNs. 1170 In addition to making the overall authentication problem simpler, 1171 hosting one's application protocol over an encrypted and 1172 authenticated channel has a number of other security benefits. 1173 First, a properly designed channel security protocol removes the 1174 threat of post-authentication hijacking (described in Section 3.2). 1175 Second, it provides confidentiality and message integrity for the 1176 rest of the application traffic, which is in general a good thing. 1178 This approach is especially applicable in client server systems where 1179 the server is well known and the clients are many. Examples include 1180 a web site being hit by many users, a remote access gateway serving 1181 many remote workers, or a content service being connected to by many 1182 subscribing applications. This approach is less well suited to peer- 1183 to-peer or mesh connections. 1185 The primary difficulty with this approach is that providing 1186 certificate-based server authentication is not straightforward. The 1187 first problem is that the server machine must have a certificate, 1188 which entails some effort, configuration, and cost. The use of self- 1189 signed certificates can ease the operational and cost issues while 1190 preserving security as long as the shal-1 fingerprint of that 1191 certificate's key is both listed in the self-signed certificate and 1192 delivered in a secure and trusted way to the end-point. Self-signed 1193 certificates without explicit verification aren't acceptable in this 1194 case (rather, they reduce one to the anonymous key exchange scenario 1195 described in Section 6). 1197 The more serious problem is establishing what the server side name in 1198 the certificate ought to be. Common practice (stemming from practice 1199 in HTTPS [RFC2818]) is to have the server's certificate contain the 1200 server's fully qualified domain name (FQDN), either in the Common 1201 Name or subjectAltName fields, but this is unacceptable if the server 1202 does not have a domain name. One can also put the server's IP 1203 address in the subjectAltName, but this is inappropriate if that IP 1204 address might change. Further, use of IP address is insufficient in 1205 cases where the "server" is actually a service intended to appear to 1206 users as one server, but in reality virtualized across several 1207 servers and IP addresses. Any protocol which uses this mechanism 1208 must specify a mechanism for determining the server's expected domain 1209 name. 1211 One concern here is what happens if the server has a certificate that 1212 has the wrong name or that is signed by a Certificate Authority that 1213 the user's client does not recognize. Many such (web browser) 1214 clients present a dialogue warning the user that the connection may 1215 be under attack and offering to let him ignore the error. The common 1216 Internet user will have no idea what this means, the implications, 1217 how to determine if the threat is real or just a configuration error, 1218 and therefore will not know how to react. The easiest path to their 1219 immediate goals is usually to chose the option to ignore the error. 1220 Obviously, if users do this routinely (and it is widely believed that 1221 they do) then they can be subject to an active attack. 1223 8.1. Case Study: Passwords over HTTPS 1225 Despite the existence of Digest Authentication, the dominant form of 1226 strong HTTP authentication is passwords with HTTP over SSL/TLS 1227 (HTTPS). As mentioned above, this mechanism has superior security 1228 properties to Digest (provided that the server has a real 1229 certificate) and is easier to deploy, especially if the server wants 1230 to use SSL/TLS for channel security in any case. 1232 There are actually two ways to use passwords over HTTPS. The first 1233 is to use HTTP's built in authentication mechanisms (either Digest or 1234 Basic) over an HTTPS connection. The second is to perform password 1235 authentication at the application layer, using an HTML form to prompt 1236 for the password. The form method is far more popular, primarily 1237 because it allows the application designer far greater control over 1238 when and how authentication occurs. In particular, the designer can 1239 give the password dialog any look he chooses. 1241 In general, if form-based authentication is used, the only available 1242 option is to use simple passwords, since HTML has no facilities for 1243 performing arbitrary computation or challenge/response passwords. 1244 Theoretically, one could perform these operations in a JavaScript or 1245 Java program, but in practice this is generally not done. 1247 8.1.1. Authentication State 1249 When Basic or Digest Authentication is used, the client can simply 1250 transmit an authenticator with every request. However, if 1251 authentication is performed using an HTML form, this approach is 1252 impractical, since it would require client interaction for every page 1253 fetch. Three approaches for solving this problem are generally 1254 proposed. 1256 8.1.1.1. The Token Problem 1258 In general, all HTTP authentication state carrying schemes involve 1259 providing the client with some token which it can then present to 1260 authenticate future requests. This token must be constructed in such 1261 a fashion that it is impossible for the client to tamper with it and 1262 obtain access to resources that they would not otherwise be able to 1263 access. 1265 There are two basic techniques for constructing tokens. The first is 1266 to have the token be self-authenticating, e.g. by having it be the 1267 user's information signed or MAC-ed with a key known only to the 1268 server. The second is to have it be an index into some database of 1269 authenticated users stored on the server. Note that these indices 1270 must be unpredictable to prevent one user from guessing another 1271 user's token. The self-authenticating approach has the advantage 1272 that it does not require persistent storage on the server but the 1273 disadvantage that there is no way to mark a token invalid or update 1274 it (although they can of course contain an expiry time). When 1275 multiple servers are involved, self-authenticating tokens have the 1276 additional advantage that they do not require inter-server 1277 communication. 1279 8.1.1.2. URL Rewriting 1281 The most general but also most difficult approach is to dynamically 1282 rewrite all URLs provided to the client after authentication has 1283 occurred. One might, for instance, pass all pages through a CGI 1284 script, where the arguments include the real page to be accessed and 1285 the authenticator token. an example of such a URL is: 1287 =MjFkNWQyOGRjYjlmM2IwMmJjMzk0NGFhODg0YTQ4YTcK?page=foo.html 1289 The CGI script would then use the authenticator argument to determine 1290 the client identity, recover the actual target page and perform the 1291 authentication checks. Using a CGI script this way is inconvenient 1292 since it requires replicating the server's access control 1293 infrastructure. A less intrusive approach involves having a server 1294 plugin unwrap the target URL early in the server's processing 1295 pipeline, before the access control checks are performed. This 1296 allows the server to perform its normal authentication checks based 1297 on the unwrapped identity. 1299 The primary difficulty with URL rewriting is that it all pages must 1300 be dynamically generated. Either each page must be generated by a 1301 script which embeds the appropriate URLs or the server must 1302 postprocess pages to embed them. Either approach makes the system 1303 more complex and therefore adds instability. However, before the 1304 introduction of cookies, URL rewriting was essentially the only 1305 option for token passing. 1307 8.1.1.3. Cookies 1309 The inconvenience of URL rewriting lead to the introduction of HTTP 1310 Cookies [RFC2695]. Essentially, an HTTP cookie is a token issued by 1311 the server and transmitted by the client with requests. The cookies 1312 can be labeled to be transmitted only when resources matching various 1313 prefixes are dereferenced, including resources on another server. 1314 Browsers generally persistently cache cookies between invocations. 1315 Cookies are the method of choice for carrying HTTP state information 1316 and can be used to carry all kinds of state besides authentication 1317 information. Note, however, that since cookies can be used to 1318 transmit information from one server to another, they have been the 1319 focus of privacy concerns [RFC2965]. Accordingly, some users choose 1320 not to accept or transmit cookies. 1322 Note that [RFC2964] specifically recommends against the usage of 1323 cookies for carrying authentication and authorization information. 1324 Nevertheless, this practice is nearly universal on the Web. 1326 8.1.1.4. HTTPS Session Binding 1328 Each TLS/SSL session has a session identifier, which is used for 1329 resuming the session without a full handshake. These session IDs are 1330 unique for any given server, so server administrators often think to 1331 use the session ID as a search key for the user's information. This 1332 is a bad idea. The fundamental problem is that there's no guarantee 1333 that any given session will be resumed. The client need not offer to 1334 resume a session and the server need not accept, or may flush its 1335 session cache at any time. Thus, using the session ID as a 1336 persistent identifier is unwise. 1338 8.2. List of Server Certificate Systems 1340 HTTP over TLS (HTTPS) [RFC2818] 1341 SMTP over TLS [RFC3207] 1342 XMPP over TLS [RFC3290] 1343 SIP over TLS [RFC3261] 1344 IPsec (under some conditions) 1345 SSH (under some conditions) 1347 9. Mutual Public Key Authentication 1349 If both client and server have certificates, then the peers can use 1350 mutual certificate authentication. This is done by having both 1351 client and server establish that they know the private keys 1352 corresponding to their certificates. A wide variety of protocols 1353 offer this functionality, including SSL, IPsec, and SSH (SSH actually 1354 offers mutual authentication with pre-arranged public keys). 1356 The two most important advantages of public key authentication are 1357 that it has no password equivalence and that it can allow 1358 authentication between parties who have no direct prior arrangement 1359 together, but who have prior arrangement with some third mutually 1360 trusted party, and some local configuration by which they will be 1361 able to accept each other's credentials.. 1363 9.1. Password Equivalence 1365 With public key authentication, the server knows only the client's 1366 public key. It is therefore incapable of forging any kind of 1367 authentication message from the client. Similarly, knowledge of the 1368 public key does not allow an attacker to authenticate to the server. 1369 Accordingly, public key techniques never store a password equivalent 1370 on the server. 1372 9.2. Authentication between Unknown Parties 1374 One advantage of certificate-based public key authentication systems 1375 --as opposed to those using pre-arranged public keys--is that it 1376 allows authentication between parties who have had no prior contact. 1377 Authentication of servers with which one has had no prior arrangement 1378 happens all the time in the HTTPS context: the user wishes to 1379 connect to a host at a given URL and is able to verify that the 1380 server certificate matches that URL. 1382 In addition to strict identity verification, it's possible to use 1383 certificates to carry authorization information. This allows a 1384 central authority to make both authentication and access control 1385 decisions for distributed servers merely by issuing certificates. 1386 [BFL96] describes such a system. 1388 Note that each party does need to do some fairly complex 1389 configuration and bootstrapping in order to contact a previously 1390 unknown party in this way. This work includes: locating a trusted 1391 third party, securely downloading and installing that third party's 1392 certificate and public key (which has complex and nested security 1393 challenges of its own), determining the protocols and configuration 1394 to be used for certificate request, retrieval, and revocation 1395 checking and life-cycle maintenance, generating a public-private key 1396 pair, crafting a certificate request, sending the certificate 1397 request, retrieving and installing the granted certificate, and local 1398 configuration about which connections should employ the certificate. 1400 9.3. Key Storage 1402 The primary security problem with public key authentication protocol 1403 (assuming the basic protocol is designed correctly) is protecting the 1404 private keys of the certificate issuer first and foremost, and 1405 secondarily of the clients. In server applications and many non- 1406 mobile client applications, the key is simply stored on disk, often 1407 encrypted under a password-derived symmetric key. In applications 1408 where the user must carry his authentication information around, this 1409 can be done in essentially two ways: with a token or by generating 1410 the key from a password. 1412 9.4. Tokens 1414 The general idea of a secure token is relatively simple: you have a 1415 tamper-resistant and portable token which carries your private key 1416 (and probably your certificate). The token can be interfaced to a 1417 computer, typically through a portable media interface, like USB 1418 drive, compact flash, SD, PCexpress, smartcard, etc. The private key 1419 is generally protected by a PIN, but of course this PIN is known to 1420 any computer on which the token is used, since the PIN is sent to the 1421 token by the computer. The primary threat to tokens is loss or 1422 theft. It's not generally economical to make such tokens completely 1423 tamper-proof, so a lost token in the hands of a dedicated attacker 1424 means a lost private key. 1426 There are two major types of tokens: those which are pure memory for 1427 key storage and those which do the cryptography on the token. The 1428 first are substantially cheaper but less secure because they give the 1429 key to the host computer. 1431 9.5. Password Derived Keys 1433 It's generally possible to derive a user's private key from a 1434 relatively short password, simply by using the password to seed a 1435 cryptographically secure pseudorandom number generator (PRNG) which 1436 is used to generate the private key. Unfortunately, this technique 1437 is susceptible to dictionary attack, since an attacker can dictionary 1438 search the password space until he finds a password that generates a 1439 key pair that matches the signature. Protocols can be designed to 1440 resist this attack by exchanging the signed client response under the 1441 server's private key, but many protocols (notably SSL/TLS) do not. 1442 Accordingly, password derived keys should be viewed as a mechanism 1443 for using shared keys with public-key-only protocols, not as a fully 1444 public key system. 1446 9.6. Case Study: SMTP over TLS 1448 SMTP can be combined with TLS as described in [RFC3207]. This 1449 provides similar protection to that provided when using IPsec. Since 1450 TLS certificates typically contain the server's host name, recipient 1451 authentication may be slightly more obvious, but is still susceptible 1452 to DNS spoofing attacks. Protection is provided against replay 1453 attacks, since the data itself is protected and the packets cannot be 1454 replayed. 1456 9.7. List of Mutual Public Key Systems 1458 SSL/TLS (client auth mode) [RFC5246] 1459 IPsec IKE [RFC4306] 1460 S/MIME [RFC3850] 1462 10. Generic Issues 1464 10.1. Channel Security Protocols 1466 Building a full security system into each application protocol is 1467 extremely expensive in terms of design and implementation effort. 1468 One common approach is to design a generic channel security protocol 1469 which provides a generic secure channel abstraction between a pair of 1470 endpoints. The endpoints of the channel can be authenticated at 1471 setup time and then all data flowing between them is automatically 1472 secured, allowing the application to be mostly agnostic about the 1473 security properties. SSL/TLS, SSH, and IPsec all provide this sort 1474 of functionality. 1476 TLS [RFC5246] provides a good example of the basic pattern, as shown 1477 below. 1479 Client Server 1480 ------ ------ 1481 <----------------- TLS Handshake ----------------> 1483 Application message (protected by TLS) ------------> 1484 <------------ Application message (protected by TLS) 1485 ... 1487 At the beginning of the TLS session, the client initiates a TCP 1488 connection to the server (TLS only works over TCP, but DTLS [RFC4347] 1489 serves a similar function for UDP), but instead of sending 1490 application data, the client and the server perform a TLS handshake, 1491 which can authenticate the server and/or the client, and which 1492 establishes cryptographic keys which are then used to protect all 1493 future traffic. This cryptographically binds any application layer 1494 traffic to the authentication performed in the handshake. 1496 A channel security protocol is not itself an authentication 1497 technology. Rather, it's built on top of an authentication 1498 technology, or on top of multiple technologies. Most such protocols 1499 support multiple types of authentication. For instance, TLS can be 1500 used with X.509 certificates, OpenPGP certificates [RFC5081], shared 1501 keys [RFC4785], and passwords [RFC5054]. 1503 10.1.1. Limited Authentication Options 1505 Because a secure channel protocol needs to be able to establish 1506 cryptographic keys, the authentication options are necessarily 1507 somewhat limited. In particular, mechanisms such as passwords in the 1508 clear (both in the reusable and one-time varieties) may not be 1509 available. (See Section 6.1 for one approach to work around this 1510 limitation.) 1512 10.1.2. Limited Application Integration 1514 Because the secure channel protocol sits beneath the application 1515 layer protocol rather than being integrated with it, the level of 1516 integration between the two protocols is fairly loose. This is an 1517 advantage in that the application security protocol need not change 1518 at all in order to use a channel security protocol. All that is 1519 needed is for the implementation to arrange for the channel security 1520 protocol to run underneath. 1522 The disadvantage is that the application protocol tends to have 1523 limited visibility into what the channel security protocol is doing. 1524 IPsec provides an extreme example of this: because much of the stack 1525 typically lives in the kernel, the application cannot even portably 1526 specify security properties or determine which properties apply to a 1527 given class of traffic association (there are APIs for this such as 1528 PF_KEY [RFC2367] but they are not universally deployed). Even with 1529 more tightly coupled protocols such as SSH or TLS, the applications 1530 are typically limited to setting general policy and interrogating the 1531 state of the association. They cannot, for instance, control the 1532 protection properties of individual PDUs. 1534 10.1.3. List of Channel Security Protocols 1536 IPsec [RFC4301] 1537 SSH [RFC4251] 1538 SSL/TLS [RFC5246] 1539 DTLS [RFC4347] 1541 10.2. Authentication Frameworks 1543 Another popular approach is to use a pluggable authentication 1544 framework. The general idea behind a pluggable application framework 1545 is that you would like the application protocol actively involved in 1546 the authentication (unlike with a channel security protocol) but that 1547 you want to avoid specifying all of the details. Typically, the 1548 protocol framework doesn't provide any authentication features per se 1549 but instead allows you to negotiate the authentication mechanisms you 1550 wish to use. SASL [RFC4422], for instance, allows the negotiation of 1551 plaintext passwords, CRAM-MD5 (a digest-based challenge/response 1552 mechanism), and TLS among other mechanisms. Another example is in 1553 IKEv2 where the EAP framework is used to allow various forms of user 1554 authentication, e.g. EAP-MD5, OTP (like SecurID) or Generic Token 1555 Card. GSS-API is another example of an authneticaion framework. 1557 Authentication frameworks are appealing to security mechanism 1558 developers since they enable mechanisms to be supported by multiple 1559 protocols by writing a single specification. In general, it is 1560 easier to provide support for a mechanism with a framework than to 1561 integrate a security mechanism within each protocol which might use 1562 it. 1564 Generic authentication mechanisms are attractive to application 1565 protocol designers because when properly used, they allow protocol 1566 designers to treat mechanism-specific details in an abstract manner. 1568 While frameworks still require protocol designers to determine the 1569 threats and required security services (e.g. need for authentication/ 1570 integrity/confidentiality/replay protection, protection against 1571 active attacks, etc.) as well as naming of the conversation 1572 endpoints, details of individual mechanisms can be abstracted. For 1573 example, it is not necessary for a protocol designer to concern 1574 themselves about how to locate a Kerberos KDC, or what information 1575 the latest revision of example.com's proprietary authentication token 1576 requires; these issues are handled by the framework. 1578 While frameworks inherently provide abstraction benefits for protocol 1579 designers, the detail hiding is generally imperfect, especially from 1580 the perspective of implementers. For instance, if the framework 1581 provides mechanisms with a wide variety of security levels, designers 1582 and implementors need to be conscious of what security is provided 1583 with each level. This is often difficult to get right. 1585 Some applications such as DNSSEC focus on providing a service to the 1586 Internet at large, that is inter-domain services. For these 1587 applications, where interoperability of authentication between 1588 parties who have no prior association is critical, having an 1589 authentication mechanism that is "mandatory-to-implement," as opposed 1590 to a pluggable authentication framework, is likely to be the right 1591 approach. Other examples include BGP's authentication mechanism 1592 TCP-AO, and DKIM. In these types of situations, an authentication 1593 framework is likely to add significant complexity. If there is not a 1594 compelling reason to use an authentication framework in such 1595 Internet-wide, inter-domain protocols, then it should not be used. 1597 For applications that are often used in intra-domain contexts, i.e. 1598 within a single organization, and where end-users are authenticating 1599 within the application, frameworks may be more appropriate. This is 1600 especially true when authentication is used in a context where 1601 parties have prior associations that they use to establish 1602 credentials. With respect to intra-domain authentication, we have 1603 seen considerable diversity in the credential types that are used. 1604 Some organizations adopt PKI and smartcards, some use token cards, 1605 others use passwords or OTP systems. Authentication frameworks 1606 enable that diversity to be supported within a single architecture. 1607 For example, SSH is typically used for a party who has established a 1608 credential to access some service. Similarly, applications like 1609 IMAP, XMPP, and LDAP are used within a context of a prior 1610 relationship. It is desirable that products from one vendor 1611 interoperate with products from another vendor. However, it is more 1612 important within an intra-domain deployment that products (like an 1613 SSH system) accessing related resources (like an LDAP server) be able 1614 to use the same authentication mechanisms. That is, the example.com 1615 administrators are more concerned that whatever SSH implementation 1616 they choose can support an authentication mechanism that is also 1617 supported in the IMAP implementation they choose, than they are 1618 having all SSH implementations share an authentication mechanism. 1619 Authentication frameworks aim to allow protocol implementers to 1620 develop applications that support this deployment goal. 1622 For protocols in the class (intra-domain), a framework may be used if 1623 it is available. If a framework is chosen, each protocol must define 1624 a mandatory-to-implement authentication mechanism. However, the 1625 framework will permit vendors to implement multiple authentication 1626 mechanisms so that those deploying implementations may choose the 1627 same mechanism across protocols. In such cases, designers should use 1628 an existing framework like EAP, SASL, or GSS-API as opposed to 1629 attempting to create something from scratch. These frameworks have 1630 taken much (re-)work to get to their current states, with more work 1631 ongoing. Attempting to replicate these efforts from scratch is not 1632 recommended, and strongly discouraged. 1634 However, interoperability difficulty has emerged where many disparate 1635 authentication mechanisms all use the same credentials. Therefore, 1636 consideration must be given to limiting the number of specified 1637 mechanisms for any one class in an authentication framework, and, 1638 again, at least one "mandatory-to-implement" mechanism must be 1639 specified. See more on this in section Section 10.2.2. 1641 10.2.1. Downgrade Attacks 1643 One of the most serious problem with generic authentication 1644 mechanisms is their susceptibility to DOWNGRADE ATTACK, in which the 1645 attacker interferes with the negotiation to force the parties to 1646 negotiate a weaker mechanism than they otherwise would. This issue 1647 is generally worse with frameworks which do not provide channel 1648 security because the weakest provided mechanism is often quite weak. 1649 Consider a set of peers, each of which supports both challenge/ 1650 response and simple passwords. An attacker can force them into using 1651 a simple password and then capture that password. 1653 The standard countermeasure to downgrade attack is to authenticate a 1654 message digest of the offered mechanisms, as is done in the 1655 handshakes of both IKE and TLS. However, this is not possible if a 1656 simple password mechanism is supported (as is the case in many 1657 frameworks), and policy enables it to be negotiated, because the 1658 attacker can simply capture the password in flight. 1660 Note that if the client can establish an authenticated, integrity 1661 protected channel to the server (as is done in SSH), then the client 1662 authentication mechanism can be negotiated without fear of downgrade. 1663 Some protection against downgrade attacks can also be provided by 1664 having an endpoint cache the other endpoint's offers and complain if 1665 less secure mechanisms than were previously offered suddenly becomes 1666 available. This approach obviously bears the risk of false positives 1667 under simple misconfiguration. 1669 Finally, downgrade prevention can be achieved by users of generic 1670 security profiling the mechanisms they offer to ensure that they are 1671 all adequately strong--at least strong enough to provide downgrade 1672 detection. 1674 10.2.2. Multiple Equivalent Mechanisms 1676 The ease of adding new security mechanisms to generic authentication 1677 layers enables the development of multiple mechanisms with similar 1678 characteristics or even multiple mechanisms supporting the same 1679 authentication technology. This diversity has the potential to 1680 introduce interoperability problems as well as additional complexity. 1682 Trouble arises when we have many disparate authentication mechanisms 1683 using the same credentials. One particularly egregious example is 1684 token card support in EAP, where we have a variety of EAP mechanisms 1685 supporting RSA SecurID: 1687 a. Use of EAP Generic Token Card (GTC) defined in [RFC3748], along 1688 with a tunneling mechanism such as PEAPv0 [MS-PEAP], PEAPv1, EAP- 1689 TTLSv0 [RFC5281] or [RFC5216]. 1691 b. Use of EAP-RSA along with a tunneling mechanism such as PEAPv0. 1693 c. Use of EAP Protected One Time Password (POTP) [RFC4793]. 1695 Given this level of diversity, it is common today for popular EAP 1696 peer and server implementations from different vendors to be unable 1697 to negotiate a common EAP method for SecurID support. In practice, 1698 the fact than none of these mechanisms are designated as "mandatory- 1699 to-implement" has made it very difficult for customers to put 1700 together multi-vendor deployments with any hope of interoperability 1701 -- yet the non-interoperable vendors can each claim that they 1702 implement "standards" by supporting an IETF RFC or Internet-Draft. 1704 Another example occurs with pre-shared key mechanisms. [RFC3748] 1705 defined EAP-MD5; since this mechanism did not support key generation 1706 it did not satisfy the security requirements outlined in [RFC4017] 1707 for use on wireless networks. In order to address this weakness, 1708 additional mechanisms supporting key generation have subsequently 1709 been defined and published as Informational RFCs, including EAP-SIM 1710 [RFC4186], EAP-AKA [RFC4187], EAP-PSK [RFC4764], EAP-PAX [RFC4746], 1711 EAP-SAKE [RFC4763]. To address the lack of a standardized mechanism, 1712 the IETF EMU WG has produced a standards-track pre-shared key method 1713 known as EAP-GPSK [RFC5433]. 1715 Often the proliferation of mechanisms is driven by the need to 1716 support widely deployed authentication technologies, particularly 1717 those embodied in hardware which enable "what you have" 1718 authentication. Aside from manufacturing and distribution costs, 1719 deployment of these mechanisms may involve training or backend 1720 integration costs which can only be recouped after a considerable 1721 period of use. 1723 However, when a limited set of standardized mechanisms is defined, 1724 specification for protocol authors and deployment for network 1725 operators becomes far more successful. Whenever feasible, limiting a 1726 set of standardized mechanisms is recommended, and should be 1727 encouraged. At the very least, specifying a "mandatory-to-implement" 1728 is a must. 1730 For example, today EAP authentication within RADIUS [RFC3579] is now 1731 widely supported, and implementations offering mechanisms satisfying 1732 the security requirements outlined in [RFC4017] are common in such 1733 implementations as FreeRADIUS. As a result, greenfield client or 1734 server deployments rarely have a need for use of EAP-MD5, and the 1735 development of standardized pre-shared key mechanism may eventually 1736 enable replacement of EAP-MD5 as the mandatory-to-implement EAP 1737 authentication mechanism. 1739 The real point here it to ensure that multiple authentication 1740 mechanisms aren't trying to authenticate the same credential type, 1741 rather than to arbitrarily limit the number of authentication 1742 mechanisms. For example, while neither Kerberos nor (D)TLS are 1743 authentication frameworks, each now supports multiple credential 1744 types. This is both powerful and desireable for customers, since it 1745 means that they don't have to support each credential type with each 1746 application individually. 1748 However, having multiple different ways to authenticate with the same 1749 credential type, enabling vendors to claim compliance without 1750 interoperating, would be likely to result in customer frustration. 1751 This can be avoided by standardizing a "mandatory-to-implement" 1752 mechanism for each credential type, ensuring interoperability out-of- 1753 the-box." 1755 In order to encourage interoperability and the reduction of 1756 complexity, it is recommended that the IETF standardize only a small 1757 number of authentication mechanisms within a pluggable authentication 1758 framework. Proliferation of mechanisms should be limited to no more 1759 than one for any given class within the framework. Recalling section 1760 10.2, having a small number of mechanisms and clearly stating this 1761 minimal set in the protocol specification is particularly important 1762 when all implementations on the Internet will need to use the same 1763 mechanisms for authentication in order to interoperate. Examples of 1764 such Internet wide protocols have included DKIM, DNSSEC, and 1765 infrastructure protocols like BGP. Support for a standardized 1766 password-based (includes pin + OTP) mechanism is highly recommended 1767 for protocols where end-users (as opposed to unattended machines) 1768 will be involved. 1770 When working to limit the number of mechanisms, designers should take 1771 care not to break the architecture of an existing framework. For 1772 example, for SASL, it goes against the architecture to have 1773 mechanism-specific information such as specific mechanism 1774 restrictions in a protocol. Care must also be taken that such 1775 restrictions do not lead to mechanism-specific details making their 1776 way directly into protocols. Such layering violations make it harder 1777 to revise mechanisms in the future or to change the set of 1778 appropriate mechanisms if proven necessary over time. Experience has 1779 demonstrated that we are likely to need to change the set of 1780 mechanisms over time, as new technologies or new requirements emerge. 1782 10.2.3. Channel Bindings 1784 Many applications desire channel security but tighter integration of 1785 authentication with the application than is typically provided by 1786 channel security protocols. A common approach is to run the 1787 application protocol on top of a channel security protocol (most 1788 commonly TLS) but to use an authentication framework (most commonly 1789 SASL) for client (and sometimes server) authentication. As described 1790 in Section 6 this is potentially subject to man in the middle attack. 1791 As described in Section 6.1 and Section 8 if the server can be 1792 authenticated by the channel security protocol, then a MITM attack is 1793 not possible. 1795 If the server cannot be so authenticated, then the authentication 1796 performed by the framework must be cryptographically bound to the 1797 cryptographic context formed by the channel security protocol (this 1798 is often called a CHANNEL BINDING) so that the authentication 1799 framework will fail if a MITM attack is underway. 1801 For example, consider the figure below. If TLS is used without 1802 client or server authentication to provide only privacy (via 1803 encryption) and per-packet authentication and integrity (meaning I 1804 know that the packet came from the same person with whom I started 1805 this connection, and that it hasn't been changed along the way), it 1806 is still suceptible to a MitM attack. A challenge-response mechanism 1807 may be used inside the TLS to add end-point authentication. If so, 1808 one must include something from the TLS exchange in the challenge- 1809 response exchange in order to actually protect against a MitM attack. 1810 I.e. the channel and the authentication exchange must be bound 1811 together. 1813 Channel = ========================== 1814 TLS 1815 | | 1816 Client | | Server 1817 V V 1819 Authentication -------------------------- 1820 Exchange = 1821 Challenge/Response 1823 Channel Binding Example 1825 For instance, if the authentication framework is using a challenge- 1826 response mechanism, the response computation could include a 1827 characteristic value from channel security protocol, thus forcing the 1828 response given to the attacker and the response expected by the 1829 server to be different. Note that care must be used in selecting the 1830 characteristic value to ensure that the attacker cannot force the 1831 values to be the same for both connections. 1832 [I-D.altman-tls-channel-bindings], 1833 [I-D.williams-ipsec-channel-binding] and 1834 [I-D.williams-sshv2-channel-bindings] describe selection of values 1835 for TLS, IPsec, and SSH. 1837 Note that this technique cannot be used with non-cryptographic 1838 mechanisms such as simple passwords or one-time passwords. If these 1839 mechanisms are to be used in environments where MITM attacks are a 1840 concern, then the server must be authenticated by the channel 1841 security protocol. 1843 10.2.4. Excessive Layering 1845 Many of the legacy authentication mechanisms that users and 1846 administrators wish to support are themselves generic frameworks of 1847 one kind or another. In general, when two security frameworks are 1848 run together with one as a mode of the other, it becomes very 1849 difficult to make assertions about the security properties of the 1850 composed system. Among the issues are: 1852 o The state machines can become interlinked, causing confusion at 1853 one layer about the state of the other layer. For instance, TLS 1854 has a simple two round trip exchange, but [I-D.nir-tls-eap] 1855 extends that with a generic "EAPMsg" that may occur an arbitrary 1856 number of times without transitions in the TLS state machine. 1857 o Understanding the composed system becomes difficult. Experts in 1858 one security protocol often are not experts in all, and unless the 1859 encapsulation boundaries are very carefully drawn, analyzing the 1860 composed protocol may require an unavailable level of general 1861 expertise. 1862 o Any proofs of security that may be available for one of the 1863 systems almost certainly depend on knowledge of the available 1864 cryptographic mechanisms, but if one of those mechanisms is a 1865 framework, then those proofs no longer apply. 1867 These issues have been encountered within the Extensible 1868 Authentication Protocol (EAP), defined in [RFC3748] Where EAP runs 1869 over link layers that support authentication mechanisms other than 1870 EAP (such as PPP or IEEE 802.16), it may be necessary to first 1871 negotiate use of EAP, and then within EAP, to negotiate the specific 1872 EAP mechanism to be used. This may introduce security 1873 vulnerabilities. For example, since neither PPP authentication 1874 negotiation nor EAP mechanism are secured, it is necessary for both 1875 PPP and EAP authentication policy to be pre-provisioned on the EAP 1876 peer and server in order to prevent bidding down attacks. 1878 Since EAP supports a wide range of security mechanisms, support for 1879 multiple link layer authentication mechanisms is generally 1880 unnecessary, and in general greenfield link layer designs supporting 1881 EAP are best advised to forgo other approaches. 1883 The issue of multiple negotiation layers is also encountered within 1884 EAP methods. While some EAP methods (such as EAP-TLS [RFC5216] only 1885 support a single authentication mechanism, other such as EAP-FAST 1886 [RFC4851] and [I-D.funk-eap-ttls-v0] act as "tunneling methods", 1887 providing for negotiation of an "inner EAP method". As noted in 1888 [RFC3748] Section 7.4, unless the inner and outer authentication 1889 mechanisms are cryptographically bound, tunneling methods are 1890 vulnerable to a man-in-the-middle attack. 1892 In accordance with the principle of having as few mechanisms as 1893 possible, applications should try to avoid having multiple 1894 negotiation layers. If that is not possible, applications should 1895 profile a single negotiation layer. If application Foo is to be used 1896 with framework Bar which supports authentication methods Alpha and 1897 Bravo, itself supports framework Baz, which supports authentication 1898 methods Alpha, Bravo, and Charlie, Foo should indicate whether Alpha 1899 and Bravo are to be supported via Bar or Baz. 1901 10.2.5. List of Authentication Frameworks 1903 GSS-API [RFC2743] 1904 SASL [RFC4422] 1905 EAP [RFC3748] 1907 11. Sharing Authentication Information 1909 In many cases, users will use the same authentication data for a 1910 large number of services. For instance, users may expect to use the 1911 same username/password pair for TELNET, IMAP, and FTP. In such 1912 cases, it is generally desirable for all such services to share a 1913 single set of authentication data. For instance, TELNET, IMAP, and 1914 FTP typically all share the same password database. 1916 11.1. Authentication Services 1918 This problem is made more difficult if the services which must share 1919 authentication data reside on different machines. This problem is 1920 typically solved (when it is solved, as opposed to simply ignored) by 1921 having some unique system which has the credentials. Such a machine 1922 may either provide authentication as service (as in Kerberos) or 1923 simply provide credentials to authorized machines (YP, NIS). In 1924 either case, this protocol needs to be secured. 1926 11.2. Single Sign-On 1928 A related problem is that it's undesirable to have users manually 1929 authenticate each time some service wants authentication. First, 1930 it's inconvenient for the users. Second the cognitive load 1931 associated with frequent authentication seems likely to lead to 1932 careless use of credentials, enabling attacks such as phishing. 1933 Rather, they want to authenticate once and have software take care of 1934 the rest. This capability is called SINGLE SIGN-ON. 1936 If all authentication will be performed by one program, this can be 1937 fixed simply by having the program cache the user's credentials. If 1938 credentials need to be shared across multiple services then it's 1939 necessary to have some way to pass them from the program which first 1940 authenticates to others (or to have some central credential manager). 1941 As a special case, consider the case where mutually suspicious 1942 systems all want to allow a user to authenticate with a single set of 1943 credentials. If certificate-based authentication is being used, the 1944 protocols are straightforward since all relying parties can have the 1945 same verifier. In the case where passwords are being used, the 1946 typical solution is to have some third party authentication service 1947 which authenticates the user and then vouches for the user to the 1948 services. Microsoft Passport is one such provider. 1950 11.3. Case Study: RADIUS 1952 RADIUS, defined in [RFC2865], is a protocol for Authentication, 1953 Authorization and Accounting (AAA), commonly implemented in Network 1954 Access Servers (NASes). NAS devices are often constrained in terms 1955 of their CPU power, memory, or non-volatile storage. As a result, it 1956 may be difficult for them to implement a variety of authentication 1957 mechanisms. Also, given that access networks may contain hundreds or 1958 even thousands of NAS devices, management concerns may lead to 1959 implementation of a centralized authentication scheme. As a result, 1960 NAS devices may not perform authentication directly, instead 1961 delegating this to one or more authentication servers. 1963 When utilizing AAA servers for authentication, NAS devices act as 1964 "pass-through" devices, forwarding authentication exchanges between 1965 the user and the AAA server. Such an arrangement implicitly assumes 1966 the AAA server acts as a trusted third party, and that communication 1967 between the NAS and AAA server is authenticated and integrity and 1968 replay protected. 1970 As described in "The Network Access Identifier" [RFC4282] and 1971 "Chargeable User Identity" [RFC4372], there are circumstances in 1972 which the user desires to keeps its identity confidential both to a 1973 potential attacker that may be snooping on the conversation between 1974 the user and the NAS, as well as to the NAS itself. In these 1975 circumstances, only the AAA server may authenticate the identity of 1976 the user, and the NAS may only be provided with a "temporary 1977 identity" sufficient for authorization and billing purposes. " 1979 11.4. Case Study: Kerberos 1981 Kerberos [RFC4210] is a popular authentication/single sign-on 1982 service. Kerberos is based on the Needham-Schroeder authentication 1983 protocol. The authentication server role is played by a Key 1984 Distribution Center (KDC). When a client first signs on the client 1985 proves its identity to the KDC, usually by means of a password shared 1986 with the KDC. Kerberos is unusual in that the authentication service 1987 is provided to the client rather than the server. When a client 1988 wishes to communicate with a server, it first contacts the KDC and 1989 acquires a TICKET. That ticket contains a new symmetric key 1990 encrypted for both the client and server. The client can transmit 1991 the ticket to the server and use it both to prove its identity and 1992 establish a secure channel. 1994 11.5. List of Authentication Server Systems 1996 Kerberos [RFC4120] 1997 RADIUS [RFC2865] 1998 Diameter [RFC3588] 2000 12. Guidance for Protocol Designers 2002 Adding authentication to protocols is difficult and is made even more 2003 difficult by the large number of options. This section attempts to 2004 provide some guidance to protocol designers. No single document can 2005 tell you how to build a secure system, but the following guidelines 2006 provide generally good advice. If you feel you need to violate one 2007 of these rules of thumb, make sure you know why you're doing it. 2009 12.1. Know what you're trying to do 2011 The first thing to do is figure out what the security problem you're 2012 trying to solve is. Questions to ask include: 2014 12.1.1. What's my threat model? 2016 Sorting out the threat model (see [RFC3552]) is always the first step 2017 in deciding what sorts of security mechanisms to use. In the case of 2018 authentication you must consider, at minimum: 2020 1. What will be the result of various forms of attack? 2021 2. Does the threat model include active attack? (Hint: it should.) 2022 3. Do I need protection for my data or just the authentication? 2023 (Hint: probably you do) 2024 4. How valuable is the data being secured? Are exhaustive 2025 computational attacks practical? 2026 5. How competent are my users going to be? 2028 12.1.2. How many users will this system have? 2030 In general, the difficulty of managing a system scales with (or 2031 greater than) the number of users. This means that mechanisms which 2032 are practical with a small number of users may simply have too much 2033 overhead with a large number of users. For example, many token-based 2034 solutions charge by the token, which may be a prohibitive expense if 2035 there are many users. 2037 The complexity compared to scale of users will also be affected 2038 depending on whether all the users are "managed" or are "unmanaged". 2039 Managed users are those whose machines are owned, operated and 2040 managed by the organization deploying the system. Unmanaged users 2041 are those whose machines are not own, operated or managed by the 2042 deploying organization. System administrators tend to have far more 2043 control over managed machines, e.g. a company issued laptop or 2044 desktop machine, as compared to unmanaged machines, e.g. someone's 2045 home computer or personal smart phone. The complexity may further 2046 decrease for managed machines when a central management system is 2047 available for making configuration changes quickly and easily to all 2048 devices in the system. A central management system is unlikely for a 2049 solution with unmanaged machines. 2051 12.1.3. What's my protocol architecture? 2053 In some systems (e.g. POP, IMAP, TELNET), clients connect directly 2054 to the server. In others (e.g. HTTP, SIP, RSVP, BGP), 2055 authentication may need to be established over multiple hops when the 2056 entities have no independent authentication. Each case requires a 2057 different strategy. See Section 13.2.2 for more discussion on this 2058 topic. 2060 12.1.4. Do I need to share authentication data? 2062 If authentication data needs to be shared, especially between 2063 multiple servers, it's generally worth considering some sort of 2064 authentication server or using certificates. 2066 12.2. Use as few mechanisms as you can 2068 In the best case, each system would only have one or a small number 2069 of forms of authentication. The more methods of authentication a 2070 system allows, the more things there are to go wrong, and the more 2071 difficult it is to gain solid interoperability. Unfortunately, this 2072 is not always possible. In general, there are two reasons why 2073 systems allow more than one authentication mechanism. The first is 2074 that you're retrofitting a system which already has a large number of 2075 authentication mechanisms which cannot be displaced. The second is 2076 that users have widely different environments which for some reason 2077 cannot use the same authentication mechanism conveniently (e.g. some 2078 users have tokens and some do not). Even for the same user, some of 2079 the user's machines could accept a token, e.g. a laptop, while others 2080 may not, e.g. a smart phone. 2082 Naturally, designers need to take such considerations into account 2083 but they should take reasonable steps to minimize the number of 2084 mechanisms. Designers should take special care to minimize the 2085 number of mechanisms that use the same underlying keying material in 2086 different ways. For instance, a system that provides a challenge/ 2087 response mechanism and a public key based mechanism is a reasonable 2088 design, one that provides three different challenge/response 2089 mechanisms using the same passwords/keys presents serious complexity 2090 challenges and should be avoided if possible. Again, this is not 2091 always possible in systems with legacy authentication mechanisms but 2092 should be avoided in new designs. 2094 This doesn't mean that designers should not use security frameworks 2095 where multiple mechanisms are appropriate, but it does mean that they 2096 should be avoided unless there's a good a priori case for diversity 2097 in authentication mechanisms. Where generic security frameworks are 2098 used, designers need to carefully analyze the threats relevant to 2099 each mechanism in the context of the specific application layer 2100 protocol environment. In order to mimimize the attack surface, 2101 individual deployments would be wise to specify policies which 2102 disallow mechanisms which are unnecessary in their environment, even 2103 if they are specified in the protocol. For instance, if users are 2104 expected to use challenge response, then optimally clients would be 2105 configured not even to perform plaintext passwords, as this 2106 represents a security threat no matter what the server configuration 2107 is. 2109 12.3. Avoid simple passwords 2111 It's widely known that simple plaintext passwords are unsafe, but 2112 what's less widely known is that merely providing such a scheme can 2113 weaken systems even if stronger mechanisms are present. The 2114 difficulty is that simple passwords almost never provide the user 2115 with any form of server authentication. Consider the case where a 2116 system uses a negotiation framework that allows passwords. A 2117 downgrade attack can force the user to reveal his password even if 2118 both client and server support stronger mechanisms. 2120 Even when an authenticated and encrypted channel to the server is 2121 available, the use of cleartext passwords places strong requirements 2122 on the protection provided by encryption, in part because the same 2123 plaintext is transmitted repeatedly. [RFC3579] and [CHVV03] describe 2124 examples of such situations. 2126 Accordingly, designers should avoid deploying simple password 2127 mechanisms if at all possible, not just provide stronger mechanisms. 2129 12.4. Avoid inventing new frameworks 2131 Despite the large number of mechanisms we've discussed, this document 2132 describes only a small number of the available authentication 2133 mechanisms. There are very few situations in which designers cannot 2134 use some preexisting mechanism. This is vastly preferable to 2135 designing their own version of one of the standard mechanisms. In 2136 particular, designers should avoid designing their own authentication 2137 frameworks or channel security systems. If you want an 2138 authentication framework, use SASL or GSS-API or (if you're in a 2139 network access context) EAP. If you want a channel security system, 2140 use IPsec, TLS, or DTLS. Note that none of these systems can be 2141 blindly dropped into an existing system and provide adequate 2142 security. Care must be taken to analyze the protocol being secured 2143 and determine the correct interaction model. [RFC5406] provides 2144 guidance on this topic for IPsec. 2146 12.5. Use the strongest mechanisms you can 2148 Having the strongest security you can propose is generally a good 2149 plan. It's particularly good advice here, since passwords in the 2150 clear, one-time passwords, challenge-response and zero-knowledge 2151 password proofs all require the user to have the same kind of 2152 credential: a password. (Note that some OTP schemes such as SecurID 2153 require a token.) When designing a new system, the ability to 2154 provide a familiar interface to a user is valuable, minimizing 2155 additional work for client and server implementors is not. NIST 2156 Spec. Pub. 800-63 [SP800-63] provides good guidance about the 2157 minimum requirements for various applications. 2159 12.6. Consider providing message integrity 2161 Although most of the authentication mechanisms we've described are 2162 themselves resistant to active attacks, many are subject to hijacking 2163 after authentication has completed. If your threat model includes 2164 active attack (it should), you should strongly consider providing 2165 message integrity for all of your protocol messages in order to 2166 prevent hijacking. 2168 Message integrity provides a cryptographic indication in each message 2169 that, when validated, confirms that the message has not been altered 2170 since being sent from a trusted host. When applied correctly, it is 2171 often possible to use one cryptographic operation to achieve both the 2172 message integrity and the message authentication. For example, doing 2173 a digest authentication operation over a suitably large portion of 2174 the message (or payload, or packet, depending on the protocol in 2175 question) using a connection key known by both parties provides both 2176 message integrity and message authentication. IPsec, TLS, DTLS and 2177 SSH are all examples of protocols that provide message integrity and 2178 message authentication in one operation. 2180 13. Scenarios 2182 Despite the proliferation of authentication mechanisms, there are 2183 generally one or two optimal mechanisms for each scenario. We 2184 attempt to describe those mechanisms here. This section is divided 2185 into two parts, attacking the problem from different angles. In the 2186 first, we consider the various kinds of capabilities entities might 2187 have and the best mechanisms to use with those capabilities. In the 2188 second part we discuss a number of different protocol architectures 2189 and the potential mechanisms which can be used with those 2190 architectures. 2192 13.1. Capability Considerations 2194 There are three primary authentication scenarios: (1) Neither side 2195 has a public/private key pair. (2) One side has an authenticated key 2196 pair (either via a certificate or prior arrangement). (3) Both sides 2197 have authenticated key pairs 2199 Despite the proliferation of authentication mechanisms, there are 2200 only one or two best mechanisms for each scenario. We describe them 2201 here. 2203 13.1.1. Neither side has a public/private key pair 2205 Three basic strategies are suitable for the situation where neither 2206 side has a key pair: challenge/response, one-time passwords, and 2207 ZKPPs. The only situation in which OTP systems are superior to 2208 challenge/response systems is when adapting a legacy system in which 2209 it is difficult to change the client software. If the client 2210 software can be changed, challenge/response offers roughly equivalent 2211 security with significantly less management complexity. ZKPP proofs 2212 are technically superior however, in at least two cases (SACRED and 2213 IPS), IETF WGs have chosen not to require ZKPPs due to IPR concerns. 2215 These considerations make challenge/response the best choice for this 2216 scenario. If at all possible, it should be performed under cover of 2217 an anonymous key exchange, as described in Section 6. With this 2218 adaptation, an attacker needs to mount an active attack in order to 2219 dictionary search the password space. 2221 13.1.2. One side has an authenticated key pair 2223 If the server has a key pair which the client can authenticate, then 2224 several alternatives are available for password authentication. 2226 Simple username/password encrypted under the server's public key is 2227 the preferred authentication mechanism. Rather than encrypting 2228 directly under the server's public key, the standard practice here is 2229 to use the server's key to establish a secure channel and then pass 2230 the password over that channel. Challenge/response is in fact weaker 2231 in this case because it is is password equivalent. 2233 In this situation, using a single OTP only to authenticate the client 2234 to the server during a first connection, as a bootstrap, is quite 2235 useful. Once authenticated, and a secure channel is established, the 2236 client can pass some long term credential to the server, like its 2237 self-generated key pair's public key. Then after, the public key is 2238 used for the client authentication proof. This is how some mobile 2239 devices "register" and bootstrap secure connections to servers (e.g. 2240 how the handset registers to it's home mail server). 2242 Assuming that an authenticated server key pair is available, the use 2243 of a continuous list of OTPs and ZKPP systems offer significant 2244 additional management complexity for marginal security benefit. 2246 However, the difficulties involved in establishment of an 2247 authenticated server key pair may be substantial. These issues 2248 include: 2250 a. Provisioning of trust anchors. In a number of scenarios, such as 2251 establishment of network access from an unprovisioned host, trust 2252 anchors may not be pre-populated or utilization of pre-populated 2253 trust anchors may introduce security vulnerabilities. In such 2254 circumstances, either trust anchors need to be verified after the 2255 fact, leaving the client vulnerable to active attack, or out-of-band 2256 provisioning mechanisms need to be provided. 2258 b. Certificate validation. In practice, the deployment of 2259 Certificate Revocation Lists (CRLs) or Online Certificate Status 2260 Protocol (OCSP) may present practical difficulties. 2262 c. Man-in-the-Middle attacks. In order to avoid trust anchor 2263 provisioning or certificate validation, "leap of faith" approaches 2264 such as that used within SSH may be appealing. However, such an 2265 approach assumes that an attacker cannot gain sufficient access to 2266 disrupt the initial authentication attempt which establishes trust in 2267 the server public key pair. In some scenarios (e.g. client 2268 authenticating to a server in a restricted environment), this 2269 assumption may be valid; in other scenarios (wireless network 2270 authentication), it may not be. 2272 13.1.3. Both sides have authenticated key pairs 2274 If both sides have key pairs, the optimal mechanism is mutual public 2275 key authentication. 2277 13.2. Architectural Considerations 2279 In this section, we consider 3 different network architectures and 2280 the authentication mechanisms that are most suitable for each. 2282 13.2.1. Simple Connection 2284 The simplest authentication scenario is where the peers are connected 2285 by some interactive connection. Mercifully, this situation is quite 2286 common in such protocols as IMAP, TELNET, etc. In this simple case, 2287 mostly any authentication mechanism can be employed and so the choice 2288 depends on other factors, such as what credentials are available and 2289 the degree of security required. 2291 13.2.2. Proxied Client/Server 2293 It's quite common for client/server communication to be propagated 2294 through some gateway, as happens with HTTP. This situation has two 2295 potential authentication problems. 2297 1. How does the client authenticate to the proxy so that the proxy 2298 knows to serve it? 2299 2. How does the client authenticate to the server with the proxy in 2300 the way? 2302 The problem of authenticating to the proxy looks essentially like the 2303 ordinary client/server authentication problem (except in the case 2304 where there are multiple proxies in which case authenticating to 2305 anything other than the first hop proxy looks rather like problem 2.) 2307 The problem of authenticating through the proxy is rather more 2308 difficult. The obstacle is that either client nor server may not 2309 trust the proxy and they do not want to involve it in their 2310 authentication. They therefore need to provide an authentication 2311 method (preferably with message integrity) that doesn't require 2312 trusting the proxy. This rules out simple passwords and makes one- 2313 time passwords extremely questionable. There are three basic 2314 strategies available. 2316 13.2.2.1. Tunnel 2318 If the client and the server establish a tunnel through the proxy 2319 then they can behave as if this was an ordinary client/server 2320 transaction. Although this rather obviates the point of having a 2321 proxy, it's still a popular strategy and is used with HTTPS 2322 [RFC2817], [RFC2818]. Since the proxy is untrusted, the application 2323 protocol must either be run over a secure channel or hardened against 2324 active attacks. 2326 13.2.2.2. Challenge/Response 2328 A shared symmetric key between client and server can be used for 2329 authentication even in the face of a proxy by using standard 2330 challenge/response methods (with appropriate protocol modifications 2331 to distinguish between protocol data units (PDUs) directed towards 2332 the proxy and those directed towards endpoints.) These methods 2333 should include integrity protection for the individual PDUs. 2335 On a small scale, this technique works (it's what's used in HTTP when 2336 HTTPS is not used) but it quickly becomes unwieldy. If there are a 2337 large chain of proxies each of which wishes to authenticate the 2338 client, server, other proxies or all three, an enormous number of 2339 pairwise keys need to be established and maintained. In a protocol 2340 where long proxy chains are expected, symmetric key based 2341 authentication is probably impractical. 2343 A variant of this technique is to use a message-based system with 2344 symmetric keying such as S/MIME. All PDUs can then be encapsulated 2345 in secure messages. Recursive encapsulation can be used to provide 2347 authentication to proxies. 2349 13.2.2.3. Digital Signatures 2351 The final approach is to use public-key based digital signatures. 2352 Each endpoint signs each message (possibly with some set of nonces to 2353 prevent replay attack). The disadvantage of this approach is that it 2354 requires a PKI. The advantage is that it doesn't require pairwise 2355 keys. Each proxy in the chain can validate the client and the server 2356 based solely on their signatures. 2358 13.2.3. Store and Forward 2360 A number of important IETF protocols, most importantly, e-mail, are 2361 of the store and forward messaging variety. Such protocols have 2362 roughly the same security options as proxied protocols except that 2363 tunneling is no longer possible. Additionally, since store and 2364 forward protocols are non-interactive, many of the usual challenge/ 2365 response techniques for preventing replay attack no longer work and 2366 so care must be taken to either make one's system idempotent or 2367 introduce a specific anti-replay mechanism. The standard technique 2368 for store-and-forward situations is message security a la S/MIME. 2370 13.2.4. Multicast 2372 A number of IETF protocols have the property that multicast or 2373 broadcast message integrity needs to be provided. For example, 2374 routing and DNS both require the ability for a single sender to 2375 broadcast authenticated and integrity protected messages to a large 2376 number of receivers. There are two relevant cases: In the first, 2377 all members of the group are trusted and so it's feasible to have 2378 some group key which is used for authenticating all transmissions. 2379 This group key may be manually configured or established via some 2380 protocol such as GSAKMP [RFC4535]. 2382 In the second case, individual group members are anticipated to 2383 possibly forge messages. With such systems, it's not really 2384 practical to use symmetric key systems because the sender would need 2385 to agree on a key with each recipient (there may not even be a return 2386 channel). The only really practical approach in these multicast 2387 situations is for the sender to digitally sign each transmission with 2388 its private key. 2390 14. Acknowledgements 2392 Eric Rescorla was the original author and editor of this document, 2393 for versions -00 through -05. Gregory Lebovitz assumed the editor 2394 role starting in draft -06. Early versions of this document were 2395 reviewed by Fred Baker, Lisa Dusseault, Ted Hardie, and Mike St. 2396 Johns. Thanks to Jeffrey Altman, Sam Hartman, Paul Hoffman, John 2397 Linn, and Nico Williams for their reviews and comments. Bernard 2398 Aboba contributed extensive sections of this document, performed 2399 several reviews, and kept the meticulous issue tracker, which 2400 received plenty of contributions. 2402 Though published in 2010, the vast majority of the work done on this 2403 document occurred under the IAB teams of 2003-2006. Your efforts are 2404 remembered and appreciated. 2406 15. References 2408 15.1. Normative References 2410 15.2. Informative References 2412 [SP800-63] 2413 "National Institute of Standards and Technology, 2414 "Electronic Authentication Guideline: Recommendations of 2415 the National Institute of Standards and Technology", SP 2416 800-63", 2004. 2418 [AKA] "Technical Specification Group Services and System 2419 Aspects; 3G Security; Security Architecture (Release 5) 2420 3GPP TS 33.102 V5.1.0.". 2422 [BFL96] Blaze, M., Feigenbaum, J., and J. Lacy, ""Decentralized 2423 trust management", IEEE Symposium on Security and Privacy 2424 '96.". 2426 [Bell89] Bellovin, S., ""Security Problems in the TCP/IP Protocol 2427 Suite", Computer Communications Review", 1989. 2429 [Bell92] Bellovin, S. and M. Merritt, ""Encrypted Key Exchange: 2430 Password-based protocols secure against dictionary 2431 attacks", Proceedings of the IEEE Symposium on Research in 2432 Security and Privacy '92.", 1992. 2434 [Bell94] Bellovin, S. and M. Merritt, ""Augmented Encrypted Key 2435 Exchange: a Password-Based Protocol Secure Against 2436 Dictionary Attacks and Password File Compromise". AT&T 2437 Bell Laboratories Technical Report", 1994. 2439 [CHVV03] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, 2440 ""Password Interception in a SSL/TLS Channel", Advances in 2441 Cryptology CRYPTO 2003.", 2003. 2443 [DTH06] Dhamija, R., Tygar, J., and M. Hearst, ""Why Phishing 2444 Works", CHI 2006", 2006. 2446 [Crack] Muffet, A., "CRACK v 5.0a". 2448 [Wil68] Wilkes, M., ""Time-Sharing Computer Systems", American 2449 Elsevier New York.". 2451 [Worm88] Spafford, E., ""The Internet Worm Program: An Analysis",". 2453 [Jab96] Jablon, D., ""Strong Password-Only Authenticated Key 2454 Exchange", Computer Communication Review", 1996. 2456 [KP01] Kaufman, C. and R. Perlman, ""PDM: A New Strong Password- 2457 Based Protocol", Proceedings of the 10th USENIX Security 2458 Symposium '01", 2001. 2460 [Klein90] Klein, D., ""Foiling the Cracker: A Survey of Improvements 2461 to Password Security"", 1990. 2463 [I-D.altman-tls-channel-bindings] 2464 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 2465 for TLS", draft-altman-tls-channel-bindings-07 (work in 2466 progress), October 2009. 2468 [I-D.funk-eap-ttls-v0] 2469 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 2470 Authentication Protocol Version 0 (EAP-TTLSv0)", 2471 draft-funk-eap-ttls-v0-05 (work in progress), April 2008. 2473 [I-D.newman-auth-scram] 2474 Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, 2475 "Salted Challenge Response (SCRAM) SASL Mechanism", 2476 draft-newman-auth-scram-13 (work in progress), May 2009. 2478 [MS-PEAP] Microsoft Corporation, "MS-PEAP: Protected Extensible 2479 Authentication Protocol (PEAP) Specification", 2480 January 2010. 2482 [I-D.nir-tls-eap] 2483 Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "TLS 2484 using EAP Authentication", draft-nir-tls-eap-06 (work in 2485 progress), April 2009. 2487 [I-D.williams-ipsec-channel-binding] 2488 Williams, N., "End-Point Channel Bindings for IPsec Using 2489 IKEv2 and Public Keys", 2490 draft-williams-ipsec-channel-binding-01 (work in 2491 progress), April 2008. 2493 [I-D.williams-sshv2-channel-bindings] 2494 Williams, N., "Channel Binding Identifiers for Secure 2495 Shell Channel", draft-williams-sshv2-channel-bindings-00 2496 (work in progress), November 2007. 2498 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2499 Specification", STD 8, RFC 854, May 1983. 2501 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2502 STD 9, RFC 959, October 1985. 2504 [RFC1760] Haller, N., "The S/KEY One-Time Password System", 2505 RFC 1760, February 1995. 2507 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 2508 STD 53, RFC 1939, May 1996. 2510 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2511 Hashing for Message Authentication", RFC 2104, 2512 February 1997. 2514 [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 2515 AUTHorize Extension for Simple Challenge/Response", 2516 RFC 2195, September 1997. 2518 [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- 2519 Time Password System", RFC 2289, February 1998. 2521 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 2522 Management API, Version 2", RFC 2367, July 1998. 2524 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2525 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2526 Authentication: Basic and Digest Access Authentication", 2527 RFC 2617, June 1999. 2529 [RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText 2530 Transfer Protocol", RFC 2660, August 1999. 2532 [RFC2695] Chiu, A., "Authentication Mechanisms for ONC RPC", 2533 RFC 2695, September 1999. 2535 [RFC2743] Linn, J., "Generic Security Service Application Program 2536 Interface Version 2, Update 1", RFC 2743, January 2000. 2538 [RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808, 2539 April 2000. 2541 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 2542 HTTP/1.1", RFC 2817, May 2000. 2544 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2546 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2547 "Remote Authentication Dial In User Service (RADIUS)", 2548 RFC 2865, June 2000. 2550 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 2551 RFC 2945, September 2000. 2553 [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", 2554 BCP 44, RFC 2964, October 2000. 2556 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 2557 Mechanism", RFC 2965, October 2000. 2559 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 2560 Transport Layer Security", RFC 3207, February 2002. 2562 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2563 A., Peterson, J., Sparks, R., Handley, M., and E. 2564 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2565 June 2002. 2567 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 2568 Informal Management Model for Diffserv Routers", RFC 3290, 2569 May 2002. 2571 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2572 4rev1", RFC 3501, March 2003. 2574 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 2575 Text on Security Considerations", BCP 72, RFC 3552, 2576 July 2003. 2578 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2579 Dial In User Service) Support For Extensible 2580 Authentication Protocol (EAP)", RFC 3579, September 2003. 2582 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 2583 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2585 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2586 Levkowetz, "Extensible Authentication Protocol (EAP)", 2587 RFC 3748, June 2004. 2589 [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail 2590 Extensions (S/MIME) Version 3.1 Certificate Handling", 2591 RFC 3850, July 2004. 2593 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 2594 Authentication Protocol (EAP) Method Requirements for 2595 Wireless LANs", RFC 4017, March 2005. 2597 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 2598 Kerberos Network Authentication Service (V5)", RFC 4120, 2599 July 2005. 2601 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 2602 Protocol Method for Global System for Mobile 2603 Communications (GSM) Subscriber Identity Modules (EAP- 2604 SIM)", RFC 4186, January 2006. 2606 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 2607 Protocol Method for 3rd Generation Authentication and Key 2608 Agreement (EAP-AKA)", RFC 4187, January 2006. 2610 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 2611 "Internet X.509 Public Key Infrastructure Certificate 2612 Management Protocol (CMP)", RFC 4210, September 2005. 2614 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2615 Protocol Architecture", RFC 4251, January 2006. 2617 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 2618 for Transport Layer Security (TLS)", RFC 4279, 2619 December 2005. 2621 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 2622 Network Access Identifier", RFC 4282, December 2005. 2624 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2625 Internet Protocol", RFC 4301, December 2005. 2627 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2628 RFC 4306, December 2005. 2630 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2631 Security", RFC 4347, April 2006. 2633 [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 2634 "Chargeable User Identity", RFC 4372, January 2006. 2636 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2637 Security Layer (SASL)", RFC 4422, June 2006. 2639 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 2640 "GSAKMP: Group Secure Association Key Management 2641 Protocol", RFC 4535, June 2006. 2643 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 2644 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 2645 November 2006. 2647 [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication 2648 Protocol Method for Shared-secret Authentication and Key 2649 Establishment (EAP-SAKE)", RFC 4763, November 2006. 2651 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 2652 Pre-Shared Key Extensible Authentication Protocol (EAP) 2653 Method", RFC 4764, January 2007. 2655 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 2656 Ciphersuites with NULL Encryption for Transport Layer 2657 Security (TLS)", RFC 4785, January 2007. 2659 [RFC4793] Nystroem, M., "The EAP Protected One-Time Password 2660 Protocol (EAP-POTP)", RFC 4793, February 2007. 2662 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 2663 Flexible Authentication via Secure Tunneling Extensible 2664 Authentication Protocol Method (EAP-FAST)", RFC 4851, 2665 May 2007. 2667 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 2668 RFC 4949, August 2007. 2670 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 2671 "Using the Secure Remote Password (SRP) Protocol for TLS 2672 Authentication", RFC 5054, November 2007. 2674 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 2675 Layer Security (TLS) Authentication", RFC 5081, 2676 November 2007. 2678 [RFC4248] Hoffman, P., "The telnet URI Scheme", RFC 4248, 2679 October 2005. 2681 [RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, 2682 November 2005. 2684 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2685 Authentication Protocol", RFC 5216, March 2008. 2687 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2688 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2690 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 2691 Protocol Tunneled Transport Layer Security Authenticated 2692 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 2694 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2695 October 2008. 2697 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 2698 Security: An Unauthenticated Mode of IPsec", RFC 5386, 2699 November 2008. 2701 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2702 Version 2", BCP 146, RFC 5406, February 2009. 2704 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 2705 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 2706 RFC 5433, February 2009. 2708 Appendix A. IAB Members at the time of this writing 2710 Marcelo Bagnulo 2711 Gonzalo Camarillo 2712 Stuart Cheshire 2713 Vijay Gill 2714 Russ Housley 2715 John Klensin 2716 Olaf Kolkman 2717 Gregory Lebovitz 2718 Andrew Malis 2719 Danny McPherson 2720 David Oran 2721 Jon Peterson 2722 Dave Thaler 2724 Authors' Addresses 2726 Eric Rescorla 2727 RTFM, Inc. 2728 2064 Edgewood Drive 2729 Palo Alto, CA 94303 2730 USA 2732 Email: ekr@rtfm.com 2734 Gregory Lebovitz 2735 Juniper Networks, Inc. 2736 1194 N. Mathilda Ave. 2737 Sunnyvale, CA 94089-1206 2738 USA 2740 Email: gregory.ietf@gmail.com 2742 Internet Architecture Board 2743 IAB