idnits 2.17.1 draft-williams-httpbis-auth-classification-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 : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 11, 2012) is 4330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2818' is defined on line 1335, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 1344, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-02) exists of draft-williams-rest-gss-01 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Williams 3 Internet-Draft Cryptonector 4 Intended status: Informational June 11, 2012 5 Expires: December 13, 2012 7 A Proposals for Classification and Analysis of HTTPbis Authentication 8 Proposals 9 draft-williams-httpbis-auth-classification-01 11 Abstract 13 This document proposes a classification scheme for HTTPbis 14 authentication proposals, to help with analysis and selection. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 13, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Conventions used in this document . . . . . . . . . . . . 3 52 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . 8 55 2.1. Threat Models . . . . . . . . . . . . . . . . . . . . . . 9 56 2.2. On Trust . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 2.3. On the TLS Server PKI . . . . . . . . . . . . . . . . . . 10 58 2.4. On Mutual Authentication and URI Schemes . . . . . . . . . 11 59 2.5. On Authentication Mechanism Message Counts . . . . . . . . 11 60 2.5.1. On One-Message Authentication Mechanisms . . . . . . . . . 12 61 2.6. Logon Sessions . . . . . . . . . . . . . . . . . . . . . . 12 62 2.7. Web Cookies, a Form of Bearer Tokens . . . . . . . . . . . 12 63 2.8. User Interface Issues . . . . . . . . . . . . . . . . . . 13 64 3. Classification Axes . . . . . . . . . . . . . . . . . . . 14 65 3.1. Dependence on TLS Server PKI . . . . . . . . . . . . . . . 15 66 3.2. Bearer Tokens vs. Proof of Possession . . . . . . . . . . 15 67 3.3. Layer at which Authentication Protocol Operates . . . . . 15 68 3.3.1. HTTP- vs. Application-Layer Authentication in the 69 Network Stack . . . . . . . . . . . . . . . . . . . . . . 17 70 3.3.2. HTTP- vs. Application-Layer Authentication in the API 71 Stack . . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 3.3.3. Choice of Layer . . . . . . . . . . . . . . . . . . . . . 21 73 3.3.4. User Authentication in the TLS Layer . . . . . . . . . . . 22 74 3.4. Party Responsible for Infrastructure Messaging . . . . . . 23 75 3.5. Number of Messages . . . . . . . . . . . . . . . . . . . . 24 76 3.6. Trust Establishment . . . . . . . . . . . . . . . . . . . 26 77 3.7. Threat Modeling . . . . . . . . . . . . . . . . . . . . . 28 78 3.8. Explicit versus Implicit Session Management . . . . . . . 28 79 3.9. In-Band versus Out-of-Band Authentication . . . . . . . . 28 80 4. Analysis of Some Possible Authentication Proposals . . . . 29 81 5. Author's Recommendations . . . . . . . . . . . . . . . . . 30 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . 32 83 Author's Address . . . . . . . . . . . . . . . . . . . . . 34 85 1. Introduction 87 The HTTPbis WG is accepting proposals for new authentication systems 88 for HTTPbis, the successor to Hypertext Transport Protocol (HTTP) 89 version 1.1[RFC2616]. This document proposes a classification system 90 for these proposals. Several axes of classification are proposed, 91 and several simplified imagined or likely authentication systems are 92 used to illustrate the classification system. 94 The author assumes that the WG is interested primarily in new user 95 authentication proposals, with ones that provide mutual 96 authentication (of users and servers to each other) being in scope. 97 The author also assumes that Transport Layer Security (TLS) [RFC5246] 98 will continue to be used by HTTPbis for cryptographic session 99 protection. 101 Some familiarity with authentication systems is assumed. A glossary 102 is provided. 104 1.1. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 1.2. Scope 112 This document considers user authentication only in the context of 113 HTTP applications, whether they be web applications or otherwise. 114 Authentication of the service is also in scope, but authentication 115 methods that authenticate only the user to the service (with the 116 service authenticated by Transport Layer Security (TLS)) are in 117 scope. 119 There are at least two entities involved in authentication in this 120 context: the user (on the client side), one or more of the web server 121 host or the web server application/service, and any trusted third 122 parties that an authentication mechanism might involve. 124 1.3. Glossary 126 This section defines terms as they are used in _this_ document. 127 Readers are strongly encouraged to read this section before reading 128 any subsequent section. 130 API Application Programming Interface. These are interfaces between 131 an application and a feature that is abstracted into a "library" - 132 a service provided by the platform's operating system. 134 API Layer A complex Internet application might require a large 135 number of APIs, such as, for example, one for every network layer. 136 In practice it is more common to have a single API that 137 encompasses all network layers below it, with the component 138 providing that API likely invoking other APIs itself. which in 139 turn invoke other APIs. For example, a web application might use 140 a library that presents a single API to all of the HTTP network 141 stack from HTTP all the way down to IP. Note that there need not 142 be a direct correspondence of network and API layers. 144 Authentication The process of establishing the veracity or origin of 145 some statement (e.g., of an entity's identity), usually by proxy 146 (e.g., with key-pairs to an asymmetric key cryptographic system 147 "speaking for" the authenticated entities). In this document, and 148 unless otherwise stated, "authentication" will refer to 149 authentication of identity of entities such as "users", "hosts", 150 and "services". 152 Authentication Mechanism A cryptographic protocol for authenticating 153 entity identities. Note that this does not cover POSTing 154 usernames and passwords in forms, but it does cover bearer token 155 mechanisms (if just barely). 157 Authentication Method A scheme for authenticating entity identities. 158 An authentication method can be non-cryptographic, covering HTTP 159 Basic authentication and usernames&passwords POSTed from HTML 160 forms. 162 Authentication Framework A protocol into which other authentication 163 mechanisms may be plugged in. For example: SASL[RFC4422], GSS- 164 API[RFC2743], EAP[RFC3748], among others. 166 Bearer Token A technique for authentication that involves a message 167 that can be presented by the authenticating entity to another. No 168 proof of possession is required for using bearer tokens, which 169 means that the token can be presented by any entity possessing the 170 token, which in turn means that bearer tokens must be sent with 171 confidentiality protection, as otherwise eavesdroppers can steal 172 them and use them to impersonate the subject. 174 Channel Binding A security protocol composition and analysis tool. 175 The purpose of channel binding[RFC5056] is to "bind" a secure 176 channel (at one layer in the network stack) into an authentication 177 protocol running at a higher layer in the stack, thereby ensuring 178 that the channel is end-to-end and "speaks for" its end-points. 180 Confidentiality protection Cryptographic encryption of data. 181 Confidentiality protection is/must always be used with integrity 182 protection as well. 184 Data authentication Data origin authentication, a.k.a., integrity 185 protection. 187 Hardware Security Module (HSM) A hardware component of security- 188 critical trusted third parties. An HSM is intended to be 189 reasonably secure against physical and software attacks against it 190 -much more than traditional servers-, thus making it ideal for 191 storing non-extractable secret/private key material. 193 Integrity protection Cryptographic protection against modification 194 of data. See also "data authentication", above. 196 Mechanism Shorthand for "authentication mechanism", a protocol 197 defining messages to be exchanged in order to authenticate one 198 party to another (or two parties to each other). 200 Mutual Authentication Authentication of a user and a server/service 201 to each other. 203 Mutual Authentication (key confirmation sense) In some protocols key 204 exchange is bound to authentication of the service to the user 205 such that the service is finally authenticated when it sends a 206 proof-of-possession of the exchanged session key back to the user. 207 Protocols that use RSA key transport (e.g., TLS in common usage), 208 Diffie-Hellman with a persistent public key for the server, or 209 Needham-Schroeder protocols (such as Kerberos[RFC4120]), perform 210 server authentication in this way. A client may not always care 211 to receive key confirmation. For example, a Kerberos client for a 212 lossy logging application might not care that confidentiality 213 protected data ends up at the wrong server, as long as unintended 214 servers can't decrypt the data. Some clients may send application 215 data optimistically ahead of key confirmation from the server. 216 Such data should generally be confidentiality protected, and the 217 protocol should not be subject to MITM attacks where the MITM can 218 somehow modify what optimistic data is sent, nor should an active 219 attacker be able to replay such optimistic data. 221 Network Layer A layer in the OSI or Internet network model. 222 Examples of layers that are relevant to HTTP applications: IP, 223 TCP/UDP, TLS, HTTP, and the application layer. 225 Proof of Possession A technique for authentication that involves 226 using a cryptographic operation to "prove" (not necessarily in a 227 rigorous sense) that the entity that creates the proof has access 228 to a private/secret key to a cryptosystem (e.g., a private RSA 229 key, a secret AES key, etcetera). 231 Public Key Infrastructure (PKI) An authentication system based on 232 public key cryptography and supporting hierarchical transitive 233 trust via trusted third parties known as Certificate Authorities 234 (CAs). 236 Relying Party An entity that authenticates another. For example, in 237 PKI the entity that validates another's certificate as part of the 238 process of authenticating that other entity, is a relying party. 240 SCRAM Salted Challenge Response Authentication Mechanism 241 (SCRAM)[RFC5802], a SASL[RFC4422] and GSS mechanism based on 242 password-derived pre-shared keys and challenge/response. SCRAM is 243 intended as the successor to SASL's DIGEST-MD5, and possibly to 244 HTTP's DIGEST-MD5. 246 Server A system with one or more IP addresses, serving HTTP on one 247 more TCP ports on those IP addresses. [A general definition would 248 not be constrained to HTTP only, but for the purposes of this 249 document this is good enough.] 251 Service An entity providing a service or services for an 252 application. Typically -but not always!- a service is closely 253 related to a host server, which may provide several services. 254 Usually we need to distinguish between the various services that a 255 single host provides, thus we often need to authenticate the 256 _service_ rather than the host server. For HTTP applications a 257 service may be a collection of resources available on one (or 258 more) ports on a given server. 260 Trust (in authentication) This word, "trust", is a terrible word: it 261 means too many things to too many people. But it's also a very 262 convenient word when everyone understands the meaning to be 263 accorded to it in any given context. For the time being this 264 document will use this word, "trust", as follows: to trust an 265 entity is to accept as fact assertions -relating to other 266 entities- made by the trusted entity. Alternative phrasing: to 267 trust an entity is to rely on it to make assertions relating to 268 other entities the truth of which cannot otherwise be ascertained. 269 For example, in a PKI a relying party relies on the certification 270 authorities (and related infrastructure) to make statements of 271 facts of the form "the public key belongs to " 272 (details elided). We only use "trust" in connection to "trusted 273 third parties" - when an authenticated entity makes assertions 274 about itself we do not speak of trusting them to do so. 276 Trust (in user interfaces) One of the many alternative meanings of 277 "trust", and the only alternative one used in this document, 278 relates to user interfaces, namely: a trusted user interface is 279 one that the user can somehow ascertain that it is presented by 280 the operating system or browser platform and _not_ by some 281 possibly malicious peer. 283 Trust Path Continuing with the horrible word "trust", we use "trust 284 path" to the note the list of trusted third parties involved in 285 authenticating an entity to a relying party. This list is 286 ordered, though it could conceivably be set of lists when multiple 287 trust paths are possible. 289 Trusted Third Party An entity that can be relied up -by those 290 relying parties that trust it- to make assertions relating to 291 other entities, typically assertions about how to authenticate 292 those entities and/or of facts relevant to authorization at the 293 relying party. 295 [[anchor1: Fill out! Add some entries for OAuth, Kerberos, Basic, 296 DIGEST-MD5, EAP, GSS, SASL, ...]] 298 2. Background 300 Web applications today use a variety of user authentication methods, 301 many of which are somewhat or deeply unsatisfying. Almost all of 302 these methods involve the user-agent being mostly dumb - not 303 participating in any cryptographic protocols other than TLS. 305 The most common user authentication methods used in web applications 306 today include: 308 o Username and password POSTed to the server from an HTML form. 309 Usually the URL to post to is an HTTPS URL. Not as often the URL 310 of the HTML page containing the form is also an HTTPS URL. 312 o HTTP Basic or DIGEST-MD5 authentication. 314 o Out-of-band methods: 316 * PINs sent to user devices via SMS (POSTed along with passwords) 318 * OTP tokens (POSTed along with passwords) 320 * login URLs e-mailed to the user 322 * passwords e-mailed to the user 324 Not much use is made of TLS user certificates, though that is 325 available as well. 327 These methods are somewhat-to-highly unsatisfactory for a variety of 328 reasons: 330 o Users have to remember/carry too many passwords, even when they 331 have many fewer "identities" (typically in the form of e-mail 332 addresses). 334 * Credential sharing becomes a problem: compromise of one site 335 can result in compromise of user accounts at unrelated sites. 336 Also, a malicious site posing as a friendly site can do the 337 same. 339 o The service is generally not authenticated to the user. TLS does 340 authenticate the server, but not necessarily the service, and 341 anyways only to the best of the TLS server PKI's ability. 343 * This problem derives in part from the nature of the HTTP URI 344 scheme: by identifying server hosts rather than services the 345 HTTP URI scheme fails to provide the user and user-agent with 346 enough information by which to identify, and thence 347 authenticate, a service. New URI schemes may be required. 349 o The TLS server PKI is fundamentally weak. 351 o User credentials are too easy to "phish". 353 o OTP and out-of-band methods do not protect against MITMs, and thus 354 depend on the integrity of TLS and the TLS server PKI. 356 o HTTP/Negotiate[RFC4559], which effectively uses GSS-API[RFC2743] 357 mechanisms, usually NTLM [XXX Add reference] or Kerberos[RFC4120], 358 [RFC4121]. 360 Additionally, there is no strong concept of "sessions" in web 361 applications. Sessions, such as they are, consist of HTTP requests 362 and responses united into a session by the web cookies they bear. 363 Not all web cookies are used for identifying sessions, and there is 364 no simple "logout" functionality. The biggest problem with web 365 cookies is that they are too easy to misuse or steal (e.g., given the 366 occasional TLS vulnerability, such as BEAST [XXX Add references!]). 368 Furthermore, there are uncomfortable user interface (UI) problems. 369 In particular it is difficult to convey to the user information about 370 the server's/service's identity and how it is authenticated (if at 371 all). 373 HTTP applications that are not web application have similar issues, 374 though some of them can also use SASL[RFC4422]. Non-web HTTP 375 applications also may not need cookies, instead using a single 376 HTTP/1.1 persistent connection over which to issue all requests that 377 make up a session - such applications have a stronger sense of 378 session than web applications do. 380 [[anchor2: XXX Finish this section.]] 382 2.1. Threat Models 384 [[anchor3: Talk about threat models and which are appropriate for 385 HTTPbis. Discuss the Internet threat model and its flaws (namely/ 386 primarily, the local security assumption).]] 388 2.2. On Trust 390 [[anchor4: Describe issues w.r.t. "trust", such as transitivity, 391 introductions, and so on. This is important for evaluating 392 proposals. A proposal that replaces the TLS server PKI's primacy 393 with... another system with similar transitive trust issues may not 394 be a useful proposal. On the other hand, it seems impossible to 395 avoid transitive trust when scaling to Internet scale. Understanding 396 this may help, for example, give impetus to improvements to the TLS 397 server PKI, or it may guide replacements, understand scalability, and 398 so on.]] 400 2.3. On the TLS Server PKI 402 The TLS server PKI, and, truly, any hierarchical or flat PKI intended 403 for authenticating servers or services to users has a fundamental 404 problem: the number of Names for which to issue certificates is too 405 large to expect the PKI administrators to do a good job of keeping 406 out the bad guys. Bad guys use any number of phishing techniques 407 such that the names of their services need not even match those of 408 the services that they wish to steal credentials for. The goal 409 should be to keep the bad guys out altogether, but this is also quite 410 difficult, if not impossible for many reasons including political 411 ones. 413 The TLS server PKI suffers from a number of other non-fundamental 414 problems, mostly due to legacy deployment: 416 o x.500-style naming, which utterly fails to match Internet naming 417 (domainnames, e-mail addresses, etcetera); 419 * The addition of subjectAlternativeName (SAN) does not 420 successfully address this problem because a) the 421 TBSCertificate's primary Name is still limited to being an 422 x.500 name, and b) too much of the deployed relying party base 423 simply lacks SAN support. 425 o incomplete implementations of the PKIX standards; 427 * For example, missing implementations of name constraints, 428 leading to the inability of CAs to safely issue intermediate CA 429 certificates to their customers as either such certificates 430 cannot contain critical name constraints or those are ignored 431 by some relying parties anyways, thus intermediate CAs have no 432 real constraints other than those enforceable by HSMs. 434 * In general it is not possible to make use of critical 435 certificate extensions in certificates that will be presented 436 to the Internet web's user-agents: they will either ignore such 437 extensions, fail soft (by prompting the user as to whether to 438 continue or fail), or fail hard. None of these relying party 439 behaviors are desirable on the Internet. This problem arises 440 from the nature of security protocols that use PKIs, which in 441 turn results from the off-line infrastructure nature of PKIs. 443 By encouraging non-negotiation of security features, PKI pushes 444 future extensions into a critical/non-critical dichotomy, but 445 since critical extensions are difficult to deploy, the result 446 must either be additional negotiation in protocols using PKI 447 (e.g., TLS SNI), or non-use of critical extensions. Compare to 448 Kerberos, where there is a negotiation between the client and 449 the server _by proxy_ (i.e., mediated by the KDC). 451 The TLS server PKI also suffers from all the problems that trusted 452 third party systems suffer from, namely: the need to trust the third 453 parties. Fortunately there are a number of efforts under way to 454 improve the trustworthiness of TLS server PKI CAs by, for example, 455 making them auditable by the public [XXX Add references to CT, 456 Convergence, HSTS/TACK/other pinning schemes, and others!] 458 And yet the TLS server PKI is here to stay. It will not go away. We 459 can only minimize the dependence of the web's security on the TLS 460 server PKI. To do so requires authentication mechanisms that can 461 provide authentication of the server to the user in some manner such 462 that none of the above problems apply. The hardest PKI problem to 463 address is the fundamental problem described above: this requires 464 accepting a smaller scale of server/service authentication to the 465 user - a balkanization of sorts of the web, but see the discussion of 466 trust islands in Section 3.6. 468 2.4. On Mutual Authentication and URI Schemes 470 [[anchor5: Describe the limitations imposed by the Internet threat 471 model when there is no mutual authentication. Describe the two 472 types/senses of mutual authentication: authenticating the server (in 473 addition to the client) and key confirmation. Describe the 474 limitations, imposed by the HTTP URI scheme, on service 475 identification and authentication.]] 477 2.5. On Authentication Mechanism Message Counts 479 All authentication mechanism require some number of messages in order 480 to authenticate an entity. For example, TLS generally requires two 481 round-trips, while OAuth requires a single message from the client to 482 the server. Here we count only messages from the HTTP client to the 483 HTTP server; additional message exchanges may be required involving 484 trusted third parties. 486 The number of authentication messages that must be exchanged for a 487 given authentication mechanism is important. The API of at least one 488 important credential management facility is premised on 489 authentication mechanisms having exchanges of just one message - 490 adding new API is possible, but it would take a long time for 491 applications to begin using it. Thus mechanisms that require just 492 one message are at a premium (but see the next section). 494 The number of authentication messages is also important for latency 495 reasons: since authentication message exchanges are synchronous, each 496 round trip time is added to the latency observed by the user. 498 The number of messages that an authentication mechanism needs to 499 exchange with infrastructure (e.g., trusted third parties) also 500 affects latency, but at least applications need never be aware of 501 messages exchanged with infrastructure - these can be abstracted away 502 by the APIs. Some authentication mechanisms have fast re- 503 authentication facilities such that the latency cost of 504 infrastructure messaging need not be incurred as frequently as the 505 entity authenticates to others. 507 [[anchor6: ...]] 509 2.5.1. On One-Message Authentication Mechanisms 511 Half round trip mechanisms depend utterly on some other system for 512 authentication of the server - in webauth this means the TLS server 513 PKI. To understand why imagine that an application sends the one 514 authentication message to a service, but it turns out that it is 515 speaking to an impersonator for that service. The impersonator can 516 at the very least obtain any sensitive data that the application is 517 willing to send immediately. Additionally, if there's no channel 518 bindings between the authentication mechanism and the service 519 impersonator then the one message can be sent by the impersonator to 520 the real service, letting the service impersonator impersonate the 521 user to the real service as well (thus being a proper MITM). 523 There exist a number of one-message webauth authentication mechanisms 524 that are widely deployed; we cannot forbid their use, we can only 525 document their security considerations, namely: that they depend 526 entirely on the TLS server PKI for their security. 528 2.6. Logon Sessions 530 [[anchor7: Discuss the binding of HTTP requests (and responses) to 531 logon sessions. Discuss logout.]] 533 2.7. Web Cookies, a Form of Bearer Tokens 535 [[anchor8: Discuss cookies as a form of bearer token and how the 536 situation is not as dire as with bearer tokens for user 537 authentication. Discuss alternatives based on MACing portions (or 538 all) of the HTTP requests (and responses) or the channel bindings 539 data for the TLS channel.]] 541 2.8. User Interface Issues 543 [Discuss phishing issues, in particular the difficulty of creating 544 user interfaces in web apps that cannot be spoofed by either server 545 impersonators or MITMs. Reference Sam Hartman's anti-phishing I-D 546 [I-D.hartman-webauth-phishing].] 548 3. Classification Axes 550 Several orthogonal classification axes are proposed: 552 1. Dependence on/independence of the TLS server PKI; 554 2. Solutions based on bearer tokens vs. ones based on proof of 555 possession; 557 3. Layer at which user authentication takes place: TLS, HTTPbis, or 558 the application layer (note: distinguishing network layer from 559 API layer); 561 4. Whether the client, the server, or both, engage in infrastructure 562 messaging; 564 5. Number of messages exchanged / "round trips"; 566 6. Trust establishment: pair/group-wise non-transitive, federated or 567 otherwise transitive, hierarchical vs. mesh; 569 7. Threat modeling; 571 8. Explicit versus implicit session management; 573 9. In-band / out-of-band. 575 [[anchor9: Maybe add something about separation of password verifier 576 access, to limit the attack surface area for password recovery?]] 578 [[anchor10: Note: The author assumes that all acceptable proposals 579 will have HTTPbis continue to depend on TLS for transport security - 580 for confidentiality (encryption) and integrity (authentication) 581 protection of data exchanged by the HTTPbis client and server. If 582 this assumption is incorrect then we can add one more axis of 583 classification: dependence on / independence of TLS.]] 585 These nine classification axes are largely orthogonal to each other. 586 Other classification criteria are also possible and may be added in 587 future versions of this Internet-Draft. Some such possible 588 additional criteria are subjective, such as, for example: ease of 589 deployment, ease of implementation, etcetera. Perhaps the WG can 590 come to consensus regarding desirable properties based on objective 591 classification to narrow the set of proposals to consider. Or 592 perhaps the WG can consider a large number of proposals and use 593 objective classification to guide any applicability statements for 594 the proposals accepted. Ideally the WG can apply objective 595 classification first, then for each "bucket" of similar proposals the 596 WG could consider more subjective classification criteria. 598 3.1. Dependence on TLS Server PKI 600 The web today depends utterly on the "TLS server PKI" for security. 601 This would be just fine were it not for the systemic weaknesses in 602 the TLS server PKI: the lack of name constraints, the large number of 603 trust anchors, the large number of certificate authority (CA) 604 compromises, and so on. Building on the TLS server PKI and thus 605 assuming its being sufficiently secure, is quite tempting, as it may 606 simplify various aspects of user authentication (not least by 607 providing server authentication a priori, thus saving the designers 608 the need to provide server authentication themselves). 610 This classification axis is very simple: either a proposed solution 611 depends on the TLS server PKI or it doesn't. Some shades of black 612 are imaginable in this case (if not likely). 614 3.2. Bearer Tokens vs. Proof of Possession 616 A bearer token is a message the presentation of which is sufficient 617 to authenticate the presenter. Stolen bearer tokens may be used to 618 trivially impersonate the subject, thus bearer tokens generally 619 require confidentiality protection in any protocols over which they 620 might be exchanged, and generally depend on authenticating the 621 relying party first. 623 Proof of possession systems consist of some secret/private key(s), an 624 authenticator message the "proves" possession of the secret or 625 private key(s) used in the construction of the authenticator, and a 626 token not unlike a bearer token but which securely indicates to the 627 relying party(ies) what keys the user must have used in the 628 construction of the authenticator. The relying party then validates 629 the authenticator to establish that the user did indeed possess the 630 necessary secret/private key(s) to the best of the cryptographic 631 capabilities of the authentication system used. 633 3.3. Layer at which Authentication Protocol Operates 635 It is possible to design user (and mutual) authentication mechanisms 636 that can work at any end-to-end layer between the HTTPbis client and 637 server. The relevant layers are: 639 o TLS, 641 o HTTPbis, 642 o and the application layer. 644 We dismiss out of hand the possibility of that layer being TCP or 645 IPsec, though admittedly they are also end-to-end layers where user 646 authentication could theoretically be done. 648 We distinguish between network layers and API layers (see glossary). 649 A solution at the application _network_ layer might nonetheless be 650 implemented at the HTTP _API_ layer (and vice-versa). 652 User authentication is generally something that a transport layer 653 cannot know to initiate on its own: the application must be in 654 control of when (server- and client-side) to authenticate, how 655 (server- and/or client-side), with what credentials / as whom 656 (client-side). This means that authentication in the transport layer 657 requires APIs that give the application a measure of control. HTTP 658 API capabilities will vary, but HTTPbis is a good opportunity to 659 standardize an abstract API outlining capabilities and semantics to 660 be exposed to applications by an HTTP stack. 662 Note that on the user-agent side the platform may provide user 663 interaction facilities for authentication, thus simplifying user 664 authentication APIs. The application, on the server side, remains in 665 control over when to initiate authentication. 667 End-to-end session cryptographic protection is best done in the 668 lowest possible transport layer. For HTTP applications, historically 669 this means TLS; though it'd be technically feasible to provide 670 protection at lower layers it does not appear to be a realistic 671 option at this time. 673 User authentication is best "bound" into transport security layers, 674 in this case TLS. When user authentication is moved to higher layers 675 a "channel binding" problem arises: we would like to ensure that no 676 man-in-the-middle exists in the transport layer, with the MITM 677 terminating two TLS connections. For more information about channel 678 binding see [RFC5056]. 680 UI and API issues are quite different for web applications versus 681 non-web applications. The former have rich UI elements (all of 682 HTML's) and programming models (scripting, particularly through 683 JavaScript). One problem that is particularly severe for web 684 applications, is the ability of server impersonators to emulate all 685 imaginable graphical user interfaces that the native user-agent might 686 wish to use to distinguish itself from the applications it runs. 687 Regardless of what layer implements authentication this problem will 688 arise in web applications. 690 3.3.1. HTTP- vs. Application-Layer Authentication in the Network Stack 692 It's important to note that there need not be much difference between 693 HTTP-layer and application-layer user authentication, at least if we 694 assume a standard application-layer user authentication convention. 695 For argument's sake let's assume an application-layer user 696 authentication convention like the one in [I-D.williams-rest-gss], 697 and let's assume two possible HTTPbis HTTP-layer authentication 698 solutions: one that is most similar to HTTP/1.1's and one that uses a 699 new verb for authentication. Then let's look at what each of these 700 three solutions look like on the wire using the SCRAM mechanism for 701 cases where the client already knows it has to authenticate. For 702 brevity we elide any HTTP request and response where the server 703 indicates that the client must authenticate, as well as any requests/ 704 responses involving negotiation of mechanism to use. 706 C->S: HTTP/1.1 POST /rest-gss-login 707 Host: A.example 708 Content-Type: application/rest-gss-login 709 Content-Length: nnn 711 SCRAM-SHA-1,,MIC 712 n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL 714 S->C: HTTP/1.1 201 715 Location http://A.example/rest-gss-session-9d0af5f680d4ff46 716 Content-Type: application/rest-gss-login 717 Content-Length: nnn 719 C 720 r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 721 s=QSXCR+Q6sek8bf92,i=4096 723 C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46 724 Host: A.example 725 Content-Type: application/rest-gss-login 726 Content-Length: nnn 728 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 729 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 731 S->C: HTTP/1.1 200 732 Content-Type: application/rest-gss-login 733 Content-Length: nnn 735 A 736 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 738 Figure 1: REST-GSS Login w/ SCRAM Example 740 Figure 1 742 C->S: HTTP/1.1 LOGIN 743 Host: A.example 744 Content-Type: application/SASL 745 Content-Length: nnn 747 SCRAM-SHA-1,,MIC 748 n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL 750 S->C: HTTP/1.1 201 751 Location http://A.example/login-session-9d0af5f680d4ff46 752 Content-Type: application/SASL 753 Content-Length: nnn 755 C 756 r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 757 s=QSXCR+Q6sek8bf92,i=4096 759 C->S: HTTP/1.1 LOGINCONTINUE /login-session-9d0af5f680d4ff46 760 Host: A.example 761 Content-Type: application/SASL 762 Content-Length: nnn 764 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 765 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 767 S->C: HTTP/1.1 200 768 Content-Type: application/SASL 769 Content-Length: nnn 771 A 772 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 774 Figure 2: HTTPbis w/ New Verb Login w/ SCRAM Example 776 Figure 2 778 C->S: HTTP/1.1 GET /location/of/interest/to/app 779 Host: A.example 781 S->C: HTTP/1.1/401 Unauthorized 782 Server: HTTPd/0.9 783 Date: Sun, 10 Apr 2005 20:26:47 GMT 784 WWW-Authenticate: 785 Content-Type: text/html 786 Content-Length: nnn 788 790 C->S: HTTP/1.1 GET /location/of/interest/to/app 791 Host: A.example 792 Authorization: SCRAM-SHA-1,,MIC 793 n,,n=user,r=fyko+d2lbbFgONRv9qkxdaw 795 S->C: HTTP/1.1 4xx 796 WWW-Authenticate: C 797 r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 798 s=QSXCR+Q6sek8bf92,i=4096 799 WWW-Authenticate-Session: 9d0af5f680d4ff46 801 C->S: HTTP/1.1 GET /location/of/interest/to/app 802 Host: A.example 803 Authorization-Session: 9d0af5f680d4ff46 804 Authorization: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 805 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 807 S->C: HTTP/1.1 200 808 WWW-Authenticate: A 809 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 810 Content-Type: ... 811 Content-Length: nnn 813 815 Figure 3: Extended HTTP/1.1 Style Login w/ SCRAM Example 817 Figure 3 819 There's not much difference between the first two examples. The 820 third example has several important differences relative to the first 821 two examples: 823 o The URL is sent to the server before any chance to have completed 824 mutual authentication, should the selected mechanism provide 825 mutual authentication. If the client knows a priori to 826 authenticate and the URL contains sensitive information then the 827 client has no choice but to leak this information prior to 828 completing mutual authentication, thus the client becomes 829 dependent on TLS for authenticating the server even when the 830 client could authenticate the server more strongly via the 831 selected HTTP authentication mechanism. This is an important 832 weakness. 834 o The whole sequence involves multiple requests/responses, which 835 goes against the stateless nature of HTTP. State is needed in all 836 three examples, but the first example is RESTful, while the second 837 employs a would-be new verb that provides for stateful 838 authentication. The third example simply cannot be thought of as 839 remotely RESTful. Perhaps this is not a problem. 841 * Alternatively mechanisms requiring multiple round trips can be 842 ruled out of scope. This would rule out quite a few desirable 843 mechanisms! 845 The main difference on the wire between a generic HTTP-layer user 846 authentication framework (like the one in the second example) and an 847 application-layer equivalent (as in the first example) can be so 848 minimal as to make the choice of layer seem like splitting hairs. 850 3.3.2. HTTP- vs. Application-Layer Authentication in the API Stack 852 There are HTTP stacks that make it possible to implement HTTP 853 authentication methods in the application (e.g., FCGI in web 854 servers), and nothing would prevent HTTP stacks from implementing a 855 _standard_ application-layer user authentication protocol either. 856 The APIs offered by an HTTP stack should look remarkably similar 857 regardless of which layer the user authentication protocol is 858 technically at. Once again, the difference between HTTP-layer and 859 standard application-layer user authentication is minimal. 861 Note however that if the HTTP stack does not implement 862 authentication, leaving it to the application to do so, then the 863 application developer runs the risk of making mistakes in the 864 implementation, such as failing to implement channel binding where 865 possible. Thus it is generally best if the HTTP stack implements 866 authentication - even if TLS is used for user authentication, the 867 HTTP stack should provide a singular API for authentication. 869 3.3.3. Choice of Layer 871 The choice of layer is clearly more important for APIs than on the 872 wire. On the wire the choice of layer is minimal, trivial even, when 873 the choice is between HTTP and the application layer. 875 If the WG agrees that the distinction between HTTP-layer and 876 application-layer user authentication is or should be minimal then 877 how should the WG pick one of those two layers, if it decides not to 878 pursue TLS-layer user authentication? 880 A standard application-layer authentication scheme implies no changes 881 to HTTP itself, and may not rely on any particular features of 882 HTTP/1.1 or HTTPbis, thus it may be usable even with HTTP/1.0. This 883 is true of the REST-GSS proposal[I-D.williams-rest-gss], which is 884 also RESTful. This must be of some value. 886 An HTTP-layer authentication solution must either: a) not support 887 multi-round trip mechanisms, b) add verbs, or c) not be RESTful. (a) 888 works with HTTP/1.0, (b) would not work with HTTP/1.0. [The author 889 believes that RESTfulness is desirable.] 891 3.3.4. User Authentication in the TLS Layer 893 Issues: 895 o The transport cannot know when to require user authentication (on 896 the server side) or when to initiate it (on the client side). 897 Simply always initiating user authentication creates privacy 898 problems: the user may not want to disclose their identity all the 899 time! 901 o To address the problem of when to require or initiate user 902 authentication the TLS implementation must provide suitable APIs 903 to the application. And since the application will generally 904 decide that authentication is required only after (possibly well 905 after) a TLS connection is setup, the user generally must be 906 authenticated by renegotiating TLS, which in turn means that two 907 round trips will be needed just for that, at minimum, even if the 908 user authentication mechanism selected requires fewer round trips. 909 This is inefficient, though not fatal. 911 o The TLS community has resisted proposals for user authentication 912 mechanisms with arbitrary round trip counts before [references? 913 this is in reference to Stefan's TLS-GSS proposal...]. This may 914 no longer be true (or perhaps the author is misunderstanding or 915 misremembering the events in question), but if it is still the 916 case then the range of choices for user authentication in TLS is 917 significantly curtailed. 919 o Several major TLS implementations defer certificate validation 920 until the peer's Finished message is received. This means that 921 unless one is using TLS renegotiation (with the inner connection's 922 server certificate being the same as in the outer connection's) 923 the user's identity and the payloads related to user 924 authentication will be revealed to the server before the server is 925 authenticated. 927 o User Interface issues: 929 * A user authentication framework and future mechanisms will 930 likely need to interact with the user. In some cases this may 931 be best done through a platform component, such as a credential 932 management facility. In other cases this may best be done by 933 the application. Driving user interaction from within the TLS 934 layer presents a slight complication: any interaction has to be 935 effected through application- or platform-provided code paths. 936 Adding interaction to existing TLS implementations may not be 937 trivial. 939 * ... 941 Benefits: 943 o Where the platform can provide credential management and user 944 interaction then user authentication in TLS can greatly simplify 945 HTTP applications: no user authentication APIs or UIs are then 946 needed in the application. 948 * Note however that the user may have a hard time identifying the 949 context in which they are being prompted by the system for 950 credentials or credential selection. This is usually not a 951 problem in smart-phone and other such small devices, where it 952 is generally clear what application is in the foreground, and 953 therefore the context of a prompt. But this is not necessarily 954 so on other platforms. 956 o Non-web applications typically know a priori when they wish to 957 authenticate. Typical non-web applications that use HTTP/1.1 over 958 a single TLS connection, with an application session consisting of 959 all the HTTP requests performed over that one connection. For 960 such applications having user authentication in the TLS layer may 961 be the simplest way to get user authentication into the 962 application. 964 3.4. Party Responsible for Infrastructure Messaging 966 [[anchor11: XXX Add references for OCSP, AAA, ...]] 968 "Infrastructure" consists, for the purposes of this document, of 969 services such as Identity Providers (IdPs), Certificate Revocation 970 Lists (CRLs) and their servers, Online Certificate Status Protocol 971 (OCSP) responders, Kerberos Key Distribution Centers (KDCs), RADIUS/ 972 DIAMETER servers, etcetera. These are services that run on parties 973 other than a client (e.g., a web browser / user agent) and an 974 application server. In some cases infrastructure services may be 975 physically co-located with the client or server, but by and large 976 they are physically separated; infrastructure services are always 977 logically separate from the client and server. [XXX Move this to 978 glossary.] 980 Some protocols require that the client do all or most of the message 981 exchanges with infrastructure, some require that the server do this 982 messaging, some require both to do some messaging. In some cases a 983 server might proxy a client's messages to infrastructure. There are 984 advantages to the client doing this messaging: namely a simpler 985 server, less subject to denial of service / resource consumption 986 attacks. [Are there advantages to the server doing this messaging?] 988 Consider a protocol like Kerberos. Kerberos relies on Key 989 Distribution Center (KDC) infrastructure, and it relies on the client 990 doing all the messaging needed to ultimately authenticate it to a 991 server. Kerberos can be used in a way such that the relying party 992 proxies this messaging for the client (see IAKERB), but even so the 993 client had to communicate with the KDCs in order to ultimately 994 authenticate to the relying party - IAKERB is simply a proxy 995 mechanism. 997 Now consider an authentication mechanism based on PKI. The only 998 online infrastructure in a PKI are the CRLs and OCSP responders. Of 999 course, a Certificate Authority (CA) can also be online, as in kca 1000 [add reference], a CA that authenticates clients via Kerberos and 1001 which issues fresh, short-lived certificates. Private keys for 1002 certificates can also be served by online services such as SACRED and 1003 browserid. The method of validating certificates currently 1004 considered ideal is for the possessor of certificate's private key to 1005 send both, the certificate and a current/fresh OCSP response for it 1006 (or, rather, responses, for the entire certificate chain), thus the 1007 PKI relying party should ideally not have to contact infrastructure; 1008 in practice CRL checking is still the more commonly used method, 1009 requiring infrastructure messaging on the relying party side. 1011 The responsibility for infrastructure messaging varies widely. 1013 3.5. Number of Messages 1015 The number of messages that must be exchanged in order to 1016 authenticate a peer varies a lot by authentication mechanism. Some 1017 require just one message from the client to the server. Others 1018 require a reply message from the server. Others require some larger 1019 number of messages (typically three or four). Yet others require a 1020 variable number of messages. 1022 Typically key exchange is also required in order to provide 1023 confidentiality and integrity protection to the transport. Key 1024 exchange protocols also vary in number of messages required. Key 1025 exchange and authentication may be combined, either directly in a 1026 single network layer, or across layers via channel binding. 1028 One-message authentication protocols: 1030 o OAuth 1032 o Kerberos (w/o key confirmation) 1034 o Public key signature schemes when authenticating only the client 1036 o Diffie-Hellman (when the client knows the server's DH public key a 1037 priori, and w/o key confirmation) 1039 o RSA key transport (w/o key confirmation) 1041 o all bearer token protocols (but see [ref to on channel bindings 1042 section]) 1044 Two-message authentication protocols: 1046 o Kerberos 1048 o Diffie-Hellman with fixed public keys 1050 o RSA key transport 1052 Authentication protocols with three or more messages, or with 1053 arbitrary numbers of messages: 1055 o Most/all zero-knowledge password proof protocols (e.g., SRP) 1056 (usually three or four messages) 1058 o SCRAM, and other challenge-response protocols (usually three or 1059 four messages) 1061 o IAKERB (usually four messages) 1063 o Pluggable frameworks (SASL, GSS, EAP) (arbitrary message counts, 1064 usually dependent on what mechanism is selected) 1066 It's worth pointing out that TLS is a three- to four-message 1067 protocol, but when providing confidentiality protection for the 1068 client identity it becomes a six- to eight-message protocol (though 1069 there is a proposal to improve this, getting back to three to four 1070 messages [add reference to Marsh's I-D]). 1072 Some authentication protocols can provide key exchange, others 1073 cannot. Similarly, not all mechanisms can provide channel binding. 1075 The total number of messages required is important. These message 1076 exchanges are always ordered and synchronous; no progress can be made 1077 by the application until they are completed. Over long distances the 1078 time to complete each round trip add up to noticeable latency, and 1079 there is much pressure to get this latency down to an absolute 1080 minimum. 1082 Integrating user authentication into TLS has the clear allure of 1083 potentially cutting down the number of round trips necessary, but 1084 it's not clear that this can be achieved in every case. In 1085 particular it may not be clear that a client has to authenticate 1086 until after a TLS connection is established over which the client may 1087 request access to some resource that requires authenticated clients. 1089 3.6. Trust Establishment 1091 Pair-wise pre-shared keying systems require careful initial key 1092 exchange, but otherwise have no transitive trust issues: every pair 1093 of entities that has shared keying can communicate without the aid of 1094 any other entity. However, pair-wise pre-shared keying does not 1095 scale to the Internet as it is O(n^2), and it requires either "leap 1096 of faith" (a.k.a., trust on first use, or TOFU) or physical proximity 1097 for the key pre-sharing. Physical proximity 1099 Authentication mechanisms that scale to the Internet of necessity 1100 require some degree of trust transitivity. That is, there must be 1101 many cases where Alice and Bob can communicate with each other only 1102 because they can authenticate each other by way of one or more third 1103 parties (e.g., Trent) that each of them trust a priori. 1105 There are a number of issues with trust transitivity: 1107 o Trusted third parties can mount MITM attacks on the parties that 1108 rely on them 1110 * Compromise of trusted third parties, therefore, has far 1111 reaching, negative effects 1113 * The longer a trust path, the less trustworthy -so to speak- it 1114 is 1116 o Policy for determining acceptable trust paths is difficult to 1117 express 1119 o Mechanisms for establishing trust paths are often manual and prone 1120 to error or abuse 1122 There are several ways to use transitive trust. In hierarchical 1123 transitive trust we organize the trusted third parties in such a way 1124 that there should be a trust path for every pair of entities of 1125 interest (e.g., every user to every server, every user to every user, 1126 ...) - think of PKI. In mesh systems trust transits through every 1127 entity's "friends" - think of PGP. 1129 There may be other models of transitive trust, such as one with 1130 islands of trust. An islands of trust model would consist of 1131 federations of transitive trust (using hierarchical or mesh models) 1132 that are much smaller than the entire Internet, but large enough to 1133 be of use to large numbers of users. For example, an online merchant 1134 might provide for authentication of all users to a set of 1135 participating vendors [XXX expand on this]. 1137 Given the need for transitive trust and the serious drawbacks of 1138 transitive trust, some workarounds may be necessary, such as: 1140 o Policy language for choosing suitable trust paths 1142 o Facilities for limiting the length of, or otherwise shortening 1143 trust paths 1145 * By, for example, providing for bootstrapping of shorter trust 1146 paths when a given trust path involves an "introducer" trusted 1147 third party. 1149 o "Pinning" facilities to force changes in the infrastructure to 1150 proceed in ways which make some MITM attacks harder to mount 1152 o Auditing -and compromise detection- facilities by which to show 1153 that trusted third parties are not mounting MITM attacks 1155 o Revocation facilities that actually work 1157 o Root keys that are rarely used and live in HSMs 1159 o Fast re-keying as a method for dealing with trusted third party 1160 compromise 1162 For an example of pinning, consider a TLS extension where self- 1163 signed, persistent user certificates are used, possibly one per- 1164 origin for pseudonymity purposes. The user agent can enroll the user 1165 certificates at their corresponding origin servers such that 1166 thereafter no MITMs are possible that can impersonate the user to the 1167 server. Of course, such a scheme suffers from needing a fall-back 1168 authentication method when the user's device(s) that store the 1169 relevant private keys are lost. Users would need to be able to fall- 1170 back on an alternative authentication method for re-enrollment, 1171 likely one that is susceptible to attack or else is inconvenient. In 1172 this cases the pinning is on the server side; keep in mind that 1173 pinning need not only be used on clients, but may be used even in the 1174 distributed trust infrastructure (e.g., to shorten trust paths). 1176 Ideally an authentication facility for HTTP/2.0 should support a 1177 variety of trust establishment models, as it is not clear that one 1178 mode is superior to the others. (Though certainly the hierarchical 1179 model is likely the scheme that can have the most universal reach, 1180 and therefore most minimize user credentials needed. However, users 1181 may not mind having a small number of logon credentials for a trust 1182 island model.) 1184 3.7. Threat Modeling 1186 [[anchor12: Cover the Internet threat model. Discuss the end-to-end 1187 model and the hop-by-hop semantics of transitive trust.]] 1189 3.8. Explicit versus Implicit Session Management 1191 [[anchor13: Discuss lack of / weakness of application session concept 1192 on the web. Discuss the historically limited application of TLS 1193 sessions to HTTP apps. Discuss desirability of a real concept of 1194 session and logout.]] 1196 3.9. In-Band versus Out-of-Band Authentication 1198 [[anchor14: Discuss out-of-band user authentication systems such as 1199 ones where "tokens" are sent to users' mobile phones via SMS, as well 1200 as systems where a "login URL" is sent to the user via e-mail.]] 1202 4. Analysis of Some Possible Authentication Proposals 1204 [Cover: 1206 o Authentication mechanisms: 1208 * Bearer token systems 1210 * Other half round trip systems, including Kerberos, OAuth 1212 * PK w/ SACRED, browserid, smartcards 1214 * ZKPPs 1216 * Challenge/response password-based mechanisms (DIGEST-MD5, 1217 SCRAM) 1219 o Generic auth frameworks 1221 * GSS, SASL, EAP (anything else? IKEv2? SSHv2?) 1223 o Authentication in TLS, HTTP, and above HTTP 1225 o OTP and out-of-band (SMS, e-mail) auth, both as part of 1226 authentication mechanisms and as port of traditional webauth. 1228 o Traditional webauth (passwords posted in forms), possibly with 1229 password wallets (stateful and stateless) 1231 ] 1233 [[anchor15: What else to cover?]] 1235 5. Author's Recommendations 1237 It seems likely that no single user authentication method will 1238 satisfy the needs of all web applications. Nor can we predict the 1239 future. Moreover, some weak authentication approaches are perfectly 1240 safe for accessing low-value resources, or in contexts where the 1241 Internet threat model is overkill. This argues for a multitude of 1242 solutions, and possibly a pluggable system. 1244 The author proposes the following: 1246 1. For all authentication mechanisms (i.e., cryptographic 1247 authentication methods) use the GSS-API, possibly through the 1248 thin shim of SASL/GS2[RFC5801]. 1250 1. do this above HTTP in the network stack, but... 1252 2. ...recommend that this be implemented by HTTP stacks, rather 1253 than by applications. I.e., authentication above HTTP on the 1254 wire, but within HTTP as far as APIs are concerned. 1256 2. Encourage the adoption of islands of trust / federation for 1257 service authentication, rather than one single, world-wide PKI 1258 for service authentication. 1260 3. Encourage development of authentication mechanisms that fit the 1261 chosen authentication framework and which have the following 1262 features: 1264 1. federation (even though it implies trusted third parties) 1266 2. strong initial user authentication (e.g., with ZKPPs) 1268 3. minimized password verifier attack surface area (e.g., 1269 minimize the number of servers that have access to password 1270 verifiers) 1272 4. trust path bootstrapping 1274 5. short trust paths 1276 6. auditable trusted third parties 1278 7. [preferably] mutual authentication 1280 4. Standardize weak authentication mechanisms (e.g., passwords 1281 POSTed in forms) to facilitate the development of effective 1282 password managers. [This is primarily for low-value sites.] 1284 5. Specify HTML and JavaScript interfaces for initiating 1285 authentication, including the name of the service to authenticate 1286 to. This will allow login pages to have a customized look, yet 1287 allow for login operations to be performed by the browser 1288 platform using a strong authentication mechanism. Specifically 1289 there must be a method for kick-starting authentication such that 1290 the user and/or device identity and credential input does not 1291 happen through HTML forms but through browser/platform trusted 1292 user interfaces. 1294 6. Specify a new URI scheme that identifies services rather than 1295 hosts. For example: svc:@/. An 1296 option to embed service authentication information (possibly a 1297 digital signature, or a URL referring to a digital signature) may 1298 prove useful. 1300 1. Also specify a service location protocol. 1302 7. Specify an abstract API for interfacing HTTPbis applications to 1303 HTTPbis. 1305 6. References 1307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1308 Requirement Levels", BCP 14, RFC 2119, March 1997. 1310 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1311 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1313 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1314 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1315 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1317 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1318 Channels", RFC 5056, November 2007. 1320 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1321 Kerberos Network Authentication Service (V5)", RFC 4120, 1322 July 2005. 1324 [I-D.williams-rest-gss] 1325 Williams, N., "RESTful Hypertext Transfer Protocol 1326 Application-Layer Authentication Using Generic Security 1327 Services", draft-williams-rest-gss-01 (work in progress), 1328 June 2012. 1330 [I-D.hartman-webauth-phishing] 1331 Hartman, S., "Requirements for Web Authentication 1332 Resistant to Phishing", draft-hartman-webauth-phishing-09 1333 (work in progress), August 2008. 1335 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1337 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1338 Security Layer (SASL)", RFC 4422, June 2006. 1340 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1341 "Salted Challenge Response Authentication Mechanism 1342 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 1344 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1345 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1346 Authentication: Basic and Digest Access Authentication", 1347 RFC 2617, June 1999. 1349 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1350 Levkowetz, "Extensible Authentication Protocol (EAP)", 1351 RFC 3748, June 2004. 1353 [RFC2743] Linn, J., "Generic Security Service Application Program 1354 Interface Version 2, Update 1", RFC 2743, January 2000. 1356 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 1357 Kerberos and NTLM HTTP Authentication in Microsoft 1358 Windows", RFC 4559, June 2006. 1360 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1361 Version 5 Generic Security Service Application Program 1362 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1363 July 2005. 1365 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1366 Service Application Program Interface (GSS-API) Mechanisms 1367 in Simple Authentication and Security Layer (SASL): The 1368 GS2 Mechanism Family", RFC 5801, July 2010. 1370 Author's Address 1372 Nicolas Williams 1373 Cryptonector, LLC 1375 Email: nico@cryptonector.com