Download Kerberos Assisted Authentication in Mobile Ad

KAMAN
Kerberos Assisted Authentication
in Mobile Ad-hoc Networks
by Vladimir Ostrovsky
Routing in ad-hoc networks

In contrast to classical wired networks, any
node in ad-hoc network may be chosen to
route traffic for other nodes.

The choice is made according to its
geographical position, computing resources,
etc.

Routing paths may change dynamically as the
nodes join, leave or change their position.
MANET routing - illustration
Routes are periodically recalculated:
Security implications

Also, in wireless mobile network every node may hear
traffic between all nodes, by changing its position if
needed.

These properties make ad-hoc networks very
susceptible to a large variety of attacks.

The attacks may be carried on many layers – physical,
MAC, network, application, etc.

The aim of the attacks may be eavesdropping, DoS on
network or specific node, unauthorized access, etc.
Possible attacks on ad-hoc networks

Worm-hole: replaying messages in order to take
control on routes between nodes.

Black-hole: redirecting routes to hostile node, which
will discard all traffic.

Battery exhaustion: redirecting routes to a victim node,
in order to waste its battery on the excess traffic.

Impersonation: attempt to “steal” MAC of IP address of
another station in order to get unauthorized access.

Jamming: on physical or MAC layers.
Classical attacks become easier

Passive eavesdropping.

“Man-in-the-middle”: can be carried out much
easier than in the wired network.

Replay attacks: made easier due to ability to listen
to the traffic.

Flooding attacks: other nodes are exploited to
distribute junk traffic.
Example – worm-hole attack
Here nodes A and B think that they are neighbors:
In this way, routes in the network are manipulated
without actually injecting false routing messages.
Partial solution - cryptography

Many of the described attacks can be
prevented by use of cryptography.

Many, but not all. Worm-hole attack, for
example, cannot.

Cryptography may be applied on many layers
– from MAC to application.

MAC frames may be encrypted, routing
messages can be signed, SSL tunnels may be
built, etc.
Key distribution

In order to use cryptography, secret keys have to be
distributed between nodes.

The keys may be symmetrical (WPA, IPsec) or
asymmetrical (SSL, IPsec).

Encryption keys may be distributed manually (WEP) or
established during negotiation (PGP).

The authentication scheme may be direct (ChallengeResponse, SSH) or may relay on third party (PKI,
Kerberos).
Key distribution - continued

In most primitive case (WEP), encryption keys are
simply entered by administrator to every network’s
node.

In more complex case (PKI), each node may have
unique digital certificate signed by a common trusted
party (CA). Keys are created dynamically during
negotiation.

We will focus on a modification of Kerberos system for
ad-hoc networks, called KAMAN.
Kerberos
Named for a three-headed infernal dog from
Greek mythology that guarded a gate to Hades.
Kerberos - features

Kerberos is based on symmetric keys only.

It is used to mutually authenticate 2 parties
and to establish common secret key between
them.

In order to do so, it relays on a third party, Key
Distribution Center, trusted by both of them.

The common key may be used for encryption,
signing or even for access control.
Kerberos – basic principles

Three parties are involved: client, server and KDC (3
heads of the dog).

Client wants to establish connection to the server.

For this purpose, it doesn’t prove the server that it
knows the right key.

Instead, it provides the server with a ticket, issued by
the KDC. The ticket proves that KDC knows this client.
Kerberos – basic assumption

The client and the KDC both know client’s secret
key.

The same about the server and the KDC.

The client and the server shall establish another
secret key, shared by both of them.

The idea: if someone provided me some relevant
data encrypted with my secret key, then he has
the key.
Kerberos - operation

At step 1, client needs to prove his identity to the
KDC.

It does it by sending a request to KDC for a TicketGranting Ticket (TGT):
 client , KDC , nonce,{timestamp}KC 

The KDC decrypts the timestamp with client’s key,
checks it and replies with TGT and session key SC , KDC:
 {SC , KDC }K C , TGT  {client , validity, SC , KDC }K KDC 

TGT is used in order to avoid using client’s secret key
as possible.
Kerberos - operation

At step 2, client contacts KDC to obtain ticket for a server by
presenting his TGT:
 service , TGT , {client , timestamp}SC,KDC 

