CELLULAR
AUTHENTICATION
FOR MOBILE AND INTERNET
SERVICES
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg,
Pekka Laitinen and N. Asokan
All at Nokia Research Center, Helsinki, Finland
A John Wiley & Sons, Ltd, Publication
CELLULAR
AUTHENTICATION
FOR MOBILE AND INTERNET
SERVICES
CELLULAR
AUTHENTICATION
FOR MOBILE AND INTERNET
SERVICES
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg,
Pekka Laitinen and N. Asokan
All at Nokia Research Center, Helsinki, Finland
A John Wiley & Sons, Ltd, Publication
This edition fi rst published 2008.
© 2008 John Wiley & Sons, Ltd.
Registered offi ce
John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom
For details of our global editorial offi ces, for customer services and for information about how to apply for
permission to reuse the copyright material in this book please see our website at www.wiley.com.
The right of the author to be identifi ed as the author of this work has been asserted in accordance with the
Copyright, Designs and Patents Act 1988.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in
any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by
the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be
available in electronic books.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand names
and product names used in this book are trade names, service marks, trademarks or registered trademarks of
their respective owners. The publisher is not associated with any product or vendor mentioned in this book.
This publication is designed to provide accurate and authoritative information in regard to the subject matter
covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If
professional advice or other expert assistance is required, the services of a competent professional should be
sought.
Library of Congress Cataloging-in-Publication Data
Cellular authentication for mobile and Internet services / Silke Holtmanns . . . [et al.]
p. cm.
Includes bibliographical references and index.
ISBN 978-0-470-72317-3 (cloth)
1. Mobile communication system–Access control. 2. Internet–Access control.
3. Cellular telephone systems–Access control. 4. Wireless LANs–Access control.
5. Authentication. I. Holtmanns, Silke.
TK6570.M6.C44 2008
005.8 – dc22
2008018998
A catalogue record for this book is available from the British Library.
ISBN 978-0-470-72317-3 (HB)
Set in 11/13pt Times by SNP Best-set Typesetter Ltd., Hong Kong
Printed in Singapore by Markono Print Media Pte Ltd, Singapore.
Contents
Preface ix
Acknowledgements xi
1 Introduction 1
1.1 Authenticated Key Agreement 1
1.2 The Challenge in Authenticated Key Agreement 2
1.3 How to Read this Book? 5
Reference 6
2 Classical Approaches to Authentication and Key Agreement 7
2.1 Existing Mobile Security Solutions 7
2.1.1 UMTS Security Infrastructure 7
2.1.2 Issues in Securing Services with Radio Layer Security 14
2.2 General-Purpose Approaches to Authentication and Key Management 16
2.2.1 Public Key Infrastructure (PKI) 16
2.2.2 Passwords 18
2.2.3 Kerberos 19
2.2.4 Radio Layer and General Purpose Security Mechanisms 19
2.3 Requirements for GAA 20
References 21
3 Generic Authentication Architecture 23
3.1 Overview of Generic Authentication Architecture 23
3.1.1 Rationales for Design Decisions 23
3.1.2 A Bird’s Eye View of GAA 25
3.2 Foundations of GAA 30
3.2.1 Architectural Elements of GAA 30
3.2.2 Bootstrapping 33
3.2.3 Authentication 39
vi Contents
3.3 Variations of the Generic Bootstrapping Architecture 41
3.3.1 GBA_ME 42
3.3.2 GBA_U 42
3.3.3 2G GBA 47
3.3.4 Detection of Bootstrapping Variants by the NAF 48
3.3.5 3GPP2 GBA 54
3.4 Building Blocks of GAA 66
3.4.1 Introduction 66
3.4.2 PKI Portal 72
3.4.3 HTTPS Support 74
3.4.4 Key Distribution Service 74
3.4.4.1 Key Distribution for Terminal to Remote Device Usage 74
3.4.4.2 Key Distribution for UICC to Terminal Usage 77
3.5 Other Architectural Issues 79
3.5.1 Access Control Mechanisms in GAA 79
3.5.1.1 Local Policy Enforcement in the BSF 80
3.5.1.2 USS usage for NAFs 81
3.5.2 Identities in GAA 82
3.5.3 Identity Privacy and Unlinkability 84
3.5.4 Usability and GAA 84
3.5.5 Split Terminal 87
3.5.6 Interoperator GAA: Using GAA Across Operator Boundaries 89
3.5.7 Security Considerations of GAA 91
3.6 Overview of 3GPP GAA Specifi cations 96
References 100
4 Applications Using Generic Authentication Architecture 105
4.1 Standardized Usage Scenarios 105
4.1.1 Authentication Using GAA 105
4.1.1.1 HTTP Digest Authentication 107
4.1.1.2 Pre-Shared Key TLS 111
4.1.1.3 Proxy Mode Authentication 112
4.1.1.4 Referrer Mode Authentication 116
4.1.2 Broadcast Mobile TV Service 119
4.1.2.1 Security Goals 123
4.1.2.2 Service Architecture 123
4.1.2.3 Message Flow Example 126
4.1.2.4 Tracing Source of Leaked Keys 130
4.1.3 Further Standardized Usage Scenarios 131
4.2 Additional Usage Scenarios 135
4.2.1 Secure Enterprise Login 136
4.2.2 Personalization for Payments and Securing Public
Transport Tickets 138
4.2.3 Secure Messaging in Delay and Disruption-prone Environments 140
4.2.4 Terminal to Terminal Security 141
Contents vii
4.2.5 Transitive Trust in IP Multimedia Subsystems (IMS) 144
References 148
5 Guidance for Deploying GAA 153
5.1 Integration with Application Servers 153
5.1.1 Introduction 153
5.1.2 Username / Password Replacement 154
5.1.3 NAF Library 155
5.1.3.1 Apache Web Server 156
5.1.3.2 J2EE Servers 157
5.1.3.3 Direct Usage of NAF Library 158
5.1.4 Web Services Direct Usage 159
5.2 Integration with OS Security 159
5.2.1 Threats for GAA Implementations in Open Platform UEs 160
5.2.2 Access Control Requirements 161
5.2.3 Basic Access Control in Practice: Integration in the Series 60 Platform 162
5.2.4 Extended Access Control: Design Options 163
5.2.5 Other Platforms 165
5.3 Integration with Identity Management Systems 166
5.3.1 Introduction 166
5.3.2 GAA Interworking with Liberty ID-FF 167
5.4 Integration of GAA into Mobile Networks 170
5.4.1 Integration of HLR into GAA 170
5.4.2 Key Lifetime Setting in BSF 173
5.4.3 Usage of SIM Cards in GAA (2G GBA) 175
5.4.4 Charging and GAA 177
5.4.5 GAA Integration into Large Networks 178
References 180
6 Future Trends 183
6.1 Standardization Outlook 183
6.1.1 GBA Push 183
6.1.2 GAA User Privacy 185
6.1.3 GAA in Evolved Packet Systems (EPSs) and Mobile IP (MIP) 187
6.2 Outlook for GAA 189
References 192
Terminology and Abbreviations 193
Index 201
Preface
Like many useful and successful systems, the Internet was not designed with security
in mind. Consequently, authentication on the Internet has been a vexing problem
ever since it was opened up to the larger public in the early 1990s. The fact that most
computers on the Internet are general-purpose devices has made this problem more
acute. Peter Steiner’s famous New Yorker cartoon with the caption ‘On the Internet,
nobody knows you are a dog’ continues to remain apt. However, there is an existing
useful and successful system that has struck the right balance among security, cost,
and usability: this is the worldwide cellular authentication infrastructure. This is the
infrastructure that allows a mobile network subscriber to travel halfway across the
world, have the local mobile network operator authenticate the subscriber, provide
cellular services, and subsequently charge him for those services. Naturally, many
people have wondered whether it is possible to use this large-scale infrastructure to
secure services on the Internet. Already in the late 1990s, there were examples of
using short message service (SMS) messages to pay for soda on a vending machine.
These are ad hoc means of bootstrapping security for new applications from the
existing cellular security infrastructure.
Back in 2000, we started to think about designing a systematic approach to bootstrap cellular authentication for Mobile and Internet Services. What began as a small
Nokia Research Center project grew into a standardization work item in 3
tion Partnership Project (3GPP). The fi rst version of the standardization of the basic
Generic Authentication Architecture (GAA) features was completed in 2006. Two
lead applications for GAA emerged: Multimedia Broadcast/Multicast Services specifi ed by 3GPP and Smart Card Profi le for broadcast Mobile TV, specifi ed by Open
Mobile Alliance.
There are a number of detailed specifi cation documents of GAA and its applications. In 2005, we published a paper titled ‘Extending cellular authentication as a
service’ at the First IEE International Conference on Commercialising Technology
rd
Genera-
x Preface
and Innovation. While GAA was being specifi ed, it was of primary interest to engineers involved in standardization. The existing standards documents were suffi cient
to meet the needs of this group.
In the last two years, several new groups of people have become interested in
GAA, including technical architects, software developers, executive decision makers,
and academic researchers. So far, there has been no single source for a comprehensive, yet readable treatment of GAA, which will present the technology in a form
that is accessible to these groups of people. Our desire in writing this book is to
address this gap.
Deployment of broadcast Mobile TV is expected to begin in the latter half of 2008.
We expect this will introduce GAA to more people who would want to learn more
about the technology. We hope that this book will help them.
Many people helped along the way to take GAA where it is today. Several colleagues at Nokia Research Center contributed to the NRC GAIN project where we
conceived and did much of the early work. Standardization delegates from various
companies took active roles in developing GAA and its applications, not only in
3GPP SA3 working group, but also in other fora. Several people in Nokia and other
companies were instrumental in transforming this technology from research to
product. Our sincerest thanks to all of them; without their hard work, we would not
have had the possibility to write this book.
Acknowledgements
3GPPTM TSs and TRs are the property of ARIB, ATIS, ETSI, CCSA, TTA and TTC,
who jointly own the copyright in them. They are subject to further modifi cations and
are therefore provided ‘as is’ for information purposes only. Further use is strictly
prohibited.
All images of Nokia devices are reproduced with the kind permission of Nokia.
1
Introduction
Over the last few decades, information technology has changed the world in two
major ways. The fi rst development is computerization. Computers have gradually
entered into almost every walk of life. Many services that used to require interaction
with humans are now provided by computers. When you withdraw money from your
bank account, or look for a book in the library, or check in at the airport, chances
are that you are interacting with computer systems hosting these services.
The second development is the immense and increasing popularity of an open
network of interconnecting computers, the Internet. Access to computerized and
automated services now takes place over this open network: when you use online
banking to make payments from your bank account, or order books from an online
bookstore, or browse the online photo albums of your friends, you are using the
Internet, as well as a variety of communication links to access the Internet.
In this chapter, we will discuss what is needed to secure the access to appli cations and services over open networks, what the primary diffi culty in achieving
security is, and why Generic Authentication Architecture (GAA) helps solve this
problem. We will also outline how this book is structured and how to go about
reading it.
1.1 Authenticated Key Agreement
Although the nature of accessing services has changed, many of these services
require some form of controlled access: for example, only you should be able
Cellular Authentication for Mobile and Internet Services
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg, Pekka Laitinen and N. Asokan
© 2008 John Wiley & Sons, Ltd
2 Cellular Authentication for Mobile and Internet Services
to make payments from your bank account. Usually, controlling access to services
is contingent on identifying who is requesting access and verifying the
requestor’s identity. In other words, the serving computer has to authenticate the
requestor.
In a closed network, like the plain old telephone system, authentication can be
implicit based on the presumed physical security of the network. But in an open
network like the Internet, physical security is not relevant – it is easy to claim any
identity towards a distant server. Worse still, it is easy to pretend to be a distant server
towards an unsuspecting client (for example, using IP address spoofi ng). Therefore,
we need to make use of cryptographic techniques for mutual authentication in order
to have suffi cient trust in the authentication process.
In open networks, authenticating the parties at the beginning of a communication
session is not suffi cient: An attacker may wait for authentication to complete and
then hijack the session by inserting, modifying or deleting the messages being
exchanged. To prevent this, the authentication process should also establish session
keys which can be used to guarantee the integrity of the entire communication
session.
In some services, the messages exchanged may need to be private. For example,
suppose you have an online photo album accessible only to family and friends. When
a friend is legitimately viewing the pictures on your album, the information has to
travel from the album server to your friend’s browser. It may traverse several communication links with varying levels of physical security. For example, your friend’s
computer may be connected to her access router over an open wireless link. You do
not want anyone eavesdropping along the way to be able to see your pictures. Cryptographic techniques for encryption can protect the messages while en route. Session
keys established during the initial authentication can be used for encrypting messages
exchanged during the session.
The process of mutual authentication and session key agreement is known as
authenticated key agreement.
1.2 The Challenge in Authenticated Key Agreement
Mechanisms and protocols for performing authenticated key agreement are well
known. For example, every time you access a protected web server, your browser
and the web server engage in the Transport Layer Security (TLS) handshake protocol
for authenticating the server and agreeing on a session key. The challenge in the
authentication is in the task of initializing the necessary credentials at the parties
involved in the authentication.
Consider what typically happens when you enrol into the authentication system
in the bank. You have to visit the bank in person, and possibly show some photo
identifi cation to open an account and provide a mailing address. The bank will then
Introduction 3
send you the credentials needed to access the bank account, for example, a bank card
and the personal identifi cation number (PIN) in separate mails. The process costs
time and money. One approach to reduce the cost of initialization is to relax the
expected level of security and usability. This is the approach taken by popular free
e-mail services: initialization is done by the user visiting a signup page and choosing
a username and setting a password. The user ends up using the same password for
many different services or puts up with the inconvenience of remembering many
different passwords. This may in turn cause that users are more frequently calling
the help desk, or a special password recovery tool is required, which also introduces
costs to the service provider.
An alternative approach is to bootstrap the needed credentials from an existing
security infrastructure. One such security infrastructure is the cellular security
infrastructure. The cellular security infrastructure has several characteristics that
make it a particularly attractive infrastructure to bootstrap security for applications
from.
The fi rst and foremost characteristic is its scalability. The Global System for
Mobile Communications (GSM) and Universal Mobile Telecommunications System
(UMTS) infrastructure consists of hundreds of participating mobile operators and
over two billion subscribers worldwide. Most mobile operators have roaming and
billing agreements with many other operators. Once you enrol as a GSM / UMTS
subscriber with a local operator in your home country, you will be able to authenticate
to many mobile operators, and use their networks to make phone calls or send and
receive messages.
The second characteristic is its ease-of-use. Cellular authentication is an example
of security that remains under the hood and just works. Users are not required to
perform any verifi cation or understand technical security concepts.
The third characteristic is its level of security. Authentication in cellular
systems is based on the possession of smart cards. Even though some of the
cryptographic algorithms in earlier versions of GSM have been broken, the entire
system has stood the test of time. GSM / UMTS security architecture is beginning
to be acknowledged as an example of the principle of ‘good enough’ security
of striking the right balance among cost-effectiveness, security and usability
[Sandhu03].
GAA consists of a set of specifi cations that describe how the cellular security
infrastructure can be used to provide a general-purpose authentication service for
applications and services. It has been standardized both in the 3
ship Project (3GPP) and its North American counterpart the 3
rd
Generation Partner-
rd
Generation Partnership Project 2 (3GPP2). Deployment of GAA in mobile devices and mobile networks
is expected to start in 2008.
The GAA concept is illustrated in Figure 1.1. GAA is a generic architecture for
mutual authentication and key agreement (AKA). Its fundamental building block is
Generic Bootstrapping Architecture (GBA). GBA enables automatic provisioning of
4 Cellular Authentication for Mobile and Internet Services
Subscribers
databases
GBA
HTTPS
Application
server
Mobile
terminal
certificates
Key
Center
Authentication/Key agreement
Figure 1.1. Generic Authentication Architecture (GAA) concept
shared keys between the mobile terminal and an application server (provided that
the user has a valid subscription
1
to cellular network services).
Other GAA constituents are built on top of GBA (new GAA building blocks con-
tinue to be specifi ed):
Support for subscriber certifi cates (SSC) specifi es procedures for the registration
•
of user’s public keys. Those procedures are authenticated with GBA.
Access to application servers with HTTPS specifi es how to use shared keys
•
created with GBA in conjunction with server-authenticated HTTPS to establish
secure and mutually authenticated HTTP communication between mobile terminal
and application server.
Key Centre enables creation of keys shared between terminals.
•
Broadcast mobile television and Multimedia Broadcast/Multicast Service (MBMS),
in which encrypted content is wirelessly broadcast, or multicast, are the lead applications driving the deployment of GAA. In those applications, the delivery of service
keys that are needed to decrypt the received content is secured with GAA. This makes
valid cellular subscription a prerequisite for, e.g., watching mobile television programs. Also, when generating charges for mobile television and MBMS, the person’s
cellular identity, which is verifi ed with GAA, is used.
1
Valid subscription implies that the mobile terminal and subscriber’s databases have a copy of shared
key that is used in cellular authentication.
Introduction 5
1.3 How to Read this Book?
Our goal in writing this book is to explain what GAA is and how it can be used. We
have four different types of readers in mind:
Developers are software designers who design and implement new applications
•
and services. We show how developers can make their application software use
GAA for authentication.
Architects are technical experts who design protocols and systems. We explain
•
the GAA concepts and technical details and show examples of how GAA is integrated into existing protocols so that architects can determine if and how GAA
could be used to solve the authentication needs of the systems they are
designing.
Executives are decision makers in companies who need to fi gure out whether need
•
to deploy GAA. We provide a general overview of GAA and brief analyses of its
benefi ts and tradeoffs that can serve as background materials for decision
making.
Academics are university professors, researchers and students studying computer
•
science or communication systems. We explain the principles and technical details
in the design of GAA that can serve as starting points for academics interested in
analyzing and evaluating GAA, comparing it to other authentication systems, and
designing authentication systems for the future.
The chapters are arranged in the logical order in which we recommend the reader to
proceed. Table 1.1 indicates which sections are likely to be of interest to different
types of readers.
Table 1.1. How to read this book
Section Developer Architect Executive Academic
1. Introduction
1.1 Authenticated Key Agreement
1.2 The Challenge in Authenticated
Key Agreement
1.3 How to Read this Book?
2. Classical Approaches
2.1 Existing Mobile Security
Solutions
2.2 General-Purpose Approaches
2.3 Requirements for GAA
✓✓✓ ✓
✓✓✓ ✓
✓✓✓ ✓
✓✓ ✓
✓✓
✓✓✓ ✓
6 Cellular Authentication for Mobile and Internet Services
Table 1.1. (continued)
Section Developer Architect Executive Academic
3. Generic Authentication
Architecture (GAA)
3.1 Overview of GAA
3.2 Foundations of GAA – Generic
Bootstrapping Architecture
(GBA)
3.3 Variations of GBA
3.4 Building Blocks of GAA
3.5 Other Architectural Issues
3.6 Overview of 3GPP GAA
Specifi cations
4. Applications Using GAA
4.1 Standardized Usage Scenarios
(incl. Broadcast Mobile TV)
4.2 Additional Usage Scenarios
5. Guidance for Deploying GAA
5.1 Integration with Application
Servers
5.2 Integration with OS Security
5.3 Integration with ID
Management Systems
5.4 Integration of GAA into Mobile
Networks
✓✓✓ ✓
✓✓ ✓
✓✓
✓✓
✓✓
✓✓
✓✓✓
✓✓✓
✓✓
✓✓
✓✓✓ ✓
✓
6. Future Trends
Terminology and Abbreviations
✓✓✓ ✓
✓✓✓ ✓
Reference
[Sandhu03] Ravi S. Sandhu: Good-Enough Security: Toward a Pragmatic Business-Driven Discipline.
IEEE Internet Computing 7(1): 66–68 (2003).
2
Classical Approaches to Authentication and Key Agreement
In this chapter, we look at existing approaches to AKA in order to set the stage for
discussing the motivation for and the design of GAA. We begin by examining the
security architectures in mobile networks and then take a broader look at other more
general-purpose AKA mechanisms. We then identify requirements for bootstrapping
an authentication architecture from existing infrastructures.
2.1 Existing Mobile Security Solutions
In the last two decades, several different mobile network architectures have been
designed and deployed. By far, the most widespread have been the UMTS and especially its predecessor GSM infrastructures. Therefore, in this section, we focus on
the security of these infrastructures.
2.1.1 UMTS Security Infrastructure
As we pointed out in Chapter 1, there are many compelling reasons for bootstrapping
credentials from the existing, widely used, cellular security infrastructures. Before
we go on to describe the design and details of the GAA, let us briefl y describe the
UMTS security infrastructure and the associated terminology in order to motivate
the need and the requirements for GAA.
Cellular Authentication for Mobile and Internet Services
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg, Pekka Laitinen and N. Asokan
© 2008 John Wiley & Sons, Ltd
8 Cellular Authentication for Mobile and Internet Services
One of the cornerstones of GAA is the HTTP Digest authentication using
AKA protocol (HTTP Digest AKA) [RFC3310]. The UMTS AKA protocol (AKA)
has been originally designed for the purpose of securing subscriber access to
cellular networks, more specifi cally, Universal Mobile Telecommunication System
(UMTS) or 3G networks [Niemi07], [TS33.102]. The authentication part of the AKA
protocol of the UMTS security is needed to verify the subscriber’s identity while
key agreement is used for generating keys that are subsequently used in encryption
of traffi c in the radio network and also for protecting integrity of the signalling
messages.
These security features are applied for all user data. Therefore, all applications
and services used over the cellular access automatically gain a certain basic security
level. Because the security protocols and cryptographic algorithms used in UMTS
networks are up-to-date with the state of the art in the area, this basic security level
is fairly good in many respects. For example, 128-bit keys are used in the cryptographic algorithms and all details of these algorithms are publicly known, and therefore, open for public domain scrutiny as well.
In the rest of this subsection, we give a brief description of the most essential
security features in UMTS infrastructure. The UMTS infrastructure consists of a
number of mobile operators with UMTS networks. For each subscriber, there is a
home network run by the operator with whom the subscriber entered into a business
relationship, for example, by opening a billing relationship or purchasing a prepaid
subscription. Each subscriber has a unique identifi er known as the International
Mobile Subscriber Identity (IMSI).
Cutting a few corners, the security architecture of GSM networks can be viewed
as a subset of that of UMTS networks.
In Figure 2.1, we have six different entities, each of which can exist in many
instances in a real network. There is a fair amount of symmetry in this security
architecture. We continue by describing UMTS security architecture via these symmetries, fi ve of them in total.
The fi rst symmetry is on the generation of the keys and other authentication
data.
Beginning from the top of Figure 2.1, the Authentication Center (AuC) is the
network element responsible for storing the permanent cryptographic keys bound to
the subscription and computing the session keys and the authentication data. The
AuC is usually implemented as an integral part of Home Location Register (HLR)
or in latter releases of the 3GPP specifi cations Home Subscriber Server (HSS) which
is the main operator database, containing all subscriber data, including information
about the whereabouts of the subscriber. Often the HSS is implemented as an HLR
with extended functionality.
In the AuC calculations, the permanent key for a subscriber is denoted by K.
Another security-relevant parameter is the sequence number SQN
. As the name
AuC
already indicates, sequence numbers are constantly changing, in contrast to the
Classical Approaches to AKA 9
Home Network
Visited Network
VLR
User Equipment
K
AKA Algorithms
Authentication Vectors
CKCS, IK
RAND, AUTNRES
CS
Encryption and Integrity
Protection Algorithms
SQN
AuC
CKPS, IK
Secure
communication
AuC
SGSN
PS
RNC
Encryption and Integrity
Protection Algorithms
CKCS, IK
K SQN
AKA Algorithms
CS
USIM
CKPS, IK
PS
USIM
Figure 2.1. Summary of the UMTS access security features
ME
10 Cellular Authentication for Mobile and Internet Services
master key K. AKA algorithms are used to create a UMTS Authentication Vector
(AV), containing a quintuple of:
RAND: random 128-bit number generated by AuC
•
XRES: derived by a one-way function from K, RAND and SQN
•
CK: a session key that is also derived by a one way function from the same input
•
parameters
IK: another session key derived similarly
•
AUTN: an authentication token containing SQN
•
istrative fi eld AMF and a message authentication code (MAC) that protects the
integrity of the AV.
Moving next to the bottom, we fi nd the counterpart of the AuC on the user side:
UMTS Subscriber Identity Module (USIM). This is an application residing in a
special kind of smart card, the Universal Integrated Circuit Card (UICC). The technical representation of the subscription is the subscriber-specifi c shared master key K.
Thus, the master key K is stored permanently in the USIM, as well as in the AuC.
If two of the AV parameters, RAND and AUTN, are given as input parameters to
the USIM, very similar set of algorithms, compared to those used in the AuC, are
used to calculate CK, IK and another parameter RES that should be identical to
XRES if everything has been done correctly. The subscriber’s device, called Mobile
Equipment (ME) is capable of interfacing with the UICC.
Next, we describe the second symmetry: this is related to the architecture of the
UMTS as a whole.
There are two different domains that act independently in many respects. In Figure
2.1, there are two elements on the second layer from the top:
in encrypted form, an admin-
AuC
AuC
Visitor Location Register (VLR) belongs to the Circuit-Switched (CS) domain
•
while the
Serving GPRS Support Node (SGSN) belongs to the Packet-Switched (PS) domain.
•
The main service provided by the CS domain (resp. PS domain) is the voice calls
(resp. data transfer). Both VLR and SGSN fetch authentication vectors from the
HLR/AuC node whenever a subscriber has attached to them and there is need for
authentication of the subscriber. The session keys in these AVs for each domain are
marked by the subscripts ‘CS’ and ‘PS’.
Our third symmetry is related to the authentication: the network wants to authen-
ticate the subscriber. On the other hand, it is also in the subscriber’s interest to
authenticate the network to avoid, for example, false base-station attacks.
For each of the domains, the authentication of the subscriber is carried out in an
identical manner. First, VLR (resp. SGSN) sends the two parameters RAND and
AUTN to the USIM. (There are several network elements on the path but they are
Classical Approaches to AKA 11
irrelevant in this context.) The USIM checks fi rst that the Message Authentication
Code (MAC) in the AUTN is correct. Next, the USIM checks that it has not seen
the sequence number hidden in the AUTN before. If these two checks lead to a positive end result, it is concluded, fi rst, that the parameters have truly been generated
in the AuC and, second, that the parameters are used fi rst time in this particular
authentication (this is usually called protection against replay attacks). What follows
is that the USIM sends the calculated response parameter RES back to the VLR
(resp. SGSN). A comparison with the parameter XRES concludes the authentication
procedure.
The generated session keys lead us to the fourth symmetry.
The VLR (resp. SGSN) transfers the session keys CK and IK to the Radio Network
Controller (RNC). Similarly, the USIM provides identical keys to the ME. Note that
in the case of successful authentication, the parameters RES and XRES have found
to be identical and there is a great probability that the session keys on both sides are
identical as well.
Our fi fth symmetry is between the usage of the session keys CK and IK.
Indeed, CK is used for confi dentiality protection purposes while the IK is used for
integrity protection purposes. In addition to these session keys, appropriate cryptographic algorithms are needed here. In UMTS Release 99 specifi cations, one confi dentiality algorithm and one integrity algorithm were defi ned [TS35.201]. Both
algorithms are based on the same block cipher cryptographic algorithm called
KASUMI [TS35.202]. KASUMI uses 128-bit keys and a block size of 64 bits. One
difference between the confi dentiality and integrity protection mechanisms is that
the former is applied to both user traffi c and signalling traffi c, while the latter is only
used for signalling traffi c.
Next, we briefl y list the main differences between the Global System for Mobile
communication (GSM) access security architecture and the UMTS access security
architecture.
Our fi rst symmetry exists also for the GSM access parameters. Instead of the
5-parameter long AV, only three parameters are in use:
random challenge (RAND),
•
(expected) response (now called SRES) and
•
the cipher key (now called Kc).
•
The counterpart of the AuC on the user side is called the Subscriber Identity
Module (SIM). The SIM is a smart card itself. The second symmetry is visible also
in GSM. Actually, the UMTS core network architecture is inherited from the GSM
and its packet-switched extension, GPRS. The third symmetry does not exist in
GSM / GPRS: in these systems, only authentication of the subscriber is carried out.
The fourth symmetry is visible in GSM and GPRS but there are differences, both
compared to the UMTS system and also between the solutions of GSM and GPRS.
12 Cellular Authentication for Mobile and Internet Services
In GSM, the cipher key Kc is transferred all the way to the Base Station (BS) while,
on the other hand, in GPRS, the cipher key stays in the SGSN, it is only transferred
to the ciphering function. The fi fth symmetry is not applicable to GSM since there
is no separate integrity protection mechanism in GSM (or in GPRS).
The ciphering algorithms are also different in GSM / GPRS compared to those
used in UMTS. The most notable difference is length of the key: the key Kc of GSM
/ GPRS has a length of 64 bits. The specifi cations of the fi rst two versions of both
GSM and GPRS encryption algorithms (A5/1 and A5/2 for GSM, GPRS Encryption
Algorithm (GEA) versions, GEA1 and GEA2, for GPRS) have been kept private and
available only to the mobile operators and to vendors of the infrastructure elements
and terminals. There are also KASUMI-based public version A5/3 and GEA3 available nowadays which address some shortcomings of the previous algorithms.
Some other security features of UMTS and GSM / GPRS relevant for the rest of
the book are briefl y described in the balance of this section.
The user identity is protected by the usage of temporary identities. As soon as the
permanent identity of the subscriber, the IMSI (International Mobile Subscriber
Identity), is known to the network (i.e., VLR or SGSN), the network begins to use
a temporary identity, TMSI (Temporary Mobile Subscriber Identity) instead. The
TMSI is sent to the User Equipment (UE) over the encrypted channel. The UE is a
mobile terminal with a smart card inserted. Whenever the TMSI has been used by
the UE to, for example, set up a call, receiving a call or location update, the network
provides a new TMSI for the UE. The TMSI mechanism does not give protection of
user identity confi dentiality against active attacks because the attacker can always
pretend to be a network element that has lost the TMSI, and thus, requests the permanent identity from the UE. But the TMSI protects against passive attacks like
eavesdropping.
The session keys CK, IK and Kc may be used for several sessions. In other words,
authentication is not required for each session. There is no lifetime associated to the
keys, though. In UMTS, there is a possibility to restrict how much of data is protected
by the same session key but this amount is typically very high and the protection is
intended for extremely long sessions only. The reason for omission of the lifetime
is that in case a subscription itself expires, information about this is carried to the
serving network that can technically then simply cut down the session.
In Figure 2.2 we show the information fl ow related to the AKA protocol.
Figure 2.2 shows the exchanges involved in the UMTS AKA protocol. Subscribers
access services by connecting to a serving network. The serving network depends
on the subscriber’s present location: when he is at home, the serving network is
the same as the home network; when he is travelling elsewhere, it is usually a
network of a different operator who has a roaming agreement with the home network
operator.
The subscriber’s USIM and the Home Network share a long-term key K and
maintain a running sequence number SQN.
Classical Approaches to AKA 13
K, SQN
RAND K
RES SQN’ CK
AUTN
IK
Check if SQN’ is big enough
UE Serving Network
IMSI/TMSI
IMSI
<RAND, AUTN, XRES, IK,CK>
RES
Check if RES = XRES
AKA Credential Fetching Protocol
Home Network
IMSI K
… …
… …
RAND
XRES
HSS
K
AUTN CK
SQN
…
…
SQN
IK
Figure 2.2. UMTS authentication and key agreement (AKA) protocol
1. The authentication procedure is triggered by the UE sending its permanent identity to a server in the serving network (home or visited network). The fi rst time
UE connects to a serving network it has to use its true IMSI as the identifi er. But
on successful authentication, the serving network may provide a temporary identifi er TMSI. The serving network maintains the mapping of TMSIs to IMSIs.
2. The serving network forwards the IMSI to the home network which chooses a
random challenge RAND and looks up K and the current SQN for IMSI. RAND,
K and SQN are fed into a set of cryptographic algorithms to produce four values:
an authenticator AUTN to prove that RAND was sent by the home network, an
expected response XRES for the given RAND and two cryptographic session keys
CK and IK to be used to protect confi dentiality and integrity of subsequent communication between the UE and the serving network.
3. The Home Network sends these four values along with the corresponding RAND
to the serving network.
4. The serving network forwards RAND and AUTN to UE.
5. The UE’s USIM takes RAND, AUTN and K as input to the same set of cryptographic algorithms as in step 2 to produce a response RES, the sequence number
SQN’ used by the Home Network, and the two keys IK and CK.
14 Cellular Authentication for Mobile and Internet Services
6. The USIM checks if the value SQN’ is big enough given its own sequence number
value SQN. If so, it accepts the authentication and sends RES back to the serving
network. If RES is the same as XRES, the serving network accepts the authentication as well.
Thus, AKA provides mutual authentication between the subscriber and the network
operator. It also results in temporary session keys shared between the UE and the
serving network. The above is an extremely simplifi ed overview of the UMTS security architecture intended to present only those aspects relevant for eliciting the
requirements for GAA. Readers interested in a comprehensive description of UMTS
security architecture should consult [Niemi07].
In normal AKA usage, the UE sends and receives AKA message over its radio
interfaces. But there is nothing inherent in AKA that binds it to UMTS radio layer.
Therefore, in course of time, two new transports for AKA signalling were specifi ed.
The fi rst is HTTP Digest AKA [RFC3310]. HTTP Digest AKA defi nes a new
‘algorithm’ for the HTTP Digest authentication scheme [RFC2617] by mapping AKA
parameters to the information elements required by HTTP Digest authentication.
Essentially, HTTP Digest AKA encodes the RAND and AUTN parameters into the
nonce fi eld of an HTTP Unauthorized response from the server; the client extracts
RAND and AUTN, applies the normal AKA processing, and uses the resulting RES
parameter of AKA as the ‘password’ for HTTP Digest Authentication, thereby turning
HTTP Digest into a one-time password scheme. The resulting IK and CK can be
used to protect the subsequent communication between the client and the server.
Usually, HTTP Digest authentication is used in conjunction with a server-authenticated TLS tunnel so that subsequent communication between the server and the client
is protected by the TLS session key. However, HTTP Digest AKA authentication
must not be used in this manner because an attacker pretending to be a serving
network could easily get RES from a UE using regular AKA (see [Asokan05] for
details of this type of man-in-the-middle attacks).
The second alternative transport for AKA is over Extensible Authentication Protocol (EAP) defi ned in the EAP-AKA RFC [RFC4187]. This specifi cation defi nes a
new EAP authentication method to transport AKA signalling. This allows AKA to
be used in applications that support EAP, usually for access authentication, e.g., in
WiFi networks.
2.1.2 Issues in Securing Services with Radio Layer Security
Many service providers have concluded that the basic security level provided by the
radio layer (i.e., the link layer) is suffi cient for their services that are provided on
higher layers. From the point of view of confi dentiality, this conclusion may be well
justifi ed in many cases. Indeed, the radio interface is the one that is most vulnerable
to the eavesdroppers. Encryption on the radio layer provides protection against such
Classical Approaches to AKA 15
attackers for all data in higher layers as well. On the other hand, from the point of
view of authentication, the situation is more complicated.
This is because the well-accepted layered approach in communications (e.g.,
OSI 7-layer model, IETF 5-layer model) does not fi t optimally with authentication.
The reason for this stems from the following facts:
Authentication is always done in relation to a certain identity, i.e., verifying that
•
identity.
The layers use different identities (e.g., MAC address, IP address, Session Initia-
•
tion Protocol (SIP) identity).
Therefore, we have to choose one of the following approaches:
(a) execute authentication in many layers (which obviously adds complexity to the
system);
(b) let some identities be unauthenticated (which implies that certain threats cannot
be addressed at all); and
(c) bind different identities together.
The last solution has also drawbacks:
The binding has to be done securely which adds the need for a new security feature
•
to the system. Also, the binding may change frequently and cause quite some load
to the systems. Network Address Translation (NAT)
complexity if used together with identity binding for IP addresses.
The binding causes a violation against the core idea of the layered communication
•
model.
In 3GPP systems, all of these approaches are in use, e.g., in IP Multimedia Core
Network Subsystem (IMS):
Full IMS with IP Multimedia Subsystem Identity Module (ISIM) application on
•
the UICC is an example of approach (a) [TS31.103], [TS33.203]. This is a very
secure and scalable approach; the largest drawback is that the penetration of ISIM
applications on the UICC is still limited and the network support for this is not
that wide.
HTTP digest authentication over insecure access. This has been specifi ed as an
•
optional mechanism for fi xed networks in ETSI TISPAN. This is an easy, but not
very secure, approach. It is an example of approach (b) in the sense that access-
level identities are not assumed to be authenticated.
1
http://en.wikipedia.org/wiki/Network_address_translation
1
servers may cause additional
16 Cellular Authentication for Mobile and Internet Services
Early IMS security [TR33.978], i.e., IP address binding is an example of approach
•
(c). This approach works, but has some scalability issues, when a large range of
users using a large set of service (potentially with NATs deployed in the system).
Also IP address spoofi ng may become an issue with this approach. Frequent IP
address changes cause additional complexity and load to this approach.
Network Attachment Subsystem (NASS)-IMS bundled authentication, i.e., binding
•
to the calling line identifi er [TS33.203] is another example of approach (c). This
approach works well enough for simple use cases, but does not support mobility.
If mobility or several users behind one line should be supported, then additional
features or functionalities are required.
2.2 General-Purpose Approaches to Authentication and Key Management
2.2.1 Public Key Infrastructure (PKI)
Public key cryptography was invented in the mid-1970s [Diffi e76]. Two groundbreaking concepts were introduced:
(1) Separation of keys used for encryption and decryption. As a consequence, one
of the keys could be made public without revealing the other key.
(2) Digital signature. It became possible to verify authenticity of a completely digital
document in a way that also enabled unforgeability: only the source could have
created the document with the digital signature.
It was fi rst thought that concept (1) would make key management of a big system
very easy. Every entity in the system could have its own private key, stored and
protected in one single entity. The corresponding public key could be made available
for every other entity in the system by including it in an appropriate database. Soon
it was observed, however, that when the system becomes even bigger and less centrally managed, the database solution for managing public keys does not scale
anymore. It becomes diffi cult to guarantee access to the database in a secure manner,
and, on the other hand, it becomes, more and more diffi cult to guarantee that the
public keys in the database are authentic themselves.
Fortunately, concept (2) provided solutions to these problems. Public keys could
be digitally signed by an authority, thus creating a certifi cate. Then there is no need
to have a secure online access to a centralized authentic database: if you want to
send a message to a person, you could fi nd the digitally signed certifi cate from
whatever source (e.g., from the Internet).
However, the issue is not so straightforward: verifying of digital signatures itself
requires authentic keys. In the setting described above, the sender of the message
Classical Approaches to AKA 17
has to have access to the authentic verifi cation key of the authority. Otherwise, it is
not possible to check the digital signature in the certifi cate, and in consequence, it
would not be possible to trust the public key in the certifi cate.
It may seem that we are back to square one: in order to be able to fetch securely
a public key of the receiver, we fi rst have to fetch securely the public key of the
authority. Luckily, the number of authorities is much smaller than the number of all
entities in the system, and therefore, we have converted a big scale issue to a much
smaller scale issue. As a solution to the remaining smaller scale issue, we iterate the
same process: we have a master authority that signs the public signature key of the
lower-level authority. In this way, we have created a chain of certifi cates.
Our wish would be that the number of master authorities would be so small that
the corresponding public keys could be installed to the system entities securely in
some direct manner, for instance, at the same time when the public key cryptographic
functions are installed. In some cases, our wish does not materialize, and we have
to add further layers of authorities to the system. All these authorities constitute the
public key infrastructure. In addition to Certifi cate Authorities (CA), the PKI typi-
cally needs also Registration Authorities (RA) for the purpose of introducing new
entities to the system: authenticating users physically by the means of, e.g., checking
their identity cards or driver’s licence.
The PKI constitutes a generic-purpose authentication and key management system,
and in principle, it would suit for mobile systems as well. One challenge with the
mobile systems is the fact that these systems tend to be global, putting up the requirement for a global PKI. Building a global infrastructure of any sort is a big effort, not
only technically and fi nancially but also politically. (See Figure 2.3.)
One of the biggest existing use case for PKI stems from the use of certifi cates
in the Transport Layer Security (TLS) protocol [RFC2246]. It has been possible to
issue certifi cates to a large number of companies and servers. What is still largely
missing at the time of writing is a wide base of client certifi cates. TLS supports client
User identity
information
RA
Validation of user
identity
Verification of user
CA
Issuing of
certificate
User
certificate
Service
Usage of
cryptographic keys
and certificate
Figure 2.3. An example of Public Key Infrastructure (PKI)
18 Cellular Authentication for Mobile and Internet Services
certifi cates but, on the other hand, a server certifi cate is suffi cient to put up a TLS
session. In a later section, we describe how GAA could be used to support client or
subscriber certifi cates.
In the wireless area, the largest initiative to build a PKI has been Wireless PKI
(WPKI), specifi ed originally in the Wireless Application Protocol (WAP) Forum, and
later continued in the Open Mobile Alliance (OMA) (see [OMAWPKI]). An important element of WPKI is WIM (Wireless Identity Module) (see [OMAWIM]).
2.2.2 Passwords
The dominant approach in authentication of applications in the Internet is to use
passwords. Each user has a username and a password that is assumed to be known
only by the user. The password could be changed by regular time intervals but is
also often the case that the password is never changed. From security point of view,
it would be best to use one-time passwords. Obviously, they have the disadvantage
that there has to be a way of securely transferring one password per session to the
user. One-time passwords are typically used in certain security-critical applications
where authentication is needed typically in the frequency of daily or more seldom.
Internet banking is an example of such application. Of course, user cannot memorize
one-time passwords, which implies that the list of unused one-time passwords has
to be stored securely while still kept handily available.
If the user would need to send over the password as such every time she wants to
access the service, an eavesdropper anyway on the path from the user to the server
would have plenty of opportunities to snatch the password. That would enable the
attacker to masquerade as the user against the server. Obviously, in the wireless
environment, an attacker would have easy access to the path but there are typically
also vulnerable points on the network interfaces. In order to protect against this kind
of attacks, what is usually sent over is not the password itself but something derived
from it. Some time-varying or random parameter needs to be added to the derivation,
otherwise, the eavesdropper would just need to capture the data derived from the
password and use that for masquerade purposes.
The dominant mechanism user for username-password is the HTML form-based
authentication where the web page itself contain username and password fi elds. The
dominant protocol used for username-password mechanism in the Internet is called
HTTP Basic and Digest [RFC2617]. The difference between the two is that HTML
forms are carried in the HTTP payload while the HTTP Basic and Digest use the
HTTP headers to carry the username-password data. With HTML forms, the user
types in the username and password and they are sent to the server. They are typically protected using https, i.e., SSL or TLS [RFC2246], in which the HTTP communication is conducted via encrypted secure channel. The difference between HTTP
Basic and Digest authentication is that in Basic, the username and password are sent
in the clear to the server (or actually base64 encoded), and Digest uses message
Classical Approaches to AKA 19
digests (i.e., MD5) to protect the password. Moreover, HTTP Digest authentication
is of ‘challenge-response’ type. The server is sending over a challenge in the form
of parameter called ‘nonce’. The response from the user must contain a parameter
‘response’ that contains a hash function value derived from the username, password
and nonce, together with some other parameters. It is worth noting that the server
does not have to store the password as such or actually it does not even have to know
it. It is enough that an intermediate value derived as well by a hash function from
the password and the username (together with some other parameters).
Later in the book we show how GBA could be used to support HTTP Digest.
2.2.3 Kerberos
There are also key general-purpose key management systems based on shared secret
keys. One of the most used systems is Kerberos, developed by MIT in the 1980s
(see [RFC4120]). It is supported by, e.g., all recent versions of Windows operating
system. Kerberos is based on a Key Distribution Center (KDC) that shares a permanent master key with each user of the system. It is also assumed that well-synchronized clocks are available for each user. These are needed to be able to provide
time-stamped tickets for users. These tickets can then be used as authentication
tokens in order to grant access to services.
One disadvantage of Kerberos stems from its dependency on the KDC that acts
as a centralized, trusted third party. This introduces similar issues as the centralized
CA approach. Fast-expiring tickets put high availability requirements on the KDC.
Availability of synchronized clocks is another constraint, especially in the mobile
environment.
2.2.4 Radio Layer and General Purpose Security Mechanisms
As hinted in earlier sections, before GAA, there had already been earlier attempts to
utilize the existing access security architecture for other purposes than cellular radio
access.
One approach is to use short message service (SMS) as an independent channel
to carry authentication data. For example, in order to get access to a service in the
Internet, a user could fi rst send a request over SMS to the number provided by
the service. By checking the phone number, the service would be able to identify the
user. As a next step, a one-time password could be sent to the UE, to be subsequently
used when accessing the service over the Internet, using, e.g., HTTP Digest protocol.
Note here that in case an attacker could spoof its phone number in the SMS, it would
still not receive the password because it would be routed to another UE (if anywhere).
It is also worth noting that the actual service could be accessed either by the same
UE over the cellular network or by another machine, e.g., a home PC, over a fi xed
broadband network.
20 Cellular Authentication for Mobile and Internet Services
Another approach was introduced for the purpose of securing access to Wireless
Local Area Networks (WLANs). The original idea was to take the SIM-based authentication protocol and embed that in the WLAN protocols somehow. In this approach,
Extensible Authentication Protocol (EAP) [RFC3748] plays a major role. It is a
protocol that supports various authentication methods and it can be run on top of
various link layer protocols, e.g., on top of IEEE 802 protocols. The SIM authentication mechanism has been introduced to EAP as a specifi c EAP method, called
EAP-SIM, in [RFC4186]. Similarly, UMTS AKA has been specifi ed as an EAP
method, called EAP-AKA, in [RFC4187].
Another approach was introduced for securing access to IMS. For the purpose of
the so-called full IMS security solution [TS33.203], the AKA protocol was embedded
into HTTP Digest protocol as an extension [RFC 3310]. This mechanism is also the
cornerstone of GAA.
In the full IMS security system keys generated during the AKA run are used for
securing SIP signalling messages. This is done by deriving IPsec Security Associations from the AKA keys and some other parameters. Then IPsec is used to protect
the confi dentiality and integrity of signalling messages between the terminal and the
fi rst IMS entity, an SIP server called Proxy CSCF.
2.3 Requirements for GAA
So far in this chapter, we have examined existing approaches for authentication. As
we pointed out in Chapter 1, there are many compelling reasons for bootstrapping
credentials from existing, widely used, authentication infrastructures. Before we go
on to describe the design of the GAA, let us consider desirable characteristics of a
general-purpose AKA architecture, especially when it is bootstrapped from an existing authentication infrastructure.
Generality: Many different types of applications and services must be able to use
GAA for authentication. For simplicity, let us call these GAA applications. For
example, broadcast Mobile TV with smart card profi le authentication that is specifi ed
by OMA BCAST group [OMASC] is a GAA application.
Application separation: Security guarantees of one GAA application must not
depend on the correct behaviour of other GAA applications. For example, suppose
there is a fl aw in the design or implementation of a GAA application protocol, and
this results in the exposure of secret data used by that application, this must have no
effect on the secret data used by other GAA applications. Similarly, a misconfi gured
application server or client may result in the exposure of secret data used by that
instance. This must have no effect on other servers or clients even if they are using
the same GAA application.
Access independence: Use of GAA must not depend on a particular access technology. For example, earlier in this chapter, we saw how SMS messages may be
Classical Approaches to AKA 21
used for bootstrapping authentication. This is an access-specifi c mechanism since
SMS messages can be sent and received only when a device is connected to the cellular access network.
Reuse: In order to maximize the benefi ts of bootstrapping, GAA should reuse
existing protocols and infrastructure wherever possible. It should also be extensible,
in that sense, that future applications can reuse GAA easily.
Protection of original infrastructure: A fl aw in the design, implementation or
confi guration of GAA or any GAA application must not harm security and operation
of the UMTS security infrastructure itself.
Control by home network: The home network operator is the entity that has a
business relationship with the subscriber. Therefore, the home network operator
should be able to set the policy what GAA applications are available to a given
subscriber.
In Chapter 3, we will discuss how those requirements are realized in practice.
References
[Asokan05] N. Asokan, Valtteri Niemi and Kaisa Nyberg, Man-in-the-middle in tunneled authentica-
tion protocols, Proceedings of 11th Cambridge Workshop on Security Protocols, Springer
Lecture Notes in Computer Science 3364 (2005), 28–41.
[Diffi e76] Whit Diffi e, Martin Hellman, New Directions in Cryptography, In IEEE Transactions
on Information Theory, 22:6 (644–654), November 1976. Available at http://ieeexplore.
ieee.org/xpls/abs_all.jsp?arnumber=1055638
[Niemi07] Valtteri Niemi, Kaisa Nyberg, UMTS Security, Wiley & Sons (2003).
[OMASC] Open Mobile Alliance (OMA), OMA-TS-BCAST_SvcCntProtection-V1_
0-20070529-C, Service and Content Protection for Mobile Broadcast Services Specifi ca-
tion, Candidate Version 1.0 – September 2007, http://www.openmobilealliance.org/
release_program/bcast_v1_0.html
[OMAWIM] Open Mobile Alliance (OMA), OMA-WAP-WIM-V1_1-20021024-C, Wireless Identity
Module (WIM), Part: Security, Version 1.1 – October 2002. Available at http://www.
openmobilealliance.org/release_program/wpki_v10.html
[OMAWPKI] Open Mobile Alliance (OMA), OMA-WPKI-V1_0-20040615-C, OMA Wireless Public
Key Infrastructure, Version 1.0 – June 2004. Available at http://www.openmobileal-
liance.org/release_program/wpki_v10.html
[RFC2246] Internet Engineering Task Force (IETF), The TLS Protocol Version 1.0, RFC 2246,
January 1999. Available at http://www.ietf.org/rfc/rfc2246.txt
[RFC2617] Internet Engineering Task Force (IETF), HTTP Authentication: Basic and Digest Access
Authentication, RFC 2617, June 1999. Available at http://www.ietf.org/rfc/rfc2617.txt
[RFC3310] Internet Engineering Task Force (IETF), Hypertext Transfer Protocol (HTTP) Digest
Authentication Using Authentication and Key Agreement (AKA), RFC 3310, September
2002. Available at http://www.ietf.org/rfc/rfc3310.txt
[RFC4120] Internet Engineering Task Force (IETF), The Kerberos Network Authentication Service
(v5), RFC 4120, July 2005. Available at http://www.ietf.org/rfc/rfc4120.txt
[RFC4186] Internet Engineering Task Force (IETF), Extensible Authentication Protocol Method for
Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-
SIM), RFC 4186, January 2006. Available at http://www.ietf.org/rfc/rfc4186.txt
22 Cellular Authentication for Mobile and Internet Services
[RFC4187] Internet Engineering Task Force (IETF), Extensible Authentication Protocol Method for
3rd Generation Authentication and Key Agreement (EAP-AKA), RFC 4187, January
2006. Available at http://www.ietf.org/rfc/rfc4187.txt
[TR33.978] 3rd Generation Partnership Project (3GPP), Technical Report TR 33.978, Security
Aspects of Early IP Multimedia Subsystem (IMS), Version 7.0.0 (2007). Available at
http://www.3gpp.org/
[TS31.103] 3rd Generation Partnership Project (3GPP), Technical Specifi cation TS 31.103, Charac-
teristics of the IP Multimedia Services Identity Module (ISIM) application, Version 7.1.0
(2006). Available at http://www.3gpp.org/
[TS33.203] 3rd Generation Partnership Project (3GPP), Technical Specifi cation TS 33.203, 3G
Security; Access Security for IP-based Services, Version 8.1.0 (2007). Available at
http://www.3gpp.org/
[TS33.102] 3rd Generation Partnership Project (3GPP), Technical Specifi cation TS 33.102, 3G
Security, Security Architecture, Version 7.1.0 (2006). Available at http://www.3gpp.
org/
[TS35.201] 3rd Generation Partnership Project (3GPP), Technical Specifi cation TS 55.201, Specifi -
cation of the 3GPP confi dentiality and integrity algorithms; Document 1: f8 and f9
specifi cation, Version 7.0.0 (2007). Available at http://www.3gpp.org/
[TS35.202] 3rd Generation Partnership Project (3GPP), Technical Specifi cation TS 55.202,
Specifi cation of the 3GPP confi dentiality and integrity algorithms; Document 2: Kasumi
specifi cation, Version 7.0.0 (2007). Available at http://www.3gpp.org/
3
Generic Authentication Architecture
3.1 Overview of Generic Authentication Architecture
In this chapter, we will present the overall picture of the design of GAA. We start
by describing how the requirements identifi ed in Section 2.3 infl uenced important
design decisions. An in-depth description of the technical details appears in the subsequent sections of this chapter.
3.1.1 Rationales for Design Decisions
The fi rst design decision is the type of credentials that should be bootstrapped from
the parent infrastructure.
The generality requirement states that the bootstrapped credentials should be
usable with a wide variety of applications. In GAA, the bootstrapped credential
is in the form of a transaction identifi er and a temporary shared secret key. This
part of GAA is called as the Generic Bootstrapping Architecture (GBA). In GBA, a
temporary shared session key is obtained by running the authentication protocol in
the parent infrastructure. In the case of UMTS networks, this protocol is the AKA
protocol (see [TS33.102] or [RFC3310]).
This session key can be used directly in any application which uses username/
password style of authentication. Alternately, it can be used to initialize other types
of credentials. For example, it can be used to enrol a public key of the subscriber to
an operator-run Public Key Infrastructure (PKI). The PKI can then issue a subscriber
certifi cate to be used with applications that support public-key authentication. Thus,
Cellular Authentication for Mobile and Internet Services
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg, Pekka Laitinen and N. Asokan
© 2008 John Wiley & Sons, Ltd
24 Cellular Authentication for Mobile and Internet Services
GBA constitutes the foundation of GAA, which consists of GBA and several other
forms of application authentication, built on top of GBA. Together they help meet
the generality requirement.
The access independence requirement implies that the bootstrapping procedure
must be the same regardless of the type of network currently being used by the
bootstrapping device. As we saw earlier, there are currently two ways to transport
the messages for UMTS AKA in an access-independent manner: using Digest AKA
[RFC3310] or using the Extensible Authentication Protocol EAP-AKA [RFC4187].
GAA uses Digest AKA within HTTP when bootstrapping from the UMTS infrastructure because EAP is typically used for access authentication rather than service
authentication.
The discussion above already shows that also the requirement of reuse has been
satisfi ed with GAA.
To satisfy the protection of original infrastructure requirement, the session keys
resulting from original authentication protocol are not used directly to secure GAA
applications. Instead, these session keys are used as the GAA master session key.
The shared session key for GAA applications are obtained by applying a key diver-
sifi cation function to the GAA master session key. The key diversifi cation function
is one-way: it is easy to compute the GAA application key from the AKA session
keys, but it is infeasible to do the reverse. This way, even if the GAA application
key is exposed due to a design or confi guration fl aw in a GAA application, it cannot
be used to attack original infrastructure.
Similarly, the GAA transaction identifi er is independent of identifi ers in the
original infrastructure, such as UMTS subscriber identities like the International
Mobile Subscriber Identity (IMSI) or Mobile Station International ISDN Number
(MSISDN). Moreover, the average extra load on the original infrastructure from
GAA application requests is controlled by the lifetime of bootstrapped keys. If a
GAA application uses the bootstrapped keys only for the indicated lifetime, it can
automatically detect when the subscriber’s keys are revoked in the original infrastructure. It is entirely up to the GAA application to decide whether or not to use the
bootstrapped keys only for the indicated lifetime.
In order to achieve application separation, we cannot use a single shared session
key for all GAA applications. Instead, each GAA application must be given mutually
independent key material. This key separation is implemented by including the
application server’s identity and application protocol’s identity as an input parameter
to the key diversifi cation function. As a result, the same subscriber’s device will end
up using a different GAA application key with each different GAA application. Furthermore, key diversifi cation guarantees that one GAA application key cannot be
used to derive another GAA application key.
Finally, a number of mechanisms are used for achieving home control. The GAA
master session key and all the associated application-specifi c keys have limited lifetimes specifi ed by the home operator. The home operator also maintains application-
Generic Authentication Architecture 25
specifi c user profi le for each subscriber, which specifi es what information about a
subscriber is released to an application server, and to confi gure the type of service
that an application server is allowed to provide to a subscriber.
3.1.2 A Bird’s Eye View of GAA
Figure 3.1 shows a schematic view of the basic GAA. There are three different
general network functions in GAA:
The Home Server (HS) is the subscriber database and contains the long-term
•
subscriber key for each subscriber. It is a standard function in cellular networks.
For example, in UMTS networks (according to latest set of specifi cations), it is
known as the HSS. In GSM networks (and older UMTS networks), the HS is
known as Home Location Register (HLR).
Bootstrapping Server Function (BSF) is a new network function introduced in
•
GAA. It facilitates the use of AKA to bootstrap a new GAA master session key.
The server functionality of each GAA server application is a Network Application
•
Function (NAF).
GBA
Home Server
Zh: Credential Fetching Protocol
Bootstrapping
Function (BSF)
Ub: Bootstrapping Protocol
BSF client
UICC
User Equipment (UE)
Zn: Key distribution
Protocol
Ua: Application Protocol
NAF client
Function (NAF)
Figure 3.1. Generic Authentication Architecture
GAA
Network
Application
26 Cellular Authentication for Mobile and Internet Services
A network function is an abstract (or logical) construct. Each network function may
be implemented in a separate physical network elements. But it is possible for some
network functions to be co-located in the same network element. For more details
on each network element, see Section 3.2.1.
The client device, also known as the User Equipment (UE), contains the clientside functionality. The long-term subscriber keys are contained in subscriber identity
modules. For example, in UMTS USIM, application on a smart card is used for
enabling packet- and circuit-switched access. Typically, the subscriber identity
modules are housed in the subscriber’s smart card, known as Universal Integrated
Circuit Card (UICC). The BSF client is the entity in UE that participates in bootstrapping. It interacts with the BSF on the network and the subscriber identity module in
the UE. The UE will also have one or more NAF clients, which obtain an application-specifi c bootstrapped key from the BSF client and use it to secure the application
protocol. A NAF client is an application-specifi c software element in the device, e.g.,
streaming application, browser application, etc. The NAF server obtains the same
key from the BSF server.
The protocols for the interactions between two entities are specifi ed by the inter-
face (also called reference point) between them. There are four such interfaces in
the basic GAA. We explain the interfaces by describing the procedures in which they
are used: bootstrapping of a shared key and the use of that key. Strictly speaking,
there is a difference between the notions of ‘interface’ and ‘reference point’, i.e., the
former refers to a boundary between two physical entities while the latter refers to
a connection point between two logical functions. But in the sequel, these terms are
used interchangeably.
The fi rst procedure is GAA bootstrapping. This is the process by which the AKA
protocol in the parent infrastructure is used to set up a GAA master session key
between the UE and the BSF. The starting point of bootstrapping is that the UE and
Home Server share a long-term key and can use it to run an AKA protocol specifi ed
for the parent infrastructure. The exchanges between UE and BSF during the bootstrapping procedure are specifi ed by the Ub interface. The exchanges between BSF
and the Home Server are specifi ed by the Zh interface. The typical GAA bootstrapping procedure shown in Figure 3.2 consists of the following steps:
1. The BSF client in UE initiates bootstrapping by sending a request to the BSF with
the identity by which the subscriber is known in the original infrastructure. Thus,
is done over the Ub interface.
2. This triggers a run of the authentication protocol between UE and HS with the
BSF acting as the intermediary. At the end of this run, UE and BSF obtain a set
of shared session keys. The GAA master session key Ks is derived from this set.
In the case of UMTS AKA, the session keys are known as IK and CK. Ks is
simply the concatenation of the IK and the CK.
Generic Authentication Architecture 27
3. The BSF also receives a set of user profi les from the HS over Zh interface if the
HS is an HSS. Each GAA application may have a user profi le.
4. BSF constructs a transaction identifi er B-TID and stores B-TID, Ks and the
user profi les in its database. It also chooses a key lifetime according to its local
policy.
5. BSF sends B-TID and the key lifetime to the UE.
6. UE stores B-TID, Ks and key lifetime.
At this point, the bootstrapping is complete. Both UE and BSF share a temporary
GAA master session key Ks and a transaction identifi er B-TID that can be used to
identify Ks. It should be noted that the Ks itself is not bound to a particular application or NAF.
The second procedure is the usage of bootstrapped keys. This is the process by
which UE can use the bootstrapped keys to secure its exchanges in an application
protocol with a NAF acting as the application server. The exchanges between UE
and NAF in the application protocol, during the bootstrapping usage procedure, are
UE
Request (user identity)
Run authentication and key agreement protocol
Derive GAA master session key Ks
B-TID, key-lifetime
Store <B-TID, Ks, key-lifetime>
Figure 3.2. GAA bootstrapping procedure
BSF
Derive GAA master session key Ks
and Transaction identifier B-TID
user-profiles
Add <B-TID, Ks, User-profile> to database
B-TID, Ks, user-profilesB-TID, Ks, key-lifetime
Ub interface
Zh interface
HS
28 Cellular Authentication for Mobile and Internet Services
B-TID, Ks, ke
UE BSF
y-lifetime
Derive Ks_NAF
Application Request
(B-TID, msg)
Store <Ks_NAF, bootstrap-time app-prof,k ey-lifetime>
Application Answer
Ua interface Zn interface
msg is an application-specific message
app-prof is the application-specific part of user-profiles
NAF
B-TID, Ks, user-profiles
Authentication Request
(B-TID,NAF-Id )
Derive Ks_NAF
Authentication Answer
(Ks_NAF, app-prof, boostrap-time, key-lifetime)
Figure 3.3. GAA Bootstrapping usage procedure
specifi ed by the Ua interface. The exchanges between NAF and the BSF are specifi ed
by the Zn interface. If the NAF and the BSF reside in different networks, an intermediate proxy (Zn proxy) is needed to communicate to the BSF. The interface
between the NAF and the Zn proxy is the Zn interface. The interface between the
Zn proxy and the home-BSF is called Zn′ interface (spelled ‘Zn prime’). For more
details on Zn proxy, see Section 3.5.5.
Figure 3.3 illustrates the typical form of bootstrapping usage (for other cases see
the use cases in chapter 4). It consists of the following steps:
1. Once the application-specifi c NAF client in UE decides to engage in an application protocol run with a specifi c NAF, it derives an application-specifi c session
key Ks_NAF from the GAA master session key Ks.
2. UE starts the application protocol by sending a request which contains the key
identifi er, i.e., B-TID over Ua interface.
3. NAF forwards B-TID and its own identifi er NAF-Id to the BSF over Zn
interface (if it resides in a visited network then Zn′ and Zn interface are used
together).
Generic Authentication Architecture 29
4. BSF can now look up its database for the entry corresponding to the B-TID. It
fi rst decides whether the NAF is authorized to receive application-specifi c keys
for this particular subscriber. This is determined according to local policy and the
policy in user profi les obtained from the HS.
5. If the decision is positive, BSF derives the application-specifi c session key Ks_
NAF from Ks. It also selects the subset of user profi les that the NAF is authorized
to receive.
6. BSF sends Ks_NAF, the application-specifi c subset of user profi les and other
relevant information to the NAF over Zn interface.
7. NAF stores the received information. At this point, UE and NAF share a tempo-
rary GAA application key, i.e., the application-specifi c session key Ks_NAF, and
can use it to protect subsequent exchanges in the application protocol.
8. NAF replies to UE using the application protocol and the application-specifi c
session key Ks_NAF.
The key derivation procedure used in steps one and fi ve has two properties as shown
in Figure 3.4. First, it uses a one-way function so that while it is easy to compute
Ks_NAF from Ks, it is extremely diffi cult to compute Ks given Ks_NAF. Second,
an identifi er for the NAF as well as session-specifi c information are used as inputs
to the procedure so that the Ks_NAF keys for different applications and different
sessions will be mutually independent. In Sections 3.2 and 3.3, we will see exactly
how key derivation is done.
So far we have gained a conceptual overview of GAA. The details vary depending
on what the original infrastructure is (e.g., UMTS or GSM), where the resulting
application-specifi c keys are to be stored and used in the UE (inside the UICC or in
the mobile terminal). In addition to the primary entities and interfaces we have seen
so far, there are other components of GAA. Now we are ready to look at the technical details of GAA.
Unique identifier for
NAF and application
protocol
Ks
Key derivation
function (KDF)
Session-specific
information
Figure 3.4. Deriving application-specifi c keys with key separation
Ks_NA
F
30 Cellular Authentication for Mobile and Internet Services
3.2 Foundations of GAA
In the previous section, the GAA architecture has been outlined and an overview of
GAA was provided. In this section, we present the detailed description of GAA that
has been specifi ed in 3GPP.
3.2.1 Architectural Elements of GAA
The basic GAA architecture in a 3G or 2G network consists of four different
components (see also more general description in Section 3.1.2):
HSS or HLR that contains the subscriber data, and from GAA perspective it
•
contains the long-term master key K that is shared between the terminal and the
operator and GBA User Security Settings (GUSS) data. In more general terms, the
HSS and HLR are described as HS in Section 3.1.2.
BSF that serves as a credential server. The BSF is the centrepiece of GAA
•
by establishing the GAA master session key between itself and the UE. It also
distributes application-specifi c keys to NAFs.
NAF that is any kind of application server that is able to use GAA to authenticate
•
subscribers. The NAF functionality is typically only a small part of the server
software and can be, for example, realized through a NAF library. The NAF can
be (i) part of the home operator network, (ii) in another operator network, or (iii)
in a third-party network. We assume that in cases (ii) and (iii), the business relationship between the home operator and the owner of the NAF will be defi ned in
a contractual agreement.
Terminal or User Equipment (UE) that contains a smart card, e.g., UICC, issued
•
by mobile network operator (MNO). The smart card contains also the long-term
master key K that is shared with the operator.
These four elements form the core of GAA. Typically, there is one logical HSS and
BSF per MNO but there are naturally multiple UEs and application servers, i.e.,
NAFs interworking in the system. If an HSS is used in a larger network with several
HSS servers, then a Subscriber Locator Function (SLF) might be used. The BSF can
query the SLF to determine the correct HSS for a given subscriber. However, when
looking at a single GAA transaction, there is only one of each element involved at
one time. The architecture of GAA with some details on components that are working
inside each element is shown in Figure 3.5. Note that the SLF is not depicted in this
fi gure.
UE: Terminals that are capable of using GAA need a GAA supporting function.
One way to integrate the GAA supporting function is to add a dedicated software
component to the operating system, which facilitates the communication with the
Generic Authentication Architecture 31
NAF
Ua
Ua
Ua
Ua
Ua
Service
Service
Service
Service
...
Service
NAF Library
Zn
UE
Application
Application
Application
...
Application
Application
BSF
Zn handler
Ub handler
Zh handler
session data
Bootstrapping
Bootstrapping logic
Ub
Zh
GBA Module
UICC
USIM
IMSI, Key
HSS
Zh handler
Subscriber entry:
-IMSI
-Key
-GUSS (optional)
data
Subscriber
Figure 3.5. GAA components
smart card (UICC) and the BSF on behalf of the applications utilizing GAA in the
terminal. In our case, we call the GAA supporting function the ‘GBA Module’ (or
also called ‘BSF Client’).
The GBA module is responsible for establishment of GAA master session key
together with the BSF. This is carried out by performing the AKA procedure over
the Ub reference point. The GBA module does its part by using the smart card
inserted into the terminal. The smartcard is either a SIM card, or a UICC containing
the USIM or ISIM applications.
The GBA module is responsible for communicating with the smart card via the
device drivers, which are also part of the platform. It also offers an Application
32 Cellular Authentication for Mobile and Internet Services
Programming Interface (API) to the applications in the terminal through which these
applications can request application-specifi c GAA keys from the GBA module so
that they can be used with a NAF over the Ua reference point. It should be noted
that the actual application using the GAA key may also reside outside the terminal
and is connected locally, e.g., via USB cable or Bluetooth to the UE. This is then
usually referred to as ‘split terminal’ case.
The high-level terminal architecture for GAA can be found in [TR33.905] and for
Nokia Series60 devices in Section 5.2 of this book.
NAF: The NAF functionality (e.g., implemented by a software library) can easily
be added to any server. The application server may reside in the network of the subscriber’s home operator, but it can also be run by a third-party network. What the
NAF functionality actually means is that a server is able to use GAA-based keys to
authenticate users in Ua reference point and to support the key request on the Zn
interface. In order to do so, it must be able communicate with the BSF to request
these keys along with some other additional information which we come to later.
The Zn interface for requesting the key can be based on the Diameter protocol
[RCF3588] or Web Services [W3C-SOAP].
BSF: The BSF is either a dedicated server or combined with another set of nodes
operated by an MNO. The terminal always bootstraps with his home credential
server, i.e., the BSF that is owned by the MNO with whom the subscriber has the
subscription.
HSS: Each MNO has some home server (for example, the HSS or the HLR) that
stores the long-term keys of the subscriber. The only GAA specifi c data that the home
server may store is the GUSS element. GUSS is a feature that can be used by any
kind of service (but the support of the GUSS is mandatory only for a limited range
of services). The BSF can request the GUSS and needed credential data from the
HSS using the diameter-based Zh interface, if the HSS supports Diameter. If the HSS
does not support the Diameter protocol, it may then use the Mobile Application
Part (MAP)-based Zh′ interface.).
These are the nodes involved in the implementation of GAA. The GAA
functionality can be split in two distinct phases: GAA bootstrapping and GAA
authentication. First, the generation of the keys and then later on the usage of those.
In more technical terms, we have:
GAA bootstrapping, during which the UE, the BSF and the HSS work together
•
to establish a shared secret (GAA master session key) utilizing reference points
Ub between terminal and BSF and Zh between BSF and HSS (with potential
detour using the SLF to fi nd the right HSS).
GAA authentication, during which the UE, a NAF and the BSF work together
•
to mutually authenticate the subscriber using the application in the UE, and the
service running a server with NAF functionality using reference point Ua between
the terminal and the NAF, and Zn between the NAF and the BSF.
Generic Authentication Architecture 33
The GAA bootstrapping run is based on the cellular authentication that therefore
serves as a prerequisite for the service-specifi c GAA authentication. One GAA
bootstrapping run can be used for several GAA authentications, but before the
service-specifi c GAA authentication can take place, there has to be at least one GAA
bootstrapping run.
In GAA, the reference points Ub, Zh and Zn are specifi ed in such a way that
interoperability between different terminal manufacturers and BSF network node
vendors can be assured, and the application server NAFs can interoperate with any
BSF without any vendor-specifi c modifi cations. This allows application developers
to connect their NAF server to different MNOs without being forced to change their
application programs.
The Ua reference point has been more loosely specifi ed. The intention is that
any protocol could be a Ua reference point. If GAA is used in some form to authenticate and otherwise secure the connection between a client and a server, then
this protocol is also a Ua reference point. Thus, the number of potential protocols
that can implement the Ua reference point is huge. For example, if a protocol
supports username/password-based authentication scheme, GAA can be plugged in
and used there almost directly. This is the intention of GAA: to be able to use underlying authentication framework (e.g., (U)SIM cards) in different deployment scenarios and, in particular, make life easier for the users by not requiring to remember
a large range of username/password combinations. Instead of remembering passwords, users are able to reuse their cellular authentication in a secure and automated
manner. Therefore, the Ua reference point has not been selected to use one single
protocol.
3GPP has specifi ed how to use GAA in two general cases:
HTTP Digest [RFC2617]; and
•
Pre-Shared Key (PSK) TLS [RFC4279].
•
Already these two cover a wide range of use cases as HTTP [RFC2616] is the most
widely used protocol in Internet today, and any other protocol can be tunnelled
through TLS [RFC4346], which can run on top of both Transport Control Protocol
(TCP) for normal TLS and User Datagram Protocol (UDP) for Datagram TLS (see
IETF Datagram TLS specifi cation [RFC4347]). These cases are covered in Section
4.1 of this book.
3.2.2 Bootstrapping
It is assumed that the terminal contacts an application server NAF at some point
in time to register or request a service. The NAF server desires to secure the
34 Cellular Authentication for Mobile and Internet Services
communication to the terminal using GAA. The bootstrapping phase is not dependent
on the actual service to be used. The NAF indicates the desire to use GAA to the
NAF application in the terminal (e.g., web browser or video streaming application).
Then the GAA bootstrapping is triggered by the application in the terminal (or alternatively the GBA module in the terminal can be confi gured to have a valid GAA
master session key at all time, i.e., ‘keep-alive GAA session’). The GBA module will
perform the GAA bootstrapping over Ub interface if it does not have a valid GAA
master session key Ks when an application requests application-specifi c GAA key
from it.
The GAA master session key Ks is identifi ed by a key identifi er B-TID. It is valid
for a certain amount of time after it has been established between the GBA module
in the UE and the BSF. The lifetime of the key is set by an operator and may depend
on factors like load balancing, value of the provided services and trustworthiness of
the application servers connected to the BSF. Section 5.4.3 discusses the effect key
lifetime setting has on the amount of bootstrapping operations.
Below is the message sequence fl ow diagram in the case where the UE contains
a 3G smart card, i.e., a UICC, that does not have any GAA specifi c functionality and
the subscriber database is the HSS. The smart card hosts either a 3G USIM or ISIM
application. This confi guration (or GBA variant) is also referred as GBA_ME or
normal GBA where ME refers to mobile equipment and indicates that all GAA
functionality, e.g., key generation and storage functionality resides in a trusted part
of the ME.
It should be noted that the GBA module will always establish the GAA master
session key with the home BSF, i.e., it will contact the BSF that is operated by the
same operator that issued the UICC to the subscriber. The address of the home BSF
is derived the following way:
If USIM or SIM application on the UICC is used, the application identifi er is IMSI.
•
If the IMSI is, for example, 234150999999999, where the Mobile Country Code
(MCC) is 234, and the Mobile Network Code (MNC) is 15, and the Mobile Station
Identity Number (MSIN) is 0999999999, then the BSF address is derived to be
bsf.mnc015.mcc234.pub.3gppnetwork.org.
If ISIM application on the UICC is used, the subscriber identifi er is IMPI. If the
•
IMPI is subcriber@operatorB.com for example, then the derived BSF address is
bsf.operatorB.com.
The derivation of BSF address from IMSI or IMPI is specifi ed in [TS23.003]. (See
Figure 3.6.)
The general form of the KDF used in GAA is:
derived key = KDF (master session key, gba variant, RAND, IMPI, NAF_ID).
Generic Authentication Architecture 35
UE
USIM
2.
3.
12.
13.
Application
GBA Module
1.
18.
4.
11.
14.
17.
BSF
Ub handler
Zh handler
Bootstrap. logic
9.
10.
15.
16.
session data
Bootstrapping
HSS
data
Subscriber
Zh handler
5.
6.
7.
8.
Figure 3.6. Normal bootstrapping message fl ow
1. An application in the UE has come to a state that it needs application-specifi c GAA
keys from the GBA module in the UE. Thus, it contacts the GBA Module in the UE
and gives the NAF_ID parameter to it. The NAF_ID consists of the Fully Qualifi ed
Domain Name (FQDN) of the NAF application server (i.e., DNS name of the server)
and a fi ve-octet Ua security protocol identifi er that identifi es the protocol that is being
used between the UE and the NAF over the Ua reference point.
2. The GBA module contacts the USIM application in the UICC and asks for the
International Mobile Subscriber Identity (IMSI) of the USIM. IMSI is the unique
identifi er of the USIM application that is used in HSS to locate the corresponding
long-term key of USIM, i.e., to fi nd the counterpart key of the subscriber in the
subscriber database. If an ISIM application is used, then the unique identifi er is called
IP Multimedia Private Identity (IMPI).
3. The USIM returns the IMSI to the GBA module. The GBA module converts the IMSI
to the IMPI format according to [TS23.003] so that it can be carried over the Ub
36 Cellular Authentication for Mobile and Internet Services
Figure 3.6. Normal bootstrapping message fl ow (continued)
reference point. In ISIM case, no conversion is needed because the identity is already
in IMPI format.
4. The GBA module starts the bootstrapping over Ub reference point with the BSF by
sending the IMPI to it. The message complies with the HTTP Digest AKA Version
1 messaging according to [RFC3310]: It should be noted that it is assumed that the
password in ‘AKAv1’ HTTP Digest AKA is in binary format.
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-6
Date: Thu, 25 Oct 2007 2:38:00 GMT
Accept: */*
Authorization: Digest
username=”<IMPI>”,
realm=”bsf.home1.net”,
nonce=””,
uri=”/”,
response=””
5. The BSF receives the IMPI, converts it back to IMSI format if needed and sends
a request for Authentication Vector (AV) and GUSS to the HSS over the operator
internal diameter-based Zh interface. The GUSS request is optional, but if the operator
wants also to use GBA_U variant of GAA, then the GUSS is required
for the BSF to process the AV correctly.
6–7. The HSS queries its internal database for the master session key, next sequ -
ence number and GUSS data element. It then generates a random number, and
with it, master session key, and the sequence number generates the AV which
consists of RAND, AUTN (containing sequence number and a MAC), RES, CK and
IK.
8. The fi ve values of the AV (quintet) and, if available, the GUSS, are sent back to the
BSF.
9–10. The BSF initializes the generation and storage of the bootstrapping session data to
its internal session database. The actual storage and data management in the BSF is
vendor implementation specifi c, but at least the AV, GUSS and key generation
timestamp should be stored for further requests and processing.
11. The BSF challenges the UE by sending the RAND and AUTN to the UE to perform
the client authentication:
HTTP/1.1 401 Unauthorized
Server: Bootstrapping Server; Release-6
Date: Thu, 25 Oct 2007 2:38:00 GMT
WWW-Authenticate: Digest
realm=”bsf.home1.net”,
nonce=“base64(RAND + AUTN + serverdata)”,
Generic Authentication Architecture 37
Figure 3.6. Normal bootstrapping message fl ow (continued)
algorithm=AKAv1-MD5,
qop=”auth-int”,
opaque=”5ccc...0c41”
12. The GBA module extracts the RAND and AUTN from the challenge and runs
AUTHENTICATE command with the USIM with RAND and AUTN as input
parameters to the smart card command [TS31.102] (in case a ISIM is used, then
[TS31.103] applies).
13. Upon successful validation of RAND and AUTN, the USIM returns RES, CK and
IK to the GBA module. The GBA module establishes the GAA master session key
(Ks) by concatenating CK and IK received from the card.
14. The GBA module sends response back to the BSF by calculating the response using
RES as password.
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-6
Date: Thu, 25 Oct 2007 2:38:00 GMT
Accept: */*
Authorization: Digest
username=”<IMPI>”,
realm=”bsf.home1.net”,
nonce=”base64(RAND + AUTN + serverdata)”,
uri=”/”,
nc=00000001,
cnonce=”8802...308c”,
response=”6629...4cf1”,
opaque=”5ccc...0c41”,
algorithm=AKAv1-MD5
qop=auth-int,
The BSF validates the response received from the UE with the stored data.
15–16. Upon successful validation, the BSF updates the bootstrapping session data by setting
up key lifetime and generating the key identifi er B-TID.
17. The BSF sends B-TID and key lifetime to the UE using the HTTP payload, which
is protected by the digest operations, as the quality of protection (qop) parameter is
set to ‘auth-int’:
HTTP/1.1 200 OK
Server: Bootstrapping Server; Release-6
Authentication-Info: qop=auth-int,
rspauth=”23ac...5ff0”,
cnonce=”8802...308c”,
nc=00000001,
38 Cellular Authentication for Mobile and Internet Services
Figure 3.6. Normal bootstrapping message fl ow (continued)
opaque=”5ccc...0c41”,
nonce=”base64(RAND + AUTN + serverdata)”
Date: Thu, 25 Oct 2007 2:38:00 GMT
Expires: Thu, 25 Oct 2007 14:38:00 GMT
Content-Type: application/vnd.3gpp.bsf+xml
Content-Length: 185
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp-gba”>
<btid>base64(RAND)@bsf.operator.com</btid>
<lifetime>2007-10-25T14:38:00Z</lifetime>
</BootstrappingInfo>
Upon receiving the message, the GBA module validates the response and stores the
master session key Ks, the identifi er B-TID and the corresponding key lifetime.
18. The GBA module derives the application-specifi c GAA key using the NAF_ID that
was received from the application in step 1. It then returns this key with key lifetime,
and optionally, other parameters, such as GAA bootstrapping type, which in this case
would be ‘GBA_ME’. In GBA_ME, only one application-specifi c GAA key is
generated (Ks_NAF).
The Ks_NAF is computed as:
Ks_NAF = KDF (Ks, ‘gba-me’, RAND, IMPI, NAF_ID)
The KDF consists of an application of HMAC-SHA-256 and its exact form is defi ned
in Annex B of [TS33.220]. The master session key is always Ks when deriving
application-specifi c GAA keys. The gba variant parameter specifi ed which GBA
variant is in question. In GBA_ME case, its value is ‘gba-me’. The other parameters
consist of user’s IMPI, the NAF_ID and RAND. The NAF_ID is constructed as
follows:
NAF_ID = FQDN of the NAF || Ua security protocol identifi er.
The Ua security protocol identifi er specifi es what kind of protocol is used in the Ua
interface and the standardized value are specifi ed in Annex H of [TS33.220]. The
Ua security protocol identifi er consists of fi ve bytes, and for example, if HTTPS
is used as the Ua protocol, that value would be (0x01, 0x00, 0x00, 0x00, 0x02)
and if MBMS is used then it would be (0x01, 0x00, 0x00, 0x00, 0x01) for
MBMS. The main reason for using the Ua security protocol identifi er is to have key
diversifi cation between different protocols if there are multiple protocols used
Generic Authentication Architecture 39
between the UE and the NAF. This way, if due to some weakness in one protocol
the Ks_NAF is discovered, it would affect another protocol as its Ks_NAF would
be different.
Other variants of GAA bootstrappings are described in Section 3.3. The difference
between these variants results from the underlying security architecture.
3.2.3 Authentication
In this phase, the key generated in the bootstrapping run are actually used for authentication. As said earlier, the protocol used in Ua reference point, i.e., between the
UE and the BSF, can be any kind of protocol. Below is a generic message sequence
fl ow on how application-specifi c GAA key (Ks_NAF) is used for authentication
purposes. (See Figure 3.7.)
UE NAF
USIM
Application
GBA Module
3.
5.
1.
2.
6.
11.
Service
4. Bootstrapping
NAF Library
7.
10.
BSF
Zh handler
session data
Bootstrapping
Bootstrap. logic
8.
9.
Figure 3.7. Authentication Message Flow Using GAA
1. The application in the UE contacts an NAF using an application-specifi c protocol over
the Ua interface. It may indicate that it can use GAA although this is not required.
2. The NAF decides to use GAA for authentication based on its internal policy or upon
a requirement in the service agreement with the operator. This decision may depend
40 Cellular Authentication for Mobile and Internet Services
Figure 3.7. Authentication Message Flow Using GAA (continued)
on whether GAA support was indicated during step 1, or it can be static rule to always
use GAA. The NAF then sends a request with required parameters to challenge the
UE to authenticate using GAA.
3. This step is the same as step 1 in previous section. The application in the UE requests
Ks_NAF from the GBA module and send the application server identifi er the NAF_ID
to the GBA module. The interface between the GBA module and the application in
the UE is secured through platform security, more on this subject can be found in
Chapter 5.
4. If GBA module does not have a valid bootstrapping session active, then it will perform
GAA bootstrapping run at this phase as outlined in the previous section (starting
directly from step 2 because step 1 is already done). If it already has the session, then
it can proceed directly to step 5 without making a bootstrapping run.
5. This is the same step as step 18 in previous section. The GBA module returns the
derived Ks_NAF, the key identifi er, i.e., B-TID, and the key lifetime to the application
in the UE (e.g., browser or streaming application) through the GBA module API.
6. The application in the UE uses the key to calculate a response to the challenge of the
NAF. It will then include this response with the B-TID to the message and send it to
the NAF application server.
7. The NAF will extract the B-TID, response, and any other necessary information from
the message. It will then request the Ks_NAF from the BSF over the Web Services
(WS) or diameter-based Zn interface. It will include at least B-TID and NAF_ID to
the request, but may also request one or more User Security Settings (USS) elements
from the BSF, if it is confi gured to do so. GUSS and USS usage is discussed in Section
3.3. The USS may also contain information about whether 2G GBA has been used for
bootstrapping or not (see next section for description of 2G GBA), the NAF may then
compare this information with its local security policy.
8–9. The BSF retrieves the bootstrapping session information from its local session database
including the session key Ks, key lifetime and optional USS elements if requested
from the NAF.
10. The BSF derives the Ks_NAF based on Ks, NAF_ID and other necessary parameters.
It then returns this key, key lifetime and USS elements (if requested and existent in
the HSS/BSF) to the NAF.
11. The NAF validates the received response from the UE using the Ks_NAF, and if the
validation is successful, it creates an authenticated session for the user in its local
database and indicates to the user that the authentication was successful.
Naturally, the NAF and the application in the UE need to run many applicationspecifi c functionalities and tasks, but in essence, the above is what they need to do
from GAA’s perspective. An example of an additional application-specifi c task could
be authentication of the NAF by the UE using the same GAA key.
Generic Authentication Architecture 41
More application-specifi c message sequence fl ows for several use cases are
described in Chapter 4.
3.3 Variations of the Generic Bootstrapping Architecture
GAA builds upon the shared key stored in MNO’s database and in the smart card
that is given out to the user. Today’s smart cards have a much broader functionality
than the SIM cards that users got a few years ago. The second generation Global
System for Mobile Communication (GSM) SIM card specifi cation was frozen by
3GPP in Release 4 in 2001 [TS51.011], i.e., only essential corrections
allowed. The third generation smart card is the Universal Integrated Circuit Card
(UICC), which was modelled after the GSM SIM card, but can host several applications. It contains the USIM [TS31.102] that is used for authentication and is the
evolution of GSM SIM.
For 3GPP2 systems that are, for example, used in North America, the UICC can
contain, in addition to (or instead of) the USIM application, the Removable User
Identity Module (R-UIM and ISIM) application. The UICC card can also run the
GSM SIM card functionality or the IP Multimedia Subsystem (IMS) Identity Module
(ISIM) [TS31.103] as an application.
If every mobile terminal would include a smart card with USIM application, a
single variant of GAA could work everywhere. But large-scale replacement of
deployed smart cards with new model is costly and so smart cards that were given
out to the subscribers are rarely replaced. This is one of the reasons why several
bootstrapping variants have been standardized.
The bootstrapping procedure that we have described so far was standardized fi rst.
It is now called GBA_ME or ‘normal GBA’. GBA_ME bootstraps from USIM
(UMTS) credentials and the bootstrapped keys are stored in the mobile equipment
(ME), outside the smart card.
The second bootstrapping variant is called GBA_U or ‘UICC-aware’ bootstrapping. It was created because for some services, e.g., broadcast mobile TV, the bootstrapped key should be protected not only from outsiders but also from the owner
of the mobile device. For that reason, the bootstrapped master key stays on the smart
card; it is not revealed to applications on the ME.
2
1
are now
1
An essential correction is a correction without which the system would not work.
2
As we will describe in detail later, in GBA_U, the smart card creates two keys for each application:
external and internal. The external key is given to application and can be used in the same way as in
GBA_ME. The internal key stays in the smart card. The application that needs that key, e.g., to decrypt
data, will send the encrypted data to the smart card.
42 Cellular Authentication for Mobile and Internet Services
The other GBA variants were created to enable bootstrapping in second genera-
tion, i.e., pre-UMTS, cellular networks.
The third GBA variant is called ‘2G GBA’ or ‘SIM GBA’ and bootstraps from
SIM (GSM) credentials.
The fourth, the fi fth and the sixth GBA variants were standardized by 3GPP2 for
Code Division Multiple Access (CDMA) networks.
3.3.1 GBA_ME
This is the terminal-based variant of GAA, also sometimes called normal GBA and
was outlined in full detail in the previous section. In GBA_ME, it is assumed that
the terminal contains a 3G UICC smart card, but the card does not need to be aware
of GAA or to be specially confi gured for that purpose. The UICC contains an ISIM,
or USIM or R-UIM application; in most typical scenarios, it will contain at least a
USIM. The cryptographic key management of GAA is done by the terminal, in particular, the master session key and the application-specifi c keys are derived in the
terminal, after requesting the needed key derivation material from the UICC
[TS33.220]. In GBA_ME, only one application-specifi c key Ks_NAF per NAF_ID
is derived from the master session key Ks that has been established in each bootstrapping run with the BSF. The NAF_ID consists of the FQDN name of the NAF and
of the Ua security protocol identifi er used between the NAF and the terminal. The
security of the master key and the application-specifi c key are protected by the terminal platform and the operating system. The interface between the UICC and the
terminal is described in [TS31.102] for the USIM and in [TS31.103] for the ISIM.
The message fl ow and the details were explained in the Section 3.2.
3.3.2 GBA_U
GBA_U is the smart card centred variant of GAA. It requires a specially confi gured
UICC smart card that is GAA aware and supports some GAA-specifi c interfaces and
functionalities. The difference compared to GBA_ME is that the master key Ks stays
inside the UICC and all key derivations happen in the UICC. If GBA_U is used,
then the BSF and the smart card derive two keys, the Ks_int_NAF and the Ks_ext_
NAF, instead of just a single key Ks_NAF. The Ks_int_NAF stays in the card and
the Ks_ext_NAF is given out to the terminal. GBA_U is, for example, used for
MBMS security, as an alternative to GBA_ME. The key derivation varies slightly
from the one for GBA_ME:
Ks_ext_NAF = KDF (Ks, ‘gba-me’, RAND, IMPI, NAF_ID)
and
Ks_int_NAF = KDF (Ks, ‘gba-u’, RAND, IMPI, NAF_ID).
Generic Authentication Architecture 43
The KDF is the HMAC-SHA-256-based Key Derivation Function and the NAF_ID
is a concatenation of the FQDN of the NAF and the Ua security protocol identifi er
(see Section 3.2).
Below is message sequence fl ow diagram in the case where the UE contains a
UICC that contains an USIM application and supports GAA-specifi c functionality
(i.e., the smart card is GBA_U enabled) and the subscriber database is an HSS. (See
Figure 3.8.)
UE BSF HSS
USIM
2.
3.
12.
13.
18.
19.
21.
GBA Module
1.
22.
Application
4.
11.
14.
17.
Ub handler
Bootstrap. logic
Zh handler
9.
10.
15.
16.
session data
Bootstrapping
5.
8.
Zh handler
data
Subscriber
6.
7.
Figure 3.8. GBA_U message fl ow
44 Cellular Authentication for Mobile and Internet Services
Figure 3.8. GBA_U message fl ow (continued)
1. An application in the UE has come to a state that it needs application-specifi c GAA
keys from the GBA module in the UE. Thus, it contacts the GBA module in the UE
and gives it the NAF_ID. The NAF_ID consists of the FQDN of the NAF application
server and a Ua security protocol identifi er.
2. The GBA module contacts the USIM application in the UICC and asks for the
International Mobile Subscriber Identity (IMSI) of the USIM. IMSI is the unique
identifi er of the USIM application that is used in HSS to fi nd the counterpart key of
the subscriber in the subscriber database.
3. The USIM returns the IMSI to the GBA module. The GBA module converts
the IMSI to the IMPI format so that it can be carried over the Ub reference
point.
4. The GBA module starts the bootstrapping over Ub reference point with the BSF by
sending the IMPI to it. The message complies with the HTTP Digest AKA Version
1 messaging according to [RFC3310]. An example message is given below:
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-6
Date: Thu, 25 Oct 2007 2:38:00 GMT
Accept: */*
Authorization: Digest
username=”<IMPI>”,
realm=”bsf.home1.net”,
nonce=””,
uri=”/”,
response=””
5. The BSF receives the IMPI, converts it back to IMSI format, and sends a request for
Authentication Vector (AV) and GBA User Security Settings (GUSS) to the HSS over
the diameter-based Zh interface. Since GBA_U is deployed in the operator network,
the HSS needs to return the GUSS.
6–7. The HSS queries its internal database for the master session key, next sequence
number, and GUSS data element. It then generates a random number, and with it,
master session key, and the sequence number generates the AV, which consists of
RAND (the random number), AUTN (sequence number, and a MAC), RES (the
expected response value), CK (cipher key) and IK (integrity key).
8. The fi ve values of the AV (quintet) and, if available, the GUSS is sent back to the
BSF. The GUSS contains information that in the XRES the least signifi cant bit has
to be fl ipped before storing it and that the MAC* and AUTN* have to be calculated
as outlined in Chapter 5 of [TS33.220]. It should be noted that without the GUSS,
the BSF would have no indication that it has to do these changes, i.e., for GBA_U
support the GUSS is needed in the BSF.
Generic Authentication Architecture 45
Figure 3.8. GBA_U message fl ow (continued)
The fl ipping of the least signifi cant bit of XRES value above is done because then
the corresponding AV cannot be used in the normal AKA procedure. With this change,
it can be ensured that this particular AV can be used only in the GBA_U mode.
9–10. The BSF initializes the generation and storage of the bootstrapping session data to
its internal session database. The actual storage and data management in the BSF is
vendor implementation-specifi c, but at least the AV, GUSS and key generation
timestamp should be stored for further requests and processing.
11. The BSF challenges the UE by sending the RAND and AUTN* to the UE to perform
the client authentication:
HTTP/1.1 401 Unauthorized
Server: Bootstrapping Server; Release-6
Date: Thu, 25 Oct 2007 2:38:00 GMT
WWW-Authenticate: Digest
realm=”bsf.home1.net”,
nonce=”base64(RAND + AUTN* + serverdata)”,
algorithm=AKAv1-MD5,
qop=”auth-int”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”
12. The GBA module extracts the RAND and AUTN* from the challenge, and runs
AUTHENTICATE command with the UICC in ‘GBA Derivation’ mode with RAND
and AUTN* as input parameters to the smart card command [TS 31.102]. In the
‘GBA Derivation’ mode, the UICC does not return the CK and IK back to me
opposite to the UMTS Mode where they are returned. The UMTS Mode is used with
GBA_ME, but the ‘GBA Derivation’ mode is used with GBA_U.
The UICC validates the RAND and calculates IK and MAC by performing:
MAC = MAC* ⊕ Trunc (SHA-1 (IK)).
Then the UICC checks AUTN value (i.e., SQN ⊕ AK ⎪⎪ AMF ⎪⎪ MAC) to check
that the challenge was really coming from an authorized network.
13. Then the UICC calculates CK and RES. This will result in the master session key
Ks, which is a concatenation of CK and IK that is then stored in the UICC. The UICC
then transfers only the RES (after fl ipping the least signifi cant bit) to the GBA
module.
14. The GBA module sends response back to the BSF by calculating the response using
RES as password.
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-6
Date: Thu, 25 Oct 2007 2:38:00 GMT
Accept: */*
46 Cellular Authentication for Mobile and Internet Services
Figure 3.8. GBA_U message fl ow (continued)
Authorization: Digest
username=”<IMPI>”,
realm=”bsf.home1.net”,
nonce=”base64(RAND + AUTN* + server specifi c data)”,
uri=”/”,
qop=auth-int,
nc=00000001,
cnonce=”6629fae49393a05397450978507c4ef1”,
response=”6629fae49393a05397450978507c4ef1”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
algorithm=AKAv1-MD5
The BSF validates the response received from the UE with the stored data.
15–16. Upon successful validation, the BSF updates the bootstrapping session data by setting
up key lifetime and generating the key identifi er B-TID.
17. The BSF sends B-TID and key lifetime to the UE using the HTTP payload.
HTTP/1.1 200 OK
Server: Bootstrapping Server; Release-6
Authentication-Info: qop=auth-int,
rspauth=”6629fae49394a05397450978507c4ef1”,
cnonce=”6629fae49393a05397450978507c4ef1”,
nc=00000001,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
nonce=”base64(RAND + AUTN* + serverdata)”,
qop=auth-int
Date: Thu, 25 Oct 2007 2:38:00 GMT
Expires: Thu, 25 Oct 2007 14:38:00 GMT
Content-Type: application/vnd.3gpp.bsf+xml
Content-Length: 185
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp-gba”>
<btid>user@bsf.operator.com</btid>
<lifetime>2007-10-25T14:38:00Z</lifetime>
</BootstrappingInfo>
Upon receiving the message, the GBA module validates the response, i.e., checks
the ‘rspauth’ value, and stores the NAF-specifi c Ks_ext_NAF key, the identifi er
B-TID and the corresponding key lifetime.
18. To conclude the bootstrapping phase of the procedure, the GBA module stores
the B-TID, the RAND, and the key lifetime received in the previous step to the
UICC.
Generic Authentication Architecture 47
Figure 3.8. GBA_U message fl ow (continued)
19. To respond to the original request made by the application in step 1, the GBA module
derives application-specifi c GAA keys. This key derivation happens in the UICC.
The GBA module sends the NAF_ID (received in step 1), and the IMPI to the UICC,
and requests it to derive the keys Ks_ext_NAF and Ks_int_NAF.
20. The UICC uses the GAA master session key Ks and other parameters as outlined in
[TS33220] to derive both the Ks_int_NAF and the Ks_ext_NAF. The UICC stores
the Ks_int_NAF together with the corresponding B-TID and RAND on its fi le
system. It then returns the Ks_ext_NAF to the GBA module.
21. The GBA module sends now the Ks_ext_NAF key with key lifetime and optionally
other parameters, such as GAA bootstrapping type, which in this case would be
‘GBA_U’ to the application in the UE. If the application wants to utilize later the
Ks_int_NAF, then it has only the possibility to hand over encrypted data to the smart
card for processing with Ks_int_NAF since the Ks_int_NAF key does not leave the
card.
3.3.3 2G GBA
Though smart cards are evolving and have new features with each release, cards
that have been given to subscribers are rarely changed. Thus, most mobile operators
have a large number of subscribers that have use SIM card (implemented according
to [TS51.011]) and operators want to exploit these cards and the existing infrastructure also for new services. Therefore, 3GPP decided that service consumption of
GAA-secured services should also be possible with a SIM card and later on integrated also the case that the operator may use an HLR (for more information see
[TS33.220]). The main requirement was that no changes to existing cards need to be
made and that users could just use their old cards in new terminals to consume a
service (e.g., watch mobile TV). This 2G GBA, also called SIM GBA, was then
specifi ed in Annex I in [TS33.220] in Release 7 of 3GPP. Additionally, [TR33.920]
contains a list of changes that need to be implemented for 2G GBA on top of Release
6 [TS33.220].
The core network needs to have an HSS or an HLR. The BSF needs to retrieve
the 2G Authentication Vector and optionally the GUSS from the HSS using a diameter-based interface. If an HLR is deployed instead of the HSS or an HSS without
Diameter support is used, then only the 2G Authentication Vector is retrieved via a
MAP-based interface. 2G GBA is very similar to GBA_ME; in 2G GBA also, the
master key and the application-specifi c key are derived and stored in the terminal
and protected by the platform and the operating system.
48 Cellular Authentication for Mobile and Internet Services
The Key Derivation Function (KDF) is the same as for GBA_ME, but the input
parameter ‘key’ is different from the GBA_ME case due to the different format of
the baseline key Kc. The generated application-specifi c key Ks_NAF has the same
format as the GBA_ME-based key and can be used in the same way. Terminals
that support 2G GBA are also recommended to support GBA_ME and GBA_U.
When the UICC card supports both the SIM application functionality and the
3G application functionality (USIM or ISIM), the terminal is required to use the 3G
application.
The application in the terminal requesting the NAF-specifi c key can indicate to
the GBA module in the platform whether 2G GBA is acceptable for this application
or not. In general, it is assumed that 2G GBA can be used for applications, except
if is explicitly prohibited by the operator or by the application specifi cation. It is
expected that the application server in the network (i.e., the NAF server) has a local
policy about whether to accept 2G subscribers, but this depends on the actual security
needs of the application which uses the keys.
It should be noted that in case where a terminal can use either a 2G SIM-based
GBA or a 3G USIM-based GBA, the UE always has to choose use of the USIM
for the bootstrapping. Both 2G GBA and the MAP-based Zh′ interface between
BSF and HLR are 3GPP Release 7 features and are optional to support. We will
now outline the message fl ow for 2G GBA that is used together with an HLR. (See
Figure 3.9.)
It should be noted that even if the BSF and the GBA module store the key, a situation may occur that either the BSF or the UE has deleted the key and the related
material. In the BSF, this might be caused by memory management and the terminal
may have deleted the data, e.g., when UICC was removed. If the BSF has deleted
the key, then NAF will get the ‘B-TID unknown’ error reply after requesting the key
using the B-TID over Zn reference point. In this case, the NAF will indicate to the
UE that it needs to perform new GAA bootstrapping, to derive new Ks_NAF from
newly generated Ks, and to request Ks_NAF from the BSF again. If the UE has
deleted the key, it will perform new GAA bootstrapping when a Ks_NAF is needed.
This will cause the BSF to overwrite the existing key in its databases as the BSF is
required to remember only the most recent key and the related material for a particular subscriber.
3.3.4 Detection of Bootstrapping Variants by the NAF
The application server (NAF) may not be part of operator’s network, hence, it is not
directly aware of the GBA variant used between the BSF and the UE, and the resulting security level of the keys. It is not that straightforward for the NAF to determine
the provided security level. There are several cases to be distinguished. In the following, we show how the NAF can determine which case is in use, i.e., what is the
security level provided:
Generic Authentication Architecture 49
UE BSF
SIM
Ub handler
2.
3.
12.
13.
Application
GBA Module
1.
18.
4.
5.
11.
14.
17.
Zh´ handler
Bootstrap. logic
10.
15.
16.
session data
Bootstrapping
HLR
data
Subscriber
Zh´ handler
6.
7.
8.
9.
Figure 3.9. 2G GBA message fl ow with HLR
The message fl ow for this scenario is similar to the one described for normal GAA in the
previous section, but has some particularities.
1. An application in the UE has come to a state that it needs application-specifi c GAA
keys from the GBA module in the UE. Thus, it contacts the GBA module in the UE
and gives it the NAF_ID.
2. The GBA module contacts the SIM card and asks for the IMSI.
3. The SIM returns the IMSI to the GBA module. The GBA module converts the IMSI
to the IMPI format so that it can be carried over the Ub reference point.
4. The UE sets up a server-authenticated TLS tunnel to the BSF on the Ub interface.
The authentication of the BSF is performed using certifi cates. The further
communication between ME and BSF is sent through this secure TLS tunnel.
The TLS usage is the fi rst difference between 2G GBA and GBA_ME. TLS is
required because the BSF needs to be authenticated using a certifi cate that has been
50 Cellular Authentication for Mobile and Internet Services
Figure 3.9. 2G GBA message fl ow with HLR (continued)
issued by a trusted certifi cation authority (CA). In GBA_ME, the BSF is indirectly
authentication as part of the AKA.
Also upon receiving messages, both the UE and the BSF should check that the
‘realm’ parameter contains the same FQDN that is present in BSF’s certifi cate that
was used to setup the TLS tunnel. The ‘realm’ check is performed to make sure that
there is no man-in-the-middle.
5. The UE now sends an initial HTTP request containing subscriber’s IMPI. An example
request may look like this:
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-7
Date: Thu, 25 Oct 2007 2:38:00 GMT
Accept: */*
Authorization: Digest
username=”<IMPI>”,
realm=”bsf.home1.net”,
nonce=””,
uri=”/”,
response=””
6. The BSF converts IMPI back to IMSI format. Then the BSF requests the authentication
vector from the HLR using the Zh′ reference point as outlined in [TS29.109]. No
GUSS or USS is requested since the HLR is not designed to store the GUSS. If an
operator desires, he may have an additional database connected to the BSF that serves
as a GUSS repository, but this database and the discovery of the GUSS for this case
are not covered by the standard. If an operator has a mixed infrastructure and several
HLR and HSS deployed in his network, then the BSF may need to determine which
protocol to use for which subscriber. This selection process is also not covered by
the standard, but left for operator-specifi c implementations and confi guration, e.g.,
look-up server or enhanced SLF server.
7–8. The HLR retrieves the authentication vector from its internal database.
9. Since we consider here the SIM-based GBA variant, the HLR returns the requested
2G authentication vector AV = (RAND, SRES, Kc) over the Zh′ reference point.
Latest at this point of time, the BSF knows that the UE is equipped with a SIM card
by looking at the type of the received authentication vector. It should be noted that
the MAP protocol supports 3G and 2G authentication vector requests. The Zh′
reference point is used when the HSS does not support the diameter-based Zh or
when there is only an HLR available.
10. The BSF converts the received 2G authentication vector (AV = (RAND, SRES, Kc)
to the 2G GBA-specifi c RES by setting
RES
which is truncated to 128 most signifi cant bits, and where key is
= KDF (key, ‘3gpp-gba-res’, SRES),
Generic Authentication Architecture 51
Figure 3.9. 2G GBA message fl ow with HLR (continued)
key = Kc || Kc || RAND.
Also the BSF selects a 128-bit random number ‘Ks-input’ and sets the serverspecifi c data equal to the Ks-input in the AKA-nonce of HTTP Digest AKA and stores
the data
11. The BSF sends the RAND, the AUTN (which contains only 0 × 00 octets), and the
Ks-input as the server-specifi c data through the TLS tunnel in the 401 message. This
in turn triggers the UE to authenticate itself.
HTTP/1.1 401 Unauthorized
Server: Bootstrapping Server; Release-7
Date: Thu, 25 Oct 2007 2:38:00 GMT
WWW-Authenticate: Digest
realm=”bsf.home1.net”,
nonce=”base64(RAND + AUTN(=0x00..00) + Ks-input)”,
algorithm=AKAv1-MD5,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”
12–13. The GBA module in the UE obtains the RAND from the received message and then
communicates with the SIM card to calculate the corresponding Kc, SRES and also
the 2G GBA-specifi c RES.
14. The GBA module in the UE sends the HTTP Digest AKA response message to the
BSF using the GBA-specifi c RES value as a password.
qop=”auth-int”,
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-7
Date: Thu, 25 Oct 2007 2:38:00 GMT
Accept: */*
Authorization: Digest
username=”<IMPI>”,
realm=”bsf.home1.net”,
uri=”/”,
qop=auth-int,
nc=00000001,
cnonce=”6629fae49393a05397450978507c4ef1”,
response=”6629fae49393a05397450978507c4ef1”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
algorithm=AKAv1-MD5
15. The BSF can now authenticate the UE by verifying the HTTP Digest AKA response
message received. Then the BSF generates the master session key Ks:
nonce=”base64(RAND + AUTN(=0x00..00) + Ks-input)”,
52 Cellular Authentication for Mobile and Internet Services
Figure 3.9. 2G GBA message fl ow with HLR (continued)
Ks = KDF (key, Ks-input, ‘3gpp-gba-ks’, SRES).
The BSF also generates the key identifi er B-TID value from the base64 encoded
RAND value and the BSF server name, i.e., the B-TID is of the form
B-TID = base64encoded(RAND)@BSF_servers_domain_name.
The BSF stores the GAA session master key, the B-TID and the associated key
lifetime.
16. The BSF returns the B-TID and the key lifetime of the GAA session master key and
indicates the success of the authentication.
HTTP/1.1 200 OK
Server: Bootstrapping Server; Release-7
Authentication-Info: qop=auth-int,
rspauth=”6629fae49394a05397450978507c4ef1”,
cnonce=”6629fae49393a05397450978507c4ef1”,
nc=00000001,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
nonce=”base64(RAND + AUTN(=0x00..00) + Ks-input)”,
qop=auth-int
Date: Thu, 25 Oct 2007 2:38:00 GMT
Expires: Thu, 25 Oct 2007 14:38:00 GMT
Content-Type: application/vnd.3gpp.bsf+xml
Content-Length: 185
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp-gba”>
<btid>user@bsf.operator.com</btid>
<lifetime>2007-10-25T14:38:00Z</lifetime>
</BootstrappingInfo>
17. Upon receiving the message, the GBA module validates message by checking the
‘rspauth’ value. If this validation is successful, the GBA module generates the master
session key Ks in the same manner as the BSF did in step 15. The GBA module
stores then the GAA master session key, the key lifetime and the B-TID.
18. The GBA module derives from the GAA master session key Ks, the applicationspecifi c key Ks_NAF and sends it to the application so that the application can use
the key to secure the communication over Ua reference point.
Generic Authentication Architecture 53
(a) The terminal contains a SIM card and uses 2G GBA:
If the NAF is able to use GBA_U, it would send the GBA_U awareness indicator over the Zn reference point to the BSF. Since the BSF uses 2G GBA, it
would, in this case, return in the ME Key material fi eld the Ks_NAF. The UICC
key material fi eld would not be sent to the NAF. Additionally, the BSF can utilize
the User Security Settings (USS) to indicate which key to use by populating the
KeyChoice fi eld in the USS stating if ‘Ks_NAF or Ks_ext_NAF’ is supposed to
be used. The NAF receives also indication that the SIM has been used by setting
the GBA Type equal to 1 [TS29.109].
If the NAF is not GBA_U-aware and sends no indicator to the BSF or sets
the indicator accordingly, then the BSF returns in the ME key material fi eld the
Ks_NAF and the UICC-Key-Material fi eld would not be sent. The BSF may send
the USS information if saying ‘Ks_NAF or Ks_ext_NAF’ is supposed to be used
(not the population of the actual fi elds does not have these values). As in the
previous case, the NAF will also get indication that SIM has been used since the
GBA Type would be set to 1. The GBA Type fi eld is only for indication if SIMbased GBA has been used or not.
(b) The terminal contains a GBA_U unaware UICC and uses GBA_ME:
If the NAF is able to use GBA_U keys, then it would send a GBA_U awareness
indication to the BSF. The BSF returns then in the ME key material fi eld the
GBA_ME key Ks_NAF since the card in the terminal is not GBA_U aware. The
UICC key material fi eld would not be populated by the BSF. The BSF may additionally send the USS, containing the key usage fi eld and the GBA-type fi eld.
If the NAF is not GBA_U-aware, it sends no indicator to the BSF or sets the
indicator accordingly. In this case, the BSF returns in the ME key material fi eld
the GBA_ME key Ks_NAF and the UICC key material fi eld would be empty.
The BSF may send the USS information stating if ‘Ks_NAF or Ks_ext_NAF’
are supposed to be used and that no SIM has been used (GBA Type = 0).
(c) The terminal contains a GBA_U-aware UICC and uses GBA_U:
If the NAF is able to work with GBA_U keys, i.e., Ks_int_NAF and Ks_ext_
NAF, then it would give a GBA_U awareness indication to the BSF. If the
GBA_U smart card internal key Ks_int_NAF is intended to be used then the
NAF shall send a GSID (GAA Service Identifi er) to request the USS identifi able
via the GSID. The BSF returns then in the ME key material fi eld the Ks_ext_
NAF, since the card is GBA_U-aware. The BSF may include the Ks_int_NAF
and the BSF needs to return the USS information if ‘Ks_int_NAF’ or the ‘Ks_
int_NAF AND the Ks_ext_NAF’ are supposed to be used. The NAF will also
get indication that no SIM has been used.
If the NAF is not GBA_U-aware and sends no indicator to the BSF or sets
the indicator accordingly, then the BSF returns in the ME key material fi eld only
54 Cellular Authentication for Mobile and Internet Services
the Ks_ext_NAF and the UICC key material fi eld would be empty since the NAF
did not indicate that it supports usage of the Ks_int_NAF key. The BSF may
return USS that indicates that Ks_NAF or Ks_ext_NAF is to be used. The NAF
will also get indication that no SIM has been used. If the NAF is not requesting
a USS, then in this case, the NAF is not aware that the key it received is the
Ks_ext_NAF and not the Ks_NAF key.
It should be noted that the support of USS is optional for the operator, but if
an operator wants to use GBA_U, then USS support is required. For GBA_U
the BSF needs to modify the authentication vectors received from HSS and needs
to deduct the information when to make this modifi cation from the USS. If the
card is GBA_U-aware, then the terminal will utilize GBA_U. If a GBA_Uunaware UICC contains a USIM and a SIM application, then the terminal will
use GBA_ME and interacts with the USIM application for GBA.
3.3.5 3GPP2 GBA
GAA core functionality has also been specifi ed in 3rd Generation Partnership
Project 2 (3GPP2), the North American counterpart of 3GPP. 3GPP2 has agreed to
use GAA specifi ed in 3GPP when the bootstrapping is based on SIM, USIM or ISIM.
However, they have also specifi ed in [S.S0109-0] a way to utilize Code Division
Multiple Access–based (CDMA-based) authentication mechanism in GAA as well.
CDMA is the North American alternative to GSM. These CDMA-based alternatives
for GAA are based on the CDMA2000 1× and CDMA2000 1× EV-DO (Evolution –
Data Only or Data Optimized). CDMA2000 1× is the fi rst phase of CDMA2000.
CDMA2000 1× EV-DO is optimized CDMA carrier for packet data services and the
wireless data access based on CDMA. 3GPP2 bootstrapping mechanisms are based
on password protected Diffi e-Hellman key exchange [C.S0016-C] is where the
authentication is done based on CDMA authentication mechanisms. The details and
parameters for Diffi e-Hellman key agreement are defi ned in [S.S0109-0]. It uses the
p value taken from second Oakley group defi ned in [RFC 2409] but with a generator
g of 13.
CDMA devices are typically equipped with User Identity Module (UIM) or
Removable User Identity Module (R-UIM). The main difference between the two is
that the UIM is part of the terminal and the R-UIM can be physically removed from
the terminal. The R-UIM can be either a stand-alone module as defi ned [C.S0023-C],
or a multi-application platform, i.e., UICC, that may hold several applications that
can be operated concurrently. In this section, we call all type of UIMs that are
unaware of the GAA, i.e., do not have any GAA-specifi c functionality legacy UIMs.
The UIMs that are aware of GAA are called GAA-aware UIMs.
In this section, we describe these legacy CDMA GAA bootstrapping mechanisms
in high level. The reader is referred to 3GPP2 specifi cations and [S.S0109-0] in
Generic Authentication Architecture 55
particular to fi nd out the details. For example, how to calculate the BS_RESULT,
MS_RESULT, and temporary AKA key can be found in Section 4.5.2.2.3 of [S.
S0109-0]. The same section also describes how CK, IK and RES are obtained from
the temporary AKA key and the AKA Challenge.
Note about standardization status in 3GPP2: At the time of writing this book, the
GAA specifi cation work is currently ongoing in 3GPP2. For example, the Zn interface is currently being standardized and most likely it is based on the work done in
3GPP. Additionally, the specifi cation [S.S0109-0] contains a few fl aws that should
be noted and corrected:
‘GET mistake’: All of the HTTP requests issued over the Ub interface are GET
•
requests. However, they should be POST requests as the terminal is sending data
to the BSF in the HTTP payload.
‘qop mistake’: The specifi cation mistakenly claims that the 401 authentication chal-
•
lenge messages are integrity protected, when qop is set to ‘auth-int’. However, as
specifi ed in [RFC2617], the challenge message (401) is not integrity protected even
though the qop is set to ‘auth-int’. This is because in the normal HTTP digest case,
the qop in this phase is used to indicate to the client what qop options are supported
and allowed by the server. The HTTP payload or any other part of the HTTP
response is not protected by the HTTP digest as is hinted in the specifi cation.
The message sequence fl ows are described in this section as they are specifi ed in
[S.S0109-0], thus, the above mistakes are either written in (GET mistake) or omitted
(qop mistake).
Bootstrapping with CDMA2000 1¥
CDMA2000 1× uses Cellular Authentication and Voice Encryption (CAVE) procedures to authenticate terminals in CDMA2000 1× networks. More details on CAVE
authentication procedures can be found in [C.S0023-C], Section 4.2.2. The GAA
uses this infrastructure to establish a shared secret between the terminal and the BSF
the following way.
The BSF uses the authentication request (AUTHREQ) transactions over MAP
protocol [X.S0004-540-E] to request authentication response (AUTHU) and random
variable (RAND) unique challenge pair. They are transformed into a RAND and
authentication response (AUTHR) pair, and these are used by the BSF to request the
associated session keys, i.e., the signalling message encryption key (SMEKEY) and
the CDMA private long code mask (CDMAPLCM) from the Foreign Location Registry / Authentication Center (FLR/AC). The RAND parameter (used in CAVE) is
transported to the Mobile Node (MN) using HTTP Digest authentication mechanism.
The MN will then generate the AUTHR, SMEKEY and CDMAPLCM by sending
the RAND to the legacy User Identity Module (UIM) that contains the CAVE
56 Cellular Authentication for Mobile and Internet Services
functionality. After this, both the BSF and the MN have AUTHR and session keys
(SMEKEY and CDMAPLCM) available.
The Diffi e-Hellman key agreement is used to ensure the cryptographic separation
between the CAVE-generated key material (SMEKEY, CDMAPLCM and AUTHR)
and the GAA master session key (Ks). The generated key material is used as the
password for authenticating the Diffi e-Hellman key agreement between the MN and
the BSF. The password (PW) is formed by concatenating the key material:
SMEKEY⎪CDMAPLCM⎪AUTHR (⎪ denotes the concatenation). These are also
noted in the sequence fl ow below as mobile station password (MS_PW) and base
station password (BS_PW), which are equal. During the procedure, the BSF also
generate an AKA challenge that is sent to the MN.
The MN and the BSF will utilize the password generated from the PW and the
Diffi e-Hellman key agreement procedure to generate a temporary AKA key. This temporary key is used as the key (K) in the following AKA functions, the AKA challenge
is used as the RAND in standard 3GPP2 AKA functions f3, f4 and f2 functions to generate the CK, IK and RES [S.S0055-A]. These are then used as defi ned in GBA_ME,
i.e., RES is used as the password in HTTP Digest calculations and the GAA master
session key (Ks) is generated by concatenating CK and IK. (See Figure 3.10.)
Bootstrapping with CDMA2000 1¥ EV-DO and Legacy UIM
The CDMA2000 1× EV-DO (Evolution – Data Only / Data Optimized) uses the
Mobile IP (MIP) authentication to authenticate terminals in CDMA2000 1× EV-DO
networks. MIP authentication procedures can be found in Section 4.7.3 of [C.S0023C]. The GAA uses this infrastructure to establish a shared secret between the terminal
and the BSF the following way.
The BSF and the terminal use HTTP Digest to transport the MIP authentication
message exchanges between them. Once the GBA module in the terminal and the
BSF possess the MN- Authentication, Authorization and Accounting (MN-AAA)
Authenticator, they are ready to perform the password-protected Diffi e-Hellman key
exchange similarly as in the CDMA2000 1× case in previous section. The communication between the BSF and the Home-AAA (H-AAA) is based on the Remote
Authentication Dial-In User Service (RADIUS) protocol. (See Figure 3.11.)
Bootstrapping with CDMA2000 1¥ EV-DO and GAA-aware UIM
3GPP2 have also defi ned a case where a CDMA1× EV-DO terminal is equipped with
a GAA-aware UIM. In this case, part of the GAA functionality, i.e., key derivation
is moved to UIM.
The GAA-aware UIM prevents the usage of normal MIP authentication procedure,
which is used with legacy UIMs. This is achieved so that the BSF and the MN derive
MS_CHALLENGE* and BS_CHALLENGE* by concatenating the exchanged MS_
CHALLEGE and BS_CHALLENGE (i.e., MS_CHALLENGE* = BS_CHALLENGE* = MS_CHALLENGE ⎪⎪ BS_CHALLENGE). The BSF will send the
Generic Authentication Architecture 57
MN
CAVE on UIM
10.
11.
BSF
Application
GBA Module
1.
2.
9.
12.
15.
16.
Ub handler
Zh handler
Bootstrap. logic
7.
8.
13.
14.
session data
Bootstrapping
3.
4.
5.
6.
HLR/AC
Zh handler
data
Subscriber
Figure 3.10. CDMA2000 1×-based bootstrapping with legacy UIM
1. An application in the Mobile Node (MN) has come to a state that it needs applicationspecifi c GAA keys from the GBA module in the MN. Thus, it contacts the GBA
module in the MN and gives it the NAF_ID.
2. The MN sends an HTTP GET request to the BSF, which contains the user’s identity
in the form of ‘IMSI@realm.com’ as the username in the Authorization header. The
GBA module has obtained this identity earlier from the legacy UIM. The Electronic
Serial Number (ESN) value of the MN is also sent to the BSF in the HTTP payload
(in CDMA, the ESN is one cornerstone of the general security architecture).
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; 3GPP2 GBA
version 1.0
Date: Thu, 21 Nov 2007 14:09:15 GMT
Accept: */*
Content-Length: 95
58 Cellular Authentication for Mobile and Internet Services
Figure 3.10. CDMA2000 1×-based bootstrapping with legacy UIM (continued)
Content-Type: application/vnd.3gpp2.bsf+xml
Authorization: Digest
username=”<IMSI>@<realm.com>”,
realm=”bsf.home1.net”,
nonce=””,
uri=”/”,
response=””
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<esn>base64(ESN)</esn>
</bootstrappingInfoType>
3. The BSF extracts the IMSI from the username parameter and sends an AUTHREQ
message for getting the RANDU and the AUTHU pair to the HLR/AC. The
AUTHREQ includes the parameters IMSI, ESN and the SYSACCTYPE set to GBA
access.
4. The HLR/AC responds with an authreq, which includes the RANDU and AUTHU
pair. The BSF takes the 24-bit RANDU value and concatenates it with the 8 least
signifi cant bits of IMSI_S2 derived from the IMSI to create the RAND. The BSF
sets the AUTHR equal to the AUTHU. It also generates a secret random number x
and calculates (g
x
mod p).
An IMSI_S2 consists out of the most signifi cant 3-digit (10 bits) part of a 10-digit
IMSI_S. An IMSI_S is a 10-digit (34 bits) number derived from the IMSI. If an IMSI
with equal or more then 10 digits is used, then the IMSI_S is equal to the last 10
digits of the lMSI. If the IMSI has strictly less than 10 digits, then the least signifi cant
digits of the IMSI_S are the ones of the IMSI and then to the most signifi cant side
zeros are added to obtain 10 digits.
5. The BSF sends an AUTHREQ message for getting the session keys (SMEKEY
and CDMAPLCM) from the HLR/AC. The AUTHREQ includes the parameters
AUTHR, RAND and the SYSACCTYPE set to GBA access. The SYSCAP parameter
is set to indicate that the authentication parameters were requested on the system
access (bit A = 1) and that Signalling Message Encryption and Voice Privacy are
supported by the system (bit B = 1 and bit C = 1). All other SYSCAP parameters are
set to zero.
The Home Location Register / Authentication Centre (HLR/AuC) validates the
AUTHR and generates the SMEKEY and CDMAPLCM.
6. The HLR/AuC transfers the session keys (SMEKEY and CDMAPLCM) to the BSF.
Upon receiving the session keys, the BSF calculates the
BS_PW = MS_PW = SMEKEY|CDMAPLCM|AUTHR.
Generic Authentication Architecture 59
Figure 3.10. CDMA2000 1×-based bootstrapping with legacy UIM (continued)
The BSF also generates a 128 bit random AKA challenge.
7–8. The BSF stores the session data to its local session database.
9. The BSF sends an HTTP 401 response to the MN. The AKA challenge and RAND
are based64 encoded and carried in the nonce fi eld of the WWW-Authenticate header.
The payload carries the BS_RESULT parameter.
HTTP/1.1 401 Unauthorized
Server: Bootstrapping Server; Release-6
Date: Thu, 21 Nov 2007 14:09:16 GMT
Content-Length: 99
Content-Type: application/vnd.3gpp2.bsf+xml
WWW-Authenticate: Digest
realm=”bsf.home1.net”,
nonce=”base64(AKA challenge + RAND)”,
algorithm=AKAv1-MD5,
qop=”auth-int”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<bs_result>base64(BS_RESULT)</bs_result>
</bootstrappingInfoType>
10. The GBA module in the MN verifi es that the received BS_RESULT is not zero.
The RAND challenge value is sent to the legacy UIM as a simulated Global
Challenge.
11. The legacy UIM responds to the global challenge with an AUTHR, SMEKEY and
CDMAPLCM.
The GBA module calculates MS_PW / BS_PW the same way as the BSF did in
step 6. It then recovers the BS_RESULT received from the BSF in step 9. It then
generates a secret random number y for the Diffi e-Hellman and calculates (gy mod
p) and (gxy mod p). It then generates the 128-bit random number, CRAND, and
calculates the temporary AKA key and the MS_RESULT value. Using the temporary
AKA key as K and the AKA challenge (received from the BSF in step 9) as RAND
with standard AKA functions, the GBA module can generate CK, IK and a 128-bit
RES. The GBA module sets the GAA master session key to be Ks = CK⎪IK.
12. The MN sends another HTTP GET request to the BSF with an appropriate
Authorization header. The Digest response is computed as specifi ed in [RFC2617]
using the RES as password. The HTTP request contains CRAND in the cnonce fi eld
of the Authorization header and MS_RESULT in the HTTP payload. They are both
base64-encoded.
60 Cellular Authentication for Mobile and Internet Services
Figure 3.10. CDMA2000 1×-based bootstrapping with legacy UIM (continued)
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-6
Date: Thu, 21 Nov 2007 14:09:16 GMT
Content-Length: 99
Content-Type: application/vnd.3gpp2.bsf+xml
Accept: */*
Authorization: Digest
username=”<IMSI>@<realm.com>”,
realm=”bsf.home1.net”,
nonce=”base64(AKA challenge + RAND)”,
uri=”/”,
qop=auth-int,
nc=00000001,
cnonce=”base64(CRAND)”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
algorithm=AKAv1-MD5
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<ms_result>base64(MS_RESULT)</ms_result>
</bootstrappingInfoType>
response=”6629fae49393a05397450978507c4ef1”,
The BSF verifi es that the received MS_RESULT is not zero. The BSF extracts the
CRAND from the cnonce fi eld. It will then use the MS_PW / BS_PW to recover (gy
mod p). From this it calculates (gxy mod p) and the temporary AKA key. The BSF
will use the temporary AKA key and the AKA challenge the same way as the MN
did in step 11 to obtain CK, IK and RES. The BSF then authenticates the MN by
verifying the digest response using the RES as the password. If the verifi cation is
successful, the BSF sets GAA master session key Ks to be CK⎪IK.
13–14. The BSF generates the B-TID by taking the base64-encoded AKA challenge value
and the BSF server name:
B-TID = base64encode(AKA challenge)@<BSFservername>.
It then stores the B-TID, Ks and any other implementation-specifi c parameters to its
local session database.
Generic Authentication Architecture 61
Figure 3.10. CDMA2000 1×-based bootstrapping with legacy UIM (continued)
15. The BSF sends a 200 OK response to the MN. The payload contains B-TID and key
lifetime. The Authentication-Info header is calculated using the RES as the password
and with qop set to ‘auth-int’, i.e., the HTTP payload is included in the digest
calculations and is hence integrity protected as specifi ed in [RFC2617].
HTTP/1.1 200 OK
Server: Bootstrapping Server; Release-6
Authentication-Info: qop=auth-int,
rspauth=”6629fae49394a05397450978507c4ef1”,
cnonce=”base64(CRAND)”,
nc=00000001,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
nonce=”base64(AKA challenge + RAND)”,
qop=auth-int
Date: Wed, 21 Nov 2007 14:09:16 GMT
Expires: Wed, 21 Oct 2007 20:09:16 GMT
Content-Type: application/vnd.3gpp2.bsf+xml
Content-Length: 185
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<btid>base64(AKA challenge)@bsf.operator.com</btid>
<lifetime>2007-11-21T20:09:16Z</lifetime>
</BootstrappingInfo>
The GBA module verifi es digest calculations of Authentication-Info header. If the
verifi cation is successful, the BSF is authenticated, and the GBA module stores the
Ks, the B-TID, the key lifetime and any other implementation-specifi c data to its
local session cache.
This concludes the bootstrapping procedure based on CDMA2000 1× CAVE
procedure.
16. The GBA module derives the application-specifi c GAA key using the Ks
and the NAF_ID. Then returns the application-specifi
key lifetime to the application, and the application can start to use the key with a
NAF.
c GAA key, B-TID, and
62 Cellular Authentication for Mobile and Internet Services
MN
MN-AAA on UIM
8.
9.
Application
GBA Module
1.
14.
2.
7.
10.
13.
BSF
Ub handler
Zh handler
Bootstrap. logic
5.
6.
11.
12.
session data
Bootstrapping
3.
4.
Figure 3.11. CDMA2000 1× EV-DO-based bootstrapping with legacy UIM
H-AAA
Zh handler
data
Subscriber
1. An application in the Mobile Node (MN) has come to a state that it needs
application-specifi c GAA keys from the GBA module in the MN. Thus, it
contacts the GBA module in the MN and gives it the NAF_ID.
2. The MN generates a 16-byte random number, MS_CHALLENGE. The MN sends
an HTTP GET request to the BSF, which contains the user’s identity in the form of
‘IMSI@realm.com’ as the username in the Authorization header. The GBA module
has obtained this identity earlier from the legacy UIM. The MS_CHALLENGE value
is also sent to the BSF in the HTTP payload.
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; 3GPP2 GBA
version 1.0
Date: Thu, 22 Nov 2007 15:09:15 GMT
Accept: */*
Content-Length: 95
Content-Type: application/vnd.3gpp2.bsf+xml
Authorization: Digest
username=”<IMSI>@<realm.com>”,
Generic Authentication Architecture 63
Figure 3.11. CDMA2000 1× EV-DO-based bootstrapping with legacy UIM (continued)
realm=”bsf.home1.net”,
nonce=””,
uri=”/”,
response=””
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<ms_chall>base64(MS_CHALLENGE)</ms_chall>
</bootstrappingInfoType>
3. The BSF extracts the IMSI from the username parameter. It also generates two
random numbers: 128-bit AKA Challenge and a 16-byte BS_CHALLENGE. The
BSF also generates a random number x and calculates (g
x
mod p). The BSF will then
send an Access Request message acting as a RADIUS client to the H-AAA to request
the MN-AAA Authenticator associated with the MN. The request contains both
MS_CHALLENGE and BS_CHALLENGE parameters.
The H-AAA calculates the MN-AAA Authenticator using its subscriber database
and the MS_CHALLENGE and the BS_CHALLENGE parameters that it received
from the BSF.
4. The H-AAA responds with the Access Accept message containing the MN-AAA
Authenticator, and the BSF sets the BS_PW and the MS_PW to equal the MN-AAA
Authenticator.
5–6. The BSF stores the session data to its local session database.
7. The BSF sends an HTTP 401 response to the MN. The AKA challenge and BS_
CHALLENGE are based64-encoded and carried in the nonce fi eld of the WWWAuthenticate header. The payload carries the BS_RESULT parameter.
HTTP/1.1 401 Unauthorized
Server: Bootstrapping Server; Release-6
Date: Thu, 22 Nov 2007 15:09:16 GMT
Content-Length: 99
Content-Type: application/vnd.3gpp2.bsf+xml
WWW-Authenticate: Digest
realm=”bsf.home1.net”,
nonce=”base64(AKA challenge + BS_CHALLENGE)”,
algorithm=AKAv1-MD5,
qop=”auth-int”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<bs_result>base64(BS_RESULT)</bs_result>
</bootstrappingInfoType>
64 Cellular Authentication for Mobile and Internet Services
Figure 3.11. CDMA2000 1× EV-DO-based bootstrapping with legacy UIM (continued)
8. The GBA module in the MN verifi es that the received BS_RESULT is not zero. The
GBA module extracts the BS_CHALLENGE from the nonce parameter in WWWAuthenticate header and sends it together with the previously generated MS_
CHALLENGE parameter to the legacy UIM and requests the MN-AAA algorithm
in the legacy UIM to compute the MN-AAA Authenticator.
9. The MN-AAA algorithm in the legacy UIM computes the 16-byte MN-AAA
Authenticator using the MN-AAA Key, and received MS_CHALLENGE (as Mobile
IP Registration request message, MIP-RRQ) and BS_CHALLENGE (as Mobile_IP
Challenge), see [C.S0023-C] Section 4.7.3 for details. The MN-AAA Authenticator
is returned to the GBA module.
The GBA module sets MS_PW / BS_PW to be the MN-AAA Authenticator
(as the BSF did in step 4). It then recovers the BS_RESULT received from the BSF
in step 7. It then generates a secret random number y for the Diffi e-Hellman and
calculates (g
y
mod p) and (gxy mod p). It then generates the 128-bit random number,
CRAND, and calculates the temporary AKA key and the MS_RESULT value. Using
the temporary AKA key as K and AKA challenge (received from the BSF in step 7)
as RAND with standard AKA functions, the GBA module can generate CK, IK and
a 128-bit RES. The GBA module sets the GAA master session key Ks to be
CK⎪IK.
10. The MN sends another HTTP GET request to the BSF with an appropriate
Authorization header. The Digest response is computed as specifi ed in [RFC2617]
using the RES as password. The HTTP request contains CRAND in the cnonce fi eld
of the Authorization header and MS_RESULT in the HTTP payload. They are both
base64-encoded.
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-6
Date: Thu, 22 Nov 2007 15:09:16 GMT
Content-Length: 99
Content-Type: application/vnd.3gpp2.bsf+xml
Accept: */*
Authorization: Digest
username=”<IMSI>@<realm.com>”,
realm=”bsf.home1.net”,
nonce=”base64(AKA challenge + BS_CHALLENGE)”,
uri=”/”,
qop=auth-int,
nc=00000001,
cnonce=”base64(CRAND)”,
response=”6629fae49393a05397450978507c4ef1”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
algorithm=AKAv1-MD5
Generic Authentication Architecture 65
Figure 3.11. CDMA2000 1× EV-DO-based bootstrapping with legacy UIM (continued)
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<ms_result>base64(MS_RESULT)</ms_result>
</bootstrappingInfoType>
The BSF verifi es that the received MS_RESULT is not zero. The BSF extracts the
CRAND from the cnonce fi eld. It will then use the MS_PW / BS_PW to recover (g
mod p). From this, it calculates (gxy mod p) and the temporary AKA key. The BSF
will then use temporary AKA key and AKA challenge the same way as the MN did
in step 9 to obtain CK, IK and RES. The BSF then authenticates the MN by verifying
the digest response using the RES as the password. If the verifi cation is successful,
the BSF sets the Ks to be CK⎪IK.
11–12. The BSF generates the B-TID by taking the base64-encoded AKA challenge value
and the BSF server name:
B-TID = base64encode(AKA challenge)@<BSFservername>.
It then stores the B-TID, the Ks, and any other implementation-specifi c parameters
to its local session database.
13. The BSF sends a 200 OK response to the MN. The payload contains B-TID and key
lifetime. The Authentication-Info header is calculated using the RES as the password
and with qop set to ‘auth-int’, i.e., the HTTP payload is included in the digest
calculations and is hence integrity-protected as specifi ed in [RFC2617].
HTTP/1.1 200 OK
Server: Bootstrapping Server; Release-6
Authentication-Info: qop=auth-int,
rspauth=”6629fae49394a05397450978507c4ef1”,
cnonce=”base64(CRAND)”,
nc=00000001,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
nonce=”base64(AKA challenge + BS_CHALLENGE)”,
qop=auth-int
Date: Thu, 22 Nov 2007 15:09:16 GMT
Expires: Thu, 22 Oct 2007 21:09:16 GMT
Content-Type: application/vnd.3gpp.bsf+xml
Content-Type: application/vnd.3gpp2.bsf+xml
Content-Length: 185
y
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<btid>base64(AKA challenge)@bsf.operator.com</btid>
<lifetime>2007-11-22T21:09:16Z</lifetime>
</BootstrappingInfo>
66 Cellular Authentication for Mobile and Internet Services
Figure 3.11. CDMA2000 1× EV-DO-based bootstrapping with legacy UIM (continued)
The GBA module verifi es digest calculations of Authentication-Info header. If the
verifi cation is successful, the BSF is authenticated, and the GBA module stores the
Ks, the B-TID, the key lifetime and any other implementation-specifi c data to its
local session cache.
This concludes the bootstrapping procedure based on CDMA2000 1× EV-DO
Mobile IP authentication procedure.
14. The GBA module derives the application-specifi c GAA key using the Ks and the
NAF_ID. Then returns the application-specifi c GBA key, B-TID, and key lifetime to
the application, and the application can start to use the key with an NAF.
MS_CHALLENGE* and BS_CHALLENGE* to the H-AAA, which retrieves the
MN-AAA key of the user, and computes the MN-AAA Authenticator.
The GAA-aware UIM will similarly compute the MN-AAA Authenticator, which
will not leave the UIM. Instead, the UIM will return the hash of the MN-AAA
authenticator to the ME. Furthermore, GAA-aware UIM will not respond to a normal
MN-AAA challenge where the hash of MIP-RRQ is the same as hash of BS_CHALLENGE. This will effectively protect the MN-AAA authenticator as it is never given
to the MN in this case as MS_CHALLENGE* and BS_CHALLENGE* are the
same.
Other procedures are identical to the bootstrapping case with a legacy UIM. (See
Figure 3.12.)
3.4 Building Blocks of GAA
3.4.1 Introduction
The GAA provides a general-purpose service that creates application-specifi c shared
keys between application servers and the mobile terminal. This is a cornerstone on
top of which security of various applications and services can be built. How this is
done (or should be done) depends on the characteristics of the application but it is
also clear that there are many similar needs for security mechanisms between seemingly different services. Therefore, it makes sense to have some general-purpose
security services that can be built on top of GAA. These building blocks can then
be used in combination with GAA to secure variety of services.
There is always the option to defi ne application-specifi c mechanism to use GAAgenerated keys for the security of the application. This is basically the approach that
is taken, e.g., by MBMS. However, this is far from trivial task even in the case it
has been done many times before. The approach taken by the building blocks of
Generic Authentication Architecture 67
MN
MN-AAA on UIM
8.
9.
10.
11.
16.
17.
18.
Application
GBA Module
1.
19.
2.
7.
12.
15.
BSF
Ub handler
Zh handler
Bootstrap. logic
5.
6.
13.
14.
session data
Bootstrapping
3.
4.
H-AAA
Zh handler
data
Subscriber
Figure 3.12. CDMA2000 1× EV-DO-based bootstrapping with GAA-aware UIM
1. An application in the MN has come to a state that it needs application-specifi c GAA
keys from the GBA module in the MN. Thus, it contacts the GBA module in the MN
and gives it the NAF_ID.
2. The MN generates a 16-byte random number, MS_CHALLENGE. The MN sends
an HTTP GET request to the BSF, which contains the user’s identity in the form of
‘IMSI@realm.com’ as the username in the Authorization header. The GBA module
has obtained this identity earlier from the legacy UIM. The MS_CHALLENGE value
is also sent to the BSF in the HTTP payload.
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; 3GPP2 GBA
version 1.0
68 Cellular Authentication for Mobile and Internet Services
Figure 3.12. CDMA2000 1× EV-DO-based bootstrapping with GAA-aware UIM
(continued)
Date: Thu, 22 Nov 2007 17:09:15 GMT
Accept: */*
Content-Length: 95
Content-Type: application/vnd.3gpp2.bsf+xml
Authorization: Digest
username=”<IMSI>@<realm.com>”,
realm=”bsf.home1.net”,
nonce=””,
uri=”/”,
response=””
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<ms_chall>base64(MS_CHALLENGE)</ms_chall>
</bootstrappingInfoType>
3. The BSF extracts the IMSI from the username parameter. It also generates two
random numbers: 128-bit AKA Challenge and a 16-byte BS_CHALLENGE. The
BSF also generates a random number x and calculates (gx mod p). The BSF discovers
that the UIM in the MN is GAA-aware by examining the IMSI and checking it against
a local database, where all GAA-aware UIMs identifi ed by IMSIs are stored.
Therefore, it will generate MS_CHALLENGE* and BS_CHALLENGE* by
concatenating MS_CHALLENGE and BS_CHALLENGE. The BSF will then send
an Access Request message acting as a RADIUS client to the H-AAA to request the
MN-AAA Authenticator associated with the MN. The request contains both MS_
CHALLENGE* and BS_CHALLENGE* parameters.
The H-AAA calculates the MN-AAA Authenticator using its subscriber database
and the MS_CHALLENGE* and the BS_CHALLENGE* parameters that it received
from the BSF.
4. The H-AAA responds with the Access Accept message containing the MN-AAA
Authenticator, and the BSF sets the BS_PW and the MS_PW to equal the MN-AAA
Authenticator.
5–6. The BSF stores the session data to its local session database.
7. The BSF sends an HTTP 401 response to the MN. The AKA challenge and
BS_CHALLENGE are based64-encoded and carried in the nonce fi eld of the WWWAuthenticate header. The payload carries the BS_RESULT parameter.
HTTP/1.1 401 Unauthorized
Server: Bootstrapping Server; Release-6
Date: Thu, 22 Nov 2007 17:09:16 GMT
Content-Length: 99
Content-Type: application/vnd.3gpp2.bsf+xml
WWW-Authenticate: Digest
Generic Authentication Architecture 69
Figure 3.12. CDMA2000 1× EV-DO-based bootstrapping with GAA-aware UIM
(continued)
realm=”bsf.home1.net”,
nonce=”base64(AKA challenge + BS_CHALLENGE)”,
algorithm=AKAv1-MD5,
qop=”auth-int”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<bs_result>base64(BS_RESULT)</bs_result>
</bootstrappingInfoType>
8. The GBA module in the MN verifi es that the received BS_RESULT is not zero. The
GBA module extracts the BS_CHALLENGE from the nonce parameter in WWWAuthenticate header. The GBA module is aware that the UIM in the MN is GAAaware and therefore it will generate the MS_CHALLENGE* and BS_CHALLENGE*
as the BSF did in step 3. Then it sends these parameters to the GAA-aware UIM and
requests the MN-AAA algorithm in the legacy UIM to compute the MN-AAA
Authenticator.
9. The MN-AAA algorithm in the GAA-aware UIM computes the 16-byte MN-AAA
Authenticator using the MN-AAA Key, and received MS_CHALLENGE* (as Mobile
IP Registration request message, MIP-RRQ) and BS_CHALLENGE* (as Mobile_IP
Challenge), see [C.S0023-C] Section 4.7.3 for details. As the GAA-aware UIM detect
that the MS_CHALLENGE* and BS_CHALLENGE* are equal, the GAA-aware
UIM will only return the SHA-1 hash of the MN-AAA Authenticator to the GBA
module.
The GBA module uses the hash of the MN-AAA Authenticator to calculate a
BS_PW_HASH and a MS_PW_HASH values, which are equal (see details [S.
S0109-A]). The BS_PW_HASH is used to obtain (g
x
mod p). It then generates a
secret random number y for the Diffi e-Hellman and calculates (gy mod p) and (gxy
mod p). Finally, the GBA module generates MS_RESULT value using MS_PW_
HASH and (gy mod p).
10. The GBA module sends the AKA challenge (received from the BSF in step 7) and
SHA-1 hash of (gx, gy, gxy) to the GAA-aware UIM.
11. The GAA-aware UIM generates the 128-bit random number, CRAND, and calculates
the temporary AKA key using the CRAND, received hash of (g
x
, gy, gxy), and the
stored MN-AAA Authenticator. Using the temporary AKA key as K and AKA
challenge (received originally from the BSF in step 7) as RAND with standard AKA
functions, the GBA module can generate CK, IK and a 128-bit RES. The GBA
module sets the GBA master secret Ks to be CK⎪IK. The GAA-aware UIM returns
only the CRAND and RES to the MN.
12. The MN sends another HTTP GET request to the BSF with an appropriate
Authorization header. The Digest response is computed as specifi ed in [RFC2617]
using the RES as password. The HTTP request contains CRAND in the cnonce fi eld
70 Cellular Authentication for Mobile and Internet Services
Figure 3.12. CDMA2000 1× EV-DO-based bootstrapping with GAA-aware UIM
(continued)
of the Authorization header, and MS_RESULT (calculated in step 9) in the HTTP
payload. They are both base base64 encoded.
GET / HTTP/1.1
Host: bsf.home1.net:80
User-Agent: Bootstrapping Client Agent; Release-6
Date: Thu, 22 Nov 2007 17:09:16 GMT
Content-Length: 99
Content-Type: application/vnd.3gpp2.bsf+xml
Accept: */*
Authorization: Digest
username=”<IMSI>@<realm.com>”,
realm=”bsf.home1.net”,
nonce=”base64(AKA challenge + BS_CHALLENGE)”,
uri=”/”,
qop=auth-int,
nc=00000001,
cnonce=”base64(CRAND)”,
response=”6629fae49393a05397450978507c4ef1”,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
algorithm=AKAv1-MD5
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<ms_result>base64(MS_RESULT)</ms_result>
</bootstrappingInfoType>
The BSF verifi es that the received MS_RESULT is not zero. The BSF extracts the
CRAND from the cnonce fi eld. It will then use the MS_PW / BS_PW to recover (gy
mod p). From this, it calculates (gxy mod p) and the temporary AKA key. The BSF
will then use temporary AKA key and AKA challenge the same way as the MN did
in step 11 to obtain CK, IK and RES. The BSF then authenticates the MN by verifying
the digest response using the RES as the password. If the verifi cation is successful,
the BSF sets the Ks to be CK⎪IK.
13–14. The BSF generates the B-TID by taking the base64-encoded AKA challenge value
and the BSF server name:
B-TID = base64encode(AKA challenge)@<BSFservername>.
It then stores the B-TID, the Ks, and any other implementation-specifi c parameters
to its local session database.
15. The BSF sends a 200 OK response to the MN. The payload contains B-TID
and key lifetime. The Authentication-Info header is calculated using the RES as the
password and with qop set to ‘auth-int’, i.e., the HTTP payload is included
Generic Authentication Architecture 71
Figure 3.12. CDMA2000 1× EV-DO-based bootstrapping with GAA-aware UIM
(continued)
in the digest calculations and is hence integrity-protected as specifi ed in
[RFC2617].
HTTP/1.1 200 OK
Server: Bootstrapping Server; Release-6
Authentication-Info: qop=auth-int,
rspauth=”6629fae49394a05397450978507c4ef1”,
cnonce=”base64(CRAND)”,
nc=00000001,
opaque=”5ccc069c403ebaf9f0171e9517f30e41”,
nonce=”base64(AKA challenge + RAND)”,
qop=auth-int
Date: Wed, 21Thu, 22 Nov 2007 1417:09:16 GMT
Expires: Wed, 21Thu, 22 Oct 2007 2023:09:16 GMT
Content-Type: application/vnd.3gpp.bsf+xml
Content-Type: application/vnd.3gpp2.bsf+xml
Content-Length: 185
<?xml version=”1.0” encoding=”UTF-8”?>
<BootstrappingInfo xmlns=”uri:3gpp2-gba”>
<btid>base64(AKA challenge)@bsf.operator.com</btid>
<lifetime>2007-11-21T2022T23:09:16Z</lifetime>
</BootstrappingInfo>
16. The GBA module verifi es digest calculations of Authentication-Info header. If the
verifi cation is successful, the BSF is authenticated, and the GBA module stores
the GAA master key Ks, the B-TID, and the key lifetime, and any other implementationspecifi c data to its local session cache, the GAA-aware UIM.
This concludes the bootstrapping procedure.
17. The GBA module proceeds with the generation of the application-specifi c GAA key
as was requested by the application in step 1. The GBA module sends the NAF_ID
and a Network Access ID (NAI) of the GAA-aware UIM to the GAA-aware UIM to
request the application-specifi c GAA key.
18. The GAA-aware UIM derives two keys using the stored Ks, the AKA challenge
(= RAND), the NAI, and NAF_ID: Ks_int_NAF that stays the UIM, and Ks_ext_
NAF that was given to the MN. The GAA-aware UIM returns the Ks_ext_NAF key
to the MN.
19. The GBA module returns the application-specifi c GAA key (Ks_ext_NAF), the
B-TID and the key lifetime to the application, and the application can start to use the
key with an NAF.
72 Cellular Authentication for Mobile and Internet Services
GAA is to defi ne how certain key security applications can make use of GAA. That
means we defi ne the usage of GAA-based keys for these security applications making
the task of providing security for the target applications much easier. Basically, with
the whole GAA, i.e., GAA bootstrapping and a suitable set of the other building
blocks on top of it, we have a handy toolbox that can be used for design of security
mechanisms for other applications.
GAA has been introduced in 3GPP Release 6. It has then been extended with
further functionality and additional building blocks. The building blocks and further
GAA enablers that have been defi ned for 3GPP GAA include the following:
Provisioning of subscriber (or client) certifi cates in a secure way. This feature is
•
called Support for subscriber certifi cates (SSC) and is specifi ed in [TS33.221].
Many applications have a built-in support for certifi cates, totally independent of
whether these certifi cates are provided by GAA or some other method. In the GAA
terminology, this kind of special NAF is a PKI portal.
Support for HTTPS sessions [TS33.222]. HTTPS refers to a secure HTTP and it
•
has been specifi ed how GAA-generated secrets can be used as credentials for
HTTPS. Here, the NAF can be a web server or an authentication proxy (AP) that
provides the HTTPS-secured tunnel for applications that need to be secured.
Key distribution service for terminals and remote devices [TS33.259]. GAA as
•
such is essentially a key generation service that provides keys between the UE
and the network element called NAF. In many cases, it would be benefi cial to have
a shared key between, e.g., two terminals. In this building block, the NAF is a key
distribution server. The key distribution service is a feature of Release 7.
Key distribution service for smart card and terminal [TS33.110]. Similarly as in
•
the previous building block, we get a key generation service to provision keys to
the smart card and the terminal (also includes the case that the terminal might be
remote device). In this building block, the NAF is a key distribution server. Also
this type of key distribution service is a feature of Release 7.
3.4.2 PKI Portal
In the following, we describe how the UE is able to fetch a subscriber certifi cate from
the specifi c NAF, called PKI portal [TS33.221]. We include the case where the UE has
a Wireless Identity Module (WIM), which is where the private key is stored, and the
corresponding public key being the one that needs to be certifi ed. The private keystore
may be also in other format than WIM, and the same protocol usable with other types
of keystores like.hardware tokens, and software key repositories. (See Figure 3.13.)
The usage of the subscriber certifi cates has basically very few limitations. The
most usual format of certifi cates, X.509, is supported by the method. Defi ning the
use cases is mainly out of the scope of 3GPP but maybe done in fora like OMA for
certain cases.
Generic Authentication Architecture 73
UE NAF
WIM
4.
9.
PKI client
GBA Module
3.
8.
1.
2.
5.
7.
10.
11.
PKI portal
6.
NAF Library
Figure 3.13. PKI Portal (NAF)
1. The PKI application in the UE sends an empty HTTP request to trigger the
procedure.
2. The PKI portal responds with HTTP response 401.
3. The GBA module is invoked to obtain B-TID and Ks_NAF. In case proof-of-origin
is needed for the WIM, also the WIM is contacted.
4. The parameters are delivered to the PKI application.
5. Based on the parameters obtained from GBA module and WIM, another HTTP request
is sent to the PKI portal, this time with the Authorization header.
6. The PKI portal obtains B-TID and Ks_NAF with the help of the NAF library through the
Zn interface. With these parameters, the PKI portal verifi es the Authorization header.
7. The HTTP response is returned, including the response for the WIM challenge.
8. Further WIM AssuranceInfo is requested from the WIM.
9. WIM provides the parameters that give the needed proof-of-origin. Parameters needed
for the PKCS#10 purposes are also delivered.
10. The PKI client sends the PKCS#10 request for a certifi cate.
11. The PKI portal delivers the certifi cate in the HTTP 200 OK message.
74 Cellular Authentication for Mobile and Internet Services
3.4.3 HTTPS Support
HTTPS is one of the most commonly known usages for security. GAA can be used
to support HTTP Digest Authentication and Pre-Shared TLS as outlined in [TS33.222].
The details were already described in Section 3.2.3 (GAA Authentication) and further
described in Section 4.1.1.
3.4.4 Key Distribution Service
3.4.4.1 Key Distribution for Terminal to Remote Device Usage
The key distribution service for terminals and remote devices is outlined in
[TS33.259]. It is a security feature that builds upon [TS33.220] to provision a shared
key between a UICC Hosting Device and a remote device connected via a local
interface. This can be used, for example, when a terminal, with a UICC inserted, is
connected via local means (cable, Bluetooth, etc.) to a PC or other terminal. The
shared secret is then intended to be used to secure the local communication between
those two devices.
The architecture below is based on GAA, but the NAF is a special-purpose NAF.
The NAF serves as a key distribution server to the requesting devices. Also the usage
of the key is different since it is not used between a network server and a terminal,
but between two entities, where one is a terminal with a UICC and the other one
might be a terminal, but can also be another entity, e.g., a PC or a personal network
device. (See Figures 3.14 and 3.15.)
HSS /
HLR
Zh / Zh’
UE
Local interface
BSF
UICC
UICC Hosting
Device
Remote
Device
Zn
NAF
Key Centre
Ub
Ua
Figure 3.14. Architecture for key distribution service
Generic Authentication Architecture 75
UICC
Terminal -
UICC Hosting
UE
4. If there is no valid bootstrapping session, then bootstrapping procedure is performed according to TS
33.220, else continue directly with next step.
Device
1. Request list of NAF Key Centers
3. Request key identifier (B-TID)
and chosen NAF_ID
5. Key Identifier (B_TID) and NAF_ID
Remote
Device
2. Select a NAF Key Centre
from the received list
6 Establishment of a secure channel
8.Service Request, B-TID,
and Device_ID
NAF Key
Centre
7. Check Device_ID
for blacklisting
9. Key request and
optionally also USSs
BSF
10. Derivation of
Ks_local_device key
11. Ks_local_device, B-TID and key lifetime
12. B-TID, key lifetime, Device_ID,
NAF_ID, MAC
13. Calculation of Ks_local_device and
validation of received MAC. Storage of
Ks_local_device and related data.
14. Ks_local_device key
derivation sucessful using MAC
Figure 3.15. Key establishment procedure for terminal to remote device security
76 Cellular Authentication for Mobile and Internet Services
Figure 3.15. Key establishment procedure for terminal to remote device security
(continued)
The Remote Device wants to secure the communication to the Terminal and checks, if it has
a valid key for this Terminal (the key is Ks_local_device). In the case that there is no key
that it can use, then the following procedure starts:
1. The Remote Device checks for the presence of a list of servers with NAF key distribution
servers (NAF Key Centre) functionality. If the Remote Device has already a list and
knows which NAF Key Centre to contact, then it can proceed directly with step 3. If no
list is available, then it requests the UICC Hosting Device to send a list of supported
NAF key distribution servers. The UICC Hosting Device returns then the list of available
NAF Key Centres.
2. The Remote Device then chooses an NAF Key Centre from the list (or it may also
propose its own NAF Key Centre) and stores the choice for the next time.
3. The Remote Device contacts the UICC Hosting Device, sends the identifi er for the
chosen NAF Key Centre (NAF_ID) and a requests the key identifi er.
4. If the UICC Hosting Device does not have a valid bootstrapping session, then it
runs a new bootstrapping procedure with the BSF. The bootstrapping can be based
on GBA_U or GBA_ME. When GBA_U has been performed, then the UICC
transfers the Ks_ext_NAF key to the UICC Hosting Device. The UICC Hosting Device
now has the NAF-specifi c keys, i.e., either Ks_ext_NAF or Ks_NAF.
For this key derivation, the NAF_ID received from the Remote Device is
needed.
5. The UICC Hosting Device sends a response to the Remote Device and includes the key
identifi er B-TID and NAF_ID.
6. Now the Remote Device and the NAF Key Centre establish a secure channel using TLS
with certifi cate-based mutual authentication according to TLS [RFC2246] and its
extensions [RFC3546]. A secure channel can also be established using the shared key
with the NAF Key Centre and PSK TLS [RFC4279].
7. Through this secure tunnel, the Remote Device sends a ‘service request’ to the NAF Key
Centre to request a device-specifi c key. The request contains the key identifi er
(B-TID) received from the UICC Holding Device and an identifi er for the Remote
Device, called Device_ID, e.g., IMEI. It should be noted that the specifi cation does not
address how Device_ID is authenticated.
8. The NAF Key Centre checks if the Device_ID is blacklisted. If it is blacklisted, then the
secure tunnel is terminated.
9. The NAF Key Centre requests the NAF-specifi c key and optionally USSs from the BSF
over Zn interface. The BSF returns the requested data, if allowed by BSF policy (see
Section 3.5.1).
10. The NAF Key Centre derives the Ks_local_device from the received Ks_(ext)_NAF key,
B-TID, NAF_ID and Device_ID. Ks_local_device is then stored.
Generic Authentication Architecture 77
Figure 3.15. Key establishment procedure for terminal to remote device security
(continued)
11. The NAF Key Centre sends the Ks_local_device together with the B-TID and the key
lifetime through the secure tunnel to the Remote Device. The Remote Device stores the
received data for further usage.
12. The Remote Device sends the NAF_ID, Device_ID, B-TID,
key lifetime, and a MAC, where MAC is calculated as follows:
MAC = HMAC-SHA256 (Ks_local_device, NAF_ID 储 Device_ID_ 储 B_TID),
truncated to 16 octets.
The UICC Hosting Device knows then that the key establishment was successful.
13. The UICC Hosting Device derives the Ks_local_device key and validates the MAC. The
Ks_local_device key and the related data (e.g. Device_ID) are then stored.
14. The UICC Hosting Device sends a confi rmation of the successful derivation to the
Remote device using a MAC and the Ks_local_device key.
The trustworthiness of the devices can be assured e.g. if they comply to the TCG
(Trusted Computing Group) MPWG (Mobile Phone Working Group) Mobile Phone
Specifi cations [TCG] or to other TCG technology.
3.4.4.2 Key Distribution for UICC to Terminal Usage
The previous section described how to provision keys to secure the communication
between a terminal and another device. Now we will look into the same problem for
the case that a security association is needed between a UICC and a terminal. The
situation is very similar, but there are small subtle differences due to the fact that
the UICC is more closely related to an operator than a terminal. The mechanism is
specifi ed in [TS33.110].
The architecture is the same as in the previous section, but the goal is to secure
the link between the UICC and the UICC hosting device and not (as in the previous
section) to secure the local link. Compared to the previous section, roughly the terminal takes the role of the remote device and the UICC takes the role of the UICC
hosting device. The trustworthiness of the terminal can be guaranteed for example
by complying with the TCG specifi cations [TCG]. The message fl ow is as follows:
1. The terminal contacts the UICC to check if there is a valid master key (Ks) in
the UICC. This is done by requesting the key identifi er (B-TID) and the key
lifetime from the UICC. If there is no valid master key, then the terminal runs
a GBA_U bootstrapping procedure.
2. The terminal sends the B-TID and the NAF_ID of the NAF Key Centre to the
UICC to determine if there is a valid NAF Key Centre-specifi c key, i.e., Ks_int_
78 Cellular Authentication for Mobile and Internet Services
NAF. The NAF_ID of the NAF Key Centre might be fi rst retrieved from the
UICC.
3. The terminal and the NAF Key Centre establish a secure channel using
certifi cate-based mutual authentication [TS33.222], or PSK TLS [RFC4279].
4. Through this secure tunnel, the terminal sends a ‘service request’ to the
NAF Key Centre in the network containing the key identifi er (B-TID), the terminal identifi er (Terminal_ID), the smart card identifi er – Integrated Circuit
Card ID (ICCID), the application identifi er of the UICC (UICC_appl_ID)
and the terminal application identifi er (Terminal_appli_ID). The request triggers
the establishment of the Ks_local key and a RANDx value (which can be
random or a timestamp or something else produced by the terminal). It
should be noted that due to the send parameters, the Ks_local key depends
on the terminal and the smart card application, i.e., a different application
would get a different key. There is the possibility to generate the key on a per
platform basis by setting UICC_appli_ID and Terminal_appli_ID equal to
‘platform’.
5. The NAF Key Centre makes a blacklist check using the received Terminal_ID
and then uses the Zh interface to request the GBA_U NAF-specifi c keys and
may also request one or several USSs.
6. The BSF derives the NAF Key Centre-specifi c Ks_int/ext_NAF keys and sends
them with the further key information and USSs to the NAF Key Centre according to the local policy. It is assumed that since the NAF Key Centre resides in
the same network as the BSF, then there should be no reason for the BSF not to
send the requested USSs.
7. The NAF Key Centre checks the USS (if received) if the user is authorized
to use this service. The NAF Key Centre generates a Counter Limit for use in
the UICC. Then the NAF Key Centre derives the Ks_local = Key Derivation
Function (Ks_int_NAF, B-TID, Terminal_ID, ICCID, Terminal_appli_ID,
UICC_appli_ID, RANDx, CounterLimit).
8. Through the secure channel, the NAF Key Centre sends to the Terminal the
B-TID, the Ks_local key, the key lifetime and the Counter Limit. The Terminal
stores then the data and related information.
9. The Terminal sends a request to the UICC to derive the Ks_local and includes
the needed data for key derivation. Additionally, a MAC is included.
10. The UICC then retrieves the B-TID and the Ks_int_NAF (and potentially a local
policy) and derives the Ks_local. The UICC derives also the MAC and compares
it with the received one. If the comparison was successful, this is indicated to
the Terminal and the Ks_local is used.
It should be noted, that the key establishment between a UICC and a terminal
requires many new elements for the interface between UICC and terminal. The
Generic Authentication Architecture 79
support of [TS33.110] implies that the operator has to issue special UICC smart
cards, which support this specifi c functionality.
3.5 Other Architectural Issues
In this section, we will briefl y discuss some architectural and design issues we have
not addressed so far.
3.5.1 Access Control Mechanisms in GAA
GAA uses GUSS for additional access control. This element contains securityrelevant information about the subscriber and the services he or she can access.
Each subscriber may have a GUSS element in home operator’s databases. The GUSS
includes zero or more User Security Settings (USS) elements that contain either
additional persistent identities or pseudonyms, or so called authorization fl ags, or
both. There is only identity and authorization-related data in the USS as it is intended
for security-related decisions such as:
what is the service-specifi c and persistent identity that is in use for the subscriber,
•
or
whether a subscriber is allowed to use a service, or only certain parts of the
•
service?
Any other data, e.g., user profi les should be either stored in the NAF itself, or the
NAF can retrieve the other user data from some other server.
When NAF requests the information from the BSF, it can request zero or more
USS elements to be included to the reply. If appropriate USSs exist in subscriber’s
GUSS, the BSF will include them to the reply provided that the NAF has been
authorized to receive them. The existence of particular USS in subscriber’s GUSS
can also be used as an access control mechanism in the BSF, i.e., the BSF may have
been confi gured so that for particular NAFs, the subscriber must have a certain USS.
Otherwise, the subscriber is not allowed to access the service offered by the NAF.
This functionality enables the MNO to control what services its subscribers have
access to.
GUSS has also a BSFInfo element that contains security-related information
intended for the BSF and this element is never given to the NAFs. It contains information such as:
uiccType, which indicates what kind of smart card the subscriber has, i.e., is it
•
GBA-aware (GBA_U) card or not; and
80 Cellular Authentication for Mobile and Internet Services
lifeTime, which can be used to set a subscriber-specifi c lifetime for the GAA keys,
•
and override the default key lifetime setting in the BSF.
The BSFInfo element may also contain extensions which the operator or BSF vendor
can additionally defi ne for further enhancing the GAA functionality in the BSF and
in other GAA nodes.
3.5.1.1 Local Policy Enforcement in the BSF
Local policies in the BSF are operator-specifi c, but operators can utilize USSs for
communicating those policies from the HSS to the BSF, and further to the NAF.
Depending on the different capabilities of the BSF and the NAFs, the following
scenarios are possible:
(1) The BSF does not have a local policy for this NAF and the NAF is not using
USSs, and therefore, does not request one or several USS from the BSF, i.e., no
GSID(s) are inserted.
(2) The BSF does have a local policy for this NAF, but the NAF is not using
USSs.
(3) The BSF does not have a local policy for this NAF, but the NAF is using USSs
and requests USSs from the BSF.
(4) The BSF does have a local policy for the NAF and the NAF is using USSs.
We will now briefl y outline what happens in each scenario with regard to the policy
enforcement of the home operator hosting the BSF. The NAF has received in all
scenarios the Bootstrapping Transaction Identifi er (B-TID) from the terminal as
outlined in Sections 3.2 and 3.3.
The fi rst scenario is the simplest one; here the BSF does not have a local policy
for this NAF and the NAF is not using USSs. Therefore, the NAF only requests the
NAF-specifi c key(s) and does not request one or several USS from the BSF, i.e., no
GSID(s) are inserted in the Zn request. The BSF retrieves then the subscriber information from his local database and checks if there is a local policy for this NAF.
Since in this scenario the BSF does not have a local policy for this NAF, the BSF
does not require that there be a specifi c USS present in the subscriber’s GUSS. The
BSF just generates the NAF-specifi c key(s) and returns those to the NAF without
any USSs. Independent of this, the NAF may still have his own local NAF policy
that he enforces.
In the second scenario, the BSF does have a local policy for this NAF, but the
NAF is not using USSs. The BSF notices that the NAF did not include any GSIDs
in his key request message. The BSF retrieves the subscriber information and fi nds
that there is a policy and there are required GSIDs for this NAF. It checks whether
the required USSs are present in the GUSS. If they are present in the GUSS, then
Generic Authentication Architecture 81
the BSF can continue and hand out the key(s) to the NAF, else it has to send an error
message. Again, the NAF can have additionally his own local policy.
In the third scenario, the BSF does not have a local policy for this NAF, but the
NAF is using USSs and requests USSs from the BSF. This could be the case when,
for example, one NAF with a very popular service has security relationships with
many operators and some of those have BSF that support local policies and some of
those have BSF that do not support. The NAF would most likely not modify its
request over Zn interface depending on which operator he is addressing, hence this
case has to be considered. The NAF requests the NAF-specifi c shared key(s) from
the BSF and includes one or several GSIDs in this request. The BSF then retrieves
the subscriber information and checks if a local policy exist for this NAF. Since there
is no local policy for this NAF, the BSF does not require any specifi c USS to be
present in the GUSS requested from the HSS. The BSF generates the keys and sends
the key(s) and the requested USS (if available) to the NAF. The NAF then uses the
keys and processes the (potentially) received USS.
In the fourth and ‘fully enabled’ scenario, the BSF does have a local policy
for this NAF and the NAF uses USSs. The NAF requests the shared key(s) and the
USSs identifi ed by GSIDs. The BSF retrieves the subscriber information from
his local database and check if there is a policy for this NAF. Since in this scenario
the BSF does have a local policy, the BSF requires that there is one or more specifi c
USSs identifi ed by the GSIDs to be present in the GUSS. If all the required
USSs are present in the GUSS, the BSF sends then the received USSs to the NAF,
which then processes the USSs and the keys as outlined in the previous section.
If even one of the required USSs is missing, the BSF sends an error message to
the NAF.
These scenarios are also described in Annex J of [TS33.220]. It should be
noted, that for the last two scenarios, the BSF might refrain from sending a USS to
a NAF, if the NAF is not authorized to receive it.
3.5.1.2 USS usage for NAFs
The basic need for NAF to use USS is to obtain a persistent identity or pseudonym
so that it can provide a user-specifi c service to the end-user. This can be done without
USS by using the IMPI value that may be returned by the BSF to the NAF. However,
often the MNO does not want to reveal the IMPI to the NAF unless the NAF is
operated by the MNO itself. In this case, the NAF can request a service-specifi c USS
from the BSF by using a GAA Service Identifi er (GSID). This may be a standardized
value or may be given by the MNO to the NAF. In both cases, the NAF has been
confi gured with GSID value, which it would include to all requests to the BSF. The
BSF will return the USS identifi ed by the GSID if the particular subscriber has the
USS element and if the NAF authorized to get it. The policy about whether the NAF
is authorized to receive it or not is locally confi gured in the BSF by the MNO. When
82 Cellular Authentication for Mobile and Internet Services
the NAF gets the USS, it can examine its content and use the provided persistent
pseudonym to map the subscriber to a local (or remote) user profi le data.
The other need for NAF to use USS is to obtain authorization data from the BSF
on whether a subscriber is allowed to use a service (see BSF policy enforcement in
the previous section). This can be either explicit or implicit and it can offer authorization information regarding the whole service or only to certain parts of the
service.
In the explicit case, the authorization decision is made by the NAF. In this case,
a USS has typically been returned to the NAF. If the USS does not contain any
authorization fl ag data, then the NAF can provide the service to the user. If the USS
contains authorization fl ags, then these fl ags identify the parts of the service that a
user either could access or should be denied access.
A service offered by the NAF may be divided into certain service levels,
e.g., standard account access and premium account access. In this case, the
authorization fl ags would indicate to the NAF to which account class the subscriber
belongs to and the NAF can then offer the service level that subscriber is entitled to.
Naturally, if the requested USS does not exist for the subscriber and the policy in
the NAF requires it to exist, then the subscriber is not authorized to access the
service. Hence, the pure existence of a USS can be used to control access to a service
in the NAF.
In the implicit case, the authorization decision is made by the BSF as described
in previous section. This is based on whether a particular USS identifi ed by a
certain GSID exists in subscriber’s GUSS. The BSF may be confi gured in such
a way that it requires that a particular USS must exist in subscriber’s GUSS when a
certain NAF send a request, regardless of whether it requests this USS or not. If the
USS does not exist, then the BSF takes this as an indication that this particular subscriber is not allowed to use the service offered by the NAF and it will just return
‘not allowed’ message to the NAF as an indication of this. The BSF will not even
send the keys to the NAF. If the USS does exist, then the response with GAA keys
is sent normally to the NAF. Note that the NAF is not required to request the USS
in question.
3.5.2 Identities in GAA
GAA uses and supports multiple identities that can be used in different interfaces of
GAA. The long-term persistent identity that GAA uses is the cellular identity; in 2G
and 3G cases, this is the International Mobile Subscriber Identity (IMSI), and in the
IMS case, it is the IP Multimedia Private Identity (IMPI). These are used to map
subscriber data with an identity both in the UE, namely in the UICC and in the HSS.
This long-term identity is used during bootstrapping procedures over Ub and Zh
interfaces to handle the AKA procedures.
Generic Authentication Architecture 83
Once a bootstrapping session has been completed, the BSF creates a key B-TID,
which the BSF sends to the UE over Ub interface. The key identifi er B-TID is used
to identify a bootstrapping session between the UE, the BSF and the NAF. If only
B-TID is used between the UE and the NAF, then NAF can only be certain that this
subscriber has valid subscription with the MNO provided that the authentication over
Ua interface is successful.
In the cases where NAF wants to map the subscriber to a persistent user account
to provide a user-specifi c service, it needs to obtain a persistent identifi er or identifi ers from the BSF. This can be done in two ways:
(a) The BSF may have been confi gured by the MNO to return the cellular identity
(IMPI) to the NAF. This may be the case if the MNO trusts the NAF to handle
the private identity.
(b) The NAF may request an application-specifi c user identities or pseudonyms from
the BSF.
In the latter case, the BSF has fetched a subscriber-specifi c GUSS data element from
the HSS during bootstrapping procedure. The GUSS contains application-specifi c
User Security Settings (USS) elements that contain application-specifi c identities and
authorization information (a.k.a. fl ags) that are identifi ed by a GAA Service Identifi ers (GSIDs). The NAF may request one or more USS elements to be sent back
together with the application-specifi c key, and thus use the service identifi er to handle
the persistent mapping of the user to a local user account, for example.
Figure 3.16 summarizes the different identifi ers being used in different interfaces
of GAA.
B-TID
NAF
May use IMSI / IMSI / ID(s)
Ua
B-TID
Zn
Maybe IMPI
Zero or more IDs
IMPI
BSF
Ub
B-TID
UE
Figure 3.16. GAA identifi er usage
IMSI / IMPI
Zh
Zero or more IDs
HSS
84 Cellular Authentication for Mobile and Internet Services
In order to keep the application-specifi c user identities secret, the BSF has
been confi gured in such a way that only certain NAFs have access to a certain USS
elements. If a USS is requested by an NAF that is not authorized to do so, the BSF
will not include that USS to the response message.
3.5.3 Identity Privacy and Unlinkability
One of the goals in design of cellular networks has been to protect the identity of
mobile users and the data about their movements from unauthorized third parties.
The GSM system, for example, supports the notion of Temporary Mobile Subscriber
Identifi ers (TMSIs), which the UE can use during signalling instead of its real
IMSI.
There are two places in GAA where the subscriber identity may be revealed to an
observer:
(a) during bootstrapping via the Ub interface, the private user identity, IMPI, is sent
in the initial request from UE to BSF; and
(b) during application usage via the Ua interface, the same bootstrapping identifi er
B-TID is sent in every initial Application Request during the time that a certain
bootstrapped master session key is in use.
Without further precautions, an eavesdropper watching the exchanges over the Ub
interface will learn the private user identity. An eavesdropper watching the exchanges
over the Ua interface will not learn the private user identity, but will be able to link
multiple application sessions in which the same UE participated.
The fi rst threat can be addressed by doing bootstrapping via a secure channel. For
example, if bootstrapping takes place through a server-authenticated TLS tunnel,
there is no risk of leaking the private user identity to onlookers.
The second threat can be addressed similarly: by running the application protocol
inside a server-authenticated tunnel, onlookers will not be able to link two different
application sessions by the same UE even if they use the same B-TID.
Some NAFs may need to know the subscriber’s private user identity. Whether an
NAF is allowed to have this information is controlled by policy set by the home
operator in GAA User Security Settings (GUSS).
3.5.4 Usability and GAA
The majority of Internet services rely on username and password authentication at
the time of writing, and that authentication method is applied in two main ways. In
the fi rst, the user device and the server establish an encrypted TLS channel and the
network side of that channel is authenticated based on server certifi cate. The user
Generic Authentication Architecture 85
then fi lls his username and password into an HTML form, which is sent to the server
through the encrypted TLS channel. Mutual authentication succeeds if the username
and password in the received HTML form are verifi ed by the server.
Figure 3.17 illustrates the web browser interface of a mobile device during
authentication with this method. One detail of this interface is worth mentioning:
If the user clicks on ‘Remember me’ box that is part of the HTML form, the
server will set up a HTTP cookie to the browser. In subsequent authentications, that
cookie will be automatically sent to the server and used instead of username and
password.
Second, username and password are also often used in HTTP-digest authentication. Figure 3.18 illustrates the web browser interface of a mobile device during
HTTP-digest authentication.
Another service authentication method, which may not require the user to enter
username and password, is to authenticate both TLS channel ends with certifi cates.
The user may need to input a passphrase in order to access the private key
associated with client certifi cate. The network is authenticated with server certifi cate
and the terminal with a client certifi cate. However, so far, this method has been
used rarely compared to username and password. A likely reason is that a largescale investment in distribution and management of client certifi cates in user
terminals is hard to justify if username and password method is considered good
enough.
Figure 3.17. HTML form for password authentication in a mobile device. Reproduced by
permission of © Nokia
86 Cellular Authentication for Mobile and Internet Services
Figure 3.18. Entering password during HTTP-digest authentication in mobile device.
Reproduced by permission of © Nokia
In summary, the main diffi culty for the user with the current mainstream authentication mechanisms is the need to create, remember and manage passwords. To
mitigate this diffi culty, browsers can implement a password manager that if enabled,
will save and automatically complete the username and password in future authentications. But this still leaves the password-generation task to the user and people
are not good at choosing secure passwords [Yan04].
For services that can rely on cellular authentication, GAA offers a more secure
and user-friendly alternative: A service–specifi c shared secret is automatically generated for each service using GAA and the lifetime of that key is set by the MNO. In
the rest of this section, we will discuss an implementation issue that is linked to
usability: under what conditions an application can receive that service-specifi c
shared secret transparently to the user.
Cellular services authentication is automatic. As a result, the user does not see
dialogues like the ones in Figures 3.17 and 3.18 when placing and answering calls
and transferring data over cellular network. We feel that automatic authentication
contributes greatly to the ease-of-use feeling that is associated with cellular service.
(Another and no less important fact that contributes to the ease-of-use feeling is that
cellular service works most of the time.)
Since GAA is based on cellular authentication, it can inherit this usability feature:
The GBA module in the device would bootstrap as needed and provide credentials
to applications silently, without involving the user. In this case, the decision on asking
or not asking the user to confi rm authentications is left to the application that gets
the bootstrapped credentials. This is how GBA module is implemented, e.g., in
Series60 platform.
Loading...