Providing Ubiquitous Networks Securely Using Host Identity Protocol (HIP)

1. Providing Ubiquitous Networks SecurelyUsing Host Identity Protocol (HIP) Akihiro Takahashi Graduate School of Informatics, Kyoto University Yasuo Okabe Academic Center for Computing and Media Studies, Kyoto University

2. Introduction • Open Ubiquitous Network Architecture • Anyone can PROVIDE a network safely, easily • How an administrator provide his network to visitors safely? • The administratoris an ordinary person • To anonymous public visitors • Without charge We propose the network model using HIP Consideration about operating, and some attacks

3. Problems • If an incident has occurred • The administrator should be able to trace users • Need to authenticate users • Managing accounts, taking logs…burden • The correspondent raises a complaint to the administrator • By the source IP address of attack packets

4. Problems • Reduce or distribute authentication costs • Register users and take logs • Complaint by a correspondent • The administrator ≠ A business person • Prove that the administrator is NOT malicious • Nonrepudiation

5. Problems the Internet Who?? Attack! Network Administrator Need authentication Who the user is? Other Network No! No! Manage many accounts take logs → burden Who!? Malicious User Correspondent

6. Nonrepudiation the Internet An ordinary person Maybe, you !? Attack! No, you are the attacker! Use my network FREE! Network Administrator The administrator can attack to you! Other Network Can I trust him? He can eavesdrop my packets… Who!? Put the blame on the administrator Malicious User Correspondent 6

7. Our Proposal • The administrator provide the network in which only HIP connections are allowed • Traceability • HIP host has an ID unique in the world • DNS Security Extensions (DNSSEC) • HIP is an end-to-end protocol • The correspondent can raise a complaint to the attacker or DNS operator by HIP ID • The administrator can avoid the complaint

8. Our Proposal • Distributing authentication costs • The DNS operator manages authentication • Nonrepudiation • Data is encapsulated by IPsec ESP mode (in HIP) • The administrator cannot eavesdrop packets

9. Related Works • FON • Buy FON access point and register to FON • Authentication • FON members can use networks provided by other FON members • An administrator = A user • The administrator does not have to take logs • Risk of session hijacking is large • Traceability → ? • Nonrepudiation → ?

10. Related Works • eduroam • A roaming service between universities • RADIUS • Authentication • The administrator is TRUSTED • Anyone cannot provide a network • Nonrepudiation → ?

11. eduroam Top Level RADIUS proxy RADIUS Tree .jp .au … Authentication Provider Authentication Cooperation User Administrator

12. Related Works • MIAKO.NET (Mobile Internet Access in KyotO) • Komura, Ohira et al. (‘03〜) • Using PPTP as a VPN tunneling protocol • Users can connect only by VPN tunneling after the authentication • The administrator cannot eavesdrop packets • Nonrepudiation • Distributing authentication costs • The VPN server operator and the administrator

13. MIAKO.NET (Ohira et al., ‘10) Connection via VPN Server VPN tunneling Connection via VPN Server VPN tunneling the Internet Network Administrator Other Network Authentication VPN Server File Server Authentication User User

14. Comparison

15. Host Identity Protocol(RFC 5201) • End-to-End security protocol • Authenticate each other • Each host has a pair of a public key and a secret key • Each host has an ID unique in the world • Data is encapsulated by IPsec ESP mode All connection based on HIP ↓ Secure and Safe Ubiquitous Networks

16. Host Identity,Host Identity Tag Host Identity RSA by default 512, 1024, or 2048bits Private key a special class of IPv6 used at local network Public key 128bits 32bits Host Identity Tag Local Scope Identity Oneway hash Last digits Overlay Routable Cryptographic Hash Identifiers (ORCHIDs)

17. Base Exchange HIP Initiator Responder Base Exchange I1 Diffie-Hellman key exchange R1 I2 R2 IPsec data traffic Encrypted

18. Proposal • We propose the network model using HIP • Based on MIAKO.NET, HIP replaces VPN • Each host’s ID used in HIP is stored in DNS • Use DNS Security Extensions (DNSSEC) • The DNS operator registers users to the DNS • Know who users is • Distribute management costs • If there is any incident, the administrator can trace users via the DNS operator

19. Distributing Costs the Internet • Proposal model Tunneling Other Network Network Administrator • Authentication Provider • register users to DNS • operate DNSSEC server DNS Server • Service Provider • Manage an access point • Contract the Internet service • Take logs User Correspondent

20. Nonrepudiation • Users authenticate each other • Understand who is the correspondent • An attacker cannot put the blame on the network administrator • Data is encrypted • The administrator cannot eavesdrop data

21. Traceability The administrator can verify packets and trace users only by Base Exchange packets • User Alice in the administrator’s network connects to the correspondent Bob in other network • Alice: Name resolution of Bob • Alice: I1 packet → Bob • HIT, IP address (R1, I2, R2 also includes this info. ) • Bob: R1 packet → Alice • HI of Bob, the signature of Bob • Alice: I2 packet → Bob • HI of Alice, the signature of Alice • Bob: R2 packet → Alice • the signature of Bob In our network, the administrator allows data packets that has completed Base Exchange. Alice Bob I1 R1 I2 The administrator should record relationship of BE packets. Otherwise, the administrator cannot understand which BE is certainly completed. R2 IPsec data traffic

22. Taking logs, Detection of Incorrect Packets • The administrator records only BE packets • Other data packets are encapsulated • The administrator checks BE packets • Can detect incorrect packets • Packets whose HI does not exist in DNS • Packets performing an incorrect process • Take logs • Established associations • Can trace users by these logs

23. Some Threats • Forging packets, eavesdropping, spoofing • Data is encrypted, and using electronic signature • DoS, DDoS attack • Bandwidth control • Session hijacking • Attackers conspires each other • Forge the header of data packets • Without conspiracy of attackers → Safe

24. Summary the Internet Incorrect! the attacker!! Check… Cannot eavesdrop packets’ data Network Administrator Other Network Once access to DNS… Connection is End-to-End and data is encrypted Who!? DNS Server Feel safe User 24 Malicious Attack… Correspondent

25. Summary • We proposed the network model using HIP • Distribute authentication costs to the DNS operator • If an incident has occurred, the complaint is by ID • Nonrepudiation • Protected against eavesdropping, spoofing • An attacker cannot put the blame on the network administrator • DNS Security Extensions (DNSSEC) • The administrator can verify packets and trace users • Traceability

26. Future Works • Implementation and evaluation • Packet filtering, verify packets… • Base Exchange is controlled by State Transition • The administrator should understand Base Exchange State Transition • Take logs, detect incorrect packets, check DNSSECRR… • The log’s format

27. Thank you for listening!