Survey on Authentication Protocols for Mobile Devices

ByMuhammad Hasan, Lihua Duan, Tarik El Amsy

Course :60-564 Instructor: Dr. A. K. Aggarwal

Winter, 2006

Outline

Introduction Background Information Discussion of the Selected Papers Testing Methodologies Conclusion References

Introduction

Challenges on security and quality of service (QOS) of Wireless Networks: Unprotected open mediums Burst volume of communications

IETF AAA Working Group AAA (Authentication, Authorization, and

Accounting ) Several AAA protocols proposed :

RADIUS DIAMETER

RADIUS (Remote Authentication Dial In User Service)

Based on UDP. Client/server protocol. Takes care of Server availability, Retransmission, and

Timeouts. Details found at : RFC 2865.

RADIUS Packet

MAC header

IP header UDP header

RADIUS

header

Data ::

32-bitCode ID Length

Authenticator

Attributes…..

RADIUS Header :

The Whole Packet :

DIAMETER

Improvement over RADIUS Uses reliable transport protocols (TCP or SCTP) It uses transport level security (IPSEC or TLS) support for RADIUS It has larger address space for AVPs (Attribute Value

Pairs) and identifiers (32-bit instead of 8-bit) peer-to-peer protocol, not client-server : supports

server-initiated messages

Details found at : RFC 3588

Diameter Packet

MAC header

IP header TCP header Diameter header

Data ::

32-bitVersion Msg. Length

Flags Code

Application ID

Hop by Hop ID

End to End ID

AVP []…..

Diameter Header :

The Whole Packet :

The General Architecture

Inter-network & intra-network roaming

Visitied Network ISP

AAA server

Home Network ISP

AAA server

Home Network userCell 1

Cell 2

Inter-network roaming

Intra-network roaming

Internet

Inter-network roaming takes place When the user moves from one ISP to another ISPIntra-network roaming takes place when the user moves from cell to cell within the ISP.

Existing GSM Authentication

Mobile Client VLR/LAS HLR/HAS

IMSI IMSI

RAND

SRESIMSI, K t , RAND, SRES

K t ( TMSI )

ACK

VLR : Visiting Location Register RAND : A Random Number Generated by HLRHLR : Home Location Register SRES : KA, RAND (Encrypted with one-way fn)IMSI : International Mobile Subscriber Identity Kt : temporary authentication key TMSI : Temporary Mobile Subscriber Identity

Strong Password Protocols

The aim of strong password protocols is to authenticate the user while protecting the password against dictionary attacks by online eavesdroppers.

Two earlier strong password protocols : EKE and protocol of Gong. et al.

EKE (Encrypted Key Exchange) Protocol :

It provides secure authentication between user and a server using a weak secret.

Generates per session public- private key pairs. Major Drawback : Doing private key operations on

client side makes it infeasible to use with computationally restricted devices ( Mobile devices).

In 2002 Zhu et al. presents a variant of RSA-EKE for mobile devices.

The protocol of Gong et al.

Contains a trusted third party which is continuously available online as in Kerberos.

The parties in the system authenticate each other by the help of the trusted server.

GSM User Authentication Protocol

By Özer Aydemir, Ali Aydın Selçuk

TÜBTAK UEKAE LTAREN Research Center

Ankara TURKEY

Dept. of Computer Eng. Bilkent UniversityAnkara TURKEY

Paper 1

Paper 1 :GSM User Authentication Protocol (GUAP)

Objectives : User can authenticate with his/her password

instead of the embedded key. Breaks the dependency on the SIM card

during authentication. Users will be able to reach their accounts

without their SIM cards, via any cellular phone, Internet, or a special network

GUAP ( Cont. )

Resembles the approach of Gong et al. Three entities involved in the authentication. VLR plays the trusted server role Random nonces for freshness guarantee

of the sessions.

Functionality of GUAP

Mobile Client VLR HLR

IMSI

RAND

EHLR { n1, n2, c, Π (RAND) }, rA

Π (n1, n2 EXOR K), K(rA), rB

K(rB)

