Authenticated Out-of-Band Communication Over Social Links
Anirudh Ramachandran and Nick Feamster
School of Computer Science, Georgia Tech
{avr,feamster}@cc.gatech.edu
ABSTRACT
Many existing host-based applications rely on their own au-
thentication mechanisms and peer discovery services. Al-
though social networking sites already provide mechanisms
for users both to discover other users (e.g., by logging on to
the social network Web site) and to communicate securely
with each other (e.g., using instant messages within the so-
cial networking site), today’s applications have no way to
exploit the relationships and trust that are inherent in these
networks. This paper proposes Authenticatr, a framework
that allows applications to use the authentication and peer
discovery mechanisms inherent in social networking sites to
bootstrap their own authenticated communication channels.
We describe motivating applications, detail the interface
that Authenticatr exposes to applications, and discuss prac-
tical considerations and security threats.
Categories and Subject Descriptors
C.2.0 [Computer Communication Networks]: Security
and protection; C.2.4 [Computer Communication Net-
works]: Distributed Applications
General Terms
Design, Security, Flexibility
Keywords
social networks, authentication, security
1. INTRODUCTION
Social networking is experiencing explosive growth, both
in terms of communities targeted by these networks and
overall user participation in each of these networks [1, 2].
Online communities such as Usenet and IRC have existed
for decades, but the recent wave of social networking Web
sites are notable for requiring stricter authentication proce-
dures for registering and creating social connections: Most
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
WOSN’08, August 18, 2008, Seattle, Washington, USA.
Copyright 2008 ACM 978-1-60558-182-8/08/08 ...$5.00.
networks do not allow automated registrations, and creat-
ing new social links (e.g., adding another user to your list of
acquaintances) requires authorization from the other party.
Many newer social networking sites such as Facebook [10]
have even stricter requirements for joining a social circle
(e.g., to be part of the Georgia Tech group, the user must
possess a gatech.edu email address).
Despite the rise in popularity of social networks and the
inherent information they contain about trust between their
users, these networks remain balkanized and largely sepa-
rate from many applications that could benefit from richer
social context. For example, consider a user who wishes
to share files with a set of trusted friends who are mem-
bers of the user’s network at a secure social networking site
(e.g., Facebook). The filesharing application, however, is
unaware of this relationship, and must treat all friends as
untrusted users on the Internet; thus, the user must either
manually set up and distribute passwords to all friends, or
settle for an unsecured service. The filesharing application
would benefit from the ability to utilize the secure social link
to “bootstrap” its own authentication service. Many web-
based applications can also benefit from a common social
context: users today must create isolated social networks
for each Web-based application (e.g., a user who has ac-
counts on a bookmark sharing application and a Web-based
feed reader cannot unify his friends on both applications); if
Web applications could tap into a common“social substrate”
to find friend relationships, collaboration and sharing could
be made seamless 1.
This paper presents Authenticatr, a system that uses so-
cial links between users—which already exist within the con-
texts of various social networking Web sites—as a substrate
for establishing authenticated out-of-band communication
between applications that these users run (i.e., for appli-
cations unrelated to the social network). Much like Web
services that allow users to authenticate themselves using
credentials from other social networking sites [3] or univer-
sal login mechanisms such OpenID [12], Authenticatr pro-
vides applications a generalized view of authentication in-
terfaces; applications, therefore, can treat all social network
instances in the same way. Authenticatr also enables these
applications to communicate using the social network’s se-
cure messaging capabilities, which applications can use to
1Google’s Social Graph project [7] addresses a similar goal,
using social annotations in hyperlinks as the underlying so-
cial network. This service, however, uses publicly available
information and cannot be used for secure communication.
61

