INTERNET-DRAFT O. Omran Category: Experimental Independent Expires: December 18, 2013 June 19, 2013 User Defined Key Pair Abstract In this document, I provide a high-level design for a new protocol in the application layer of the TCP/IP suite that will build a secure tunnel between the user's browser and the server without the involvement of any third party. My proposed protocol is called User- Defined Key Pair (UDKP), and its objective is to build a secure tunnel between the user's browser and the server using a public/private key pair generated for the user on the fly inside the user's browser based on the user credential information. This key pair will be used by the protocol instead of the server certificate as the starting point for creating the secure tunnel. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the Omar Omran [Page 1] INTERNET DRAFT User Defined Key Pair June 2013 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 User Registration . . . . . . . . . . . . . . . . . . . . . 4 2.2 User Authentication . . . . . . . . . . . . . . . . . . . . 6 4. Technical Details . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Messages Flow . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Implementation Considerations . . . . . . . . . . . . . . . 10 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Offline Brute Force Attack . . . . . . . . . . . . . . . . 10 5.2. UDKP and SSL Termination . . . . . . . . . . . . . . . . . 11 5.3. UDKP and OpenId . . . . . . . . . . . . . . . . . . . . . . 12 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Omar Omran [Page 2] INTERNET DRAFT User Defined Key Pair June 2013 1. Introduction Although PKI has been widely deployed and is used in most secured websites, security professionals have expressed numerous concerns regarding the nature of CAs as a single point of trust. Specifically, if the CAs were compromised, severe security damages could occur and many users would be at risk. Incidents in the past have revealed multiple types of attacks upon CAs: those related to the failure of domain validation resulting in the issuance of domain certificates to individuals who are not the domain owner and those related to the malicious control of the computing resources maintained by CAs. As a result of these breaches, attackers were able to fraudulently acquire trusted certificates for different domains and services, allowing the attackers to transparently execute a man-in-the-middle (MITM) attack to view and manipulate the data being exchanged. I will provide a high-level design for a new protocol in the application layer of the TCP/IP suite that will create a secured tunnel between the user's browser and the server. My protocol targets the issue of using the CA as a single point of trust. Instead of starting the process by receiving a certificate from the server that needs to be verified by the CA, I will start the process from the user, who will send the server a message signed with his private key generated on the fly from his credential information. The signed message only needs to be verified by the server with the corresponding public key, after which the session key will be generated by the server, encrypted with the user's public key and communicated to the user. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. UDKP - is the abbreviation for "User Defined Key Pair"; the new protocol that the document is discussing. Key pair - is a public/private key pair generated for the user on the fly inside the user's browser based on the user credential information. This key pair will be used by the protocol instead of the server certificate as the starting point for creating the secure tunnel. 2. Overview The proposed protocol addresses the main TLS issue, the inclusion of Omar Omran [Page 3] INTERNET DRAFT User Defined Key Pair June 2013 a third party (CA) in the process of authenticating and securing the traffic between the user's browser and the server, by making the process the responsibility of the user and server. The consequences of using a CA as a third party responsible for securing a user's communication with the server is that the client encrypts the required security parameters using a certificate received from some entity claiming to be the server. This claim is supported by the attestation of the CA, which may lead to many types of MITM. For example, another entity may manage to obtain a claim that it is the server and send a fake certificate to the user's browser instead of the real server certificate, thus taking advantage of the fact that browsers will automatically trust any certificate signed by a trusted CA or relying on the user to simply ignore browser warnings about untrusted certificates. As a result, the user's browser will create the secured tunnel based on this fake certificate, exposing all of the traffic to the fake certificate owner. In the proposed protocol, when the user tries to access a website, the browser will ask the user to either go through a browser plug-in to be authenticated or to register the user credential information if it is the user's first visit to the website. Based on the credential information provided by the user, the browser will generate a public/private key pair for that user. Using that key pair, the secured tunnel is then created between the user's browser and the server. In the next two sections, I will summarize the flow of messages between the user's browser and the server during the user registration and authentication. 2.1 User Registration A user visiting the website for the first time will be asked to provide a username, password, password confirmation, and the answer to one of ten available security questions. This information will be provided to a browser plug-in and will be used to generate the public/private key pair for the user, and the browser will use the generated private key to encrypt the current timestamp of the server, which will act as a token. The generated public key, username, and token will be sent to the server, which will in turn validate the token using the received public key. The server will then generate the session key, encrypt it with the user public key that it received from the user's browser and send it back to the browser. If the browser has the corresponding private key, it will be able to read the session key and start communicating securely with the server. Omar Omran [Page 4] INTERNET DRAFT User Defined Key Pair June 2013 After the successful setup of the secured tunnel between the user's browser and the server, the user will be redirected to the website registration page to complete registration at the website. (See figure 1.) Client Server U = User Name P = Password QA = Question Answer Pair KeyPair = genKeyPair(U||:||P:||QA) ClientHello ---------------> <--------------- ServerHello Token = enc(ServerHello.random, PrivKey) PubKey, U, Token ---------------> validate the token enc(PreMaster, PubKey) <--------------- [ChangeCiherSpec] Finished ---------------> [ChangeCiherSpec] Finished <--------------- Application Data <--------------> Application Data Figure 1: User Registration Omar Omran [Page 5] INTERNET DRAFT User Defined Key Pair June 2013 2.2 User Authentication When the user visits the website later, he must be authenticated through the browser plug-in, where the user will be asked to provide the username, password, and the security question/answer pair chosen during registration to generate the same key pair. The authentication will succeed only if the user provides the same information given during registration. Otherwise, an invalid public/private key pair will be generated inside the browser so that when the token, the encryption of the current timestamp of the server with the public/private key pair, is sent to the server with the username, the server will fail to validate the token using the registered public key and immediately terminate the connection with a fetal BAD_CERTIFICATE alert. (See figure 2). Client Server U = User Name P = Password QA = Question Answer Pair KeyPair = genKeyPair(U||:||P:||QA) ClientHello ---------------> <--------------- ServerHello Token = enc(ServerHello.random, PrivKey) U, Token ---------------> PubKey = Lookup (U) validate the token enc(PreMaster, PubKey) <--------------- [ChangeCiherSpec] Omar Omran [Page 6] INTERNET DRAFT User Defined Key Pair June 2013 Finished ---------------> [ChangeCiherSpec] Finished <--------------- Application Data <--------------> Application Data Figure 2: User Authentication 4. Technical Details The purpose of UDKP protocol is to provide a secured tunnel between the user's browser and the server using a set of messages. The messages exchanged between the user's browser and the server will be similar to the messages used in TLS 1.2 protocol to simplify the implementation of UDKP and to benefit from the best practices and countermeasures that are utilized in that popular protocol. UDKP protocol differs from TLS protocol in the manner that it performs the handshake; specifically, it uses a reduced number of handshake messages. However, the remainder of the UDKP sub-protocols has parallels to TLS sub-protocols, including SSL Change Cipher Spec Protocol, The SSL Alert Protocol, SSL Application Data Protocol, and SSL Record Protocol. 4.1. Messages Flow The message flow begins when the user uses a UDKP-supported browser to access a website that is protected with UDKP protocol on the UDKP- specific port. Before initiating the message flow, the browser must ask the user to provide his credential information to the UDKP plug- in . The UDKP plug-in has two modes of operation: the registration mode, for new users, and the login mode, for existing users. In the registration mode, a new user will provide a username, password, password confirmation, and select a security question to answer. The general rule of thumb is that the password will never leave the user Omar Omran [Page 7] INTERNET DRAFT User Defined Key Pair June 2013 browser; instead, the provided information will be used by the browser plug-in to generate a public/private key pair. If the user is already registered in the website, he will go through the plug-in login mode to provide his username and password, select the same security question that he selected during registration and provide the same answer. This information will be used to generate the same public/private key pair that was generated during registration. The browser is now ready to initiate communication with the server by sending the first handshake message, the ClientHello message, after which it waits for the ServerHello message response. Both of these messages are identical to their peers in TLS protocol. Unlike TLS, UDKP will not send the server certificate or the ServerKeyExchange message, as the security of the tunnel is no longer based on the server certificate. Additionally, the client authentication will be through a message signed with the user private key that was generated inside the browser plug-in, so there is no need for the server to ask for or receive the client certificate. When the browser receives the ServerHello message, it will respond with the UserAuthentication message. This is a new message that has been introduced in UDKP and contains four fields: user_token, user_name, user_public_key, and auth_mode. The user_name is the username for the user that is logging in. The user_token is constructed by encrypting the ServerHello.random value, which contains the server timestamp; this will protect against replay attacks. The user_public_key is the public key generated for the user inside the user's browser based on the user credential information. The final field is auth_mode, which will contain a zero if the user is using the plug-in registration mode and a one if the user is using the plug-in authentication mode. The user public key is mandatory only during user registration - i.e., if auth_mode contains a zero - because during authentication the public key would have been already stored into the server. struct{ UDKP_private-key-encrypted ServerHello.random user_token; UserName user_name; UserPublicKey user_public_key; AuthenticationMode auth_mode; Omar Omran [Page 8] INTERNET DRAFT User Defined Key Pair June 2013 } UserAuthentication; Once the server receives the UserAuthentication message, it will check if auth_mode is zero, indicating a registration attempt. In that case, the public key must be in the message, or the connection will be terminated with a fetal no_certificate_RESERVED alert. If user_public_key exists, the server will use it to recover its ServerHello.random value from user_token using the user public key. If auth_mode was one, indicating that the user is trying to be authenticated, the server will assume that the user is already registered and will accordingly try to locate the user_public_key using the pre-configured public key locator handler, which knows how to locate the user_public_key for the incoming username. If user_public_key was found, the server will use it to recover its ServerHello.random value from user_token using user_public_key. If the server failed to recover its ServerHello.random value from user_token using the user_public_key because of a missing or invalid user_public_key, the connection must be terminated with a fatal BAD_CERTIFICATE alert. If the value is recovered, the server will proceed to the next step by generating the pre-master secret that will be used to generate all the required session keys that would be used during the session. The method used to generate session keys is identical to that in TLS protocol. The PreMasterSecret message is also identical to its peer in TLS protocol and is communicated to the user after being encrypted with his public key so that no one can read it except the user himself, who has the related private key. struct { UDKP_public-key-encrypted PreMasterSecret pre_master_secret; } server_to_client_key_exchange; When the browser receives the server_to_client_key_exchange message that contains the encrypted PreMasterSecret, it will recover the PreMasterSecret using the user private key. At this point, it will derive session keys from the PreMasterSecret, as specified in the TLS protocol, and then send a ChangeCipherSpec message to notify the server that all subsequent communications will be protected using the newly negotiated algorithms and keys. Finally, the client sends the Finished message, which is the first message protected with the new algorithms and keys. The Finished message contains a hash for all the handshake messages received from the server so that the server can verify that the security parameters the client is using are the same as those they both agreed to use and demonstrate no manipulation. When the server receives the Finished message, it responds with its ChangeCipherSpec message, indicating that it will move to the Omar Omran [Page 9] INTERNET DRAFT User Defined Key Pair June 2013 protected mode of communication. Lastly, the server sends its protected Finished message. The ChangeCipherSpec and Finished messages are identical to their peers in the TLS protocol. At this point, the handshake is complete and both parties can communicate with each other with confidence that their communication is authenticated and protected. 4.2. Implementation Considerations There are some considerations that must be taken into consideration during the implementation of UDKP to ensure the best possible security. Firstly, the username that the user provides during registration must be the same as the username in the registered profile because the key pair generated inside the browser, which is sent to the server, is based on the profile username. If the user has the ability to change his username from the website, the public key that was sent from the browser to the server would be invalid because it would be based on the old username. Additionally, the public key cannot be regenerated by the server because the other components that are required to generate the key pair must not leave the user's browser. My Proof of Concept implements the URL for the website's registration page as part of the server configuration; then, once the secured tunnel is created, the server redirects new users to the registration page, where the page reads the username from the incoming request and displays it to the user as a read-only field. The second important consideration is that the username used in the plug-in login mode must be the same username used to authenticate the user to the website. Therefore, once the user is authenticated through the browser plug-in, he must be redirected to his home page and not to a normal login page. If a user were redirected to a normal login page, a MITM attacker would be able to set up a phishing attack against the user to steal his credential information. 5. Future Work UDKP aims to completely replace the TLS protocol; however the protocol still can go through a set of performance and security enhancements to make it more reliable. 5.1. Offline Brute Force Attack Omar Omran [Page 10] INTERNET DRAFT User Defined Key Pair June 2013 UDKP is vulnerable to offline brute force attacks against the server_to_client_key_exchange message that contains the session key premaster encrypted with the user public key. This message is only readable using the user private key. Although an MITM attacker does not have the user private key, he knows that the private key has been generated based on the username, password, and security question/answer pair using a known formula. Because the username is known to the MITM as it is transferred in the clear, the MITM attacker can try all possible passwords with all possible answers to the ten security questions to regenerate the public/private key pair. The correct password would be the one that generates the correct key pair. Each generated key pair would need to be tested by trying to decrypt the token that was encrypted with the user private key. This is a very serious vulnerability and must be mitigated with one of the following measures: 1. Forcing passwords to have a minimum complexity to make this offline attack impractical. This complexity could be achieved by enforcing a minimum length of eight characters, with different cases and at least one number or special character. Additionally, the security questions must be chosen carefully so that each question may have thousands of possible answers. 2. Another mitigation that could be implemented is to complicate the process of generating the public/private key pair by making it time- consuming. This would make a brute force attack impractical. For example, if the process of generating a key pair consumed an additional second, it would not significantly affect the user login operation but would make a brute force attack by generating all possible key pairs impractical. 3. Finally, you can give the cautious users the option to replace the security question/answer pair with external random sources of data that could be used with the username and the password as a seed to generate the user key pair. The external data source could be a random file on the users' hard disk or on the users' external USB. The use of an external source of data will add a significant amount of protection against a brute force attack. 5.2. UDKP and SSL Termination SSL termination occurs by uploading your SSL certificate to the SSL termination device or load balancer, at which point it terminates a user's SSL browsing directly. In UDKP protocol, there is no server certificate to be uploaded. Instead, the server will negotiate the encrypted connection based on the user public key that is stored in the database server. Unfortunately, the SSL termination devices are not involved in the user authentication, so they will not have access Omar Omran [Page 11] INTERNET DRAFT User Defined Key Pair June 2013 to the user public key. The proposed protocol could be modified such that the public key could be sent to the server during the login authentication mode. The load balancer could use this public key to encrypt the session key premaster secret and send it to the user. If the user is able to read the session key premaster, he knows the related private key. However, the user could generate any key pair and use it to authenticate any username, so as a final check, the load balancer must send the username and the public key to the webserver to validate that they are related to each other. 5.3. UDKP and OpenId The OpenId technology makes your internet navigation simpler by having only one username and password to remember. The goal of OpenId protocol is to allow users to sign on to different services with a single identifier, where the authentication itself is performed by the OpenId provider. The OpenId provider will provide the user with an authentication URL that the user can use at any website that supports this technology. The supporting websites redirect the user to be authenticated to the OpenId provider on behalf of the website. One of the main security concerns related to the use of OpenId technology is phishing attacks that trick users into giving away their OpenId authentication credentials. The attacker does not have to attack the OpenId provider directly, but he can set up a malicious website that will redirect the user to a phishing OpenId provider URL under the control of the attacker. As a result, the user online identity could be impersonated. This risk could be reduced by using the UDKP protocol, where your identity would be proved to your OpenId provider using a message signed with your private key through the browser plug-in. Then, the OpenId provider, who is responsible for confirming your identity to other websites, only needs to keep your public key to validate your signature. Thus, there is no need for any password to be transferred across the internet, preventing any type of phishing attacks. 6. Conclusion The use of Public Key Infrastructure that is provided by commercial CAs has protected the information that flows over the Internet from being compromised, and it is a key solution for e-commerce applications to protect their customers. However, this model is under increasing pressure to adapt to market realities, increasingly sophisticated users and higher expectations of security on the public Internet. The proposed solution aims to build traffic security Omar Omran [Page 12] INTERNET DRAFT User Defined Key Pair June 2013 without the need to be dependent on a third party to achieve this protection. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Authors' Addresses Omar Omran P.O. Box 16350 Doha, Qatar EMail: omh1835@rit.edu Omar Omran [Page 13]