The KDC decrypts the timestamp with the session key,
decrypts the TGT, checks them and grants the client with the
ticket for the server:
 Ticket  {client , validity, SC , S }K S , {SC,S }SC,TGS 

In this way, the client obtains the session key SC , S , which will
be shared by him and by the server. Now he has to transport
it to the server.
Kerberos - operation

At step 3, the client sends to the server:
 Ticket, {client , timestamp}SC , S 

The server decrypts the ticket with its own key K S , to obtain
the shared session key SC ,S .

Then it uses the session key to validate the client’s name
and timestamp. Thus it knows that the client is genuine.

The server responds to the client:

The client decrypts this to validate the server.
 {timestamp  1}SC , S 
Kerberos - illustration
Kerberos - operation

In this way, the server authenticates the client, and the
client authenticates the server, without knowing each
other’s secret key.

The client delivers TGT and tickets as a proof of its
identity, but cannot read them.

The server doesn’t have to talk with KDC at all.

The common key is established between client and
server.
Kerberos - drawbacks

The KDC is a single point of failure – if it’s
unavailable, nothing will work.

If the KDC is compromised, all keys are
compromised.

Strict clock synchronization is required
between all parties, because of the
timestamps.
KAMAN: Specifics of ad-hoc networks

Every node can join and leave in unknown time.

Every node can play a role of a server or of a
client.

Energy is limited and should be saved when
possible.

A node can be captured by hostile party.
KAMAN: differences with standard Kerberos

Several servers are needed to avoid single point of
failure.

Databases of the servers should be regularly
replicated.

The protocol is modified to require less steps.

Optional Availability Check is added to verify that a
node still in the hands of its legitimate owner.
KAMAN: secret keys - assumptions

All clients have a secret key or password known only
to them.

All servers know the hashed passwords of all the
clients and of all other servers (by replication).

When a node is elected to be a server, it receives the
passwords database by replication. When it’s
downgraded to client, the database is deleted.
KAMAN: passwords database

Each server stores the following table:
ID
Hashed Password Priority
Lifetime
Server1
0010101010101010
9
3600
Server2
1010101110011110
8
3000
Client1
1001110111111001
5
1200
Client2
0101010111010101
6
2000

Priority is the priority of the node in the network.

Lifetime means how long its key is valid.
KAMAN: operation

Let’s say Client1 wants to contact Client2.

The client sends request for a ticket to the KAMAN server.

In order to save precious energy, we eliminate the use of
TGT – it saves us one round to the server.

The server checks lifetime of the both clients and replies
with the ticket for Client2. The reply also includes session
key for Client1
KAMAN: operation

Client2 receives the ticket, decrypts it and
obtains the session key with Client1.

It replies to Client1 with the timestamp and
sequence number used to avoid replays. The
reply is encrypted with the session key.

The reply also includes another session key,
unknown to the server. The clients may use it
instead.
KAMAN: key renewal

The ticket issued by the server is valid as long as the
password.

If the ticket is going to expire, but the client still needs
it, it can apply for a new password.

The client sends a request to the server, which
replies with:
 client 1 , {new _ pass, time, nonce, client 1}old _ pass 

Then the client may request a new ticket, using the
new password.
KAMAN: Optional Availability Check

A possibility exists that a mobile device of the ad-hoc
network will be lost or fall into hostile hands.

To minimize the risks, the device may periodically or
by request from the server require its operator / user to
verify his presence – by password, biometrically, etc.

If the operator fails to do this, the device notifies the
server, downgrades itself (if it was a server), deletes
all keys and tickets. Its record is removed from the
database.
KAMAN: server elections

Elections happen, when servers number changes,
when lifetime of some server expires or when it
doesn’t pass Optional Availability check.

Servers periodically monitor each other with secure
messages, to check if they are alive.

The servers check their databases for client with the
highest priority. If several such clients exist, then
lifetime is taken into account.

The chosen client is upgraded to server and receives
the database by replication.
KAMAN: replication

Replication updates may be requested periodically by
servers, or pushed by the server which database was
modified.

In order to send or query the change in the database, the
servers establish for themselves a session key S S 1, S 2 by
usual procedure.

Then each updated record is sent with each replication:
 {timestamp , Seq # }S S1, S 2 
when Seq# is the sequence number for the record.
The End