OSNP: Secure wireless authentication protocol using
one-time key
Y.L. Huang
a,*
, P.H. Lu
a, J.D. Tygar
b, A.D. Joseph
b aDept. of Electrical & Control Eng., National Chiao-Tung Univ., Hsinchu, Taiwan bDept. of Electrical Eng. & Computer Sciences, Univ. of California, Berkeley, USAa r t i c l e
i n f o
Article history:
Received 8 March 2009 Received in revised form 26 April 2009 Accepted 15 May 2009 Keywords: 802.11 WLAN security Handover security Handover authentication Mutual authentication Inter-domain authentication EAP-based protocol SWOON experiments
a b s t r a c t
Handover security and efficiency have become more and more important in modern wireless network designs. In this paper, we propose a new protocol using the one-time key for user authentication. The proposed protocol can support both intra-domain and inter-domain authentications efficiently. Our protocol requires five messages for intra-inter-domain initial authentication; three for subsequent authentication; and five for handover authentication. No authentication server is needed during handover, and our design reduces the computing load on the authentication server. We show an integration and implementation of EAP from 802.1X and our protocol, giving an easy way to apply our protocol on existing 802.11 wireless networks. The proposed protocol is realized and verified on the SWOON secure wireless testbed.
ª2009 Elsevier Ltd. All rights reserved.
1.
Introduction
To enhance the security in wireless networks, IEEE 802.11i (Ieee, 2003) defines a new security model for 802.11 a/b/g networks, specified new standards for authentication, encryption and message integrity, and implemented 802.1X (Ieee, 2001) for user authentication and key distribution. 802.1X is a port-based network access control mechanism that provides an extensible authentication protocol (EAP) (Aboba et al., 2004) and can be used in conjunction with other popular authentication protocols, such as TLS, PEAP, CHAP, etc.
There are many EAP methods supporting 802.11i authen-tication, including EAP-TLS (Ppp Eap, 1999), EAP-FAST (The Flexible Authentication, 2007), and LEAP (Macnally, 2001). EAP-TLS and EAP-FAST are used with public-key cryptography
for authentication. Compared to symmetric-key systems, public-key systems and certificates ensure stronger security, but require more computational power. LEAP, a symmetric-key authentication protocol, requires less computational power and thus takes less response time when performing user authentication. However, LEAP is vulnerable to several attacks (Baek et al., 2004) such as weak encryption keys. To balance the efficiency and security, an efficient authentication is required for wireless networks, especially for roaming users.
In 2007, Zrelli et al. (Zrelli and Shinoda, 2007) presented an integration of the Kerberos protocol with EAP framework, called EAP-Kerberos. Kerberos (Neuman et al., 2005) is well known for its symmetric-key cryptography, strong per-person key and inter-domain authentication. However, it is still
* Corresponding author. Tel.: þ886 3 5131476; fax: þ886 3 5715998.
E-mail addresses:[email protected](Y.L. Huang),[email protected](P.H. Lu),[email protected](J.D. Tygar), [email protected](A.D. Joseph).
a v a i l a b l e a t w w w . s c i e n c e d i r e c t . c o m
j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / c o s e
0167-4048/$ – see front matter ª 2009 Elsevier Ltd. All rights reserved. doi:10.1016/j.cose.2009.05.009
inefficient in the WLAN environment because users need to use proxies to get tickets from the Kerberos Key Distributed Center (KDC). In other words, in Kerberos, KDC is involved in the handover of a roaming user.
In this paper, we propose a handover authentication protocol for WiFi (802.11) networks. Our protocol does not require a public key infrastructure and can be integrated with the 802.1X (Ieee, 2001) Extensible Authentication Protocol (EAP) (Aboba et al., 2004). The novel contributions of this paper are: We propose an efficient authentication protocol supporting
handover authentication without a trusted of third-party. We integrate the proposed protocol with the EAP framework
so that it can be applied to wireless network authentication with only minor efforts.
We implement the proposed protocol and verify it using the SWOON testbed, a secure wireless network emula-tion testbed. We also compare it with other EAP methods in terms of communication, computation and storage costs.
The rest of this paper is organized as follows. Related research is detailed in Section2. We present our authentica-tion protocol and the integraauthentica-tion with EAP in Secauthentica-tions3 and 4, respectively. Section5compares our system to others, and Section6concludes the paper. In theAppendix, we use BAN logic (Burrows et al., 1989) and a possible enhancement (Shieh et al., 1999) to formally prove that our protocol can reach the goals of mutual authentication.
2.
Related work
2.1. Network authentication protocols
This section summarizes the characteristics and drawbacks of some related authentication protocols.
Kerberos
Kerberos (Neuman et al., 2005) was developed as a solu-tion to network security problems, such as replaying, eavesdropping and sniffing packets. In Kerberos V5, six messages are required for initial intra-domain authentica-tion. The number of message required for inter-domain authentication depends on the number of KDCs between the visited and home domains.
One-Time Password/Kerberos
Since the traditional password authentication is vulnerable to dictionary and playback attacks, in 2005, Cheng et al. (Xiao-rong et al., 2005) presented a new authentication method that integrates the Kerberos protocol and a one-time password (OTP) system. The main idea of OTP authentication is to add random factors during the initial login process and make the password used vary from time to time. Similar to the Kerberos protocol, the OTP/Kerberos protocol requires three steps to authenticate a user: authentication by the KDC, request of tickets from the Ticket-Granting Server (TGS) and access to the server (S). On the client, the OTP is generated by hashing the
user’s secret passphrase and the seed from the KDC. By encrypting and decrypting messages with the OTP, the user and server mutually authenticate each other. However, to generate an OTP for authentication requires seven messages in the first step mentioned above. In other words, OTP/Kerberos increases the communication cost for authenticating a user, resulting in longer user authentication times, which is not practical for roaming users in wireless networks.
Secure Authentication Protocols
In the last decade, many secure authentication protocols (Shieh et al., 1999; Chien, 2003; Liang and Wang, 2004; Hwang, 2005) were proposed to solve the issues of Kerberos. Among these protocols, Secure Network Protocol (SNP) (Shieh et al., 1999) is one of the few protocols that has real deployment for years. SNP is a symmetric-key based protocol providing an efficient way for both intra- and inter-domain authentication. Compared to Kerberos, fewer messages are required in SNP to authenticate client identity. For intra-domain authentication, SNP takes four messages to authenticate client identity and one more optional message for mutually authenticating the server. For inter-domain authentication, it takes seven messages for initial authentication, regardless of the number of hops between the visited and home domains. Only two messages are required for subsequent authentication when requesting the same service. To simplify the design, SNP replaces timestamps with nonces, reducing the need for time servers. For faster authentication, a master key is shared by the authentication server (AS) and the service servers (S). The unchanged master keys can make the system vulner-able to various attacks.
2.2. EAP-based authentication protocols
EAP is an authentication framework used in various networks, such as wireless LANs and Point-to-Point connections (PPP). EAP provides some common functions and a negotiation of the desired authentication methods, such as EAP-MD5, EAP-OTP, EAP-TLS, etc. In wireless LANs, EAP authentication methods are normally supported with Remote Authentication Dial-In User Service (RADIUS) (Remote Authentication Dial, 2000). RADIUS is also a client/ server protocol that enables remote access servers to communicate with a centralized authentication server to authenticate dial-in users. It also authorizes their access to the requested services. The RADIUS server supporting various EAP methods then becomes the major authority of wireless networks. This section summarizes EAP authenti-cation methods supporting strong authentication for roaming users in wireless LANs.
EAP-TLS
EAP-TLS (Ppp Eap, 1999) is a popular EAP method for securing wireless LANs with RADIUS. The mobile node and RADIUS server must have certificates to mutually authen-ticate each other. EAP-TLS is resilient to man-in-the-middle attacks. However, it requires a trusted-third party (Certifi-cate Authority) to support authentication between the
mobile node and RADIUS server. Also, it requires extra management for administrating and distributing certifi-cates, supported by cooperative network management systems (NMS) or Operation, Administration, Maintenance and Provisioning (OAM&P).
EAP-Kerberos
In 2007, S. Zrelli and Y. Shinoda (Zrelli and Shinoda, 2007) showed how to integrate the Kerberos protocol as an authentication method in EAP-based authentication frameworks. They define the architectural elements and specify the encapsulation of Kerberos messages in EAP packets. Such a design allows a mobile node to be authenticated using the Kerberos systems. When a mobile node, for example, issues an initial authentication request, the EAP-Kerberos client encapsulates the Kerberos messages into EAP packets and sends them to the access node. The access node then delivers these EAP packets to the RADIUS server via the AAA (Authentication Authori-zation and Accounting) protocol. The server either vali-dates these messages or forwards them to the Kerberos KDC, as shown inFig. 1.
Kerberized Handover Keying (KHK)
In 2007,Ohba et al. (2007)proposed a Kerberized media-independent handover key management architecture for the existing link-layer technologies, including 802.11 and 802.16. The architecture uses Kerberos for securing key distribution between a mobile node, an access point (authenticator) and a server. In KHK, two handover modes are presented: proactive and reactive. In proactive mode, a mobile node uses a pre-obtained credential to authenti-cate with the access point. In reactive mode, the access point acts as a Kerberos client on behalf of the mobile node. In this architecture, Kerberos can be bootstrapped from initial authentication using an EAP method. This makes KHK work across multiple AAA domains. However, similar to Kerberos, the KDC is involved in handover authentication in KHK. Thus, the handover performance for reactive mode
depends on the location of the KDC. The larger the distance between a KDC and a mobile node, the longer the time required for a handover authentication. Also, such an architecture incurs extra costs for setting up time servers for synchronizing machine times in the network, as mentioned in the previous section.
3.
Proposed protocol: OSNP
In this paper, we propose the integration of SNP, OTP and EAP for authenticating IEEE 802.11 mobile nodes, giving us support for fast roamingdOne-time key Secure Network Protocol (OSNP).
3.1. Preliminaries
Table 1 shows the abbreviations and symbols used in our protocol.
Similar to other password-based authentication methods, our authentication servers or KDCs share secrets with users and servers in their own domains. For example, the user chooses his own strong password and shares it with his KDC; the server chooses its own strong password and shares it with its KDC. These shared secrets are assumed to be stored in a secure storage system.
3.2. Intra-domain authentication
In our protocol, we give three methods for three types of intra-domain authentication: initial, subsequent and handover authentication. In initial authentication, five messages are required for mutually authenticating the user and server. To subsequently authenticate with the same server, only three messages are used (we renew session keys without querying the KDC.) Handover authentication requires five messages to renegotiate a new session key with another server of the domain. Although five messages are required, the KDC is not involved, reducing its load.
Since authentication occurs in a common domain, the notations Ua, Sa, and KDCaare simplified to U, S, and KDC, respectively.
3.2.1. Initial authentication
To initially access a server, the wireless client U sends the authentication request message (M1) to the server. The message is then forwarded to the KDC with server credentials (M2). The KDC authenticates the identities of user and server; generates a session key and sends the message (M3) back to the server. The server then forwards the message with encrypted session key (M4) to the user. The final acknowledge (M5) is sent back to the server for mutual authentication. M1. U / S: authRQU
M2. S / KDC: authRQSkauthRQU M3. KDC / S: SIDkauthAKSkauthAKU M4. S / U: authAKUkCHSkTKTS M5. U / S: RESPSkAU
M1. When the authentication process starts, the user generates an authentication request, containing a nonce NU, the user’s identity and an encrypted message using user’s one-time key OTKU: authRQU¼UkNUkfU; NUgOTKU. The
one-time key is a hashed value of user’s identity, password and nonce: OTKU¼Hash(U, NU, PWU). The request is sent to the server for authentication.
M2. After receiving the user request, S generates its request authRQS¼SkNSkfS; NSgOTKS. It then concatenates the two
requests and sends them to the KDC.
M3. To identify each session, the KDC generates a unique identity SID ¼ UjSjNU for each session after receiving the authentication requests. It also calculates the one-time keys OTKU and OTKS to verify the requests. After authenticating both identities, the KDC randomly generates a session key KSS. The session key, server’s nonce, and identity are encrypted with OTKSto acknowledge the server’s authentication request. authAKS¼ fNS;U; KSSgOTKS
A temporary user key KTUis generated and encrypted with OTKUin the acknowledgement.
authAKU¼ fNU;S; KSS;KTUgOTKU
The temporary user key can be used for subsequent authentication.
M4. Upon receiving the response from KDC, S decrypts authAKSin M3 with OTKSand gets the session key. The server generates a new challenge for authenticating the user. The new challenge is made by encrypting a new nonce N0
Sand the server’s identity with the session key KSS, represented as CHS¼ fS; N0SgKSS. In addition, S can also optionally generate
a ticket (TKTS) for subsequently authenticating the same user. TKTS¼SID k fU; VTS;KSSgOTKS
VTS is a validation time for TKTS. Since the validation of a ticket is determined by its issuer, no time server is required. M5. The user receives the session key after decrypting authAKU. It then generates a response RESPS¼ fU; N0SgKSSto CHS.
The response is generated by replacing the server’s identity with the user’s. Then, the mutual authentication of the user and server can be guaranteed by encrypting and decrypting these messages with the shared session key. In addition, a temporary authenticator AU¼ fS; VTU;KSSgKTUis also
appen-ded to the response message. The authenticator can be used to authenticate the user in subsequent authentication rounds without querying the KDC. As above, no time server is needed.
3.2.2. Subsequent authentication
Subsequent authentication rounds occur when a user requests the same services within the specified time. For intra-domain subsequent authentication, the user must send the ticket and his temporary credential to the server. Below is the flow for intra-domain subsequent authentication. M1. U / S: sauthRQU
M2. S / U: sauthAKUkCHSkAU M3. U / S: RESPS
M1. To initiate a subsequent authentication, the user generates a subsequent authentication request, consisting of a nonce and a ticket, and sends it to the server. The subse-quent authentication request can be represented as sauthRQU¼NUkTKTS.
M2. After receiving the sauthRQU, the server retrieves the user identity from the SID contained in TKTS. Then, the server decrypts the ticket and checks its validation time VTS. If the ticket is not expired, the server generates a nonce and a new session key. The user nonce and a new session key are then encrypted with the previous session key to acknowledge the request from user.
Table 1 – Message abbreviations.
Abbreviation Description
TKTx Ticket issued by X
CHx Challenge issued by X
RESPx Response to CHx
Ax Authenticator issued by X
authRQx Authentication request sent by entity X
authAKx Authentication response to authRQx
sauthRQx Subsequent authentication request issued by X
sauthAKx Authentication response to sauthRQx
hauthRQx Handover authentication request issued by X
hauthAKx Authentication response to hauthRQx
hquthVFx The verifier sent by the previous server Sold
iauthRQx Inter-domain authentication request issued by X
iauthAKx Authentication response to iauthRQx
iauthFWx Inter-domain authentication forwarding to X
Ua User principal in domain ‘‘a’’
Sa Server principal in domain ‘‘a’’
KDCa Key distribution center in domain ‘‘a’’
PWx Password of entity X
Nx Nonce generated by X
Kss Session key for securing the communication
Kg Group key for all servers under a KDC
KTU Temporal user key for subsequent authentication
OTKx One-time key of entity X
SID Session identification
VTx Validation time (Expiration) of entity X
TUx Temporary user identity of entity X
rt The remaining time of the validate ticket ct The current time of the local host
sauthAKU¼NU;K0SS
KSS
Then, the server nonce and identity are encrypted with the new session key. This is a new challenge for mutually authenticating the user.
CHS¼ fS; NSgK0 SS
A concatenation of sauthAKU, CHS with the temporary authenticator AUreceived in the initial authentication is then sent back to the user.
M3. The user decrypts the temporary authenticator AUto get VTUand KSS. It checks the validation time of the temporary authenticator, if the authenticator is not expired, the user decrypts sauthAKS, and obtains the new session key. The nonce NSand the user identity are then encrypted using the new session key to respond the CHS. The subsequent response is represented as RESPS¼ fU; NSgK0
SS:
3.2.3. Handover authentication
Handover authentication occurs when a user requests a server belonging to the same domain as the previous server. In most network authentication protocols, an initial authen-tication is required when contacting another server. This increases the load on the KDC. In such a case, since the user is already authenticated by the KDC and recognized by the previous server, re authentication can be performed by the previous server to reduce the load on the KDC. In this paper, we propose a 5-step handover authentication protocol for intra-domain authentication.
M1. U / S: hauthRQU M2. S / Sold: CHSkhauthRQU M3. Sold/S: SID k hauthVFSold
M4. S / U: hauthAKUkCHSkTKTSkAUold
M5. U / S: RESPSkAU
M1. Similar to subsequent authentication, a user sends a hauthRQU to initiate a handover authentication. The hauthRQUis the same as sauthRQU, containing a user identity, nonce and ticket to the previous server: hauthRQU¼UkNUkTKTSold.
M2. S generates a CHS¼ fS; NSgKg and forwards it together
with the hauthRQUto its previous server Soldin TKTSold:
M3. After validating the ticket, Sold retrieves the user identity, validation time VTSold and the previous session key
KSSold from the TKTSold. The server Sold then calculates the remaining validation time for the ticket: rt ¼ VTSoldct. The
remaining validation time, user identity and the previous session key are encrypted together with the response to CHS and the temporary authenticator AUoldusing the group key Kg.
hauthVFSold¼ fU; KSSold;rt; AUoldgKg is sent to S securely.
M4. Upon receiving M3, S decrypts the message with the group key and gets the previous session key, the temporary authenticator and the remaining validation time of the previous ticket. The temporary authenticator will be forwarded to the user for proving the user’s iden-tity. When generating the new ticket TKTSfor the user, S calculates its validation time according to the remaining validation time.
VTS¼ct þ rt
An acknowledgement hauthAKU¼ fNU;KSSgKSSold is generated responding to hauthRQU in M1. Also, a challenge CHS¼ fS; N0SgKSSis sent to the user for mutual authentication.
M5. As above, the user decrypts messages to get the new session key and his temporary authenticator AU. The new session key is used to generate the response RESPS¼ fU; N0SgKSS
to the CHS and the new temporary authenticator AU¼ fS; VTU;KSSgKTU.
3.3. Inter-domain authentication
The proposed inter-domain authentication takes advantages of the SNP design. All KDCs in the hierarchy share keys. This reduces the time required for querying and searching to locate the home KDC of the visiting user. A user TUxroaming from domain X, for example, wants to access a server SYin a foreign domain Y. His authentication request will be sent to SYand then to the foreign KDCY. Since KDCYcannot authenticate the user, the authentication request will be forwarded back to the previously visited KDCxafter KDCYlocates the KDCx. In our proposal, a root KDCRidentifies a previously visited KDC for a foreign KDC. Once TUxis authenticated by KDCx, the user TUx will receive a temporary identity TUY for its subsequent services in the domain Y.Fig. 2illustrates the initial authen-tication flow for an inter-domain authenauthen-tication.
3.3.1. Hierarchical KDC
In the previous section, we presented an authentication protocol for authenticating users who registered in the same security domain. However, for a very large network, it is impractical for all the users to be registered in a single domain. Instead, users and servers should register with their own KDCs, which form a hierarchical structure. In such a structure, each node in the hierarchy represents a domain, where parent domains manage all their children domains. Each domain has one KDC to manage the authentication of its users and servers.
In the proposed inter-domain authentication protocol, every KDC must share a different secret key with all its ancestors to perform inter-domain authentication efficiently. Consequently, the root KDC needs a large database to store the shared keys for all descendant KDCs. Fortunately, the size of a key is small, and the root KDC is able to store all the keys.
3.3.2. Protocol description
Similar to the intra-domain initial authentication, our approach starts with a request from the user from a foreign domain. M1. TUx/SY: authRQTUX M2. SY/KDCY: authRQSYkauthRQTUX M3. KDCY/KDCR: iauthRQKDCYkauthRQTUX M4. KDCR/KDCx: iauthFWKDCXkiauthAKKDCY M5. KDCx/KDCY: iauthAKTUXkiauthAKKDCY
M6. KDCY/SY: SID k iauthAKSYkiauthAKTUX
M7. SY/TUx: iauthAKTUXkCHSYkTKTSY
M8. TUx/SY: RESPSYkATUY
M1. Assume that a user, requesting a service in a new domain Y, has a temporary user identity TUxfor its previously
visited domain X. It needs to send an authentication request to the server SY in domain Y before accessing the desired services. The authentication request authRQTUXconsists of the
temporary user identity TUx, a nonce NTUX and an encrypted
message containing TUxand NTUX using its previous
tempo-rary key KTUX. authRQTUX¼TUXkNTUXk TUX;NTUX KTUX
M2. Similarly, the server SY generates its authentication request authRQSY, and sends the request together with
authRQTUXto its KDCY.
M3. Since KDCYcannot authenticate the visiting user, the user authentication request is forwarded to the nearest common key distribution center (KDCR) for KDCxand KDCY. The message also includes the server identity and an authentication request from KDCY. The server identity is used to recognize the communication session while iauthRQKDCY is
used to authenticate the common KDCR for KDCY. The iauthRQKDCY message contains KDCY’s identity and a nonce
NKDCY, in plaintext.
M4. Upon receiving the request, KDCRsends a forwarding message to the previously visited KDCx. The forwarding message is encrypted using the shared key of KDCRand KDCxand can be represented as iauthFWKDCX¼authRQTUX;TUY;KTUY;KSSgKKDCX:
The forwarding message includes not only the authentication request issued by user, but also a new temporary principal name TUY, a new temporary user key and a new session key. In addi-tion, KDCRencrypts TUY, KTUY, KSSand the nonce in iauthRQKDCY
with the shared key of KDCRand KDCY, and forwards it to KDCx. This message is an authentication response to KDCYand can be represented as iauthAKKDCY¼ fNKDCY;TUY;KTUY;KSSgKKDCY:
M5. KDCx decrypts the authentication response iauthAKKDCXand gets the temporary user identity-key pair and
session key. Since that KDCx only knows the nonce and temporary user key for user TUx, it encrypts the original nonce and new temporary user identity-key pair and session key with the pervious key KTUX. This is a message in response to
the authentication request issued by user TUx, the message
is represented as iauthAKTUX¼ fNTUX;TUY;KTUY;KSSgKTUX: The message is sent to KDCY together with the authentication response iauthAKKDCYfrom KDCR.
M6. KDCYdecrypts the authentication response iauthAKKDCY,
verifies the received nonce NKDCY and extracts temporary user
identity-key pair. Then, KDCYgenerates a new session identity and an authentication response to server SY. The response can be represented as iauthAKSY¼ fNSY;TUY;KSSgOTKSY;where
OTKSY¼HashðSY;NSY;PWSYÞis the one-time key of SY.
M7. Similar to the above description of intra-domain authen-tication, the server generates a challenge CHSY¼ fSY;N
0
SYgKSSand
a service ticket TKTSY¼SID k fTUY;VTSY;KSSgOTKSY:
M8. The user generates a new temporary authenticator using its handover key HKTUY. The authenticator
ATUY¼ fSY;VTTUY;KSSgKTUY can be used for subsequent
authentication. Then the user encrypts the nonce and temporary identity for the newly visited domain with the session key and sends it back as a response to CHSY. The
response is represented as RESPSY¼ fTUY;N
0 SYgKSS:
4.
Implementation
This section discusses the integration of our protocol and the EAP framework, which we call EAP-OSNP. EAP is a client/ server protocol using different authentication methods for authenticating users requesting network access. There are three entities in the EAP protocol: peer, authenticator and server. An EAP peer acts as a client requesting authentication and network services. An authenticator is the entity that controls the network access ports. An EAP server is capable of verifying users’ credentials.
4.1. EAP integration: EAP-OSNP
Fig. 3illustrates the EAP message flow of EAP-OSNP. An EAP peer sends Association Request to the EAP server. After receiving Association Response from the server, an EAPOL session, containing a sequence of EAP-Request/EAP-Response messages, starts for peer authentication. The EAP-Request and EAP-Response messages carry the OSNP authentication payloads, but the messages exchanged between the EAP server and KDC may optionally follow the EAP framework.
Taking intra-domain authentication as an example, the EAP peer builds an authentication request authRQU and encapsulates it into EAP-OSNP messages. The EAP peer behaves exactly as a wireless client (U) while the EAP server as a service server (S) in OSNP. To comply with the EAP frame-work, one more message EAP-Request (type ¼ S2U_AUTH) is required for initiating the EAP authentication. The EAP authentication succeeds when the wireless client receives the EAP-Success message.
To carry the OSNP payloads using EAP, we need to specify OSNP as the authentication method in the EAP packet.Fig. 4 shows the five fields in an EAP packet, including:
Code: identifies the type of the EAP packet: 1 for request and 2 for response.
Identifier: a sequence number used to match the request and response packets.
Length: indicates the total length of the packet, in octets.
Type: indicates the authentication method encapsulated in the EAP packet; hexadecimal 0xDD is reserved for EAP-OSNP in our implementation.
Type-Data: contains a Message-Type and the OSNP-Data. Table 2 lists the Message-Type and OSNP-Data defined for EAP-OSNP. As mentioned in the previous paragraph, S2U_AUTH is the extra message used to initiate the EAP authentication. We also define several message types, U2S_HELLO, S2KDC_AUTH, KDC2S_AUTH, etc, for the OSNP messages M1 to M5, as described inTable 2.
Fig. 4shows an example EAP-OSNP packet for requesting user authentication: the Message-Type is U2S_HELLO and the OSNP-Data is authRQU.
4.2. EAP-OSNP implementation
This section details the implementation of our protocol, including the authentication server, service server and wire-less client.
Authentication Server
The authentication server (kdcd), also behaving as a key distribution center, is realized on Linux 2.6.20-21. We implement two databases to maintain user and server accounts. The first database, managing the OSNP user accounts, is separated from the Linux account database. The commands, osnp_useradd, osnp_userdel and osnp_passwd,
are used to manage user accounts and change user passwords.
Our protocol also requires an additional database to manage service server accounts. The server database manages the service servers registered to the authentication server. It also maintains the server identities (S) and pass-words (PWS) shared with the authentication server. In our current implementation, we support several encryption algorithms, such as IDEA, DES, AES, CAMELLIA, and hash functions, such as MD5, SHA.
Service Server
In our implementation, the service server supports both 128-bit and 256-bit AES encryption. The service server must register to an authentication server before it can offer services. After registration, the administrator of the service server configure its authentication server and supported cipher suites in/etc/eap.conf. For example, a service server registered to the authentication server (IP: 10.1.2.3, port:14000) is configured as:
osnp {
s_identity¼ eapserver1 s_passwd¼ gnitset
ciphersuite¼ ‘‘C_AES_128_CBC, C_AES_256_CBC’’ kdc_ip¼ 10.1.2.3 kdc_port¼ 14000 kdc_timeout¼ 4 vt_interval¼ 3600 s_port¼ 14000 } Association Request Association Response EAPOL-Start EAP-Request/Identity EAP-Response/Identity EAP-Request/OSNP EAP-Response/OSNP (M1) 802.11 EAP-Request/OSNP (M4) EAP-Response/OSNP (M5) EAP-Success EAPOL Authentication EAPOL-Key (Pairwise key four-way handshake) EAPOL-Key (Group key handshake)
Data transmission .. . EAPOL-Logoff M2 M3 Authentication Server (KDC) EAP Server (S) EAP Peer (U)
vt_intervalspecifies the validation time of tickets issued by the server (i.e. VTSwe mentioned in Section3.) By running hostapd (Hostapd) (ver. 0.5.10), the service server supports and manages the wireless connections with its wireless clients.
The hostapd program is configured as a pass-though authenticator (wireless AP) and the IP address of the authen-tication server can be specified in the configuration file, as shown in the following:
ssid¼ wpa-osnp ieee8021x¼ 1 auth_server_addr¼ 127.0.0.1 auth_server_port¼ 1812 auth_server_shared_secret¼ secure acct_server_addr¼ 127.0.0.1 acct_server_port¼ 1813 acct_server_shared_secret¼ secure Wireless Client
By revising the open source package, wpa_supplicant (Linux WPA/WPA2/IEEE 802.1X Supplicant,) (ver. 0.5.8), the OSNP wireless client can support WPA2 authentication. Similar to other OSNP components, we also need to configure the key management method, EAP method, cipher suite, ticket validation time, etc in the OSNP wireless client:
network¼ { ssid¼ "wpa-osnp" key_mgmt¼ WPA-EAP eap¼ OSNP pairwise¼ CCMP group¼ TKIP identity¼ "eapuser" password¼ "testing"
ciphersuite¼ "C_NULL, C_AES_256_CBC" vt_interval¼ 4800
priority¼ 20 }
In this example, the wireless client uses WPA-EAP (EAP-OSNP) to connect to the access point with SSID ‘‘wpa-osnp’’. Its cipher suite is configured as 256-bit AES, while the valida-tion time (VTU) is 4800 seconds.
4.3. Experimentation
We validate the proposed protocol on the SWOON (Secure Wireless Overlay Observation Network) testbed (Huang et al., 2008). In this section, we brief the SWOON testbed and explain how we test and verify our protocol on SWOON. The experi-ments are built on Linux kernel version 2.6.20-21 with kernel cryptographic API enabled. In the end of this section, we compare our protocol with other EAP methods in terms of the protocol handshaking performance.
4.3.1. SWOON testbed
Taking Emulab (White et al., 2002; Emulab) and DETER (Benzel et al., 2006; cyber-DEfense Technology) as its basis, the SWOON testbed is an emulation testbed for wireless networks. The SWOON testbed is a comprehensive and flex-ible testbed allowing designers to test and validate their new wireless protocols and systems without building a physical test environment. The SWOON testbed supports heteroge-neous wireless networking technologies, including WiFi and WiMAX. On SWOON, we can specify the desired wireless network topology for experimentation.
SWOON uses virtual wireless devices which encapsulate wireless packets with UDP broadcast headers, so that we can send/receive wireless packets over the DETER testbed (an emulated ethernet testbed). The SWOON testbed can emulate wireless broadcast, delivery latency and packet loss. Such features help us to validate correctness and measure perfor-mance under various network conditions.
4.3.2. Setting up experiments
We setup an experiment for measuring the performance of the intra-domain authentication protocols of various EAP Fig. 4 – EAP-OSNP packet format: authRQU.
Table 2 – EAP-OSNP messages.
Message-type OSNP-data
S2U_HELLO S
U2S_HELLO M1: authRQU
S2KDC_AUTH M2: authRQSkauthRQU
KDC2S_AUTH M3: SIDkauthAKSkauthAKU
S2U_AUTH M4: authAKUkCHSkTKTS
methods, including EAP-OSNP, EAP-TLS, EAP-TTLS/MD5 and PEAPv0(MS-CHAPv2). Fig. 5illustrates the wireless network topology of our experiment, in which there are five nodes: one authentication server (kdc), two service servers (s0, s1), one wireless station (sta), and one wired node (dst).
The authentication server, kdc, and the two service servers are located in the same domain and thus connected via a private LAN switch ( plan). The service servers, s0 and s1, behaving as wireless APs, are both equipped with two network interfaces: one wired network interfaces card (NIC) and one wireless NIC. The wireless station (sta) is equipped with only one wireless NIC. Since these three nodes are radio reachable, we connect them to the same switch (wireless). The wired node (dst), offering public services, is located outside the public network. It can be reached via the external switch (lan).
For the intra-domain authentication, the wireless station sta, requesting the service running on s0, is authenticated by kdc. To request services running on other server, says s1, sta executes the subsequent authentication protocol to obtain a new session key without involving kdc. If the wireless station sta wants to request for services running on nodes in another domain, dst, for example, the handover authentication is proceeded. With the above scenarios, we can measure and compare EAP methods in terms of the performance of user authentication.
4.3.3. Experiment results
By running a packet sniffer tool, wireshark (Wireshark) (ver. 1.0.0) on sta, we capture the authentication messages exchanged between the service server and the wireless station. After analyzing the captured messages, we can
calculate the time duration (Dt) between EAP-Response/EAP-Identity and EAP-Success shown inFig. 3.
We measure the time cost by running 1000 user authenti-cations on each protocol and obtain the average cost shown in Table 3. The table shows the mean value for the average time cost of authentication. Compared with TLS, TLS/MD5 and PEAPv0(MSCHAPv2), OSNP takes 10.37 ms for an initial authentication, 4.43 ms for a subsequent authentication and 10.68 ms for a handover authentication.
From the result, we conclude that EAP-OSNP has a better performance than any other EAP method. Even the curves of EAP-OSNP initial authentication and handover authentication are quite close, we still reduce the computational loads of KDC since no KDC is involved during handover.
5.
Analysis and comparisons
This section discusses how our protocol can protect against the attacks. We also compare the OSNP protocol with other EAP-based protocols in terms of costs (communication, storage, etc) and performance.
5.1. Security analysis
Trivial Substitutions and Replay Attack
Since all of the proposed protocols are nonce-based and every credential and ticket in our protocols contains the nonces used to verify the freshness of that credential, trivial substitutions and replays attacks can be easily detected. Similar to other nonce-based protocols, the challenger starts a timer and waits for a response. If the timer expires before receiving the response, the challenger assumes that the message is either lost or corrupted and must issue a new challenge.
Man-in-the-Middle Attack
Since all critical messages in our protocol are encrypted to prevent eavesdropping, it is nearly impossible to modify the messages exchanged between entities. However, if an attacker A eavesdrops the communication channel between U and S, he can replace the authentication request authRQU with authRQA. The replaced authRQAis forwarded to the KDC together with authRQS. The attacker may be successfully authenticated by the KDC if he is a legitimate user in the system, but the Man-in-the-Middle attack still fails because the attacker cannot generate a correct authAKUto respond to the authRQU. Therefore, we conclude that a Man-in-the-Middle attack would not succeed against the OSNP protocol.
Fig. 5 – The topology of our experiment.
Table 3 – Average time costs of EAP methods.
OSNP TLS TTLS/
MD5
PEAPv0 Initial Subsequent Handover
Dt (ms) 10.37 4.43 10.68 69.47 59.32 66.24
User Impersonation Attack with Compromised Session Keys Since each session key is used only for a single authentica-tion session and is discarded after authenticaauthentica-tion, an imper-sonation attack with a compromised session key can be prevented. In our authentication protocols, we do not rely on timestamps or temporary keys. Taking intra-domain initial authentication as an example, this kind of attack can be easily detected by a server in M3 by checking the freshness of the nonce in authAKS. If the intruder substitutes NSin M2 and replays M3, the server can still detect that M3 is simply a forged message by verifying the nonce in authAKS. The intruder will be rejected even if he holds a compromised session key. Forward Secrecy
Our protocol addresses forward secrecy. The disclosure of long-term secret keying material used to derive an agreed key does not compromise the secrecy of agreed keys from earlier runs (Ohba et al., 2007). In our protocol, keys are chosen randomly, and the one-time key itself is used as a key which changes with each use.
802.1X Identity Privacy
When an eavesdropper is listening on network traffic, the authentication process exposes the identity of the EAP peer. Even with a stolen identity, the eavesdropper still cannot login into the system without the correct one-time key. Taking intra-domain initial authentication as an example, suppose the eavesdropper stores the user’s identity from previous sessions. It could then generate a forged authen-tication request authRQU. However, the request would fail authentication.
Dictionary Attack
Since the user’s identity and nonce are sent in plaintext, they may suffer from the brute-force attack. An attacker may guess PWUby dictionary guessing and comparing the hash values of (U, NU, guess) and OTKU. We made a small experi-ment to obtain the time cost of compromising a PWU, as listed inTable 4. From the experiment results, we conclude that the passwords should be restricted to lengths longer than 8 bytes and the frequency of changing the password can be determined according to the selected hash function.
Table 5 summarizes the analysis of some EAP methods, including EAP-TLS, EAP-OTP, EAP-Kerberos and EAP-OSNP. We compare their characteristics and capabilities against attacks of these methods in the table.
5.2. Performance analysis
Tables 6 and 7show the performance of Kerberos and OSNP, in terms of computation, communication and storage.Table 7 shows the number of messages for mutual authentication and the number of messages submitted by a user. OSNP requires a constant number of messages independent of the number of KDCs between the user’s visited domain and home domain. This reduces the time required for roaming from one domain to another. Compared with the Kerberos protocol, OSNP requires only two messages on the user side. This is feasible and practical for mobile networks with low data rates and bandwidth. It is also good for battery-powered mobile devices. Table 7also compares the number of shared keys among these protocols. Consider a hierarchy with N domains. The
Table 4 – Expected time cost of compromising OTKs.
Length of PWU MD5 SHA1 SHA512
3 1.140 (s) 1.325 (s) 2.041 (s) 4 110.967 (s) 132.108 (s) 194.784 (s) 6 175.698 (min) 209.171 (min) 308.408 (min) 8 1101.161 (day) 1310.950 (day) 1932.904 (day) The experiment is conducted on Ubuntu 8.4.2 (kernel 2.6.24) with Intel Pentium D CPU 2.8 GHz and memory size of 1 GB. The guessing space is limited to 95 printable characters (0x20 to 0x7E ).
Table 5 – Authentication and security analysis.
EAP methods TLS OTP Kerberos OSNP
Server authentication CERT N/A PW OTK Client authentication CERT OTK PW OTK Mutual authentication No No Yes Yes Replay attack Yes Yes Yes Yes Dictionary attack Yes No No No Brute-force attack No Yes No Yes Identity privacy protection No No No No Man-in-the-middle attack Yes No Yes Yes User Impersonation attack No No Yes Yes Forward secrecy No Yes Yes Yes CERT, Certificate; PW, Password; OTK, One-time key.
Table 6 – Performance comparison: computation costs.
Authentication Operations Kerberos OSNP KDC Sold S U KDC Sold S U Initial Random 2 – 0 2 2 – 2 1 Hash 4 – 3 4 2 – 1 1 En/decrypt 6 – 5 5 5 – 5 5 Subsequent Random – – – – – – 2 1 Hash – – – – – – 1 0 En/decrypt – – – – – – 4 4 Handover Random – – – – – 0 3 1 Hash – – – – – 1 1 0 En/decrypt – – – – – 3 5 5
Table 7 – Performance comparison: communication and storage costs. #Msg for mutual authentication #Msg initiated from user Type of trust #Shared keys Mobility support
Kerberos 2m þ 4 m þ 2 P&H O(N ) No OSNP 8 2 P&H O(N ) Yes m, Number of KDCs between the user’s visited domain and home domain; N, Number of domains; P&H, Peer and Hierarchical.
number of shared keys in OSNP is proportional to the number of domains, which is the same as the number of shared keys in Kerberos V5.
6.
Conclusion
In this paper, we integrated the one-time key with our nonce-based authentication protocol, which efficiently supports initial, subsequent and handover authentication. Our protocol requires five messages for initial authentication; three for subsequent authentication and five for handover authenti-cation. Although five messages are required for handover authentication, no KDC is involved in authenticating the roaming user. Then, we extended the intra-domain authen-tication protocol to an inter-domain authenauthen-tication protocol, which requires eight messages for mutual authentication, regardless of the number of hops between the visited and home domains. In all our authentication protocols, only two messages are sent by the user. Such a design is feasible for a mobile network with limited bandwidth and for those battery-powered mobile devices.
Since KDCs are transparent to users in OSNP, only regis-tered servers can communicate with KDCs directly. This architecture is suitable for modern mobile networks, where mobile devices only need to connect to a visited server for authentication, without knowing the location of the KDC.
Acknowledgement
This effort was partially supported by the International Collaboration for Advancing Security Technology (iCAST) and Taiwan Information Security Center (TWISC) projects, spon-sored by National Science Council under the grants NSC96-3114-P-001-002, NSC97-2745-P-001-001, NSC96-2219-E-009-013 and NSC97-2219-E-009-006.
Appendix.
In the appendix, we use BAN logic (Burrows et al., 1989) and its enhancement (Shieh et al., 1999) to explain why our protocol can reach the goals of mutual authentication for initial and subsequent authentication of intra-domain authentication. The intra-domain handover is a derivation of initial authentication, replacing KDC with the previous server and the inter-domain authentication is an extension of the initial authentication; the security of these two types of authentication is guaranteed by that of the initial authentication.
The BAN logic states that the mutual authentication is complete between two parties A and B, if there is a K such that
A believes A 4K B; B believes A 4K B;
A believes B believes A 4K B; B believes A believes A 4K B:
Initial authentication
The objectives of the initial authentication are to prove: the presence of both parties to each other, and the receipt of a ticket and a session key at the user side. Assume that
U believes U 4OTKU KDC; and (1)
S believes S 4OTKS
KDC: (2)
The proof is given in two parts: to authenticate S by U, and to authenticate U by S.
For the first part, since U receives authAKU, CHSand TKTSin M4, he can decrypt authAKCand get the session key Kss. By applying annotation rule and formula 1, we obtain
U believes U 4OTKU KDC; U seesNU;S; U 4 KSS SOTKU;and U believes KDC saidNU;S; U 4 KSS S:
Since that NU is generated by U, we have the following hypothesis:
U believes freshNU;S; U 4 KSS
S:
The nonce-verification rule applies and yields U believes U 4 S:
By decrypting the CHS, U verifies the server identity. Similarly, we obtain U seesS; N0 S Kss; U believes S saidS; N0 S;U 4 KSS S ; U believes S believes U 4KSS S:
The second part is proved by M3 and M5. S receives authAKSin M3, and he can decrypt the token and extract the session key Kss. Then, S decrypts RESPS using Kss to get N0S. Similarly, applying the annotation, the message-meaning, jurisdiction rules, and formula 2, we obtain
S believes S 4OTKSKDC;
S seesNS;U; U 4 KSS
SOTKS;
andS believes KDC said ðNS;U; U 4 SÞ:Since that NSis gener-ated by S, we have the following hypothesis:
S believes fresh ðNS;U; U 4 S
; and S believes U 4 S: Similarly, N0
Sis generated by S, we apply the nonce-verifica-tion rule and jurisdicnonce-verifica-tion rule and obtain
S seesN0 S Kss; S believes freshN0 S;U 4 KSS S ; S believes U saidN0 S;U 4 KSS S; and S believes U believes U 4KSS
S:
It proves that our initial authentication can achieve the following goals at the end of the authentication round:
U believes U 4KSSS; S believes U 4KSS
U believes S believes U 4KSS S; andS believes U believes U 4KSS
S
Subsequent authentication
In our subsequent authentication, S decrypts TKTS and extracts U, VTSand Kss. After checking the validation of VTS, Kss is still validate. We can apply the above formal rules, and obtain U believes U 4KSS S; U seesnNU;U 4 K0 SS SoKss; U believes S saidNU;U 4 K0 SS S; U believes freshNU;U; U 4 K0 SS S; and U believes S believes U 4K 0 SS S: For S, we also prove that
S believes S 4OTKS KDC; S seesU; VTS;U 4 KSS SOTKS; S believes KDC saidU; VTS;U 4 KSS S: So, S believes U 4KSS S:
After receiving RESPS, which contains a nonce NSand a new session key K0 ssgenerated by S, we obtain S sees fNSgK0ss; S believes freshNS;U 4 K0 SS S; S believes U saidNS;U 4 K0 SS S; S believes U believes U 4K 0 SS S:
This proves that our subsequent authentication can achieve the above goals.
r e f e r e n c e s
Aboba B, Blunk L, Vollbrecht J, Carlson J, Levkowetz H. Extensible Authentication Protocol (EAP). RFC 3748; June 2004.
Baek K-H, Smith SW, Kotz D. A survey of WPA and 802.11i RSN authentication protocols. Tech. rep., Dartmouth College Computer Science, TR2004-524; November 2004. Benzel T, Braden R, Kim D, Neuman C, Joseph A, Sklower K,
Ostrenga R, Schwab S. Experience with DETER: a testbed for security research. Testbeds and research infrastructures for the development of networks and communities, 2006. TRIDENTCOM 2006. 2nd International Conference on, 10p; March 2006.
Burrows M, Abadi M, Needham R. A logic of authentication. In: SOSP’89: proceedings of the Twelfth ACM Symposium on operating systems principles. New York, NY, USA: ACM; 1989. p. 1–13.
Chien H-Y, Jan J-K. A hybrid authentication protocol for large mobile network. Journal of Systems and Software 2003;67:123–30.
cyber-DEfense technology experimental research laboratory testbed.http://www.isi.edu/deter/.
Emulab – Network emulation testbed.http://www.emulab.net/. Hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS
authenticator.http://hostap.epitest.fi/hostapd/.
Huang YL, Tygar JD, Lin HY, Yeh LY, Tsai HY, Sklower K, Shieh SP, Wu CC, Lu PH, Chien SY, Lin ZS, Hsu LW, Hsu CW, Hsu CT, Wu YC, Leong MS. SWOON: a testbed for secure wireless overlay networks. In: CSET’ 08; 2008.
Hwang R-J, Su F-F. A new efficient authentication protocol for mobile networks. Computer Standards & Interfaces 2005;28: 241–52.
Ieee. (IEEE 802.1X), wireless LAN media access local and metropolitan area networks: port-based network access control. Tech. rep., IEEE; June 2001.
Ieee. IEEE 802.11i/D4.0: Medium Access Control (MAC) Security Enhancements. Tech. rep.; May 2003.
Liang W, Wang W. A lightweight authentication protocol with local security association control in mobile networks. In: IEEE military communications conference (MILCOM) 2004, vol. 1; 2004, pp. 225–31.
Linux WPA/WPA2/IEEE 802.1X Supplicant.http://hostap.epitest.fi/ wpa_supplicant/.
Macnally C. Cisco LEAP protocol description,http://lists.cistron. nl/pipermail/cistron-radius/2001-September/002042.html; 2001.
Neuman C, Yu T, Hartman S, Raeburn K. The Kerberos Network Authentication Service (V5). RFC 4120; July 2005.
Ohba Y, Das S, Dutta A. Kerberized handover keying: a media-independent handover key management architecture. In: MobiArchO˜ 07, Kyoto, Japan; August 2007.
Ppp Eap TLS Authentication Protocol. RFC 2716, October 1999. Remote Authentication Dial In User Service (RADIUS). RFC 2865,
June 2000.
Shieh S, Ho F, Huang Y. An efficient authentication protocol for mobile networks. Journal of Information Science and Engineering 1999;15(15):505–20.
The flexible authentication via secure tunneling extensible authentication protocol method EAP-FAST. RFC 4851, May 2007. Wireshark: network protocol analyzer.http://www.wireshark.
org/.
White B, Lepreau J, Stoller L, Ricci R, Guruprasad S, Newbold M, et al. An integrated experimental environment for distributed systems and networks. SIGOPS Operative Systematic Review 2002;36(SI):255–70.
Xiao-rong C, Qi-yuan F, Chao D, Ming-quan Z. Research and realization of authentication technique based on OTP and kerberos. In: Eighth international conference on high-performance computing in Asia–Pacific Region (HPCASIA’05); 2005, pp. 409–16.
Zrelli S, Shinoda Y. Specifying Kerberos over EAP: towards an integrated network access and Kerberos single sign-on process. In: Advanced information networking and
applications. AINA’07, 21st international conference; 2007, pp. 490–97.
Y. L. Huang is an assistant professor of Electrical and Control Engineering at National Chiao-Tung University, Taiwan. She received her BS and PhD degrees in Computer Science and Information Engineering from National Chiao-Tung Univer-sity, Taiwan in 1995 and 2001, respectively. She is a member of Phi Tau Phi Society since 1995. Her research interests include network security, wireless security, secure testbeds, secure control systems, VoIP, embedded systems, etc.
P. H. Lu received his BS degree in Electrical and Control Engineering from the National Chiao-Tung University, Taiwan
in 2008. His research interests include network security, network administration and wireless testbeds.
J. D. Tygar is Professor of Computer Science at UC Berkeley and also a Professor of Information Management at UC Ber-keley. He works in the areas of computer security, privacy, and electronic commerce. His current research includes privacy, security issues in sensor webs, digital rights management, and usable computer security. His awards include a National Science Foundation Presidential Young Investigator Award, an Okawa Foundation Fellowship, a teaching award from Carnegie Mellon, and invited keynote addresses at PODC, PODS, VLDB, and many other conferences. Before coming to
UC Berkeley, Dr. Tygar was tenured faculty at Carnegie Mel-lon’s Computer Science Department, where he continues to hold an Adjunct Professor position. He received his doctorate from Harvard and his undergraduate degree from Berkeley. A. D. Joseph is now an associate professor at the University of California, Berkeley. He is a former member of Professor Frans Kaashoek’s research group Parallel and Distributed Operating Systems in MIT’s Laboratory for Computer Science. His research interests include operating systems and application issues related to wireless mobile computing and parallel and distributed systems.
