idnits 2.17.1 draft-hallambaker-httpauth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 565, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hallambaker-httpintegrity-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Standards Track October 22, 2012 5 Expires: April 25, 2013 7 HTTP Authentication Considerations 8 draft-hallambaker-httpauth-01 10 Abstract 12 This draft is input to the HTTP Working Group discussion of HTTP 13 authentication schemes. 15 Since the topic is one that the intended audience is more than 16 familiar with, the presentation style is maybe not what is usual in 17 such papers. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 25, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. What is Wrong in Web Authentication . . . . . . . . . . . . . 3 54 1.1. Password Promiscuity . . . . . . . . . . . . . . . . . . . 3 55 1.1.1. Password Recovery Schemes . . . . . . . . . . . . . . 4 56 1.1.2. Phishing . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Provider Lock In . . . . . . . . . . . . . . . . . . . . . 5 58 1.3. Strong Credentials Compromised by Weak Binding . . . . . . 6 59 1.3.1. Confirmation vs Authentication . . . . . . . . . . . . 7 60 1.4. What passwords get right . . . . . . . . . . . . . . . . . 7 61 2. User Authentication is Three Separate Problems . . . . . . . . 8 62 2.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.2. Credential Presentation . . . . . . . . . . . . . . . . . 8 64 2.3. Message Authentication . . . . . . . . . . . . . . . . . . 9 65 3. Deployment Approach . . . . . . . . . . . . . . . . . . . . . 10 66 3.1. Password Managers as Transition Path . . . . . . . . . . . 10 67 3.2. Non-Transferable Credentials . . . . . . . . . . . . . . . 11 68 4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 4.1. Open Protocol for credential management . . . . . . . . . 11 70 4.2. HTTP Integrity Header . . . . . . . . . . . . . . . . . . 12 71 4.3. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 5.1. User Lock In . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.2. Site Lock In . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.3. Impersonation . . . . . . . . . . . . . . . . . . . . . . 12 76 5.4. Credential Disclosure . . . . . . . . . . . . . . . . . . 12 77 5.5. Credential Oracle . . . . . . . . . . . . . . . . . . . . 12 78 5.6. Randomness of Secret Key . . . . . . . . . . . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 7. Normative References . . . . . . . . . . . . . . . . . . . . . 13 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. What is Wrong in Web Authentication 85 What is wrong with Web Authentication is that twenty years later we 86 still depend on passwords and what is worse, the weakest possible 87 password infrastructure. 89 Little has changed in the use of password authentication since the 90 publication of crack in 1990. Before crack it was a point of pride 91 for many Unix admins that the one way encryption used in UNIX "made 92 their password system more secure than VMS". It was argued that 93 making the one way encrypted password file public made the system 94 more secure than the 'security-through-insecurity' approach of VMS. 95 VMS also used one way encryption but the password file was only 96 readable with admin privileges. Endless USENET flames explained 97 'why' this was a terrible, terrible idea. When crack appeared these 98 flames were quietly forgotten and it is widely imagined that UNIX 99 systems have always had shadow passwords. 101 In the wake of crack it was discovered that most users chose terrible 102 passwords that could be guessed through a brute force or dictionary 103 attack in a few hours. The use of a salt made guessing passwords 104 moderately more difficult as did minimum length password requirements 105 and a requirement to use a non alphabetic character. 107 In the two decades since the standard rules for passwords were set in 108 scripture, computing power has increased by over a billion times and 109 it is now possible to buy a computer that will fit in the heel of a 110 shoe that is more powerful than the fastest mainframe on CERN campus 111 in 1992. The ad-hoc rules developed to make brute force attacks an 112 order of magnitude harder in 1990 have been rendered utterly 113 irrelevant by the six orders of magnitude improvement in available 114 computing power. We have arrived at a situation where we use 115 passwords that are maximally hard for people to remember while being 116 trivial for modern computers to break by brute force. 118 This approach to password security: complacency followed by ad hoc 119 patches followed by complacency has remained firmly in place since. 121 1.1. Password Promiscuity 123 Today the typical Internet user has to remember hundreds of passwords 124 and account names. Since this is of couse silly, most users, myself 125 included do no such thing. Most users have the same password for 126 every account. Security concious users have a different password for 127 every account they care about and an easy to remember password for 128 the rest. My New York Times account is phil@hallmabaker.com and the 129 password is GuessEasy. Go have a party. That information protects 130 an asset that the New York Times wants to protect. It is not an 131 asset that I care to spend time or effort protecting. 133 Password promiscuity is a natural strategy that users have adopted to 134 protect the asset they care about: Their time. Creating and 135 remembering strong passwords takes time and effort. Blaming users 136 for not taking time and effort to protect the assets of other people 137 is futile. 139 If Alice has shared her password at 100 sites then a single corrupt 140 actor who can access just one of those sites can gain access to the 141 other 99. 143 Account names pose a harder problem since most sites require that the 144 account name be unique for that site. So a user who finds their 145 preferred account name is taken has to choose another. 147 Expecting users to remember all this stuff is stupid, just stupid. 149 1.1.1. Password Recovery Schemes 151 Password and account name recovery schemes are necessary because 152 users cannot remember the hundreds of passwords or account names that 153 using the Web now involves. 155 The most common password recovery mechanism is the email callback 156 authentication mechanism first used by Mallery and Hurwitz on their 157 Open Meeting system. A challenge (usually in the form of a link) is 158 sent out to the user to their registered email address. The user 159 must respond to the challenge to reset their account. 161 One important consequence of the email callback scheme is that 162 virtually every Web site that has an accounts mechanism requests an 163 email address during registration. There is thus no loss of privacy 164 if the email address is used as the account name. Many sites have 165 realized this fact and avoid the need for the user to choose an 166 account name by allowing them to give their email address instead. 168 A site need not and in fact should not disclose the email address to 169 other users when this approach is used. Shadow account names allow 170 the user the courtesy of not having to remember the account name for 171 that site. 173 1.1.2. Phishing 175 Another circumstance that made it difficult to implement strong 176 security mechanisms at the time was the popular misconception that 177 the attackers were exclusively teenage miscreants engaged in the 178 cyber equivalent of joy-riding rather than criminals motivated by 179 money. People were warned that this was not the case but they did 180 not want to hear. 182 The core defect of the Web authentication mechanism is that passwords 183 are presented en-clair to the verifier. Thus any party who can 184 present a login page to the user stands a good chance of capturing 185 their credentials. 187 This problem was of course anticipated a few days after the BASIC 188 authentication mechanism was proposed and was the original motivation 189 for DIGEST authentication. But DIGEST authentication did not permit 190 the re-use of legacy UNIX password files and so implementation did 191 not take place until it was to late to deprecate BASIC. 193 Even today, IE7 makes no distinction between a request for 194 authentication using BASIC vs DIGEST. Thus an attacker can easily 195 capture the user's credentials through a downgrade attack. DIGEST 196 was intended to replace BASIC and for BASIC to be expunged from the 197 spec as dangerous to use. 199 In the event authentication moved into the HTML layer which likewise 200 communicated the password enclair to the verifier. Thus enabling 201 phishing. 203 1.2. Provider Lock In 205 Many schemes have been developed to provide the user with a portable 206 form of credential but all those created to date present the security 207 risk of lock-in to both users and relying parties. 209 Such schemes are often described as 'identity management' a term that 210 seems to hurt rather than help comprehension of the problems 211 involved. 213 Many users have found to their cost that when their FaceBook or 214 Twitter account is disabled, they lose access to every other Web site 215 linked to it. 217 While end users are faced with a minor inconvenience, relying party 218 sites are faced with the risk that the 'identity provider' will 219 decide to change their terms of service to their great disadvantage 220 with little or no notice. Essentially the relying parties have 221 agreed to channel all their traffic through the portal of another 222 without any form of contractual agreement to prevent the portal owner 223 setting up a toll booth. 225 A particular form of lock in that will doom any scheme to an 226 inevitable and deserved death is any attempt to tie the scheme to the 227 use of any naming registry other than the DNS. 229 In one recent exercise in mindboggling futility a group of otherwise 230 rational people spent over five years on a project where the two 231 identifier forms to be supported were 232 http://www.whowoulddothis.org/username and =username. It was rather 233 obviously and abundantly clear that the only rational reason for the 234 first choice was to corrale users to the inevitable choice of the 235 second. Well they didn't did they? 237 One of the problems with such commercial interests is that it is 238 often considered impolite or somehow improper to point out that they 239 exist. Even when it is rather clear that their presence is going to 240 doom the scheme to extinction. 242 While a naming ragistry can be profitable in theory, there have only 243 been four such registries established on an international scale in 244 the history of human civilization. Each supported a new form of 245 communication, these being the postal system, the telephone system, 246 the barcode product identifier system and the Internet. While 247 commercial control of such a registry would of course bring ritches 248 almost beyond the dreams of MBAs, the chance that such proposals 249 might succeed is negligible to nil. 251 1.3. Strong Credentials Compromised by Weak Binding 253 A secondary Web authentication problem is that use of strong 254 credentials is compromised by the inadequacy of the Web protocols. 255 For example, a One Time Password (OTP) token provides strong 256 authentication when used in the context of a VPN or other application 257 that can guarantee that the passcode is only presented to the 258 intended service. When entered into a HTML page, OTP passcodes are 259 as vulnerable to interception as passwords. 261 Use of an OTP or public key token provides strong evidence that the 262 hardware device concerned was in some way involved in a transaction 263 but not the intention of the token holder. 265 Consider the case where a wire transfer of $10,000 to be sent to 266 Nigeria is requested, the bank asks for an OTP value to be entered as 267 confirmation. The bank can only verify that the value entered is the 268 next OTP value in sequence. The bank has no means to determine 269 whether the token holder was looking at a Web page that asked them to 270 enter the value to confrim the wire transfer or whether they were 271 looking at a Web page asking if they would like to buy a fluffy pink 272 bunny for their daughter's birthday. 274 If an authentication system cannot tell the difference between a con 275 trick and a pink fluffy bunny, it should not be considered strong. 277 1.3.1. Confirmation vs Authentication 279 Modern smartphones are ubiquitous and relatively cheap. They provide 280 a computing capability, a communication capability and a display in a 281 single package. This is a platform that can and should be leveraged 282 as an authentication device that can provide proof not only that the 283 user was involved but that they were committed to the transaction 284 concerned. 286 This technology provides us for the first time with a technology 287 platform that is capable of presenting the user with the actual 288 transaction they are being asked to confirm and to thus provide a 289 strong binding between the device and the transaction. 291 My prefered hardware device for such a use would be a wristwatch with 292 an intelligent display. 294 1.4. What passwords get right 296 Overlooked in most security discussion of passwords is what they get 297 right, indeed it is often assumed that they have no redeeming 298 features. Yet if that were the case they would have been gone long 299 ago. The real problem of passwords is that they work just well 300 enough to be almost always better than the alternatives. 302 The biggest advantage of passwords is that every Internet device has 303 had to develop the affordances to support them. My Internet enabled 304 weighing scale has a USB socket whose sole purpose is to enable me to 305 plug it into a computer to set the WiFi network name and password. I 306 can log into my personal email account from every desktop computer, 307 laptop, tablet or mobile in the house. I can only acces my corporate 308 email from the one machine configured for the corporate VPN and smart 309 token. 311 Passwords require no dongles, tokens or cards which in turn means 312 that they don't require device drivers or administrator privileges. 313 While vendors of such systems strive to present low barriers for such 314 devices, low barriers can never compete with no barriers if the user 315 has a choice in the matter. People take effort to secure the assets 316 they care about which is why banks can't give authentication tokens 317 to customers while the same customers will go and pay for a 318 battle.net token to secure the assets that matter to them. 320 2. User Authentication is Three Separate Problems 322 The term 'authentication' tends to cause confusion due to the fact 323 that there are actually three separate activities that it can refer 324 to. When Alice establishes an account at a Web site, the site may 325 verify her email address is correct. When Alice presents her 326 username and password, the site verifies the data and if correct 327 issues a HTTP cookie. When Alice re-visits the same Web site to make 328 further requests, the cookie is verified each time. Each of these 329 verifications is a form of authentication but they are totally 330 different in character and only the last of these is a form of 331 authentication that is directly related to HTTP. 333 Attempts have been made to distinguish between these as 'initial 334 authentication' and 're-authentication' but this also creates 335 confusion as some people consider the first contact with the user as 336 the 'initial' authentication and others consider that to be the start 337 of a Web session. 339 2.1. Registration 341 Registration comprises all activities related to the establishment 342 and maintenance of an account. These include the initial dialogu in 343 which Alice picks out an account name for display on the site and her 344 authentication credentials and all subsequent updates including 345 password resets. 347 In a small number of circumstances, registration involves 348 authentication of dopcumentary evidence such as articles of 349 incorporation, a passport, business license or professional 350 qualifications. The term validation seems to have emerged as the 351 term of art for this activity. 353 Today registration is almost exclusively managed through HTML forms. 354 Any new system will probably have to respect this approach. 355 Registration establishes an account that is in almost every case to 356 be accessible from multiple Web browsers rather than just the browser 357 on which the registration process was completed. 359 2.2. Credential Presentation 361 Unlike the FTP and Telnet protocols that preceded it, HTTP Web 362 sessions typically span multiple TCP connections. In the typical 363 case the use will 'log in' to a Web site to establish a session that 364 then continues for several hours, days or even months. 366 Like the registration phase, credential presentation has largely 367 transitioned out of the browser to HTML. Although many users employ 368 plugins and applets that effectively reverse this, filling in the 369 account an password field from a password database that is stored 370 locally or in the cloud. 372 While such 'password managers' have traditionally been considered 373 part of the problem they are in fact a necessary part of any 374 solution. If we are going to improve matters we must first offer 375 users a solution that meets their needs better than current 376 solutions. 378 2.3. Message Authentication 380 Credential presentation has a necessary impact on the user. Since it 381 would be tedious to enter a username and password for every Web page 382 view, a lightweight mechanism is necessary to re-authenticate the 383 user and demonstrate that they are the user that authenticated 384 themselves when the session was created. 386 This is the only part of the process that is currently within the 387 scope of HTTP rather than HTML and probably the only part for which 388 it will be possible to get agreement on a better mechanism than the 389 existing one. 391 The best available mechanism is the HTTP 'cookie'. This is highly 392 unsatisfactory as a technical mechanism as they are weakly bound to 393 the HTTP transaction and disclosed to the verifier. These 394 circumstances in turn lead to numerous forms of cookie-stealling and 395 cookie-stuffing attacks. 397 Using cookies for authentication also involves privacy concerns. In 398 the context of authentication schemes, the use of cookies does not 399 raise new privacy concerns as the purpose of the authentication 400 scheme is to establish a session and uniquely identify the user. 401 Unfortunately the cookie spec permits sites to establish cookies for 402 tracking purposes without user permission or knowledge. The fact 403 that cookies may be used for illegitimate purposes compromises 404 legitimate uses and creates unnecessary transaction costs including 405 customer serivce calls, congressional subpoenas and accusations on 406 slashdot. 408 My proposal for fixing this part of the problem isdescribed in 409 [I-D.hallambaker-httpintegrity]. 411 While there are many, many concerns that need to be considered in the 412 registration and credential presentation operations, the problem of 413 message authentication can be reduced to the problems of: 415 Identifying a security context consisting of at minimum an 416 authentication algorithm, key and account identifier. 418 Applying the security context to parts of the HTTP message. 420 3. Deployment Approach 422 Proposing a better authentication mechanism for the Web is easy. In 423 fact there is nobody involved in Web Security that could not develop 424 a better scheme given a free hand and a group of people interested in 425 deployment. The development of a secure scheme should be well within 426 the capabilities of a competent first year Computer Science 427 undergraduate. 429 The much harder problem is deployment and in particular how to deploy 430 a new scheme in the context of the legacy infrastructure. Here the 431 ease with which a proposal can be made makes deployment harder, not 432 easier since there are always competing proposals. 434 3.1. Password Managers as Transition Path 436 If the users are going to participate in any new scheme it must work 437 at least as well as the existing password scheme. In particular it 438 must be possible for the user to access all their accounts from their 439 browser in a transparent fashion with minimal hassle. 441 Storing passwords in the cloud is a very good way to achieve the 442 user's interest even if the sites whose assets may be compromised as 443 a result may see it as a bad thing. Let us agree for the sake of 444 argument that we consider passwords to be such an intrinsically 445 insecure form of authentication that the user choice to store them in 446 the cloud has negligible impact on the security of the system. 448 Since all the proposals to improve the Web authentication 449 infrastructure involve some form of 'identity provider', why not give 450 that provider the secondary purpose as a password manager? 452 If the communication between the client and the password manager was 453 a widely supported Internet standard, users could choose any provider 454 they liked as their password manager and access their credentials 455 from any Web browser that they might need to use. 457 Such a confluence could in itself improve security as once the user 458 is assured that every browser they need to use has access to their 459 password manager, there is no need for the password to be memorable. 460 It is thus possible for the password used for credential presentation 461 to the site to be long and strong. 463 Use of a standards based password management protocol permits the 464 user to take their security into their own hands irrespective of what 465 attempts the sites might attempt to prevent it. What is perhaps more 466 interesting is that it also sets the scene to enabling use of strong 467 credentials. 469 3.2. Non-Transferable Credentials 471 While Web sites concerned with the risk that their customers store 472 credentials in the cloud might attempt to frustrate a cloud based 473 password infrastructure, a much better approach is to co-opt it and 474 use it as a basis to build on. At the very least, a cloud based 475 authentication infrastructure provides a useful pre-authentication 476 step that could be used as a preliminary to a site specific log-in. 478 But just as an identity provider can also be a cloud password 479 manager, the converse is also true. The cloud password manager can 480 also support one or more existing mechanisms that enable credential 481 presentation authentication without disclosure of the credential 482 being verified. These could be based on SAML, OpenID, OAUTH or even 483 some new proposal. 485 4. Action Plan 487 My proposal to improve Web authentication has the following parts: 489 Open Protocol for credential acquisition 491 HTTP Integrity Header 493 Bindings for credential presentation employing the commonly used 494 federated authentication schemes, vis SAML, OAUTH, OpenID, etc. 496 4.1. Open Protocol for credential management 498 This protocol would be responsible for managing users legacy 499 credentials (i.e. passwords) and to support whatever strong 500 mechanisms for credential exchange were developed. 502 The protocol itself would require registration, credential 503 presentation and query components. Once the user had established an 504 account they would have to be able to bind any browser or device of 505 their choice to that account, possibly doing so for a very limited 506 time or for limited sites. 508 The query component would be of the form 'how do I access site X with 509 identity Y'. For general applications the broker might then respond 510 with a username and password or a secret to be used to respond to a 511 challenge. For circumstances requiring higher security the system 512 might support some form of key splitting or sharing or other control 513 limiting exposure. 515 4.2. HTTP Integrity Header 517 This is described at length in [I-D.hallambaker-httpintegrity] 519 The biggest challenge in the design of SAML, OAUTH and OpenID was 520 establishing a secure binding between the authentication token and 521 the HTTP messages. Using cookies and URI fragments for this purpose 522 is deeply unsatisfactory. 524 4.3. Bindings 526 While we might imagine that we can get by with one single protocol 527 that is going to solve all our authentication problems we now live in 528 a world where there is much legacy that demands attention. Even if 529 we decide that in future we are all going to use one single new 530 protocol, we have to find a mechanism that allows the credential 531 management systems to trade in their old lamps for new. 533 At minimum we require a mechanism that allows Web sites to specify 534 which forms of authentication credentials they might accept, which 535 mechanisms for useing them for validation and of transporting the 536 challenges and responses for such mechanisms within HTTP message 537 headers. 539 5. Security Considerations 541 Since this is a discussion document and the whole thing is talking 542 about security, I think I will just leave the headings here to remind 543 people about the security issues I think people should consider. 545 5.1. User Lock In 547 5.2. Site Lock In 549 5.3. Impersonation 551 5.4. Credential Disclosure 553 5.5. Credential Oracle 555 5.6. Randomness of Secret Key 556 6. IANA Considerations 558 7. Normative References 560 [I-D.hallambaker-httpintegrity] 561 Hallam-Baker, P., "HTTP Integrity Header", 562 draft-hallambaker-httpintegrity-01 (work in progress), 563 October 2012. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 Author's Address 570 Phillip Hallam-Baker 571 Comodo Group Inc. 573 Email: philliph@comodo.com