EHLR { n1, n2, c, Π (RAND)} K VLR (RAND)

K VLR (K), Π (n1, n2 EXOR K)

Π i : Password of user iEx{p}: Public key encryption of plaintext p with the key of xK(p): Symmetric key encryption of plaintext p with key K.n1, n2, c : Three random nonces generated by mobile clientK : Session key rA, rB : Challenges

Security Issues :

The existence of the correct n1 value in the fifth message indicates that it is the HLR that has decrypted the first message and sending this output.

The random nonce n2 protects HLR’s response encrypted by π against dictionary attacks on π by an attacker who gets to know k or by VLR.

Random c protects first message against regeneration by VLR.

Improving mobile authentication with new AAA protocols

by H. Kim and H. Afifi Proc. IEEE Int. Conf. on Communications, May 2003 An authentication protocol by combining the AAA framework

and the USIM authentication mechanism

Paper 2

LAS PAS/AAA Broker HAS

(3)

Send AVs

Generate AVs = (User, REND, XRES)s

Store AVs(4)

Challenge (REND1)

(5)

Response (RES1)Compute RES1 Verify RES1 = XRES1

Eliminate AV1Reply

(6)

A New Request(7)

Verify User IDRequest-challenge

Utilize AV2(8)

Challenge (REND2)

(9)

Response (RES2)Compute RES2 Verify RES2 = XRES2

Eliminate AV2Reply

(10)

UPC: USIM-PROXY-CAPABILITY; AV: Authentication Vector;

REND: random number; XRES: Expected Response;

RES: Response

AAA + USIM Authentication Protocol

(1)

Request-challengeVerify UPC

(2)

Forward + UPCFirst request

MU

Some Issues

USIM-PROXY-CAPABILITY (UPC) in the request message is forwarded to HAS through LASs

One of PASs can choose to become a broker by checking if UPC field exists in the request message

The number of AVs generated at HAS is an optimization problem

A lightweight authentication protocol with local security association control in mobile networks

by W. Liang and W. Wang Proc. IEEE Military Communications Conference, 2004 An authentication protocol by introducing local security

association with optimal life time for mobile user

Paper 3

MU LAS HAS

Request-Challenge

Challenge

ResponseForward

Verify

New RequestRequest-Challenge

Challenge

ResponseSA

Verify

Reply

Terminate SA when MU's out of network domain

LAS: Local Authentication ServerHAS: Home Authentication ServerSA: Security AssociationMU: Mobile User

Authentication with Local Security Association

Generate SAYES

Reply(SAKul)

