Re: [TLS] User Defined Key Pair

["OMAR HASSAN (RIT Student)" <[e-mail]>]

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 <
[e-mail]> 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.
>
> 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) <
> [e-mail]> 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 <[e-mail]> 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
> >
> >
> >
> >
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
>
> -----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-----
>