Privacy and Trust for
Network Identities
Manish Dave, Toby Kohlenberg, Hong Li
Intel Corp.
Outline






Privacy, Trust and Identities
Trustworthy and Usable identities
Trust at the network layer
Network Specific Issues
Approaches to address the issues?
Potential Benefits
Privacy

Privacy is a critical issue for the Internet and Community





Privacy is also associated with anonymity and can conflict with security


Anxiety about the information provided over Internet: For example, concerns over
personally identifying information (PII), RFID example for privacy concerns, Google
example…
However, Personal data has some value (Data mining) and part of economic model?
Compliance to Privacy laws, regulations, organization’s privacy policy for information
technology and content over Internet
Personal privacy in a shared infrastructure is even more difficult:
encryption/confidentiality? Abuse/mis-use?
Is one way to achieve it, users may prefer to stay anonymous to protect their privacy,
however allowing anonymity causes security issues such as abuse/mis-use and lack of
traceability.
Question: How can we enable a system which allow ability to set the privacy
levels regarding disclosure of personal information?




Policy language to express privacy policies and measure/audit it?
Access controls for “privacy” tagged content transport, offline access?
User choice vs. user-burden
Tools for negotiation, perhaps delegation? Privacy agents?
Trust

Trust and privacy are inter-related: we are prepared to reveal
information to ones whom we trust more: Google, Amazon
more than an E-commerce site?


Burden on end-users: End-Users on Internet have to make day
to day decisions what to trust (URL’s, Email, EBAY etc.)
Questions:
 Can we build technologies which help represent personal trust
and privacy preferences?
 How can trust be represented and managed within such
systems? Relationships/federations?
 Web of Trust and the required ecosystem?
 Lessons from PKI: Slow to evolve for specific usage such as
server/SSL, code signing etc.
Identity




Identity is a complex topic: multiple identities are
employed as appropriate based on context on the
Internet
Well known attacks and growing identity thefts make
identities on the Internet vulnerable (abuse/misuse)
or use without user permission
Use of identities is key for policy based security
approach such as permissions, access-controls and
authorization
Question:


Can the concept of Identity at Network Layer (Topic of
Interest) be designed to address these issues?
Will this help user to be in control of identity?
Trustworthy and Usable Identities

Several forms of identities used on the Internet today:



For example: IP address, domain name, email, etc.
Used for authentication, authorization, access control, policy
enforcement
Are these identities trustworthy and usable?





Behaves as expected/claimed
Verifiable and traceable (quality of trust)
Privacy Concerns: What if it is compromised? What if it is used inappropriately?
What is the degree of trust required for a specific identity?
Usability: Burden on end users, for example how much trust a
user can have on a URL, email address, or a domain name?
Trust at the network layer

IP/domain based trust:



For example, Trust established based on a routable IP
address participates in a 3-way handshake (not enough,
known issues)
IPSec, IPv6, TLS, etc. provide some level of authentication
Issues: The problems faced by majority internet
traffics which are caused by abuses and exploits


Internet suffers from attacks because there is very limited
capability to trace the attacker based on IP address and
other network based identities (For example: SPAM BOTS,
Spoofed DOS attacks etc.)
If an identity is verified and traceable, it may still lack the
capability to determine the degree of trust
Examples of Network Specific Issues

Lack of network or lower level namespace/identity



IP address and DNS namespace have limitations for security and
cannot be used for trust or identity
IP addresses can be easily spoofed, causing DOS and other
security threats
Dynamic address assignments (DHCP) and mobility, multi-homed
(Mobile IP does not necessarily solve all these but can be
considered a starting point for evolution?)

What if every network connection session, stream or packet could
be trusted ?
Approaches to address the issues

Incremental/Evolutionary?



Futuristic questions (Minds of GENI/FIND)





For example IPSec, VPN, IPv6 CGA etc.
Considerations: overheads, computational issues, approaches need to
extend TCP/IP standards
What is wrong fundamentally with TCP/IP?
What is the right/different model (clean slate)?
What is the impact to the Internet and the applications relying on it?
What is the impact to the internet economy?
How can (relevant) technologies help?




Virtualization
Trusted platforms
Decentralized trust models
High performance networks/platforms
Potential Benefits of a Network Based
Identity System





