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 (Challenge-Response, 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 Ticket-Granting Ticket (TGT): The KDC decrypts the timestamp with client’s key, checks it and replies with TGT and session key : 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: The KDC decrypts the timestamp with the session key, decrypts the TGT, checks them and grants the client with the ticket for the server: In this way, the client obtains the session key , 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: The server decrypts the ticket with its own key , to obtain the shared session key . 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.

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: Priority is the priority of the node in the network. Lifetime means how long its key is valid. ID Hashed Password Priority Lifetime Server1 0010101010101010 9 3600 Server2 1010101110011110 8 3000 Client1 1001110111111001 5 1200 Client2 0101010111010101 6 2000

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: 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 by usual procedure. Then each updated record is sent with each replication: when Seq# is the sequence number for the record.

The End