perform challenge-response or establish cryptographic keys
before initiating direct communication2.
This paper makes the following contributions. First, we
present the design of Authenticatr, a framework that lever-
ages the relationships inherent in today’s social networks
to build authenticated out-of-band communication channels
for other networked applications. Second, we describe the
Authenticatr API, which applications can use to build such
authenticated channels. Finally, we describe how develop-
ers can use this API to build applications for performing
a variety of tasks ranging from file-sharing to network trou-
bleshooting. We also outline various practical considerations
for Authenticatr and discuss an agenda for future research.
The rest of the paper is organized as follows. Section 2 de-
scribes motivating applications for Authenticatr. Section 3
presents Authenticatr’s design and API, and Section 4 ex-
plains how applications can use Authenticatr to construct
authenticated channels. Section 5 describes various practi-
cal considerations and potential security threats. Section 6
outlines related work, and Section 7 concludes with a sum-
mary and research agenda.
2. MOTIVATING APPLICATIONS
Authenticatr provides an authenticated out-of-band com-
munication channel for many other applications, including
overlay routing, troubleshooting, root-cause analysis for net-
worked applications, censorship avoidance, and authentica-
tion for content sharing (e.g., blogs, photo albums, posted
news items). Current authentication and access control for
these types of applications are either application-specific or
too complex for typical users to establish and configure.
In contrast, social links are easy for users to establish and
verify. Social links also embody exactly the type of authen-
tication that is required by many applications: To share
a set of photos, a news posting, or some other content only
with friends, a user can specify access control in terms of ex-
isting relationships on social networks (e.g., “my friends on
Facebook”). Authenticatr extends the same authentication
mechanisms to host-based applications, allowing the user to,
for example, configure her computer to “Allow my friends on
Facebook to route traffic through me”. In this section, we
detail a few example applications that can benefit from Au-
thenticatr’s authentication mechanisms.
Secure email. Although strong end-to-end encryption
schemes such as PGP have existed for over a decade, the
complexity of public key cryptography has made this ap-
proach unattractive to most email users. On the other hand,
people already understand and use social networking ser-
vices for business and leisure, and many social networks sup-
port secure authentication and messaging (i.e., HTTP over
SSL); Authenticatr can exploit the authentication and secu-
rity already inherent in social networks for securing host-
based email clients.
File-sharing between friends. Currently, many users
lack the means or the technical expertise to share files only
with their friends. Complete security requires setting up and
managing servers, which is relatively difficult for most users.
A file-sharing client can use Authenticatr to select a social
2We assume that the social networking platform allows an
authenticated user to perform automated logins and mes-
saging. Some platforms (e.g., Orkut) currently do not allow
automated actions, but a demonstrated use like Authenticatr
might ultimately result in a change to this policy.
network and a friend (or group of friends) to share files with;
Authenticatr will exchange session keys with peer programs,
establish ports, verify logins, etc. using the social network.
Backup routing and censorship avoidance. Routing
failures often cause some parts of the Internet to become dis-
connected; BGP convergence delays cause these disruptions
to affect availability. Censorship poses reachability problems
of a different sort: Users may be denied access to certain
Web sites on the Internet. Authenticatr allows these users
to locate a friend’s host (using the social network) and route
through it to avoid the failure or the censor (previous work
has proposed a similar mechanism that applies only to cen-
sorship [9]). Routing through a trusted friend’s computer
would also be preferable to using an anonymous proxy of
unknown provenance.
Collaborative measurement and troubleshooting.
Collecting measurements from end-users is cumbersome be-
cause most users are unwilling (or unable) to operate mea-
surement software; moreover, there is no way a researcher
can signal a set of end-user machines to begin measurement
(due to DHCP reallocation, machines being turned off, etc.).
Such applications can also benefit from Authenticatr: when-
ever a researcher requires a measurement, she can issue a re-
quest to all end-user measurement applications (authorized
through a social channel, such as all subscribers of a cer-
tain Facebook application) to conduct a measurement (e.g.,
“traceroute to slashdot.org”).
3. DESIGN
This section presents the design of Authenticatr. We out-
line design goals, present Authenticatr’s design and API, and
describe how multiple processes can communicate using the
same social authentication channel. We are in the process
of implementing Authenticatr.
3.1 Design Goals
Authenticatr attempts to satisfy the following goals:
• Simplicity. The Application Programming Interface
(API) that Authenticatr presents is similar to the
Berkeley sockets API, both in terms of the functions
and the data types handled by the API. Simple API
calls are easier to compose and build upon. As a result,
the primitives provided by Authenticatr are minimal
(e.g., send, recv, etc.), but applications or libraries
can compose these primitives to perform more com-
plex tasks.
• Flexibility. The design of Authenticatr is not tied to the
functions offered by existing applications or to existing
social network structures, which makes it compatible
across many of future applications and social networks.
The API handles only basic operations (i.e., authenti-
cation, enumerating a user’s friends, and sending and
receiving data), leaving functions that are specific to
social networks to lower layers, and application-specific
functionality to higher layers.
3.2 The Middleware Layer
Figure 1 presents the high-level design of Authenticatr.
The middleware layer provides applications with various
social-network functions. Its API includes functions for au-
thenticating a user to the social network and sending mes-
sages to a user’s friends, but is independent of functions
62

