Subject: Re: [perpass] Stopping password sniffing

From: "Joe St Sauver" <[email-masked]>
Date: Fri, 15 Nov 2013 09:08:31 -0800 (PST)

Hi,

Stephane commented in response to my assertion:

#> -- unless we get broad adoption of federated authentication, we'll
#>    always have *too many* usernames and passwords
#
#This problem has been solved a long time ago, by password
#managers. Every Web browser have a pretty good one these days [...]

I must confess that the password managers in some browsers may not
meet my security expectations for secure password storage, although
arguably we're making progress:

"Google may lock down access to Chrome's stored passwords to bolster
security," 
http://www.theverge.com/2013/11/4/5064592/google-may-lock-down-access-chrome-stored-passwords

Regards,

Joe

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 15 Nov 2013 09:27:51 -0800

> http://www.theverge.com/2013/11/4/5064592/google-may-lock-down-access-chr

Ditto -- I would more trust (and do use) a stand-alone password manager
such as Roboform, Keepass, etc.

Browsers leak. :-)

- - ferg

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Sat, 16 Nov 2013 13:30:50 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Nov 2013 08:55:17 -0500

> schemes for client authentication.

I think you've slightly misrepresented PHB's modification—what he said was that you would keep the public/private keypair per site on the key server, but the keys you use to authenticate to the site would be private keys.   This saves having to generate multiple public/private key pairs per site, and works fine as long as you have repudiation.

Two additional things that have occurred to me since we had this conversation:
- Repudiation can be done by having any device contact the key server and repudiate any key, after having gotten the repudiation message signed by the key server using the private key associated with that site; this avoids the privacy issue of revealing the key server's IP address, but requires that the site actually implement the repudiation protocol; if they don't, you're SOL.   One could also have a distributed repudiation model, but I don't think it adds anything.   And even with online repudiation, it's up to the site to check that the key hasn't been repudiated, so no matter what, you are relying on the site to do repudiation correctly.   The good news is that it's easy to test whether they are doing it, and indeed that could be written into the protocol.
- One use case for this is, e.g., if you have a financial manager who needs access to some of your accounts in order to make trades on your behalf, and you want to give them a key, but you'd like to be able to revoke the key.   No change to the proposed protocol is required—it's simply another case where this security model would win massively.

Thanks for writing up the summary.

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Sat, 16 Nov 2013 14:31:44 +0000

From: Ted Lemon <[email-masked]>

>I think you've slightly misrepresented PHB's modification—what he said was that you would keep the public/private keypair per >site on the key server, but the keys you use to authenticate to the site would be private keys.   This saves having to generate >multiple public/private key pairs per site, and works fine as long as you have repudiation.

But can this authentication be performed using TLS as it currently exists? That was my concern.

>- One use case for this is, e.g., if you have a financial manager who needs access to some of your accounts in order to make trades on your behalf, and you want to give them a key, but you'd like to…

Sounds good to me.

Iain.

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Sat, 16 Nov 2013 15:37:27 +0000

>From what I can tell from Wikipedia [1] it's not possible to authenticate using a symmetric key. When TLS was designed, they must have considered the computation expense of using PKI with public and private keypairs and decided that it was fine, so I think we can trust them.

[1]: http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake

As for revoking certificates, no extension to TLS is required as long as there's a method of notifying the server of revocations. With one keypair per service, it shouldn't be too hard to push a revocation to the service the keypair is linked to that it can add to its list.

I'd really like to avoid making changes to TLS if possible, as then this might get complicated.

