Subject: Re: [TLS] User Defined Key Pair

From: Paras Shah <[email-masked]>
Date: Tue, 25 Jun 2013 19:35:12 +0000

>If  someone pretended to be Facebook, he will receive a public key and a signed message. The attacker cannot use this information to log into Facebook, because the signed message contains the current >server's time stamp, so it's valid only for a few seconds.

That is the issue right there. If the attacker was masquerading as Facebook, he would get the user's public key, signed message, username. The attacker, can then choose a session key _of his choice_, encrypt with public key of user and send it back. Thereafter, the user is communicating with the attacker instead of the real Facebook server.

Besides, even the very 1st time, how do you know that the user is communicating with Facebook for real to get the server's current timestamp for example.

Paras Shah,
SSL Security Engineer,
Riverbed Technology.

From: [email-masked] [mailto:[email-masked]] On Behalf Of OMAR HASSAN (RIT Student)
Sent: Tuesday, June 25, 2013 12:07 PM
Cc: [email-masked]
Subject: Re: [TLS] User Defined Key Pair

Hi Uri,

May be I am still not able to clear my point regarding the man in the middle attack.

When the user provides the credential information, he will not provide it to the Facebook log in page, instead he will go to the menu bar in his browser, and run the new plugin which has two tabs: one for log in; and the other for enrollment, and in the plugin interface the user will provide his credential information.

The key pair will be generated inside the browser's plugin, and only the signed message, and the username will go to Facebook, no passwords will leave the user's browser. When the server receive the username and the signed message, it will send the session key encrypted with the user's public key.

If  someone pretended to be Facebook, he will receive a public key and a signed message. The attacker cannot use this information to log into Facebook, because the signed message contains the current server's time stamp, so it's valid only for a few seconds.

And even if the attacker sends the signed message and the username to the server, and the server accepted them, the next step is that the server will respond with the session key encrypted with the user's public key. How the attacker will read the public key if he doesn't have the private key, the private key that didn't leave the user's browser.

On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student) <[email-masked]<mailto:[email-masked]>> wrote:
Hi All

>Stephan:

>How you made sure that the user (client) is connected with the intended server?
>Paras Shah:

>That is exactly the question I had. How is Server Authentication done with this approach?
>Rich:

>I don't see anything in your system that prevents this, either.  It seems that replacing your system with self-signed client >certificates would be equivalent.
>Robert:
>As the proposal has no server authentication, it is surely broken in that respect i.e. the client could be lured to any bogus >website masquerading as a legitimate one. How would the client know?

I would explain How is Server Authentication done with a practical example. Let's name facebook as our website that we need to protect using that new protocol.

When I go to facebook, I would receive a browser message telling me: "Please use the UDKP protected access (Tools->UDKP Protected Access)!"
the user will go to the plugin interface, and provide the username, password, password confirmation, the plugin will create a file with random data stream in the user's usb, and then the user will click on the register button.

At that point the plugin will create the key pair based on the random file, username, and password. The public key will go to the server with the username and a signed message, and the user will be redirected to the facebook registration page to complete his registration.

Now the user profile is created on facebook and associated with the user public key.

When the user tries to sign in later into facebook, and if he was deceived to sign in into a fake website, the user will go to the browser plugin interface, and provide the username, password, and select the file from his usb. At that point the user will be expecting to see his facebook timeline if he is really signing into the real facebook. Note that the user didn't provide the credential information to the website but to the browser plugin (Tools->UDKP Protected Access).

In our case, the fake website will only receive the username, the public key, and the token (ServerHello.random ) signed with user private key, If the attacker delivered this message to the facebook server, the server will try to read and validate the token using the user public key. If it succeeds, it will respond with the session key premaster encrypted by the user public key. Because the user private key did not leave the browser, the attacker will not be able to read the session key and hence will not be able to monitor the traffic.
So if the user was successfully able to see his timeline, he would be sure that he is communicating with the real facebook.