File Sharing MeasurementOverlay Routing
Applications using Social Authentication
Authentication and Data Transfer API
Authentication and message−passing implementation
Figure 1: High-level design of Authenticatr.
that are specific to a particular application or a particular
social-network communication protocol. Because the mid-
dleware provides only basic functionality, applications can
use libraries built on top of the middleware message-passing
API for commonly-used functionality, such as enumerating
friends-of-friends of a user, negotiating a cryptographic ses-
sion key between two users using private messaging, etc.
Applications may build upon intermediate libraries on top
of the middleware API, or deal directly with the message-
passing API for new functionality (e.g., friend“suggestions”,
or users who are connected via many common friends). The
thin middleware layer is analogous to the hourglass design
of the TCP/IP stack, which facilitates a wide range of appli-
cations to use it on higher layers, and a wide range of lower
layer (physical or link-level) protocols and media to interact
with the TCP/IP layer from below.
Below the middleware layer, Authenticatr implements var-
ious types of social network communication and authen-
tication schemes. The implementation includes the com-
munication protocol (e.g., XML-RPC for Web-based social
networking sites, Jabber for instant messaging applications,
etc.) and the functionality to send and receive private mes-
sages to friends within each network. If the social network
offers other functionality through its API (e.g., obtain the
list of a user’s friends or a list of users in a group), these may
also be implemented and exported through the middleware
to applications.
3.3 Authenticatr API
Table 1 presents the API that Authenticatr exposes to
applications. The API consists of two functions for authen-
tication and two for data transfer. The authentication func-
tions are: 1) login, to log on to a social network such as
Facebook or Google Talk [11] using a credential (such as a
username and password combination or a private key), and
2) set_auth_level, to set the authentication level of a ses-
sion handle obtained using login to a specified value. The
data transfer functions, analogous to Berkeley sockets func-
tions, are send and recv. These functions require a session
handle (obtained using login) and the identifier of a friend
in the social network with whom to communicate with. A
successful send call places the message in the Inbox (mes-
sage storage provided by the social networking site) of friend
f. The friend, f, can then call recv to retrieve the message.
The messages sent using the data transfer functions are
opaque. The middleware layer performs two basic opera-
tions: 1) Given a handle to a social network (“network *n”
in the login API), Authenticatr locates the appropriate so-
cial network implementation and obtains a session handle
using the credentials provided by the application; 2) It main-
tains a mapping between session tokens (returned by the
social network implementation on a successful login call)
and the corresponding social network sessions (e.g., using
HTTP cookies). On a send or recv call, it forwards the mes-
sages to the implementations to send and receive messages
on that social network. Applications that use the middle-
ware API can send messages for various purposes, such as
negotiating a cryptographic key, or exchanging IP addresses
of the machines the applications are running on to initiate
direct (peer-to-peer) connection (similar to STUN [8]).
Auxiliary functions. Because the middleware passes the
friend identifier f unchanged to the corresponding social net-
work, the application using a send or recv may need to
understand the semantics of mapping a user’s real identity
to that user’s corresponding social network identity (i.e.,
on one network, a user may be uniquely accessible using her
email address while on another, the unique identifier may be
a number). To tackle this problem, the middleware also ex-
ports functions such as get_friends, which retrieves a list of
a user’s friends from the corresponding social network. Be-
cause application-specific details are encapsulated within the
friend structure, applications can continue to treat users
on all social networks equally. Other examples of auxil-
iary functions include get_groups (which retrieves a list of
communities a user is a member of) and get_profile_data
(which retrieves the profile data of a user).
Using the data transfer and auxiliary functions provided
by the middleware, developers can construct more complex
message types for specific applications to use, such as “pri-
vate message” (sent to a single friend), “FoF message” (sent
to all friends and friends-of-friends), “group message” (sent
to all members of a group), or “broadcast message” (sent to
all friends).
3.4 Establishing the Channel
For each session token, the middleware stores the follow-
ing information3:
1. The access details of the social network, such as the
IP address and port.
2. The current authentication level of the session token.
3. The pointer to the set of functions implementing au-
thentication and data transfer functions for this social
network (registered as a callback function), with at
least one implementation for each data transfer func-
tion (send and recv), as well as the auxiliary functions.
Unsupported functions point to NULL.
4. A set of process identifiers that have rights to invoke
operations (i.e., data transfer or authentication func-
tions) on the session token.
When middleware allocates a session token upon a suc-
cessful login call to a social network, the process that pre-
sented the credentials for login receives ownership to the
token. Session tokens are valid across all processes on a
host. If a process wants to allow other processes (e.g., child
3Because the middleware must store information regarding
open session handles of all processes, we expect that it will
be implemented as a daemon that handles all such function
calls.
63

Authentication API
Prototype Purpose
session* login (network *n, credential *cred) Attempts to login to network n with credentials cred, return-
ing a session handle
set_auth_level (session *s, auth_level *level) Sets the authentication level for the social network session s
to level
Communication API
send (session *s, friend *f, message *msg) Sends the opaque message msg to friend f through the social
network session s
recv (session *s, friend *f, message **msg) Receives the next message from friend f through social net-
work session s into the opaque buffer msg
Auxiliary Functions
get_friends (session *s, friend *f, friend **l) Get the list of friends of a user f as the list l using the social
network session s
Table 1: API for Authenticatr’s middleware layer, both for authentication to a social network, and for data
transfer through the social network.
processes) to perform calls using this token, it must ensure
that such processes do not perform unauthorized operations,
because the same token is usable across all processes on the
host. Thus, Authenticatr provides authentication levels (set
using a set_auth_level call) to control which processes on
a given host can use each session token, and how each pro-
cess can use each token.
In this model, a user could then provide credentials to a
trusted application that performs the login, creates a ses-
sion token, adds read and write permissions for the un-
trusted application’s process ID, and passes the token to
the untrusted application process. Similarly, authentication
levels allow trusted applications to impose access restric-
tions, such as read-only or write-only restrictions, on other
processes, even though the underlying social network does
not provide this feature.
The set of authentication levels must be applicable to most
social networks while still allowing expressive access control
policies. For each session token, the middleware maintains
a pair of 2-bit masks each for two permission settings: 1)
read permission allows reading from the social network ses-
sion (i.e., reading content through the social network, such
as messages on a user’s Facebook Inbox); and 2) write per-
mission allows writing to the session (i.e., sending a message
using the social network to a friend). The authentication
level is represented as the concatenation of two such bit-
masks. The first bitmask is for processes that are in the
owner group, and the second is for processes that are in
the group group. The middleware also maintains, for each
session token, two lists of process IDs that belong to each
group (i.e., processes that are members of owner and pro-
cesses that are members of group). Modifying and enforcing
the authentication levels work much like UNIX file permis-
sions: only process IDs that are members of the owner group
can change the authentication level bitmasks or add other
processes to the owner or group lists.
4. USING AUTHENTICATR
Authenticatr assumes that the social network implemen-
tations allow users to exchange private messages over an
authenticated social link. Host-based applications can make
automated use of Authenticatr either for sending secure mes-
sages between peers through these links or use the social link
as an out-of-band signaling channel to negotiate or set up
parameters for direct communication. Authenticatr is most
useful to external applications as an authenticated out-of-
band signaling mechanism for small messages. These mes-
sages can allow host applications to perform important func-
tions such as discovering the IP address and port of a ser-
vice operated by a friend, and establishing a cryptographic
session key. We describe how Authenticatr can be used to
perform these functions in the context of a peer-to-peer file-
sharing application.
4.1 Secure Peer-to-Peer Filesharing
Consider a user who wishes to securely share a file with
a group of friends using a peer-to-peer filesharing applica-
tion (e.g., BitTorrent). The application must first provide
a way for the set of friends to discover and join the P2P
network; in BitTorrent, this process involves using a third-
party “tracker”. In addition to performing authentication
at the discovery service, the application must also secure
the communication between peers. Thus, the filesharing ap-
plication requires two steps: (1) A mechanism to securely
disseminate the location and authentication parameters of
the discovery service to the desired group of friends, and
(2) A way to set up per-peer keys for encrypting communi-
cation between peers. These tasks are akin to creating an
independent social network, where step (1) is equivalent to
logging in securely at a well-known social network URL (e.g.,
www.facebook.com), and step (2) can be accomplished using
private messaging between friends on the social networking
site. Authenticatr allows the P2P application to use exist-
ing social networking services to perform these tasks. We
discuss these two steps below.
Step 1: Address and service discovery. Many Internet
users are highly mobile or have access only to dynamic IP
addresses, and locating friends’ computers (for filesharing,
voice or video chat, etc.) can be difficult. Social networking
Web sites and instant messaging services—many of which
already track all logged-in users—can be used by friends to
“meet in the middle”, and exchange information in order
to initiate direct connectivity (e.g., the publicly accessible
port numbers of the hosts and ports where inbound access is
allowed). Existing techniques such as STUN [8] or UDP hole
punching also discover this information; the social network
acts as a point for securely exchanging the information.
Implementation. Each host that wants to advertise a ser-
vice first discovers its public IP address, port, etc. using
services such as STUN. It then logs into one or more social
64

