Subject: [TLS] User Defined Key Pair

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Fri, 21 Jun 2013 21:35:29 +0300

Hello All,

I have uploaded a new version of the User Defined Key pair protocol that is
cleaner and briefer, I will appreciate any comments or suggestions.

Just to remind you:

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

The new protocol is a new way of securing the traffic to websites without
being depending on any third party to secure the traffic between the user
and the website, so it will be possible for the user to secure his browsing
using his credential information, smart card, or a random file on usb. That
will make the use of two factor for authentication and traffic security is
separated from the application code, the website admin only needs to
configure how the users are going to access the website. Additionally there
are no passwords required to be transferred any more on the network, which
will render the Phishing attack useless.

The motivation behind the new protocol is to make the security the
responsibility of the two involved parties, because as you know, the
security and confidentiality of user browsing in TLS depend upon the number
of Certificate Authorities (CAs), major web browsers trust hundreds of
different firms to issue certificates. Each of these firms can be compelled
by their national government, or being compromised to issue a certificate
for any particular website that all web browsers will trust without
warning.Thus, users around the world are put in a position where their
browser entrusts their private data, indirectly, to a large number of
governments, and entities. (http://cryptome.org/ssl-mitm.pdf)

Thank You
Best Regards

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jun 2013 11:29:59 -0400

I didn't see any description of your genKeyPair function; is it described anywhere?  In particular, it seems to me that it's stateless - that is, it generates the keypair whenever needed, based only on the username, password, and a security question&answer.  Is that true?
                /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Mon, 24 Jun 2013 19:25:56 +0300

Hi Rich,

The idea is to separate the generation of the key pair of the server, so
the server will be expecting your public key during the enrollment, and a
message singed by your private key during the sign in.

On the browser level there should be a plugin that has a function to
generate the key pair, that function must generate the same key pair for
the same input parameters.

I didn't include any mathematics details for that function as I was
interesting in abstracting the idea, and for the real implementation there
must be unified implementation across all browsers to generate the same key
pair for the same input parameters in all browsers.

There should be three version of the generate key function as the following:

1) genKeyPair (username, password, security question&answer);
So whenever you provide the same username, password, and the security
question&answer, the same key pair will be generated for you.

2) genKeyPair (username, password, file);
So whenever you provide the same username, password, and the same file from
a usb or hard drive, the same key pair will be generated for you.

3) genKeyPair (username, password, smart card or hardware token);
So whenever you plugin the hardware token or put your smart card, and
provide the same username and password, the same key pair will be generated
for you.

In my prof of concept implementation, I used a standard java method that
will generate the same key pair for the same input string, and I provided a
concatenation of the username, password, and security question&answer.

On Mon, Jun 24, 2013 at 6:29 PM, Salz, Rich <[email-masked]> wrote:

> I didn’t see any description of your genKeyPair function; is it described
> anywhere?  In particular, it seems to me that it’s stateless – that is, it
> generates the keypair whenever needed, based only on the username,
> password, and a security question&answer.  Is that true?****
>
>                 /r$****
>
> ** **
>
> --  ****
>
> Principal Security Engineer****
>
> Akamai Technology****
>
> Cambridge, MA****
>
> ** **
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jun 2013 12:33:09 -0400

Ø  On the browser level there should be a plugin that has a function to generate the key pair, that function must generate the same key pair for the same input parameters.

That's interesting.  This is the first system I've heard of that predictably generating a keypair is not only a feature, but a requirement.

I'm sure that I am not the only person who is bothered by the security implications of this.

                /r$

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Mon, 24 Jun 2013 21:27:13 +0300

Hi Rich,

The security implications is not in the predictably generation of the key
pair, but in the seed length that you will be used to generate the key
pair, in other words it's a matter of it's sustainability against the brute
force attack.

That's why I mentioned three versions of the generate key function,
starting from generating the key pair based on the username, password, and
security question answer pair, and up to having a smart card, or hardware
token that has large enough random seed that will work with the username
and the password as a second factor authentication.

Even in the first case the password must be complex enough, and the each
security question must be follow the best practice of having thousands of
answer for each question, and remember that the question is not leaving the
browser, so the man in the middle attacker will have to try all questions
with all answers.