ulKK LIFETIMEFALGORITHMR }{||},,{001

Reply(Kul)

})||{,(5 10 MUul IDRKMDHMACK

0},,{|||||| 010 Kul FALGORITHMRFALGORITHMK

K0: pre-defined shared key for MU and HASKul: new shared key for MU and LASF0: session random number against replay attackR1: random number

Refresh Local Security Association

})||{,(5 2'

MUul IDRKMDHMACKul

• When the local security association expires, LAS will refresh it by sending to mobile user a new key and a new life time

• An optimal life time of the local security association is critical for the efficiency of the authentication

the risk to crack the key is increasing as the life time is increasing

the cost to refresh

Localized Authentication for Wireless

LAN Inter-network Roaming

By Men Long , Chwan-Hwa “John” Wu , J. David Irwin Department of Electrical and Computer Engineering

Auburn University

Paper 4

Localizing the Authentication A new approach in which an initial mutual authentication

between a visited network and a roaming user can be performed locally without any intervention by the user’s home network.

Advantages are low time delay and robustness.

A practical certificate structure x.509 Authentication adapts the SSL v3.0 handshake protocol. Local AAA server will approve or reject the authentication

request. Home network AAA will not be part of the process

Local Authentication Handshake Messages

Flow 1 “client Hello” Flow 2 “ server Hello” Flow 3 “Finished”

Roaming User Terminal

Visited Network

NU , D

EncPKs(k),Ek1 (CerU),SignSu (NS ||NU S || U)

NS , CertS

Protocol flow

Message flow (1) (NU , D ) same as “ClientHello” in SSLprotocol: The user sends a random number NU as user nonce along with

D domain name of the roaming user.

Message flow (2) (NS , CertS ) same as “ServerHello” in SSL protocol: The AAA server will attempt to find its public key certificates

CertS signed by domain D received in message 1 and sends the certificate CertS and server’s nonce NS to the user.

If it did not find a certificated signed by D then it will abort the session because there is no roaming agreement with this domain and the user get rejected.

Message flow (3):

The user employs his home network’s public key to verify the CertS. The user chooses a random number k as the pre-master secret and

then encrypts it by Enc PKS (k) using the visited network’s public key PKS in CertS.

The user’s terminal applies a pseudo random function to the pre-master secret to derive a key k1.

Then k1 encrypts the user’s certificate CertU by EK1 (CertU) via a symmetric cipher such as the AES-128 with an appropriate mode.

Finally, the user signs the message NS || NU|| S|| U using his private key SU, by DSA or the RSA methods.

Pre-master key

EncPKs(k) + Ek1 (CerU) + SignSu (NS ||NU || S || U)

Encrypted User Certificate Signature message

Authentication Key Establishment

The Visited network will Decrypt to obtain the pre-master secret k using its own private key SKs.

It then applies the publicly known pseudorandom function to the pre-master secret to derive k1.

Use k1 to decrypt and obtain the user’s certificate. The visited network will validate & verify the

authenticity of the user’s public key certificate and then the validity of the user’s signature.

EncPKs(k),Ek1 (CerU),SignSu (NS ||NU || S || U)

Security Feature Comparison

WiFi & GSM Local Authen.

Time overhead due to com. b/w Home &

Visited networkYes No

Impact resulting from home network failure Maximum Minimum

Visited network learns roaming user’s secret

Yes No

Strong authentication against cryptanalysis No Yes

Testing Methodologies

The HLR and VLR are simulated on a 2.4 GHz Pentium IV machine, and the mobile client runs on Sun’s KToolbar v.2.0 simulation toolkit

The simulations are implemented in Java2 Standard Edition (J2SE) for

HLR and VLR, and in Java2 Mobile Edition (J2ME) for the mobile client. The cryptographic functions are inherited from the Bouncy Castle

Lightweight Crypto API for both J2SE and J2ME.

Paper 1

Testing Methodologies

Consists of LAS, AAA broker, and HAS. They are geographically separated and connected by

routers. The performance of the proposed authentication

protocol is evaluated by measuring the time spent for authentication.

Two suites of experiments are performed according to: the number of users the number of proxy agents.

The gathered results reduces the spent time considerably compared with DIAMETER protocols.

Paper 2

Testing Methodologies

Paper 4 , Localized Authentication Testing Methodology 2 phases Phase I, with a Pentium 4 (2.2 GHz) and 512 MB RSA encryption or signature verification time is 0.28 milliseconds

while the RSA decryption or signature-signing time is 5.53 milliseconds.

Phase II ( SSL/TLS protocol ) . laptop Pentium 4 (1.8 GHz) & 256 MB memory and IMAP server The results indicate that the time delay per SSL channel setup

averages 24 milliseconds. According to the data from the phases 1 and 2, the expected time

delay for the proposed protocol is about 30=24+6 milliseconds.

Paper 4

Testing Methodology

Tecc

TcT

cecTc

T

Tc

TCT

rn

mcT

rn

m

,

0,)(

0,

)(

Paper 3

)(TC is the total authentication cost by processing all the authentication request sent by roaming MUs.

is the arrival rate of authentication request to initiate a new network service.

is the average residence time of a roaming MU in the foreign network.

T is the life time of a security association (SA). cc is the signaling cost to refresh a local SA.

mc is the cost for remote authentication.

nc is the cost for local authentication.

rc is the cost to compensate the risk that SA is cracked. is the factor of increasing risk.

Testing Methodology-cont.

Suppose there are 10 hops for remote authentication

Paper 3

Conclusion

DIAMETER, RADIUS, EKE and Gong et al.’s are some of the earliest standardized AAA authentication protocols.

To improve efficiency or adaptability, many new authentication protocols are proposed in the literature. We discuss four most recent ones. For those protocols aiming at improve efficiency, they

usually share one common feature: reduce the number of remote authentications by transforming them into local authentications.

For those protocols aiming at improve adaptability, they often try to relax some hardware limitation for authentication, such as the use of SIM card.

References B. Aboba and D. Simon, “PPP EAP TLS authentication

protocol”, RFC 2716, October 1999. O. Aydemir and A. Selguk, “A strong user authentication

protocol for GSM”, 14th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprise, 2005, pp.150-153.

S. M. Bellovin and M. Meritt, “Encrypted Key Exchange: Password based protocols secure against dictionary attacks”, in Proceedings of the IEEE Symposium on Security and Privacy, May, 1992, pp.72-84.

L. Biunk and J. Vollbmcht, “PPP extensible authentication protocol”, RFC2284, March 1998.

L. DeIl’Uomo and E. Scanone, “The mobility management and authentication, authorization mechanisms in mobile networks beyond 3G”, 12th IEEE International Symposium on Personal, Indoor und Mobile Radio Communications, 2001, vol. 1, pp. c 44-c 4 8.

A. Freier, P. Karlton, and P. Kocher, “The SSL protocol version 3.0”, available at: http://wp.netscape.com/eng/ssl3/draft302.txt, Nov. 1996.

S. Glass, T. Hiller, S. Jacobs, and C. Perkins, “Mobile IP authentication, authorization and Accounting Requirements”, RFC2977, October 2000.

L. Gong, T. M. A. Lomas, R.M. Needham, and J. H. Saltzer, “Protecting poorly chosen secrets from guessing attacks”, IEEE Journal on Selected Areas in Communication, Vol.11, No.5, June 1993, pp. 48-656.

H. Kim and H. Afifi, “Improving mobile authentication with new AAA protocols,” Proc. IEEE Int. Conf. on Communications, Vol.1, May 2003, pp. 497-501.

W. Liang and W. Wang, “A lightweight authentication protocol with local security association control in mobile networks”, IEEE Military Communications Conference (MILCOM 2004), Vol. 1, 2004, pp. 225-231.

.

H.-Y. Lin, L. Harn, and V. Kumar, “Authentication protocols in wireless communications”, CAUTO’ 95, 1995.

M. Long, C. J. Wu, and J. D. Irwin, “Localized authentication for wireless LAN inter-networking roaming”, IEEE Wireless Communications and Networking Conference (WCNC), Vol.1, 2004, pp. 264-267

C. Perkins and P. Calhoun, “Mobile IPv4 challenge/response extensions”, RFC3012, November 2000.

RFC 3588. Diameter Base Protocol. Available at: http://www.ietf.org/rfc/rfc3588.txt.

C. Rigney et al. “RADIUS extensions”, RFC 2869, available at: http://bgp.potaroo.net/ietf/html/ids-wg-radext.html. June 2000.

R. Rivest, “The MD5 message digest algorithm”, RFC 1321, April, 1992.

S. Shieh, E. Ho, and Y. Huang, “An efficient authentication protocol for Mobile Networks”, Authentication Protocol hrn01 of Information Science and Engineering, vol. 15, 1999, pp. 505-520.

W. Simpson, “PPP challenge handshake authentication protocol (CHAP),” RFCI334, August 1996.

W. Stallings, “Network security essentials”, Applications and Standards, 2000.

M. Xu and S. Upadhyaya, “Secure communication in KS”, in Vehculur Technology Conference, pp. 2193-2197, 2001.

http://www.cisco.com/warp/public/707/32.html. http://en.wikipedia.org/wiki/DIAMETER. KToolbar, A toolkit for J2ME, http://java.sun.com/j2me. Lightweight Crypto API, Bouncy Castle,

http://www.bouncycastle.org

Special Thanks to:

Dr. A.K. Aggarwal

Questions ?