1

Providing Ubiquitous Networks

Securely

Using Host Identity Protocol (HIP)

Akihiro TakahashiGraduate School of Informatics, Kyoto University

Yasuo OkabeAcademic 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 administrator is an ordinary person To anonymous public visitors Without charge

We propose the network model using HIPConsideration 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

UserCorrespondent

NetworkAdministrator

the Internet

OtherNetwork

Malicious

Attack!

Who!?

Who??

No! No

!

Need authenticationWho the user is?

Manage many accounts

take logs → burden

6

Nonrepudiation

6

UserCorrespondent

NetworkAdministrator

the Internet

OtherNetwork

Malicious

Attack!

Who!?

An ordinary person

Maybe, youUse my

network FREE!

Can I trust him?He can eavesdrop

my packets…

The administrator can attack to you!

Put the blameon the

administrator

!?

No, you are the attacker!

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

User Administrator

Authentication

Provider

Top Level RADIUS proxy

.jp .au …

RADIUS Tree

AuthenticationCooperation

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)

User

NetworkAdministrator

the Internet

OtherNetwork

User

Authentication

Connection via VPN Server

VPN tunneling

Authentication

Connection via VPN Server

VPN tunneling

VPN Server

File Server

14

ComparisonAuthentica

tionTaking logs

Nonrepudiation

FON FON team not need NG

eduroam

RADIUS server

need NG

MIAKO VPN server not need OK

Proposal DNS server need OKRouting Complaint to

FON end-to-end the administrator

eduroam end-to-end the administrator

MIAKOvia VPN server

the VPN address

Proposal end-to-end the HIT or HI

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

modeAll connection based on HIP↓

Secure and Safe Ubiquitous Networks

16

Host Identity, Host Identity Tag

Public key

Private key

Host Identity Tag

Host Identity

Local Scope Identity

Oneway hash

128bits

32bits

Last digits

Overlay Routable Cryptographic Hash Identifiers (ORCHIDs)

a special classof IPv6

usedat local network

512, 1024, or 2048bits

RSA by default

Base Exchange

Initiator

Responder

IPsec data traffic

I1

R1

I2

R2

HIP

Diffie-Hellman

key exchange

Encrypted

Base Exchange

17

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

Distributing Costs

User

Correspondent

DNS Server

the InternetOther

Network

Proposal model

Service Provider• Manage an access

point• Contract the Internet

service• Take logs

Authentication Provider

• register users to DNS

• operate DNSSEC server

Tunneling

NetworkAdministrator

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

Traceability 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 21

AliceBob

IPsec data traffic

I1R1I2R2

The administrator can verify packets and trace users only by Base Exchange

packets

The administrator should record relationship of BE packets.

Otherwise, the administrator cannot understandwhich BE is certainly completed.

In our network, the administrator allows data packets

that has completed Base Exchange.

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

24

UserCorrespondent

NetworkAdministrator

DNS Server

the Internet

OtherNetwork

Once access to

DNS…

Connection is End-to-End

and data is encrypted

Check…

Malicious

Attack…

Incorrect!

Who!?

the attacker!! Cannot eavesdrop packets’

data

Feel safe

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!