INTERNET-DRAFT O. Omran Category: Experimental Independent Expires: August 15, 2013 February 11, 2013 User Defined Key Pair Abstract In this document I am providing the outlines for a modified version of the Transport Layer Security Protocol (TLS); the modified version will come as a new protocol that will build a secured tunnel between the client and the server without the need to involve Certificate Authorities or any other third party in this process; it is called User Defined Key Pair protocol(UDKP), and is based on the assumption that in most cases there is a registered profile for the user on the server; a profile that includes among a lot of things the username and the password that the user uses to authenticate to the server, the proposed protocol will make use of the username and the password to create a key pair for the user on the fly at the client side, and it will use this key pair as the starting point for creating the secured tunnel instead of taking the server certificate as the starting point. Additionally the proposed protocol has self- protection against phishing attacks. 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 Omar Omran [Page 1] INTERNET DRAFT User Defined Key Pair February 2013 Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the 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 . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Implementation and Message Structure . . . . . . . . . . . . . 6 3.1. Implementation . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Message Structure . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Registration Attack . . . . . . . . . . . . . . . . . . . 13 5.2. Login Attack without Public Key . . . . . . . . . . . . . 14 5.3. Login Attack With Public Key . . . . . . . . . . . . . . . 15 5.4. Phishing Attack . . . . . . . . . . . . . . . . . . . . . 15 6. Limitation and Future Work . . . . . . . . . . . . . . . . . . 15 6.1. Migration of Existing Applications . . . . . . . . . . . . 16 6.2. Security Enhancements . . . . . . . . . . . . . . . . . . 17 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Normative References . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Omar Omran [Page 2] INTERNET DRAFT User Defined Key Pair February 2013 1. Introduction People are getting more depending on the Internet to do their daily live activities to the extent that if we have the chance to look at the information flowing through Internet cables we will see wealth of information going back and forward, which motivates malicious users to keep developing new techniques to steal valuable information that are supposed to be private. For that reason; security experts and researchers call for the need of a mechanism to protect the internet traffic by preventing eavesdropping, tampering, and spoofing attacks. Transport Layer Security (TLS) protocol is the most popular attempt to provide this kind of protection over the Internet by creating a secured tunnel based on the public key Infrastructure (PKI) technology. PKI provides the capability for two parties without previous relationship to share the security parameters that are required to create the secured tunnel between them; this is possible by relying on the service of Certificate Authorities (CAs). CA is the organization that issues and manages security credentials and public keys required for verifying the identity of the involved parties. Browser vendors usually embed a copy of the root certificates for a set of CAs that they decide to trust, in other words; it will act as an agent for the end user in deciding whether or not to trust a particular CA. When a browser receives a website certificate that is signed by any of those CAs, it will blindly trust this website on behave of the user after verifying that the website certificate has not been revoked by the CA. Certificate Authorities depend on the service of Registration Authority (RA) for verifying the information validity of the certificate applicant. If the applicant's information is verified, then the process moves forward; and a public key is assigned for encryption purposes. In this document I will provide the outlines of User Defined Key Pair (UDKP) protocol; a new protocol in the application layer of the TCP/IP suite that will create a secured tunnel between the user and the server, it's targeting the main issue of having CA as a single point of trust. Instead of starting the security process by receiving a certificate from the server that needs to be verified by CA, UDKP will start the security process from the user who will send a signed message to the server using a specific key pair that will be created for him on the fly inside the browser based on the username and the password; those username and password will be provided to the browser, not to the server. The signed message needs to be verified only by the server itself not any other third party, the verification will be done using the public key that will be stored on the server as a part of the user profile, and upon successful verification, the session key information will be generated by the server and Omar Omran [Page 3] INTERNET DRAFT User Defined Key Pair February 2013 communicated to the user using its public key. We can see here that the password will never leave the user browser, and the server will communicate the session key information to the user using his public key, so that will protect the user from phishing websites that aim to steal the user credential. 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. UDKP plug-in, Browser plug-in - a new plug-in that would be added to the UDKP supported browsers to allow them to perform UDKP related calculations on the username and password before communicating with the server. Key pair - is a public/private key pair that will be created for the website user by the browser plug-in based on his username and password; this key pair will be used for authenticating the user to the server, and for creating a secured tunnel between the user and the server without involving Certificate Authorities. Plug-in mode, UDKP mode - UDKP plug-in can perform two main functionalities: login existing users to websites; and registering new users into websites; those two functionalities called modes and accordingly we have two different modes register and login, each mode comes as a tab in the plug-in dialog. Plug-in register mode - when a new user uses the plug-in registration tab to register into a website; he would be using the register mode of the plug-in. Login mode - when an existing website user uses the plug-in login tab to login into a website; he would be using the login mode of the plug-in. 2. Overview The root cause of the current TLS implementation failure to achieve the expected security is that the client encrypts the required security parameters using the server certificate it receives from someone who claims to be the server; this claim is supported by the Omar Omran [Page 4] INTERNET DRAFT User Defined Key Pair February 2013 attestation of a third party (CA); and here is where all kinds of man in the middle attacks come, someone else manages to get attestation that it's the server and sends a fake certificate to the client instead of the real server certificate, taking advantage of the fact that the browser will blindly trust any certificate signed by one of the trusted CAs, or that the user will simply ignore warnings generated by the browser indicating that the certificate is not trusted; as a result the client will start creating the secured tunnel based on this fake certificate, so all the traffic between the user and the website will be exposed to the fake certificate owner. Additionally, the current PKI implementation cannot protect against phishing attacks, any MITM attacker can have his phisher website that has similar URL as a proxy between the client and the real website, so the communication will be between the client and the phisher website using the phisher certificate, and between the phisher website and the real website using the real certificate, so the phisher will be able to capture the traffic. In the UDKP protocol when the user registers in a website that is protected using that protocol, he would be asked to provide the registration details including the username and the password just like normal websites; but unlike any other website, the user will never provide the password to the website; instead he will provide the username and the password to a browser plug-in that will use them to generate public/private key pair using a predetermined procedure, only the public key will be sent to the server to be saved inside the database with the related user information. When the user visits the website later he would be asked to provide his user name and password to the browser plug-in and not directly to the website, the plug-in will regenerate the private key by following the same predetermined procedure followed in the registration, and then the plug-in will use it to encrypt the current server timestamp. The username and the encrypted current server timestamp will be sent to the server for authentication. The encrypted current server timestamp will work as a onetime password (OTP) that will be valid only for a few seconds, so if someone in the middle managed to intercept this OTP it will be useless after few seconds, the server will decrypt the OTP received from the user using his public key that is already stored inside the database, and if the result was the current server timestamp with a pre-defined tolerance, the server will generate the session key information and encrypt it using the user public key, so no one can read the session key information except the user as he is the only one who has access to the private key - actually the browser plug-in has this private key -. If the user is able to read the session key information using his private key he will be confident that he is communicating with the real server as it is supposed to be the only one who has the user public Omar Omran [Page 5] INTERNET DRAFT User Defined Key Pair February 2013 key, otherwise he will know that he is under MITM attack either through a phishing website or through the normal man in the middle attack. Although TLS protocol is the current implementation of the PKI model of security, which has been subjected to different types of attacks that give the impression that no practical solution might be exist for the problem at all. But TLS and its predecessor SSL have gone through various security enhancements that aimed to reduce the risks inherited from the nature of the PKI, which makes it an attractive starting point for developing new protocols and techniques that are related to the concept of creating a secured tunnel between two parties, so although UDKP is completely independent of TLS, but as we are delving deeper into the technical details of the UDKP protocol you will get the feeling that UDKP is a modified version of the TLS protocol that takes advantage of the security practices followed in TLS through years of practical experience, and that will make the implementation of UDKP is much easier as it will benefit from most of the messages structure used in TLS protocol. UDKP protocol will change the way that TLS is using to perform handshake; it comes with a reduced number of handshake messages, but for the rest of UDKP sub- protocols everything will be typical to TLS including: SSL Change Cipher Spec Protocol, The SSL Alert Protocol, and SSL Application Data Protocol. 3. Implementation and Message Structure The purpose of UDKP protocol is to provide a secured tunnel between the client and the server based on a set of messages that allow them to exchange the security parameters required for that mission. As I mentioned before the messages exchanged between the client and the server will be similar to the messages used in TLS 1.2 protocol to benefits from best practices and countermeasures followed in that popular protocol, and to simplify the implementation of UDKP. 3.1. Implementation Although UDKP is similar to TLS in messages structure, but due to changes I made in the handshake protocol, it could not be considered to be relate the transport layer anymore. UDKP protocol now needs to interact with the application layer to locate the public key for specific user, not only encapsulating packets coming from the application layer; this interaction with the application layer will move UDKP up to the application layer. The server will receive the username from the browser in the Omar Omran [Page 6] INTERNET DRAFT User Defined Key Pair February 2013 Authentication message, and depending on the implementation decision, the received username will go from the transport layer to the application layer to locate the related public key; that can be done using a pre-configured public key locator handler that knows how to locate the public key for specific user, there may be various types of handlers that are able to locate the user public key from different kinds of storage, if the website is storing the user information inside a database table like most web application, the website deployment engineer will need to specify the handler type, which will be in our case database handler, and to provide the required information to locate the user public key from the database (see figure 1). Figure 1: UDKP Server Configuration The required information in case of database handler is: className: indicate which type of locator handler the website is using - in this case it's a database locator handler. driverName: indicate the database vendor that is used by the webserver to store the user information - in this case it's mysql. connectionURL: contains the location of the database and the credential information needed for connecting to the database. userTable: the table that contains the user information. userNameCol: the column that contains the username. Omar Omran [Page 7] INTERNET DRAFT User Defined Key Pair February 2013 userCredCol: the column that contains the public key for specific user. registerURL: contains the URL that the user will be redirected to in order to complete the registration into the website - we will talk about the importance of this URL later. For complete scenario; when the webserver starts, it will create the public key locator handler based on the server configuration, and then waits for incoming connections on the UDKP port for, when it receives a connection from a client, it will pass the public key locator handler to UDKP; using this handler; UDKP will know how to authenticate the user when it receives the Authentication message from the client. 3.2. Message Structure The messages flow starts when the user uses a UDKP supported browser to access a website that is protected with UDKP on the UDKP specific port, before initiating the messages flow the browser must ask the user to provide his username and password to the UDKP plug-in. UDKP plug-in has two modes of operation; one for new users called registration mode, and the other is for existing users called login mode. The new user will go to the registration mode and provide the username, password, and password confirmation, the rule of thumb here is that the password will never leave the user browser; instead the username and the password will be used by the browser plug-in to generate public/private key pair. In case the user is already registered in the website he will go through the plug-in login mode to provide his username and password which will be used also to generate public/private key pair. The browser is ready now to initiate the communication with the server by sending the first handshake message; the ClientHello message and then waits for ServerHello message response; those messages are identical to their peers in TLS protocol. struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; Omar Omran [Page 8] INTERNET DRAFT User Defined Key Pair February 2013 CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello; struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ServerHello; Unlike TLS; UDKP will not send the server certificate or serevrkeyEchange message as the security of the tunnel is not based on the server certificate anymore, also the client authentication Omar Omran [Page 9] INTERNET DRAFT User Defined Key Pair February 2013 will be through a message signed with the user private key that has been generated inside the browser plug-in, so there is no need for the client certificate to be sent to the server, and the server will not ask for it. When the browser receives the ServerHello message, it will respond with the UserAuthentication message; a new message that is introduced in the UDKP and contains three fields: user_token; user_name; and user_public_key. the user_name and the user_token are always sent to the server; the user_name is the username for the user that is trying to login, the user_token will be constructed by encrypting the ServerHello.random value; this random value contains the server timestamp, the browser will add or deduct a few random seconds to it, those random seconds should be short enough to prevent replay attack, and at the same time should be large enough to protect against the known plain text attack as the ServerHello.random value is sent in clear. In case a new user is trying to access the website the user_public_key that will be created for him inside the browser plug- in will be sent, otherwise only user_token and user_name will be sent. struct{ UDKP_private-key-encrypted Random user_token; UserName user_name; UserPubliKey user_public_key; } UserAuthentication; Once the server receives UserAuthentication message it will check if the message contains the user_public_key or not; if the user_public_key exists the server will use it to recover its approximate current timestamp from the user_token. If the server didn't find the user_public_key in the UserAuthentication message, it will assume that the user is already registered in the website, and hence it will try to locate the user_public_key using the pre- configured public key locator handler that knows how to locate the user_public_key. If the user_public_key was found, the server will use it to recover the approximate current timestamp from the user_token. If the authentication failed because of missing or invalid user_public_key a fatal message must be returned with BAD_CERTIFICATE alert, otherwise the server will proceed to the next step by generating the pre-master secret that will be used to generate all Omar Omran [Page 10] INTERNET DRAFT User Defined Key Pair February 2013 required session keys that would be used during the session; the generation of session keys will be identical to TLS protocol. The PreMasterSecret message is identical to its peer in TLS protocol and will be communicated to the user after being protected using his public key, so no one can read it unless the user himself who has the related private key. struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret; struct { UDKP_public-key-encrypted PreMasterSecret pre_master_secret; } server_to_client_key_exchange; Once the browser receives the server_to_client_key_exchange message that contains the encrypted PreMasterSecret, it will try to recover the PreMasterSecret using the user private key, once succeeds it will be confidence that it's communicated with the real web server and not a phishing one because only the real server has the user public key. The client will start deriving session keys as specified in the TLS protocol from the PreMasterSecret, and once finish it will send ChangeCipherSpec message to indicate to the server that all communications from now on will be protected using the newly negotiated algorithms and keys, and finally the client will send the Finished message which is the first protected message using the new algorithms and keys; this message contains a hash for all handshake messages received from the server, so the server can check that the security parameters that the client is using are the same that they both agreed to use without any manipulation. When the server receives the Finished message it will respond by sending its ChangeCipherSpec message indicating that it will move to the protected mode of communication, followed by its protected Finished message. ChangeCipherSpec and Finished messages are identical to their peer in the TLS protocol. struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; Omar Omran [Page 11] INTERNET DRAFT User Defined Key Pair February 2013 struct { opaque verify_data[verify_data_length]; } Finished; At that point the handshake is over and both parties can start communicating with each other with confidence that their communication is authenticated and protected, and the communication will be protected using Application Data Protocol which is identical to its peer in TLS. 4. Security Considerations There are some security practices that must be taken into consideration during the implementation of UDKP to have the best possible security. Those security practices are related to the user registration and the user login modes of the browser plug-in. The first practice is during the user registration, when the user provides his username and password to the browser plug-in registration mode; this username must be the same username used in the registered profile, because based on that username the key pair will be generated inside the browser, and the public key will be sent to the server, if the user has the ability to change his username from the website, the public key that has been sent from the browser to the server will be invalid because it would be based on the old username and the password, and it cannot be regenerated by the server as the password must not leave the browser. As a matter of implementation practices; the URL for the registration page of the website might be part of the server configuration, so once the secured tunnel is created, and if the user is new to the website, the server will redirect the user to the registration page where the page will read the username from the incoming request and display it to the user as read only field. The second important practice is that the username used in the plug- in login mode must be the same username used to authenticate the user to the website, so the application normal log-in page must be removed; otherwise a MITM attacker will be able to monitor the traffic between the user and the web site. 5. Threat Model In this part various scenarios and use cases will be studied and Omar Omran [Page 12] INTERNET DRAFT User Defined Key Pair February 2013 discussed to evaluate and ensure the sustainability of the protocol against various types of attacks, our security evaluation will be based on a predefined fairly broadly-scoped threat model that we believe to be a real-world threat model; this thread model will be focusing on the following types of attacks: Registration Attack: is MITM attacker that is able to insert himself as a MITM when the user is registering his profile for the first time in the website. Login Attack without Public Key: is MITM attacker that is able to insert himself as a MITM during the login operation without previous knowledge of the user public key. Login Attack with Public Key: is MITM attacker that is able to insert himself as a MITM during the login operation and knows in advance the user public key; this knowledge may be through database violation or during the registration phase where the user public key is transferred in clear. Phishing Attack: is when the attacker managed to install his phishing website as a proxy between the user and the real website in the hope to steal user valuable information, with previous knowledge of user public key. 5.1. Registration Attack This attack is related to user registration phase. For the purpose of simplifying things; we will consider an example of facebook.com website and we will assume that the facebook is protected using the UDKP protocol. Now to register in facebook I will go through the browser plug-in and provide my username and password, and connect to the facebook, at that time the public/private key pair will be generated in the browser and the following message will be sent from the browser to the server for the sake of registration: struct{ UDKP_private-key-encrypted Random user_token; UserName user_name; UserPubliKey user_public_key; } UserAuthentication; If the MITM attacker deliver this message to the server, the server Omar Omran [Page 13] INTERNET DRAFT User Defined Key Pair February 2013 will respond with the session key encrypted by the user public key and as the user private key didn't leave the browser, so the MITM attacker has no idea about it, so he will not be able to read the session key information and accordingly he will not be able to monitor the traffic any more. The only chance for the attacker is to generate different key pair and to send the newly generated public key to the server, so when the server sends the session key information it will encrypt it using the MITM attacker public key, so the attacker will be able to read the session key information and he can use the victim public key to re- encrypt the session key and send it to the victim, so he can monitor the traffic, but as we said in the security considerations section 4; the username and the public key sent in the Authentication message during the handshake are the same values used to register the user into the website, so in this case the victim has not registered into the website, the one who has registered is the attacker, and when the victim tries to log-in later he will not be able to do that as the generated key pair inside the victim browser is different than the key pair stored inside facebook. 5.2. Login Attack without Public Key If the user was securely able to register into the website, he would have passed the most risky threat to his privacy, for the login operation specially if the MITM attacker doesn't have access to the user public key, his chances to monitor the traffic is almost nothing. Let's go again with the facebook example, when the user provide the username and the password to the browser plug-in login mode, and when the public/private key pair is generated by the plug- in for the user, at that time, neither the public key nor the private key leaves the user browser, the only information that leaves the user browser is the username and the token that contains the ServerHello.random value encrypted using the user private key. struct{ UDKP_private-key-encrypted Random user_token; UserName user_name; } UserAuthentication; If the attacker delivered this message to the server, the server will try to read and validate the token using the user public key, and if it successes it will respond with the session key information encrypted by the user public key, and as the user private key didn't Omar Omran [Page 14] INTERNET DRAFT User Defined Key Pair February 2013 leave the browser, the attacker will not be able to read the session key and hence he will not be able to monitor the traffic. the only chance for the attacker is to be already a registered user in the facebook and to send his own Authentication message to the server, which will respond with the session key information encrypted with the attacker public key, but at that time the victim will be waiting for the session key information encrypted with his own public key and as the MITM attacker doesn't know the user public key he will not be able to communicate the session key information to the victim so the attack will be detected and the connection will be terminated. 5.3. Login Attack With Public Key This class of attack is similar to the one mentioned in Section 5.1.2, but at that time the MITM attacker knows the victim public key either through database violation or when the user registered into the website. In this case when the user sends it's Authentication message the attacker will not pass it to the server instead the MITM attacker will send his own Authentication message to the server, so the server will respond with the session key information encrypted with the attacker public key, who will read the session key information and re-encrypt it using the victim public key, but at that time when the handshake is over and as we have mentioned in the security considerations practices section 4, the username used in the plug-in login mode will be the same user used to login the user into the website, so if this is a facebook account the victim will see the attacker facebook account information not his own account information and he will be able to detect that something wrong is happening. 5.4. Phishing Attack The main target of phishing attacks is to steal the victim credential (username and password), so he can have access to the victim account later. Fortunately, in our case neither the password nor the private key will ever leave the user browser, so phishing attacks with UDKP protocol will be for the sake of traffic monitoring and it will be detectable just like the previously discussed attacks. 6. Limitation and Future Work UDKP aims to completely replace the TLS protocol; however it still has some issues and limitations that need enhancements in order to Omar Omran [Page 15] INTERNET DRAFT User Defined Key Pair February 2013 have an attractive alternative for websites to go through. In this part I will go through the challenges facing UDKP to be widely used in websites. 6.1. Migration of Existing Applications When we compare UDKP to TLS the first challenge that comes to mind is the TLS protocol layer which is the transport layer, this means that TLS usage is transparent to the application, so existing applications can migrate easily from normal to TLS without any change to the application code. Unfortunately this is not the case with UDKP, to migrate existing applications to UDKP, it requires change to the application code; that change should be kept as minimum as possible. The change is basically for the two protocol modes: Login and Register. Website Login Mode: according to UDKP definition, the application code must not perform the login anymore as the user must not provide the password to the website. Once the user receive its website home page, he would have been already authenticated by UDKP, otherwise if the authentication failed in the handshake, the server must terminate the connection with the user. If the user was successfully authenticated to the server through UDKP protocol, the application should receive the username in the request; this requires loading the home page information for the user from the database based on the username received in the request, instead of loading it from the database based on the username and the password (see Figures 2, 3). Username = Password = SELECT FROM WHERE USER_NAME = AND PASSWORD = Figure 2: The original code of the application (pseudocode). Load the user information based on the username and the password provided from the website login screen Username = SELECT FROM WHERE USER_NAME = Figure 3: The application code after modification (pseudocode). Load the user information based on the username coming from the server Omar Omran [Page 16] INTERNET DRAFT User Defined Key Pair February 2013 with the request One more change that is required for the UDKP authentication to work; we have talked about that change before which is how to tell the server where to locate the user public key to be able to authenticate him during UDKP handshake. As we said the server might come with a set of predefined handlers to handle different types of storage, we can have database handler to locate the public key from a database, or we can have LDAP handler, or even custom handler that the website development team can define. Website Registration Mode: The registerURL is recommended for redirecting the user to the registration page when a new user tries to register through the registration mode of the plug-in. For security reasons the user must register with the same username used in the plug-in, as if the user change the username in the website the password must also be provided to the website to regenerate the public key and that is prohibited according to UDKP protocol, so application must receive the public key and the username coming from the browser plug-in and save them into the user information storage, in the same location mentioned in the handler configuration. In the registration page; the password fields must be removed as they are not required anymore, and the username must be displayed as a read only field. 6.2. Security Enhancements There are some of the enhancements that need to be done to enhance UDKP security; in this part I will go through a list of those enhancements: Offline Brute Force Attack: UDKP is vulnerable to offline brute force attacks against the server_to_client_key_exchange message that contains the session key information encrypted using the user public key; this message can be read using the user private key. Although MITM attacker doesn't have the user private key, but he knows that the private key has been generated based on the username and the password using a known formula, and the username is known to the MITM as it's getting transferred in clear, so the MITM attacker can try all possible passwords to regenerate the public/private key pair, the correct password would be the one that will generate the correct key pair, each generated key pair needs to be tested by trying to decrypt the session key information, this session key information must be used first to generate the session keys, and the encryption session key must be tested by trying to read the protected traffic. This is a very serious vulnerability and must be mitigated by forcing passwords to be with minimum complexity to make the offline attack impractical; Omar Omran [Page 17] INTERNET DRAFT User Defined Key Pair February 2013 this complexity can be determined from the server itself using extra field in the ServerHello message; this complexity may contain a policy to change the password each while. One more mitigation that could be implemented is to complicate the process of generating the public/private key pair by making it time consuming, and that will make the brute force attack impractical, if the key pair generation consume two extra seconds in normal user machine, that will not significantly affect the user, especially if the key pair get cached for later usage, but it will make brute force attack by generating all possible key pairs impractical. Unified Secured Key Pair Generation: An important part of the protocol is to generate the public/private key pair from the username and the password; this generation must be very secure and unified across all protocol implementations, so all browsers can generate the same key pair from the given username and password. Username Business Rules: Finally in case of a new user is trying to access the protected web site, he will need to provide a username and password to the registration mode in the browser plug-in to generate the key pair, the provided username must be the same username used to register into the website. There must be a way to configure the server to force some business rules against the username; these business rules may include that the username must be unique and with minimum and maximum sizes, otherwise the business integrity and security will be at great risk. Those are a set of limitation and enhancements that need to be considered for the real implementation of UDKP to achieve the best security and functionality expected from the protocol. 7. Conclusion The use of Public Key Infrastructure which is provided by the commercial CAs has protected the information flows over the Internet from being compromised, and it becomes 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 the traffic security without the need to be dependent on any third party to achieve this protection. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Omar Omran [Page 18] INTERNET DRAFT User Defined Key Pair February 2013 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 19]