I've put together a summary of the discussion in this thread so far: The ability to prove your identity to a remote system in order to gain access to remote resources is an important ability to have. The main method deployed for current Internet systems is the use of a password, a word or phrase known only to the user. Passwords present a large number of attack vectors due to the fact that the same password, the secret, is transmitted every time the user wants to prove their identity, and that secret can be used by anyone that holds it. Using a keylogger, sniffing the wire or an offline brute-force attack or a rainbow table lookup with hashes from a stolen database are all methods through which a password could be acquired.
Databases containing user data are often leaked by crackers [1] and are readily available to criminals and we have also seen that the NSA have the co-operation of ISPs when it comes to broad capturing of data [2] on the wire which would contain passwords. Once a password has been accquired, there is a good chance that the user will have reused the same password for multiple remote systems (61% in 2012 [3]). In 2012, 21% of consumers had an online account compromised and yet 89% of consumers felt secure with their password management and use habits [3]. Clearly, something is wrong. Phillip Hallam-Baker suggested that the problem is that moving to strong authentication techniques is an "all or nothing" proposition requiring both the site and the user to adopt before the scheme is useful [4]. He mentions that the double ended adoption requirement invariably leads to deployment deadlock in his experience. For web systems, he suggests a cloud-synchronised password manager be standardised that would also allow the browser to notify the remote site that it can perform an authentication exchange to create a seamless single-sign-on user experience. Bjoern Hoehrmann followed up with complaints regarding HTTP Authentication about how browsers do not offer a method of "logging out" nor do they show when a user is logged in. In his opinion, the use of web forms and cookies for managing authentication is wrong and HTTP Authentication and browser UIs should be improved [5]. Robin Wilton raises the point that many passwords are used by "password proxies" instead of directly by the user [6]. Tim Bray brought attention to the Fido Alliance [7]: > The FIDO (Fast IDentity Online) Alliance was formed in July 2012 to address > the lack of interoperability among strong authentication devices as well as > the problems users face with creating and remembering multiple usernames and > passwords. The Alliance plans to change the nature of authentication by > developing specifications that define an open, scalable, interoperable set of > mechanisms that supplant reliance on passwords to securely authenticate users > of online services. [8] Watson Ladd mentions that client certificates are already supported and widely deployed and the big problem is with the UI and UX of applications [9]. The DoD use them for "just about everything" [10]. Iain Learmonth mentions that the scheme Phillip Hallam-Baker suggested is already implemented by LastPass [11] although not as a defined standard. He suggests moving forward with the idea of TLS client authentication as it can provide a seamless UX. These client keys could be synchronised somehow through the cloud, or used with smartcards or dongles, depending on the user's needs. Robin Wilton found the TLS client authentication idea "rational and interesting" and requested more detail [13]. Iain replied [14] that for the cloud synchronisation the client key pairs would be encrypted and stored in the cloud, decrypted with a symmetric key derived from a password allowing synchronisation of the key chain across devices securely. The master key would never be passed, encrypted or in plaintext, across the wire. RFC2246 [12] contains the details for TLS client authentication. Ben Laurie points out Nigori [15][16] which is a Google protocol for storing secrets in the cloud. Iain points out that Nigori only currently supports the storage of RSA keys and so this would need to be extended to store X.509 keys and certificated [17], but is otherwise suited to this task. He then has some thoughts: * How does the service provider get the public certificate? * Should certificates be reused across sites? * Does a certificate represent an account or an identity? * Should both use cases be considered? * How do we handle multiple accounts on the same site? Robin points out that reuse would introduce privacy concerns and so recommends one certificate per service [18]. Iain then raises a concern about a privacy issue with TLS itself, regarding whether all keys would be tried for each service until one works and whether or not this would leak any identifying data that could be used for cross-site tracking [19]. Ted Lemon suggests that as part of the TLS handshake, a site ID would be provided to select a key and then one master key would exist per site with client keys on devices signed by this master key. These keys would be managed by a key server. Iain thought this idea sounded good but asked for futher clarification about how the key server would work. Ted replied stating the key server would have a collection of public/private key pairs. When you establish an account at a new site, your browser contacts the server and asks it to generate a new master key pair for the site. The browser generates a per-site key pair and sends the public half to the server; the server hands back a cert signing that key with the new per-site master key it generated. Your other devices are notified asynchronously of the new relationship, and generate their own keys, which are signed with the same per-site master key. No secret key ever crosses the network. Phillip Hallam-Baker mentions that this is essentially the CardSpace model [20] but taking roaming into account. His view is that you should use one public keypair per device or if the authentication keys are going to be per site then you should use a strong (non user chosen) symmetric key and a proof of possession scheme. There is really no value to a public key scheme for authentication if there are only two parties to the conversation and no need for non repudiation. This is only possible if TLS supports the use of symmetric schemes for client authentication. Paul Ferguson raised concerns [21] about having the authentication management built into the browser as browsers tend to have vulnerabilities that can leak data and would prefer to use a standalone solution. The threading went a bit funny, but I tried to get everything and in the right order. Iain. [1]: https://pwnedlist.com/stats/account-imports-area-chart-per-month [2]: https://www.eff.org/files/filenode/att/presskit/ATT_onepager.pdf [3]: http://www.csid.com/wp-content/uploads/2012/09/CS_PasswordSurvey_FullReport_FINAL.pdf [4]: http://www.ietf.org/mail-archive/web/perpass/current/msg00954.html [5]: http://www.ietf.org/mail-archive/web/perpass/current/msg00964.html [6]: http://www.ietf.org/mail-archive/web/perpass/current/msg00966.html [7]: http://www.ietf.org/mail-archive/web/perpass/current/msg00959.html [8]: http://www.fidoalliance.org/ [9]: http://www.ietf.org/mail-archive/web/perpass/current/msg00956.html [10]: http://www.cac.mil/ [11]: http://www.lastpass.com/ [12]: http://www.ietf.org/rfc/rfc2246.txt [13]: http://www.ietf.org/mail-archive/web/perpass/current/msg00961.html [14]: http://www.ietf.org/mail-archive/web/perpass/current/msg00980.html [15]: http://www.ietf.org/mail-archive/web/perpass/current/msg00981.html [16]: http://www.links.org/files/nigori/nigori-protocol-01.html [17]: http://www.ietf.org/mail-archive/web/perpass/current/msg00985.html [18]: http://www.ietf.org/mail-archive/web/perpass/current/msg00991.html [19]: http://www.ietf.org/mail-archive/web/perpass/current/msg00992.html [20]: http://en.wikipedia.org/wiki/Windows_CardSpace [21]: http://www.ietf.org/mail-archive/web/perpass/current/msg01033.html -- Iain R. Learmonth MBCS Electronics Research Group School of Engineering University of Aberdeen Kings College Aberdeen AB24 3UE Tel: +44 1224 27 2799 The University of Aberdeen is a charity registered in Scotland No.SCO13683 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