We could define a scheme for HTTP only (we'd have to pay attention to section 5.1.2 of draft-ietf-httpbis-p7-auth) then we could do crazier things, but working out how to do this at the TLS layer using TLS as it exists means it's portable to things like mail clients, FTP clients and clients no one's even thought of yet.

Iain.

Tel: +44 1224 27 2799

________________________________________
From: Ted Lemon <[email-masked]>
Sent: 16 November 2013 15:21
To: Learmonth, Iain Ross
Subject: Re: [perpass] Stopping password sniffing

> But can this authentication be performed using TLS as it currently exists? That was my concern.

You're asking the wrong person—I am as innocent as I can manage as to the details of TLS.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Nov 2013 13:25:42 -0500

> As for revoking certificates, no extension to TLS is required as long as there's a method of notifying the server of revocations. With one keypair per service, it shouldn't be too hard to push a re…

TLS Certificate revocation mechanisms _won't work_ because they allow different sites to tell that a particular key belongs to the same person.

> I'd really like to avoid making changes to TLS if possible, as then this might get complicated.

What we are discussing requires substantial changes on both browsers and service provider sites.   Trying to crowbar it into the existing support for TLS will probably result in the providers not implementing certificate revocation at all.   Service providers don't currently even _allow_ client authentication using client certs anyway.   So we're talking about deploying something new; might as well do it right.

> We could define a scheme for HTTP only (we'd have to pay attention to section 5.1.2 of draft-ietf-httpbis-p7-auth) then we could do crazier things, but working out how to do this at the TLS layer u…

I understand why you want to stuff this in at the TLS layer, but realistically you have to change the IMAP, POP, FTP and other implementations to use client certs anyway, so again, why not do it right?   I don't see any point in designing something that isn't a complete solution to account for existing implementations that don't exist!   :)

---

From: [email-masked]
Date: Sat, 16 Nov 2013 18:44:09 -0800 (PST)

> I understand why you want to stuff this in at the TLS layer, but
> realistically you have to change the IMAP, POP, FTP and other implementations
> to use client certs anyway, so again, why not do it right?   I don't see any
> point in designing something that isn't a complete solution to account for
> existing implementations that don't exist!   :)

You may be underestimating the amount of support for client certificates and
AUTH EXTERNAL here, in the case of IMAP at least. I believe Dovecot, Cyrus,
Courier, and Openwave all support them. Oracle's IMAP server definitely does.

On the client side, I believe both Thunderbird and Outlook support client
certificates. The state of play in the mobile space appears to be more
problematic - Apple's client reportedly doesn't support client certificates.
Dunno about Android clients.

FWIW.

				Ned

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Nov 2013 22:20:01 -0500

> Dunno about Android clients.

Interesting.  It looks like the Mavericks client might.   However, that doesn't get us non-trackable client cert revocation.

---

From: "John Levine" <[email-masked]>
Date: 17 Nov 2013 03:59:56 -0000

>Dunno about Android clients.

I poked around on my Android Nexus 7, don't see any way to install
client certs.

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 16 Nov 2013 20:16:43 -0800

Many site seem happy to manage a password for each user. The state of the art seems to be, let the user select a password, and use an e-mail exchange to verify that the user is who they say they are. It seems that it would not be much more complicated to let the user present the signature of a public key, and use an e-mail exchange to verify that this is indeed the user's public key. Has that been tried already?

- -- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Nov 2013 23:23:15 -0500

> Many site seem happy to manage a password for each user. The state of the art seems to be, let the user select a password, and use an e-mail exchange to verify that the user is who they say they ar…

Maybe so.   This works fine, but doesn't allow for per-device repudiation.

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 16 Nov 2013 21:24:18 -0800

>> Many site seem happy to manage a password for each user. The state of the
art seems to be, let the user select a password, 
>> and use an e-mail exchange to verify that the user is who they say they
are. It seems that it would not be much more complicated
>>  to let the user present the signature of a public key, and use an e-mail
exchange to verify that this is indeed the user's public key. 
>> Has that been tried already?
>

Sure. But passwords don't support repudiation either... It seems the biggest
hurdle would be getting a JavaScript API that connects with a local store of
the PGP or GPG key. 

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Nov 2013 00:31:40 -0500

> hurdle would be getting a JavaScript API that connects with a local store of

We've dipped deeply into solutions in this discussion and I wouldn't blame the moderators for asking us to go elsewhere, but having said that, I think we are talking about two different things.   You are talking about a fairly minor enhancement that makes things a little nicer, and what some other folks have talked about is a redesign that might add a lot more value, at the cost of being less easy to adopt.

I would appreciate it if some of the security folks would point out obvious flaws in what we've been discussing—I still don't have the privacy model clear in my head, for example.   But if we are going to do something new, IMHO we should get it right, and not do a bandaid that is just a little bit better.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Nov 2013 00:49:02 -0500

> Dunno about Android clients.

Android KitKat mail is pretty broken, unfortunately, but I didn't find a setting for this, nor in some of the popular replacements.

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 16 Nov 2013 22:18:14 -0800

> We've dipped deeply into solutions in this discussion and I wouldn't blame
the moderators for asking us to 
> go elsewhere, but having said that, I think we are talking about two
different things.   You are talking about
>  a fairly minor enhancement that makes things a little nicer, and what
some other folks have talked about 
> is a redesign that might add a lot more value, at the cost of being less
easy to adopt.

You are right, this is going a bit far from defense against passive
monitoring. The tangential relation Is the protection against active
attacks. We may have reasons to believe that if we manage to "encrypt
everything," the attackers will move from passive to active, using various
MITM attacks. In that case, client authentication has value, especially if
we can somehow tie client authentication to a validation of the TLS session
key.

> I would appreciate it if some of the security folks would point out
obvious flaws in what we've been discussing
>—I still don't have the privacy model clear in my head, for example.   But
if we are going to do something new, 
> IMHO we should get it right, and not do a bandaid that is just a little
bit better.

Actually, allowing PGP-style authentication of clients could be much more
than a band aid, and would have the advantage of not involving third parties
in the relation between server and client. Intuitively, that seems easier
than requiring all clients to get a PKI style certificate.

-- Christian Huitema

_______________________________________________
perpass mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/perpass

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Nov 2013 11:04:57 +0000

Christian Huitema <[email-masked]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Many site seem happy to manage a password for each user. The state of
>the art seems to be, let the user select a password, and use an e-mail
>exchange to verify that the user is who they say they are. It seems
>that it would not be much more complicated to let the user present the
>signature of a public key, and use an e-mail exchange to verify that
>this is indeed the user's public key. Has that been tried already?

Being tried (again;-)   [1] for httpauth which is a minority sport. No good reason IMO the same pattern couldn't be followed in loads of protocols

S

[1] http://tools.ietf.org/html/draft-ietf-httpauth-hoba

>
>- -- Christian Huitema
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2.0.20 (MingW32)
>Comment: Using gpg4o v3.1.107.3564 - http://www.gpg4o.de/
>Charset: utf-8
>
>iQEcBAEBAgAGBQJSiEMqAAoJELba05IUOHVQQCQH/3vrYzHLmB6Vm+8bng70BVvj
>WIW+NWkGyFwKKODOz2vmNCsxk7Kta8gigbomT0MRZfVxQ4RTENSNnVbmssC7l0xZ
>uH/839PT67wFSIjLPi5dZ+YoztRLBb8rTCwJNNt0gGOL4Df6+y6if1ephVxGD5sj
>bsI/ZgO1t04KVdE2FfIhinsRsjLWbzyJtw2nhcG1aKetfmUbiLb6dL8VmaE6PB32
>PmNP68TaxFRC/Xrn/RL06cAbzUWd+3ZSeaVK2Q8LCb5k6vuPgqneRauKpWDP+cvw
>tRs24P/yIpIvrYyMLFyPwvUi9+sWOB/YWcRkVQgXNyHbksTv03IRAc0Yx+TxWGU=
>=yxGA
>-----END PGP SIGNATURE-----
>