On Mon, Jun 24, 2013 at 7:33 PM, Salz, Rich <[email-masked]> wrote:

> **Ø  **On the browser level there should be a plugin that has a function
> to generate the key pair, that function must generate the same key pair for
> the same input parameters.****
>
> ** **
>
> That’s interesting.  This is the first system I’ve heard of that
> predictably generating a keypair is not only a feature, but a requirement.
> ****
>
> ** **
>
> I’m sure that I am not the only person who is bothered by the security
> implications of this.****
>
> ** **
>
>                 /r$****
>
> --  ****
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jun 2013 14:34:32 -0400

Ø  and up to having a smart card, or hardware token that has large enough random seed that will work with the username and the password as a second factor authentication.

That doesn't seem to make sense - if you're generating the keypair, predictably, from the inputs, how does a random seed enter into it?  And what is the second factor authentication in this situation?

I'm starting to think you're swimming out a little further into the deep end then you should.

If you are trying to avoid CA's, then why not just use self-signed certificates or similar like PGP?

                /r$

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Tue, 25 Jun 2013 00:29:30 +0300

Hello Rich

When the user enrolls into one of those websites, and let's say he will go
with the second option of using a usb as a second factor authentication,
where the password is something he knows, and the usb is something he has.

when he plug the usb into the computer, the browser plugin will create a
random data stream and save it into a file in the usb, this file will be
passed to the genKeyPair function with the username and the password to
generate the key pair.

when the user tries to log in later into the website, he will plug the usb
into the computer and select that previously created file that will be
passed to the genKeyPair function with the username and the password to
generate the same key pair.

On the server the user public key will be used to encrypt the session key
pre-master that will be used by the browser and the server to generate the
session keys.

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.

On Mon, Jun 24, 2013 at 9:34 PM, Salz, Rich <[email-masked]> wrote:

> **Ø  **and up to having a smart card, or hardware token that has large
> enough random seed that will work with the username and the password as
> a second factor authentication.****
>
> ** **
>
> That doesn’t seem to make sense – if you’re generating the keypair,
> predictably, from the inputs, how does a random seed enter into it?  And
> what is the second factor authentication in this situation?****
>
> ** **
>
> I’m starting to think you’re swimming out a little further into the deep
> end then you should.****
>
> ** **
>
> If you are trying to avoid CA’s, then why not just use self-signed
> certificates or similar like PGP?****
>
> ** **
>
>                 /r$****
>
> ** **
>
> --  ****
>

---

From: "Stephan T." <[email-masked]>
Date: Tue, 25 Jun 2013 07:24:18 +0200

Hi,

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

-Stephan

Am 21.06.2013 um 20:35 schrieb OMAR HASSAN (RIT Student) <[email-masked]>:

> Hello All,
> 
> I have uploaded a new version of the User Defined Key pair protocol that is cleaner and briefer, I will appreciate any comments or suggestions. 
> 
> Just to remind you:
> 
> The new protocol is a new way of securing the traffic to websites without being depending on any third party to secure the traffic between the user and the website, so it will be possible for the user to secure his browsing using his credential information, smart card, or a random file on usb. That will make the use of two factor for authentication and traffic security is separated from the application code, the website admin only needs to configure how the users are going to access the website. Additionally there are no passwords required to be transferred any more on the network, which will render the Phishing attack useless.
> 
> The motivation behind the new protocol is to make the security the responsibility of the two involved parties, because as you know, the security and confidentiality of user browsing in TLS depend upon the number of Certificate Authorities (CAs), major web browsers trust hundreds of different firms to issue certificates. Each of these firms can be compelled by their national government, or being compromised to issue a certificate for any particular website that all web browsers will trust without warning.Thus, users around the world are put in a position where their browser entrusts their private data, indirectly, to a large number of governments, and entities. (http://cryptome.org/ssl-mitm.pdf)
> 
> Thank You
> Best Regards
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 25 Jun 2013 10:56:50 +0300

This discussion forced me to take a look at the draft. The whole security of the system seems to be dependant on the security of the "browser plugin" and its key generation and encryption algorithms, which are not defined in the draft. I don't see how this could possibly be an interoperable standard as it is.

On 25.6.2013, at 0.29, "OMAR HASSAN (RIT Student)" <[email-masked]> wrote:

> When the user enrolls into one of those websites, and let's say he will go with the second option of using a usb as a second factor authentication, where the password is something he knows, and the usb is something he has.

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.

> 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.

But at least the keys are generated using a truly random seed, instead of part of the seed being predictable (username, password, security question) which actually sounds worse to me.

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.

Juho

---

From: Robert Cragie <[email-masked]>
Date: Tue, 25 Jun 2013 09:25:32 +0100

+1. It would seem more appropriate to use a self-signed client 
certificate (which can be generated in a similar way from username and 
password etc.) in conjunction with a CA-signed server certificate for 
mutual authentication.

Some other points:

  * 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?
  * Token = enc(ServerHello.random, PrivKey) : The concept of encrypting
    using a private key seems pointless. Don't you mean signing?

Robert

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Jun 2013 07:29:09 -0400

Ø  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$

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Tue, 25 Jun 2013 19:55:49 +0300

Hi All

>Stephan:
>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]> 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$****
>
> ** **
>
> --  ****
>

