Privacy and Trust for Network Identities

1. Privacy and Trust for Network Identities Manish Dave, Toby Kohlenberg, Hong Li Intel Corp.

2. Outline • Privacy, Trust and Identities • Trustworthy and Usable identities • Trust at the network layer • Network Specific Issues • Approaches to address the issues? • Potential Benefits

3. Privacy • Privacy is a critical issue for the Internet and Community • 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? • Privacy is also associated with anonymity and can conflict with security • 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?

4. 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.

5. 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?

6. 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 in-appropriately? • 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?

7. 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

8. 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 ?

9. Approaches to address the issues • Incremental/Evolutionary? • For example IPSec, VPN, IPv6 CGA etc. • Considerations: overheads, computational issues, approaches need to extend TCP/IP standards • Futuristic questions (Minds of GENI/FIND) • 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

10. 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

11. 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

12. Backup

13. 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.

14. 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.

15. 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.

16. 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

17. References • HIP: http://www.ietf.org/rfc/rfc4423.txt, http://www.ietf.org/internet-drafts/draft-ietf-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: • http://nms.csail.mit.edu/doa/ • http://nms.lcs.mit.edu/papers/layerednames-sigcomm04.pdf • http://nms.lcs.mit.edu/papers/doa-osdi04.pdf • 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://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