Network Working Group Young Man Park Internet Draft DongJin Kwak Document: draft-park-take-00.txt Korea Telecom Expires: August 2006 February 2006 Simultaneous authentication of user and device in Wireless IP Networks Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies a new two factor authentication and key establishment (TAKE) protocol that can be applied to low-power mobile devices in wireless IP Networks, using two factor authentication and precomputation. The two factor authentication makes use of user's password and the symmetric key which is stored in the token possessed by a user. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Protocol Overview..............................................3 3.1 Protocol Requirement......................................3 3.2 Two Factor Authentication..................................4 3.3 TAKE Protocol..............................................5 Park, et. al Expires - August 2006 [Page 1] TAKE February 2006 Internet-Draft 3.3.1 Enrollment Phase....................................5 3.3.2 Precomputation Phase................................5 3.3.3 Real-execution Phase................................6 3.4 Real-execution Phase.....................................6 4. Security Consideration........................................6 5 conclusion.....................................................8 6. References....................................................8 Author's Addresses............................................9 1. Introduction The needs for high speed Internet service through wireless IP network have been increasing thesedays. Wireless LAN was originally introduced for productivity and efficiency in industry fields but today lots of public hotspots also provide Public Wireless LAN(PWLAN) service. Broadband Wireless Access(BWA) service based on WiMAX of IEEE 802.16 is getting spreaded and new wireless IP technologies are emerging fast. But wireless security in wireless IP network is one of important technical obstacles in facilitating uses of WLAN service. This document specifies a mutual two factor authentication and key establishment (TAKE) protocol using two factor authentication and precomputation. It can be applied in low-power mobile devices for wireless IP networks such as IEEE 802.11 WLAN(WiFi) and IEEE 802.16e Mobile Wireless MAN(mobile WiMAX)[14] IEEE 802.16e is an amendment that adds support for mobility over the base IEEE 802.16 specification IEEE 802.16e specifies Privacy Key Management v2 (PKMv2) protocol, which support the Extensible Authentication Protocol(RFC 3748)[2] for user authentication and device authorization. So the TAKE protocol especially has the structure that is easy to be applied in user and device authentication in IEEE 802.16 network. The two factor authentication in the TAKE protocol makes use of user"s password and the symmetric key which is stored in the token possessed by user, i.e. the TAKE is perfect two factor authentication method verifying the symmetric key and user"s password in authentication server(AS). This protocol provides mutual authentication, and half forward- secrecy(FS). The computational complexity that the client must perform is just one symmetric key encryption and five hash functions during the runtime of the protocol. Park, et. al Expires - August 2006 [Page 2] TAKE February 2006 Internet-Draft 2. Terminology 2.1 Requirement notation In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in (RFC 2119)[15]. 2.2 TAKE Terminology This document frequently uses the following terms and abbreviations: A : client (supplicant) B : authentication server (AS) w : password t : symmetric key used in symmetric key encryption ID_A : client A's identifier E_K{ }, D_K{ } : encrypt and decrypt with symmetric key K H( ) : a cryptographic hash function sk_A : session key generated by client A p : a large prime number q : prime divisor of (p-1) g : an primitive element of order q in b : static private key and public key of B 3. Protocol Overview 3.1 Protocol requirement Security requirements of Authentication and Key Establishment (AKE) in wireless IP network are: (1) Identity protection. It is necessary to protect a client's identity from passive attacks such as eavesdropping, to ensure personal communication privacy. Identity protection is particularly useful for the client to whom a dynamic IP address is allocated by DHCP. (2) Explicit mutual authentication. As attackers can launch MitM attacks by installing a rouge AP or a rouge radio NIC between the client and the Authentication Server (AS), explicit mutual authentication between the client and the network is necessary. (3) Session key establishment. The session key must be established between the client and the AS so that it can support the dynamic WEP key. (4) Forward-Secrecy (FS). Park, et. al Expires - August 2006 [Page 3] TAKE February 2006 Internet-Draft FS should be provided to ensure that attackers cannot compute previous session keys from the sessions eavesdropped on previously, even when a long-term secret keying material of the entity participating in the protocol has been revealed. (5) Resistance to an off-line dictionary attack. It should be guaranteed that secret information (passwords and keys) shared between a client and AS is resistant to an off-line dictionary attack. (6) Key confirmation. It should be confirmed to a legitimate user participating in the protocol that he or she actually shares a common secret session key with an entity with which communication is intended. (7) Non-repudiation. Fraudulent clients must be prevented from arguing that accounting is not correct and that illegal access is paid for. (8) Efficiency. - Low computational load: The protocol requires a low computational load that can be borne by even low power devices such as PDAs, and precomputation to minimize on-line computation operations. - Minimum number of message exchanges: In terms of network resource efficiency and network delay, it is advantageous to have as few communication rounds as possible. Therefore, the number of messages to be exchanged between the client and the AS should be kept to a minimum. - Minimum communication bandwidth use: The protocol message should be as short as possible. 3.2 Two factor Authentication The two factor authentication described herein refers to authentication of an entity by identifying (1) what a user remembers (the password) and (2) what the user has (a token or wireless terminal) in an integrated fashion. Single factor authentication relying only on passwords is not secure for various reasons. First, someone can look over a user's shoulder and get the password as the user types it. Also, keystroke monitoring can reveal a password. Second, an attacker may acquire passwords by social engineering such as deceits or threats. Third, a password has low entropy in terms of the volume of information, which makes it vulnerable to dictionary attack. Fourth, bad habits of users, such as physically recording passwords or using similar passwords for different applications without renewal, may compromise the security of passwords. Two factor authentication has a demerit in that it requires a token as the second factor and a token-reading input device (a token reader). Generally, a token might be a smart card, a USB (Universal Serial Bus)-based smart key, or a wireless device. If a wireless device or USB- based smart key is used as a token in a PWLANs environment, no token reader is required. However, as the token stores within it the user's secret key or certificate data, it should Park, et. al Expires - August 2006 [Page 4] TAKE February 2006 Internet-Draft be stored in a secure module that provides a certain level of tamper resistance. 3.3 TAKE protocol The TAKE protocol is based on DH(Diffie-Hellman) key agreement and can be modified to work in an arbitrary finite group. In terms of phases, the TAKE protocol can be described as having an enrollment phase, a precomputation phase and a real-execution phase. (The operator mod p will be omitted) 3.3.1 Enrollment Phase The client and the Authentication Server (AS) determine and share the password and symmetric key used for symmetrical algorithm such as 3DES or AES And the AS selects a random number from numbers ranging from [1 ~ q-1] as its private key to a specific client, and stores the selected number in a secure database and informs the client of AS`s public key and domain parameter . The client stores the symmetric key in a secure token. Since the AS`s public key and domain parameter can be publicly released, they do not have to be stored in a secure location. The client A Authentication Server(AS) B ================= =========================== H(ID_A,g^b) --------------> r select r from [1-q] f=H(r,w,t) <-------------- e=E_f{g^x} sk_A=H(c,g^x,r,ID_A) M_A=H(sk_A,w,t,g^b) (e,M_A) --------------> f=H(r,w,t) g^x=D_f{e} c=(g^x)^b sk_B=H(c,g^x,r,ID_A) M_A ?= H(sk_B,w,t,g^b) M_B=H(sk_B,w,t,ID_A) M_B <-------------- M_B ?=H(sk_B,w,t,ID_A) Fig. 1 TAKE protocol Real-execution 3.3.2 Precomputation Phase Park, et. al Expires - August 2006 [Page 5] TAKE February 2006 Internet-Draft Precomputation is performed off-line prior to execution of the protocol. It reduces time and computational load during the protocol execution. The client's wireless device performs precomputation at idle time or at power on. To be more specific, a random number is selected from [1 ~ q-1], and then calculated and at off-line prior to protocol execution. 3.3.3 Real-execution Phase The real-execution phase performs mutual entity authentication and session key establishment and it consists of the following steps: (1) To connect to PWLANs service, client (A) sends to AS(B) its identifier ID_A and AS's public key which has been hashed into H(ID_A,g^b). If the client identifier uses an NAI (Network Access ID) to support global roaming and accounting (ex: userid@realm.com), the user name portion and the hashed into H (user id,g^b) and realm portion are sent together as well. (2) Upon receipt of H(ID_A,g^b), B extracts , , , , from its database. B selects a random number and sends it to A. (3) Upon receipt of , A computes and , using as a symmetric key for encryption of . A then computes session key and generates . A sends and to B. (4) Upon reception of and , B computes and , using as a symmetric key for decryption of . Then B computes and confirms if received from A and computed by B are identical. If they are identical, A's authentication is successful and B accepts . B then computes and sends it to A. (5) A checks if that has been received from B and as computed by A are identical. If they are identical, B's authentication is successful and A accepts . If A and B accept and respectively, mutual authentication is successful. 4. Security Considerations Following is an analysis of TAKE protocol's conformance to the section 31 protocol requirement: (1)Identity protection. Upon receiving an ID request from AP, the client sends H(ID_A,g^b) instead of its ID_A to prevent passive attackers, such as eavesdroppers, from knowing the client's identity. Yet, AS needs to be able to match the pseudonym of the client to its real identity. (2)Explicit mutual authentication Park, et. al Expires - August 2006 [Page 6] TAKE February 2006 Internet-Draft The client must know the password , the symmetric key , the session key , and the AS's public key to compute for client authentication, while AS must know the password , the symmetric key , the session key , and the AS's private key to compute for AS authentication. Therefore explicit mutual authentication is provided in this fashion. (3)Session key establishment Established session keys have freshness and randomness as they are based on a dynamic choice of random numbers and by each entity. (4)Forward-Secrecy(FS) If ,,, possessed by a client are all exposed to an attacker, the attacker may learn about by decrypting . However, the value of is hard to compute due to the DDH (Decision Diffie-Hellman) problem [10]. Therefore, FS on the client's side is ensured. On the other hand, if , , , and of a client, stored on the AS side, are all exposed to an attacker, the attacker can compute a session key. Therefore, FS on the AS side is not provided. In after all, the TAKE protocol provides partial (half) FS in that an attacker cannot compute a session key even when the client side is compromised. But, in reality, as Wireless Internet Service Providers (WISPs) providing PWLANs have their own robust security architecture, the possibility that secret information on the AS side can be compromised will be quite low. (5) Resistance to an off-line dictionary attack. As the symmetric key with high entropy, the password , and a random number are hashed into and are used as a key for encryption of , off-line dictionary attacks stand little chance of success. In other words, an attacker cannot help but guess password , symmetric key and random value at the same time. (6) Key confirmation. TAKE includes the session key in and , to confirm the keys. (7) Non-repudiation. TAKE protocol doesn't employ a digital signature so that it doesn't support non-repudiation which provides proof of the integrity and origin of data. But, using two-factor authentication makes it more difficult for fraudulent clients to deny the use of PWLANs service than using single factor authentication. (8) Efficiency. - Low computational load: During the runtime of the AKE protocol, most of the computation time is composed of exponentiation, inverse elements, and multiplication. Only a little time is spent on hash functions and symmetric key encryption/decryption [8] It is noteworthy that real-time authentication takes a long time on PDAs (or hand-held devices) characterized by low power and low computing power if the volume of the computational operation is Park, et. al Expires - August 2006 [Page 7] TAKE February 2006 Internet-Draft increased. For TAKE, client is required to perform two exponentiations for precomputation, and one symmetric key encryption and five hashes during the protocol. On the server side, the computational load is one exponentiation, one symmetric key decryption, and four hashes. - Minimum number of message exchanges: TAKE protocol requires two round trips (four passes) to the AS to perform a mutual authentication and key establishment. - Minimum communication bandwidth use: Among five messages, three are hash output bits, one is random number bits and the other is the encryption output bits 5. Conclusions Considering the wireless security problem, there have been a lot of attempts to solve the wireless security problem by means of wired security techniques such as TLS and SRP. However, those are not always successful because it is especially hard to address unique concerns in a wireless network environment. So, there is a need for a wireless security protocol that can cope with the handicaps of the wireless network. We proposed a mutual authentication and key establishment protocol using two factor authentication and precomputation. To defeat the TAKE protocol, the attacker must possess the token and knowledge of the client's password to gain access to the network. The TAKE protocol is resistant to a social engineering attacks and keystroke monitoring in a PWLANs environment and it is efficient enough to be applied to PDAs. During the protocol runtime, a computational operation required of the client is only one symmetric key encryption and five hashes. The AS's pubic key must be obtained in a trusted manner, for example, from a public-key certificate signed by a trusted third party such as Certificate Authority, or directly from the public key owner (i.e., WISP), provided that the public key owner is trusted by the receiving party and can be authenticated as the source of the data that is received. A client's symmetric key can be stored within a secure module of PDAs or a USB-based smart key. For the server's static private key , it will be more secure to use multiple private keys rather than applying only one private key to all clients uniformly. 6. References [1] IEEE, "Standard for local and metropolitan area networks - Port based network access control," IEEE Std 802.1x, June 2001. [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Park, et. al Expires - August 2006 [Page 8] TAKE February 2006 Internet-Draft [3] D.P. Jablon, "Strong Password-only Authenticated Key Exchange," ACM Computer Communications Review, vol.26, no.5, pp.5-26, October 1996. [4] IEEE Standard 802.11, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," 1999. [5] W.A. Arbaugh, "Your 802.11 Wireless Network has No Clothes," Proceedings of the First IEEE International Conference on Wireless LANs and Home Networks, December 2001. [6] C. Rigney, "Remote Authentication Dial-In User Service (RADIUS)", IETF RFC 2865, June 2000. [7] B. Aboba and M. Beadles, "The Network Access Identifier," IETF RFC 2486, Jan. 1999. [8] D. S. Wong and A. H. Chan. "Efficient and Mutually Authenticated Key Exchange for Low Power Computing Devices," In ASIACRYPT 2001, LNCS 2248, Springer-Verlag, Berlin, 2001 [9] S. Bellovin and M. Merritt. "Augmented Encrypted Key Exchange: A Password-Based Protocol that is Secure against Dictionary Attacks and Password File Compromise," ACM Conference on Computer and Communications Security 1993, pp. 244~250. [10] D. Boneh, "The Decision Diffie-Hellman Problem", In proceeding of the Third Algorithmic Number Theory Symposium, pp 48-63, 1998. [11] B. Aboba, "The Unofficial 802.11 Security Web page", http://www.drizzle.com/~aboba/IEEE. [12] M. Casole, "WLAN security - Status, Problems and Perspective", In Proceedings of European Wireless 2002, Florence Italy, February 2002. [13] S. Bellovin and M. Merritt. "Augmented Encrypted Key Exchange: A Password based protocol secure against dictionary attacks and password file Compromise," In Proceedings of the 1st Annual Conference on Computer and Communications Security, ACM, 1993. [14] IEEE, "Draft standard for Local and metropolitan area networks" IEEE p802.16e/D9,June 2005. [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Addresses Park, et. al Expires - August 2006 [Page 9] TAKE February 2006 Internet-Draft Young Man Park Network Infra Laboratory, KT 17, Woomyeon-dong, Seocho-gu,Seoul 137-792, Korea Email: Youngman@kt.co.kr DongJin Kwak Future Technology Laboratory, KT 17, Woomyeon-dong, Seocho-gu,Seoul 137-792, Korea Phone: +82-2-526-5484 Email: djk@ktco.kr Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Park, et. al Expires - August 2006 [Page 10] TAKE February 2006 Internet-Draft Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.