---

From: Paras Shah <[email-masked]>
Date: Tue, 25 Jun 2013 05:25:44 +0000

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephan T.
Sent: Monday, June 24, 2013 10:24 PM
To: OMAR HASSAN (RIT Student); [email-masked]
Subject: Re: [TLS] User Defined Key Pair

Hi,

-Stephan

Am 21.06.2013 um 20:35 schrieb OMAR HASSAN (RIT Student) <[email-masked]<mailto:[email-masked]>>:

Hello All,

Just to remind you:

The motivation behind the new protocol is to make the security the responsibility of the two involved parties, because as you know, the security and confidentiality of user browsing in TLS depend upon the number of Certificate Authorities (CAs), major web browsers trust hundreds of different
firms to issue certificates. Each of these
firms can be compelled by their national government, or being compromised to issue a certificate for any particular website that all web browsers will trust without warning.Thus, users around the world are put in a position where their browser entrusts their private data, indirectly, to a large number of governments, and entities. (http://cryptome.org/ssl-mitm.pdf)

Thank You
Best Regards
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 25 Jun 2013 14:10:39 -0400

>From the answers provided so far, it looks like there is no server
authentication. So if you pretend to be a server, get user name and
password, then pretend to be that user to, e.g., Facebook  you should get
complete access, including the ability to generate your own key pair. :)

I'd much prefer dependence on a 3rd party  Certificate Authority, to be
precise.
--
Regards,
Uri Blumenthal

From:  Paras Shah <[email-masked]>
Date:  Tuesday, June 25, 2013 1:25
To:  "Stephan T." <[email-masked]>, "OMAR HASSAN (RIT Student)"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [TLS] User Defined Key Pair

> <http://tools.ietf.org/html/draft-omar-tls-udkp-01>
> 
>  
> being depending on any third party to secure the traffic between the user and
> the website, so it will be possible for the user to secure his browsing using
> his credential information, smart card, or a random file on usb. That will
> make the use of two factor for authentication and traffic security is
> separated from the application code, the website admin only needs to configure
> how the users are going to access the website. Additionally there are no
> passwords required to be transferred any more on the network, which will
> render the Phishing attack useless.
> 
>  
> 
> responsibility of the two involved parties, because as you know, the security
> and confidentiality of user browsing in TLS depend upon the number of
> Certificate Authorities (CAs), major web browsers trust hundreds of different
> firms can be compelled by their national government, or being compromised to
> issue a certificate for any particular website that all web browsers will
> trust without warning.Thus, users around the world are put in a position where
> their browser entrusts their private data, indirectly, to a large number of
> governments, and entities. (http://cryptome.org/ssl-mitm.pdf
> <http://cryptome.org/ssl-mitm.pdf> )
> 
>  
> 
> Thank You
> 
> Best Regards

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Tue, 25 Jun 2013 22:07:09 +0300

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]>wrote:

> 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.
>
> 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
> >Token = enc(ServerHello.random, PrivKey) : The concept of encrypting
> using a private key seems pointless. Don't you mean >signing?
>
> >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.
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Jun 2013 23:02:01 +0300

Hi Omar, 