>Robert:
>Token = enc(ServerHello.random, PrivKey) : The concept of encrypting using a private key seems pointless. Don't you mean >signing?

Yes Robert, I mean signing not encrypting. Actually someone told me before about that mistake in the previous version, but unfortunately I forgot to correct it in the new version. Hopefully in the next version it will be corrected. Thank You.

>Juho Vähä-Herttua:

>The whole security of the system seems to be dependant on the security of the "browser plugin" and its key generation and encryption algorithms
I preferred to make the generation of the key pair as a black box, so we can focus our discussion on the idea itself, so the question is if we have a key generation function that can generate key pair securely based on the username, password, and the file selected, would the idea be a good one.

>What if someone detects this enrollment and sends a new public key for the user before the user has time to fill all the fields? Sounds like a race condition to me.
The key pair generation is done inside the browser plugin interface, not in the website page, so there is no race condition, the communication with the website will start after the creation of the key pair.

>I don't see how this is different from generating a self signed client cert and verifying it with for example HMAC with username+password+question derived secret. If you already need a custom >browser
>plugin to handle the login, you can put all your custom logic there and use standard TLS for the rest.
You can look at the generated key pair as a client certificate, but I preferred to make it as a key pair, so this key pair could be generated based on different approaches: security question, file, smart card, hardware token.
Additionally it's not only about custom sign in, it's also about eliminating the dependence on the CA, so the session key must be encrypted with the user public key not encrypted with a key that claims to be the server public key.

>Rich:

>It's great that you are trying to improve things; don't get discouraged, but this ain't there yet.  And as a first step to replacing all of SSL/TLS?  Nope.
I am not discouraged at all, but I am still insisting that the security of my traffic to facebook must be the responsibility of me and facebook only, and not anyone else. And I am doing my best to achieve that. The discussion is very useful to me, may be after this discussion we can come out with a new final solution to this issue.

On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

>  Self signed certificate is very dangerous because the user will not have a way to verify the identity of the certificate owner and he could be a victim to a man in the middle attack.

I don't see anything in your system that prevents this, either.  It seems that replacing your system with self-signed client certificates would be equivalent.

It's great that you are trying to improve things; don't get discouraged, but this ain't there yet.  And as a first step to replacing all of SSL/TLS?  Nope.

                /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 10 Jul 2013 10:49:41 -0700 (PDT)

On Mon, June 24, 2013 11:34 am, Salz, Rich wrote:
[snip]
> If you are trying to avoid CA's, then why not just use self-signed
> certificates or similar like PGP?

  Or why not use a protocol that is already a work item of the
TLS working group:

     http://tools.ietf.org/html/draft-ietf-tls-pwd-00

  Dan.

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Thu, 11 Jul 2013 12:42:25 +0300

Hi Dan,

I had a quick look at your work item, and I have some questions:

What will be the consequences if the server data has be stolen? will the
attacker be able to impersonate as the user?

How will the password be stored in the server initially?

How will you handle TLS termination that is used many websites to
centralize the related measurements and protection against the common SSL
attacks in one place, and to allow the application firewalls to validate
and check the incoming requests for application-level attacks such as SQL
injection and cross-site scripting?

Thanks

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 11 Jul 2013 08:22:15 -0700 (PDT)

Hi Omar,

> attacker be able to impersonate as the user?

  Successfully stealing records from the server's password file will
enable the thief to impersonate the client (back to the hacked server)
for all stolen records.

> How will the password be stored in the server initially?

  That is completely up to the server.

> injection and cross-site scripting?

  This is really an operational question. At the risk of sounding flippant
I guess I'd just say it will be handled in the best way possible.

  You claim in your draft that "UDKP aims to completely replace the TLS
protocol." That is a much more ambitious goal and you will need to handle
these sorts of issues. The tls-pwd draft just defines certificate-less
ciphersuites that are resistant to dictionary attack (and are better than
the various PSK ciphersuites) for use with the existing TLS protocol.

  regards,

  Dan.