Provides inherent trust in networks, end-nodes and
application entities using trusted network identities
Could allows a holistic “Reputation” type approach
versus per service or per application based model
End-Node protection, Infrastructure protection
Building block at to include authentication,
authorization and security for bigger known issues
such as SPAM and DOS
Authentication and Authorization: Can be used to protect
and restrict access to network resources and
applications
Potential Benefits of a Network Based
Identity System


Could be used for forensics and trace back etc. IP address is difficult
to track for DOS/Trace back etc.
Simplify and strengthen application layer identity and security:


Help simplify higher-layer security by using trusted network layer for
reuse of common functionality
Application layer services could use the network layer trusted identity
as foundation and framework for authorization and policy decision



Examples such as SIP and Web Services: can these and others gain
from a network level trusted identity?
Network level trusted identity could help enable applications and
protocols challenged by NAT/Firewall traversal issues
Mobility: Potentially provide seamless mobility while allowing
enterprise and other network to maintain the network boundaries
Backup
Existing and related work, approaches:
HIP

Related work in Network level: HIP in IETF




New identity space is proposed to be wedged between the DNS and IP
address spaces, providing identity for what the authors call “computing
platforms” (often realized as an IP stack), which in turn are the sources and
destinations of packets and the supporters of application services.
HIP uses public-key-based identity to protect against man-in-the-middle
attacks. Identifier is a public key that can be used effective for security
protocols such as IPSec.
Uses DNS to store these as RR entries.
Authentication mechanics: The Base Exchange is a Sigma-compliant […]
four packet exchange. The first party is called the Initiator and the second
party the Responder. The four-packet design helps to make HIP DoS
resilient. The protocol exchanges Diffie-Hellman keys in the 2nd and 3rd
packets, and authenticates the parties in the 3rd and 4th packets.
Additionally, the Responder starts a puzzle exchange in the 2nd packet, with
the Initiator completing it in the 3rd packet before the Responder stores any
state from the exchange.
Existing and related work, approaches:
DevID

Related work in IEEE 802.1AR






DevID in progress, 802.1AF extending 802.1x802.1AR provide protection of
the network against abuse through unauthenticated and unauthorized
access
Globally unique manufacturer provided Initial Device Identifier (IDevID),
Locally Significant Device Identifiers (LDevIDs), LDevID is bound to the
IDevID in way that makes it impossible (to within a known and exceedingly
small bound) for it to be forged or transferred to a device with a different
IDevID without knowledge of the private key used to effect the cryptographic
binding.
This standard uses and selects options provided by X.509 specifications.
802.1AR. Usage models for network-centric enterprise scenario and home
network devices amongst others.
Key attributes required for device identity, security requirements, owner,
issuer, replication etc.
Do we need to modify EAP to use this? First use model is 802.1x based
authentication. Allow auto-configuration and plug-n-play etc.
Existing and related work, approaches: I3

I3 work:



In summary, this work is a proposal to create a thin veneer
overlay above the IP layer that consists of a separate
identity space with flexibility in the mappings of those
identities to IP addresses
In order to improve the support of various functions that
have previously been supported to some extent by IP
addresses
but with various restrictions imposed by IP addresses and
their use for actual delivery of routed packets to their
destinations.
Existing and related work, approaches:
802.1x framework

Other related standards: 802.1X based
framework


Have been used for authentication, authorization
and accounting at the first network hop
Several extensions are in progress or planned
such as 802.1AR which will help extend this and
standardize the device identification
References




HIP: http://www.ietf.org/rfc/rfc4423.txt, http://www.ietf.org/internet-drafts/draftietf-hip-base-06.txt
I3 Work: http://www.cs.berkeley.edu/~istoica/papers/i3-sigcomm02.pdf
Problem and Applicability Statement for Better Than Nothing Security (BTNS):
http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-applic-04.txt
Delegation oriented architecture and EID:





I.Stoica, D.Adkins, S.Zhuang, S.Shenker, and S. Surana, Internet Indirection
Infrastructure. In ACMSIGCOMM, Pittsburgh, PA, Aug. 2002
New namespace for endpoints:


http://nms.csail.mit.edu/doa/
http://nms.lcs.mit.edu/papers/layerednames-sigcomm04.pdf
http://nms.lcs.mit.edu/papers/doa-osdi04.pdf
http://users.tkk.fi/~jylitalo/publications/EW04-Ylitalo-Nikander.pdf
IPv6 Cryptographically Generated Addresses (CGA):


http://www3.ietf.org/proceedings/03nov/I-D/draft-ietf-send-cga-02.txt
http://www.rfc-editor.org/rfc/rfc3972.txt