if you think your proposal is a good idea then I would encourage you to produce a draft. A draft, as a more complete writeup, often helps to communicate ideas more easily. It also helps to illustrate the bigger picture.

Ciao
Hannes

PS: A minor remark - Facebook (as used in your example) uses IETF technology developed in a different working group. Their use case, as you can imagine, is a bit more complex than a browser talking to a server. 

On Jun 25, 2013, at 10:07 PM, OMAR HASSAN (RIT Student) wrote:

> 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]> wrote:
> Hi All
> 
> >Stephan:
> 
> >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.
> 
> 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.
> 
> 
> 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$
> 
>  
> 
> -- 
>

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Wed, 26 Jun 2013 00:12:58 +0300

Hi Paras

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.

That's one of the main differences between udkp protocol and TLS, the
session key is generated by the server not the by the user, so the attacker
cannot chose a session key of his choice and encrypt it with the user's
public key. You refer to figure 1, 2 of the draft for the flow of messages
between the user and the 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.****
All values that the client received from the server will be hashed at the
client, and sent back to the server encrypted with the session key, so the
server can validate the hash to make sure that no one manipulate the
values. This is done in the "finish" message.

On Tue, Jun 25, 2013 at 10:35 PM, Paras Shah <[email-masked]>wrote:

>  >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,****
>
> ** **
>
> middle attack. ****
> credential information.****
>
> ** **
>
> public key.****
> stamp, so it's valid only for a few seconds.****
>
> ** **
>
> 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]> 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:****
>
>
> button.****
> facebook registration page to complete his registration.****
>
>
> public key.****
> (Tools->UDKP Protected Access).****
>
>
> able to monitor the traffic.****
>
> >Juho Vähä-Herttua:****
> the "browser plugin" and its key generation and encryption algorithms****
>
> username, password, and the file selected, would the idea be a good one.**
> **
>
>
> race condition to me.****
>
> the website will start after the creation of the key pair.****
>
>
>
> derived secret. If you already need a custom >browser ****
>
> use standard TLS for the rest.****
>
> hardware token.****
> >Rich:****
> new final solution to this issue.****
>
> ** **
>
> On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich <[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.****
>
>  ****
>

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Wed, 26 Jun 2013 00:22:36 +0300

Hi Hannes

I think you are right the biggest issue that I am facing is the
communication of the idea. Currently I am taking notes from this discussion
to make use of them in new version of the draft, but I am really interested
in the initial thoughts about the idea, and I am doing my best to clarify
whatever mysterious.

But this version of the draft is very clear compared to the first version,
even me when I tried to reread the first version of the draft I couldn't
understand it :)

Thank You for your advice.

On Tue, Jun 25, 2013 at 11:02 PM, Hannes Tschofenig <
[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi Omar,
>
> if you think your proposal is a good idea then I would encourage you to
> produce a draft. A draft, as a more complete writeup, often helps to
> communicate ideas more easily. It also helps to illustrate the bigger
> picture.
>
> Ciao
> Hannes
>
> PS: A minor remark - Facebook (as used in your example) uses IETF
> technology developed in a different working group. Their use case, as you
> can imagine, is a bit more complex than a browser talking to a server.
>
> > 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
> > 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.
> >
> >
> [email-masked]> wrote:
> server?
> with this approach?
> > >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
> > 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).
> >
> > So if the user was successfully able to see his timeline, he would be
> sure that he is communicating with the real facebook.
> >
> > >Robert:
> > 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
> >
> > >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.
> >
> >
> 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.
> >
> >
> >
> but this ain’t there yet.  And as a first step to replacing all of SSL/TLS?
>  Nope.
> >
> >
> >
> >                 /r$
> >
> >
> >
> > --
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBCgAGBQJRyfc6AAoJEGhJURNOOiAt14IH+wX1gBztEr2vC7PkwKEmcU6Z
> tbLHVm5dUT1HR2uieVHEbjDviY8K/aM46C4Esxkh/6HyYe1RIJyrhHcqP0xv8ZjA
> zMlD4G6m4OVB+d5Wgvoj8FwHM9cs/WuNqWvf342LjB9EiHKyLGKKu6HVPYhrkzUr
> wHpj04n62lxyzQyPJA3nZ7hS/z/IW5zYB7ud+jIe2SpQWyGgPl+MlyxpihwQjCs3
> FVjTVPlc4E88DfgIf5rDbbwf8JqM8r0wVNcHn1PQnOeh2k+GHkuHuflhmQisGetz
> 5x/NyhT8XIHGvf8CJ23PYjgkkYcLRHn5I/OElLCSNK54Widkn5y5GAR2kqZiL4g=
> =TTA8
> -----END PGP SIGNATURE-----
>

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 26 Jun 2013 00:37:38 +0300