---

From: Alex Elsayed <[email-masked]>
Date: Thu, 11 Jul 2013 13:53:24 -0700

> the various PSK ciphersuites) for use with the existing TLS protocol.

<snip>

I'd like to also point out:

TLS-SRP: https://tools.ietf.org/html/rfc5054
TLS-AugPAKE: https://tools.ietf.org/html/draft-shin-tls-augpake-00

Both are:

* Password-authenticated
* Do not involve CAs at all
* Do not allow a compromised server to impersonate the user
    - Zero-knowledge password proofs are rather useful
* Are designed to work with TLS, rather than replace it wholesale

While RFC 5054 is Informational rather than Standards track, it is supported 
by OpenSSL since 1.0.0h and 1.0.1 (https://www.openssl.org/news/news.html) 
and GnuTLS since at least 2007.

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Fri, 12 Jul 2013 14:37:25 +0300

Hi Dan,

I believe that your protocol will better suit for customized applications,
but when it comes to websites you will definitely face those issues that I
took about.

It's very common that a SQL injection attack against the website would give
the attacker the opportunity to steal database records, which will allow
the attacker to impersonate the client (I think TLS-SRP adds a little
complexity to protect against that scenario, I am sure you can improve this
part in your protocol)

Also TLS termination is very important, and must be supported by the
protocol, and the first challenge in that regard is that the load balancer
where the TLS connection should be terminated will not have access to the
server database, and I think without access to the server database you will
not be able to terminate the encrypted connection.

Regarding UDKP, I believe that the only valid attack against it is during
the registration. In that case using an initial TLS authenticated
connection will solve this issue, and for all later usages there is no need
to be dependent on certificate authorities.

In UDKP, if the server data has been stolen, the attacker will get only the
public key, and he will not be able to impersonate the client as he will
need the private key. And regarding TLS termination, the load balancer
could use the user public key to terminate the encrypted connection, and
the let the server authenticate the user. You can refer to section 5.2 in
the draft:

http://tools.ietf.org/html/draft-omar-tls-udkp-01#section-5.2

In the coming version of the draft I will put a detailed analysis for the
attack scenarios.

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Fri, 12 Jul 2013 15:40:41 +0300

Hi Alex,

* Password-authenticated

UDKP is key-authenticated, it's based on signing a message by the user's
private key, and getting it validated by the user's public key, which is
stored on the server.
That will make it easy for supporting TLS termination as mentioned in the
section 5.2 of the draft, which is not easy to be supported by the TLS-SRP,
and that's one of the reasons it's not yet implemented in browsers.

If it's to be used in the browsers for websites, it will have to depend on
CA to secure the registration of the user credential on the server, and
that is also the case with UDKP.

If the server is compromised, offline and dictionary attack will be
possible against the verifier, the attack will be in the password entropy.
In UDKP the authentication is done using public/private key, the server
will only contains the public key which will not be useful to impersonate
the user. The key generation should be based on at least the password, and
the security question/answer pair, for applications that require more
security the key generation will be based on a file that the user will
select, or the key generation will be based on a smart card or a hardware
token (more details on that will be in the coming version of the draft).

* Are designed to work with TLS, rather than replace it wholesale
Actually I have been advised to make it compatible with TLS, and I am
thinking of that seriously.

Thank You
Best Regards

On Fri, Jul 12, 2013 at 2:37 PM, OMAR HASSAN (RIT Student)
<[email-masked]>wrote:

> It's very common that a SQL injection attack against the website would
> give the attacker the opportunity to steal database records, which will
> allow the attacker to impersonate the client (I think TLS-SRP adds a little
> In UDKP, if the server data has been stolen, the attacker will get only
> the public key, and he will not be able to impersonate the client as he
> will need the private key. And regarding TLS termination, the load
> balancer could use the user public key to terminate the encrypted
> connection, and the let the server authenticate the user. You can refer to
> section 5.2 in the draft:
>