networks, uses get_friends to enumerate a list of friends
on each network, and uses send to send the details of the
service as private messages to one or more friends. Applica-
tions run by users who receive the private message period-
ically call recv and directly connect to the IP hosting the
service.
Step 2: Negotiating cryptographic keys. Although ad-
dress discovery can use the security of the social network,
the actual data exchange in a filesharing application must
use the open Internet. Fortunately, peers can use private
messaging within the social network to establish pairwise
cryptographic keys, which are in turn used to encrypt their
direct communication. Private messaging is ideal for key ex-
change because message sizes are typically small, and only a
few round trips are required to complete the exchange. The
established secret can be used to secure direct communica-
tion between the peers.
Exchanging keys using secure private messaging services
provided by a social network entails additional benefits: typ-
ical key exchange mechanisms such as Diffie-Hellman are
susceptible to man-in-the-middle attacks because not all
routers through which the messages pass are trustworthy.
Using a secure social channel implies that the user only has
to trust the social network provider, which greatly reduces
the chances of man-in-the-middle attacks.
Implementation. Each pair of hosts that want to establish
a shared secret first log on to the same social network. In
an initial series of “hello” messages, the hosts establish the
prime number and base for the Diffie-Hellman key exchange.
The key exchange completes using two more messages in
one more round trip. Note that if the prime and base are
well known, the hosts do not need to wait for each other to
compute the secrets (i.e., the hosts do not need to log in to
the social network at the same time).
4.2 Additional Uses of Authenticatr
Collaborative measurement and monitoring. Trou-
bleshooting network problems and identifying root causes re-
quires measurements from many vantage points. End-users
are usually the quickest to notice a problem (e.g., no route
to a host, high packet loss or latency, etc.), but they usu-
ally lack a method to conduct measurements from multiple
vantage points. Authenticatr could allow a group of users to
run measurement services (e.g., traceroute, ping, bandwidth
measurement, etc.) on their machines to which their friends
on the social network can make queries.
Implementation. Because many network failures are tran-
sient, in the case of network measurements, the user ini-
tiating the measurement first enumerates all of his on-
line friends that have the measurement application installed
(e.g., using a get_profile_data query that lists the avail-
able Authenticatr-based applications for each user). If the
measurement queries and responses are small (e.g., tracer-
oute), they may be exchanged directly using the social net-
work messaging facility. Otherwise, Authenticatr first estab-
lishes a session between each pair of hosts (as above), and
communication proceeds directly between the measurement
applications.
“Bridging” users. Most existing social networks lack a
method to verify user’s identity, which can create a threat of
impersonation. For two users who are unsure of the other’s
real identity, having a friend in common could allow that
friend to act as the “bridge” and vouch for each user to the
other. The same idea can also be extended across social net-
works: A user who is registered on two social networks (say
A and B) can voluntarily act as a bridge between a friend on
network A and a friend on network B. Through the bridge
user, the two distrusting users may conduct socially au-
thenticated communication (e.g., set up session keys), even
though they are not friends of each other (or even on the
same network).
5. PRACTICAL CONSIDERATIONS
This section discusses various practical and security con-
siderations with Authenticatr. In particular, we discuss how
applications need to change to use Authenticatr and how Au-
thenticatr might multiplex multiple communication channels
over a single login session. We also describe how Authenti-
catr might be used as a vector for malware, and outline
possible defenses.
5.1 Changes to Host Applications
The change required to existing applications is very min-
imal, and only the process of obtaining authentication in-
formation is different. For example, consider a password-
protected P2P directory. To incorporate social authentica-
tion, the P2P application needs to: (1) Handle user input
of credentials to log into a social network. This includes
the name of the social network in question, and the user-
name and password; (2) Get a list of friends of the user, and
disseminate the login and password for the P2P share (us-
ing send) to the group of friends selected by the user. The
rest of the application can function normally, allowing access
only to remote hosts that present the correct password. On
the remote end, the clients that connect to the P2P share
must similarly incorporate functionality to search a user’s
Inbox for credentials. Thus, instead of the remote user typ-
ing in the password of the P2P share, the P2P application
automatically retrieves the password by virtue of the user’s
social connection to the user hosting the P2P share.
5.2 Session Multiplexing
Most social networks allow only one login session per cre-
dential from a given host. In Authenticatr, however, multiple
host processes may have to simultaneously use the same so-
cial link to communicate with different remote processes on
another host. However, the message store (the Inbox) in a
social network behaves like a single message pool: without
any serialization, a scenario with multiple readers and writ-
ers may result in messages being retrieved by the wrong host
processes.
To tackle this problem, we suggest that these processes
use a library built upon the middleware layer to “broker”
their requests and responses. The library is responsible for
appending identifications to each outgoing message based
on the process that sent the message, and mapping identi-
fications on incoming messages back to the processes that
are supposed to receive the message. These extra fields are
attached to the message body and require no support from
the middleware. Because the middleware treats messages as
opaque objects, applications (or libraries) can impose arbi-
trary structure on message bodies to achieve diverse end-
to-end functionality (e.g., complex authentication schemes,
remote procedure call functionality, etc.).
65