> 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 p…

Personally, I would like to find out if it's possible to do securely (key generation function) before judging if it's a good idea or not. I'm defaulting to not a good idea.

> 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…

Ok. In that case I don't quite understand why the public key is not sent together with the registration, but beforehand in TLS handshake. It sounds like a much better idea to simply send public key instead of the password.

Also, why don't you simply save the encrypted private key to the USB stick? Why is saving random bytes and generating the private key from those more secure?

> 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 cl…

It doesn't matter if the premaster secret is encrypted with a client key or a server key, what matters is that it is encrypted with a key that is authenticated one way or another. This doesn't seem to be the case.

The fact is that in your system, I could do a MITM in the registration phase and get you to register my public key with your information, and you wouldn't even notice before you access it from somewhere where I cannot MITM. At that point you would have probably already confirmed your email address etc. and effectively given me tools to impersonate as you.

Juho

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 26 Jun 2013 00:53:45 +0300

On 26.6.2013, at 0.12, "OMAR HASSAN (RIT Student)" <[email-masked]> wrote:
> 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.
> 
> All values that the client received from the server will be hashed at the client, and sent back to the server encrypted with the session key, so the server can validate the hash to make sure that no one manipulate the values. This is done in the "finish" message.

I'm not sure you understand how the man-in-the-middle works here. You as a client send a ClientHello to the server, I as an attacker receive it and open a new TCP connection to the server and forward your ClientHello there. Then I get the server random nonce in ServerHello and forward it to you.

When you send your public key, I will replace it with my own public key instead. When the server sends the premaster key I will decrypt it with my private key and encrypt it (or some other premaster secret) again with yours. I will modify all Finished messages accordingly so that everyone keeps happy.

End result is that your "secure" session is actually with me, but all your data is coming from facebook and going to facebook. You would never know the difference. If you would open a "normal" TLS connection, trust the CA and send your public key there, this problem wouldn't exist. And Facebook still wouldn't know your private key.

I don't think this is just a problem with you not communicating your solution to others well enough, you also need to listen. We all want to get rid of CAs, and if it would be as easy as you propose, it most likely would've been done already.

Juho

---

From: "OMAR HASSAN (RIT Student)" <[email-masked]>
Date: Wed, 26 Jun 2013 01:49:56 +0300

Hi

Yes, man in the middle attack could only happened in the first time
registration, and in that case the attack will be detected once I accessed
the website from a clean network. I think the only solution in this case
will be to open initial TLS connection during the registration or
credential change. Once the user's public key is sent to the server, and
became associated with the user's profile, TLS connection will not be
required anymore.

On Wed, Jun 26, 2013 at 12:53 AM, Juho Vähä-Herttua <[email-masked]> wrote:

> I'm not sure you understand how the man-in-the-middle works here. You as a
> client send a ClientHello to the server, I as an attacker receive it and
> open a new TCP connection to the server and forward your ClientHello there.
> Then I get the server random nonce in ServerHello and forward it to you.
>
> When you send your public key, I will replace it with my own public key
> instead. When the server sends the premaster key I will decrypt it with my
> private key and encrypt it (or some other premaster secret) again with
> yours. I will modify all Finished messages accordingly so that everyone
> keeps happy.
>
> End result is that your "secure" session is actually with me, but all your
> data is coming from facebook and going to facebook. You would never know
> the difference. If you would open a "normal" TLS connection, trust the CA
> and send your public key there, this problem wouldn't exist. And Facebook
> still wouldn't know your private key.
>
> I don't think this is just a problem with you not communicating your
> solution to others well enough, you also need to listen. We all want to get
> rid of CAs, and if it would be as easy as you propose, it most likely
> would've been done already.
>
>
> Juho
>
>
>