NW-PP18 Web Authentication, TLS and phishing
Nicolas Williams <Nicolas.Williams@sun.com> Fri, 08 February 2008 23:59 UTC
Return-Path: <discuss-bounces@ietf.org>
X-Original-To: ietfarch-discuss-archive@core3.amsl.com
Delivered-To: ietfarch-discuss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E20628C345; Fri, 8 Feb 2008 15:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.187
X-Spam-Level:
X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty8TVL4rVBv9; Fri, 8 Feb 2008 15:59:35 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D883A7749; Fri, 8 Feb 2008 15:59:35 -0800 (PST)
X-Original-To: discuss@core3.amsl.com
Delivered-To: discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E8428C104 for <discuss@core3.amsl.com>; Fri, 8 Feb 2008 15:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88Sw2MIjrAhG for <discuss@core3.amsl.com>; Fri, 8 Feb 2008 15:59:32 -0800 (PST)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 74E803A74D4 for <discuss@ietf.org>; Fri, 8 Feb 2008 15:59:32 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m19010oQ023926 for <discuss@ietf.org>; Sat, 9 Feb 2008 00:01:01 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m19010dr016776 for <discuss@ietf.org>; Fri, 8 Feb 2008 17:01:00 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m19010do015431 for <discuss@ietf.org>; Fri, 8 Feb 2008 18:01:00 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m19010DB015430 for discuss@ietf.org; Fri, 8 Feb 2008 18:01:00 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 08 Feb 2008 18:01:00 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: discuss@ietf.org
Subject: NW-PP18 Web Authentication, TLS and phishing
Message-ID: <20080209000059.GI15878@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
X-BeenThere: discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@ietf.org>
List-Help: <mailto:discuss-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@ietf.org?subject=subscribe>
Sender: discuss-bounces@ietf.org
Errors-To: discuss-bounces@ietf.org
[Lisa: feel free to re-post with a proper PP number.] Abstract Cryptographic user and server authentication, and cryptographic transport protection are requirements for dealing with modern threat models for the Internet. Phish attacks aim to steal credentials, but if not credentials, then man-in-the-middle (MITM) access. It is important to ensure that user/service authentication and cryptographic transport protection are cryptographically bound so as to avoid MITM attacks. Implied, of course, if authentication stronger than the current reigning champion: username&password-over-TLS (which does not, and cannot support channel binding). Additionally, phishing opportunities must be limited, such as by using authentication tokens that cannot be captured and played to other relying parties. One goal is to push phishing opportunities to the edge of the system: enrolment. "Nigeria scam" type phishing is out of scope for this paper, but phishing attacks where a user is directed to a malicious site (e.g., via spam e-mail) or where the user accidentally goes to a malicious site (e.g., via typo-squatting) are in scope. Introduction Current practice for web authentication follows this pattern: - The client is directed (or re-directed) to an https URL using... - ...TLS with server certificate and anonymous client - The page at the https URL contains an HTML form with username and password text input fields; the form is [usually] POSTed via an https URL - When the browser posts said form the server sets a protected [and, where encryption is not required, an unprotected] cookie - Subsequent HTTP requests include said cookie, which contains or points to server-side state indicating who the user is and that they are authenticated Web applications generally involve many HTTP requests, using HTTP as a sort of reliable datagram transport. Usually multiple TCP connections are used, with little multiplexing of HTTP requests per-TCP connection. A few observations: - Username-and-password-over-TLS authentication is not very strong - Stealing usernames and passwords is a common phish attack goal, as those provide the access that attackers desire (e.g., to one's bank accounts) - Server certificates are only as good as the CAs that issue them - There are a multitude of CAs, and browsers ship with large trust anchor sets - There is no true global PKI - Server certificates are easy to obtain for typo and confusable versions of legitimate domain names - It is easy to obtain typo and confusable versions of legitimate domain names; DNSSEC will not change this - That said, cookies are a fine mechanism for associating a multitude of HTTP requests with a given application session - The use of cookies reduces the need for potentially expensive authentication events - If one think of a reliable datagram transport with built-in key exchange, authentication and encryption, then one can see that a protected cookie is a perfectly reasonable method of associating datagrams with sessions, thus reducing the number of authentication events needed per-session (there is plenty of precedent for this too) - So we need: better authentication of users and, possibly, servers - And we need to make sure that this authentication is strongly bound to the transport-layer encryption (TLS, in this case) - Server authentication is already so bound - Cryptographic binding of user and server authentication, and, direct or indirect cryptographic binding of authentication to key exchange and session cryptographic protection is required to detect MITMs I've been told several times that web authentication should happen at the application layer. Often the rationale is that developers don't like browsers' HTTP authentication dialogs, that they prefer to use HTML forms so that they can have more control over the authentication UI. At the same time every one seems to agree that sending username and password over TLS is a big part of the phishing problem, that we need better authentication methods. Arguments for why user authentication belongs in the application layer, even when using something other than plain username&password, can also be made. For example: o Authentication at the application layer allows application control over when it occurs, and application control over such UI elements as are reasonable to put in the hands of the application o Faster prototyping and more competition are possible if user authentication takes place at the application layer; otherwise the transport, browser and server stacks need to be re-deployed for authentication mechanism that anyone invents. On the other hand, one might argue that the difficulty of deploying new authentication mechanisms is a defense against bad authentication mechanisms, and that this is a good thing. Channel Binding The rest of this document assumes reader familiarity with the concept of channel binding [RFC5056]. Briefly, channel binding is a concept, dating to the early 1990s, where authentication at one layer is cryptographically bound to a secure channel (e.g., a TLS session, or a set of TLS sessions), such that no man-in-the-middle may exist when authentication with channel binding succeeds. Channel binding functions just like the binding between authentication and key exchange that protocols like IKE, TLS and SSHv2 already do, but with authentication removed to a higher network layer, usually the application layer. Internet and Phishing Threat Model Prior to the advent of phishing we have worried against a variety of active and passive attacks on Internet protocols, particularly active off-path attackers. But the rise of open wireless networks and the rise of phishing mean that we must take passive attacks (e.g., eavesdropping) and active attacks (e.g., server impersonation, MITM attacks) more seriously. A modern threat model for web applications should include: - passive attackers (e.g., eavesdroppers on open wireless networks) - active off-path attackers (e.g., sender spoofing) - active on-path attackers (e.g., MITMs) - active mis-direction attacks (phish attacks) - keeping in mind that phishers are after resources protected by the user credentials that they usually try to steal Federation Until recently users needed a username and password for every site and/or application that they used. This multiplicity of passwords is difficult to manage, and quite frustrating to users. Thus, users often use the same username and password across many unrelated sites, which makes theft of their credentials all the more dangerous to the users. Merely replacing usernames and passwords with stronger authentication methods may not reduce the number of identities that users must manage, but it does present the opportunity to do so. Assuming stronger authentication methods, one way to reduce the number of identities per-user is to allow one identity and/or related authentication infrastructure to be used for many sites. Credential theft in such a model is mitigated by making it difficult for attackers [who we assume do not have local access to the client] to steal the credentials; theft of authentication tokens should not be sufficient for impersonating the user. Implied in this is trust transitivity. Identity federation supposes islands of trust (as opposed to a global PKI, or other authentication infrastructure). Trust is no inherently transitive, and breaks down when trusted partners turn out to not be trustworthy, or as the trust chains become too long (does one trust a story related by a friend who heard it from a cousin who heard it from a friend who...?). Transitive trust can be implemented badly. For example, if "bearer token," asserting that the possessor is authenticated as some identity, can be presented to any relying party that participates in the associated identity federation, then theft of such a token can lead to impersonation of the user. On the other hand, small islands of trust present the opportunity for white and black listing by the identity providers, which can be used to help protect users from illegitimate sites. Rapid Prototyping of Web Authentication Various extensions to the JavaScript host environment on browsers could greatly facilitate the development and deployment of application-layer authentication for web applications. For example: - JavaScript bindings for existing authentication frameworks, such as SASL and the GSS-API (see UI note below) - JavaScript bindings for PKCS#11 and CMS/XMLdsig/XMLenc (see UI note below) - SAML APIs and JavaScript bindings for them (see UI note below) - extensions to the XmlHttpRequest object to allow applications to obtain the channel binding data for the request's TLS session Consider, with JavaScript bindings for PKCS#11. Developers could use low-level cryptographic primitives to implement PKI and ad-hoc public key user authentication. Frameworks like SASL and the GSS-API are probably more appropriate (as the GSS-API does, or SASL soon will, support channel binding already). Of course, application access to authentication credentials through such scripting interfaces MUST be suitably limited. For example, the application MUST NOT be able to use such interfaces to generate authentication messages suitable for impersonating the user to other services. This can be done, in the case of SASL and GSS-API interfaces, by not allowing the application to control the name of the target service. Additionally, user control, over what credentials a given application can access through such interfaces, MUST be provided (for example, a one-time dialog where the user can select an identity/credential to authenticate to a service as). In the case of a PKCS#11 interface, it is important to understand that not much control can be provided over what the application encrypts or signs, but control can be provided over what keys it can access. A PKCS#11 interface would probably put too much power in the hands of the application, for the risk is probably great that keys may be made available through it which are sensitive and which the user does not understand that how to limit. However, a PKCS#11 interface would allow for rapid prototyping. Enrolment Interfaces for adding identities and raw credentials for use with JavaScript interfaces to SASL, the GSS-API and/or SAML would be very, very useful. Ideally cryptographic user authentication methods, channel binding and small trust islands (as small as one per-{user, service}) will allow us to significantly reduce the possibility of phishing attacks at all but the time when the user enrols their identity/credentials with an identity provider and/or service. We may not be able to exclude phishing attacks on enrolment, but because enrolment is a rare event the opportunities for phishing would still be greatly reduced, to the point where education may be sufficient to make phishing very rare. UIs, User Expectations and User Education Even with significant improvements in web authentication it will still be possible for phish attacks to succeed where users don't or can't know about how a web page is protected. Experience tells us, too, that users do not look at, nor know what to do with, server certificates. We need UI elements that are simple and comprehensible by most users, and which nonetheless convey critical security information. Perhaps the simplest piece of information that can be shown to the user, and which conveys the most important information, is the identity that was used to authenticate to a given service. This assertion is predicated on having channel binding and either ad-hoc per-{user, service} credentials or sufficiently small trust islands (federations), for between the name of a service and the user's identity, the user has enough information to decide whether the session is legitimate. Of course, if a user can be tricked into enrolling to a malicious site such that: a) the site's name is similar to that of legitimate sites, and b) the user's identity is similar to that which would be used at legitimate sites, then the user can fail to realize when they are being phished. In the end phishing attacks are an on-line con-game. As with con-games in the off-line world, human gullibility is the key, and no technology can completely make up for human gullibility. By deploying better web authentication we may be able to greatly reduce phishing opportunities, but most likely we cannot prevent phishing altogether. A web authentication scheme that requires phishers to attack enrolment limits the opportunity for phishing to the point where user education may have a chance. Authentication Technologies A number of authentication methods are possible that can support channel binding: - methods based on PK crypto (e.g., user certs, bare user public keys, ala SSH) - methods based on pre-shared symmetric keys - methods based on passwords (e.g., challenge/response methods like DIGEST-MD5) - methods based on trusted key distribution (e.g., Kerberos V) - combinations of the above Radia Perlman and Charlie Kaufman have written a paper on "User-centric PKI" which recommends the use of bare public keys to identify users and the corresponding private keys to authenticate them -- this is very similar to SSH publickey authentication. Using certificates (which they also recommend as a supported mechanism) allows for identity federation, effectively. Passwords, of course, are the only truly portable authentication credential, at least until smartcards and smartcard readers are ubiquitous. So protocols like SACRED are recommended as a method of accessing private keys when local tokens are not available. Privacy Protection Considerations and Channel Binding Letting identity providers (IdPs) know what service the user wants to authenticate to allows the IdPs to perform white/blacklisting, and it allows user authentication to be bound to the service name at the IdP -- a useful property, in that it indirectly ensures channel binding. However, it also allows IdPs to know what services the user is accessing (and when). User authentication methods that involve an IdP but which do not involve sharing the names of the users' peers with the IdP are clearly feasible, but it is crucial, in such cases, to get channel binding right in the application protocol (or TLS, if user authentication is being done in TLS). Recommendations for Web Authentication o Whether the future of web authentication entails application-layer user authentication, or whether user authentication actually moves into the TLS layer, the ability to detect MITM attacks is REQUIRED. For example, sending a "bearer token" which can be presented to many different relying parties is dangerous: there is no binding to a particular session, therefore theft of such a token can enable the thief to impersonate the authenticated user to other sites/ applications. All the thief needs to do is fool the user into sending it the bearer token and then the thief can impersonate the user to any site that would accept that token. o Authentication messages MUST NOT be replay-able in other sessions (see above) to other services. o Use of plain username-and-password-over-TLS is NOT RECOMMENDED; in fact, since it does not meet the above requirements, it MUST NOT be used. Use of plain username-and-password-over-TLS to obtain other forms of credentials, however, MAY be used. o If user authentication moves to the transport layer (e.g., TLS), and if its computational and/or bandwidth cost be significant, then a method SHOULD be provided for a) controlling when TLS user authentication is used, b) binding occasional user authentication to a multiplicity of TLS sessions. o Browser UIs MUST display the user's identity, used to authenticate to a given site, as prominently as the name of the site and its URL, whenever the authentication method used is: a) cryptographic (not plain username&password), b) bound to the TLS sessions that make up the application session. [This section is left unfinished due to lack of time. RFC2119-like terminology is used.]
- NW-PP18 Web Authentication, TLS and phishing Nicolas Williams