Internet DRAFT - draft-omar-tls-udkp
draft-omar-tls-udkp
INTERNET-DRAFT O. Omran
Category: Experimental Independent
Expires: December 18, 2013 June 19, 2013
User Defined Key Pair
<draft-omar-tls-udkp-01.txt>
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]
