The Multicast Internet Key Exchange (MIKE) in Tactical Ad Hoc Networks

ahemcurrentNetworking and Communications

Nov 21, 2013 (3 years and 8 months ago)

110 views



RTO
-
MP
-
IST
-
111

17

-

1



The Multicast Internet Key Exchange (MIKE)

in T
actical Ad Hoc Networks

Anne Marie Hegland

/
Hans
-
Are Ellingsrud

Kongsberg Defence & Aerospace AS

P.O. Box 87, NO
-
1396 BILLINGSTAD, Norway

anne.marie.hegland@kongsberg.com

/
hans.are.ellingsrud@kongsberg.com


ABSTRACT

The existing tactical ad hoc networks
typically
rely on pre
-
sh
ared

symmetric group keys and hop
-
by
-
hop
encryption for

their communications. This has the shortcoming that it is hard to

dynamically include new
members. It would be beneficial if the

key management scheme enabled secure information sharing with

the
friendly forces that move into the area. The Multicast Internet

Key Exchange (MIKE) is designed with
dynamic group changes

in mind. The article assesses MIKE for the use in tactical ad hoc

networks and
proposes a number of optimizations that can

enhance it
s performance.

1.0

INTRODUCTION

M
uch of the communication at the lower tactical echelons

is multicast radio traffic by nature. As an
example,

position data for friendly force tracking must be distributed to

all coalition partners within
shooting range. Cur
rent systems

typically rely on pre
-
placed symmetric group keys (PPK) to

protect the
radio communication. Friendly forces that move

into the area need the proper group key to start receiving

position data and other information. Key management schemes

that a
llow dynamically inclusion of new
members are sought.

The Multicast Internet Key Exchange (MIKE) is one

candidate. Basically, MIKE
does for multicast groups what the

Internet Key Exchange (IKEv2) [1] does for unicast peers: It

provides
automated negotiatio
n of symmetric cryptographic

keys for IPsec. IKEv2 is geared towards two
communicating

peers. MIKE provides a group key.


The article assesses MIKE and its applicability for wireless

ad hoc communication at the lower tactical
levels, and suggests

some enha
ncements.
The assessment is based on available documentation on MIKE
reported in
[2]
[3]
[4]
[6]

and
[7]
.
The work has been carried out by

Kongsberg Defence & Aerospace in co
-
operation with the

Norwegian Defence Research Establishment as part of the

CoNSIS (Coalition Network
for Secure Information Sharing)

project. Additional details are described in [9]
.


Section
2

provides an introduction to MIKE. Then the

scenario is studied in section
3
. Section
4

provides
the

evaluation criteria and section
5

the results of the assessment.

Section
6

elaborates on possible
optimizations. Related work

is described in S
ection
7

and concluding remarks and further

work are
summarized in section
8
.

2.0

I
NTRODUCTION TO
MIKE

MIKE operates in either Key Agreement or Key Distribution

mode of operation. In the Key Distribution
mode

a Group

Controller (GC) generates and
distributes all keys. In the Key

Agreement mode all users
contribute to the generation of the

group key.

Both modes use Key
-
trees for efficient key management. In

the Key
D
istribution mode the Key
-
tree is a logic construct

known only by the GC who knows al
l keys. In
the Key

Agreement mode all users
must have
a common view of the

Key
-
tree
, but n
o single entity knows
all

keys in the Key
-
tree.

The basic operations are user Join and user Leave. Both

modes of operation
demand a

Public Key

Infrastructure (PKI).

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks






17

-

2

RTO
-
MP
-
IST
-
111



2
.1

Key
-
trees

Key
-
trees are here explained as used in the Key Distribution

mode. The purpose of the Key
-
tree is
optimized key

distribution. Instead of encrypting the new group key with the

individual keys of all N
group members it is encrypted with

auxiliar
y keys shared by subsets of the users.


The Key
-
tree consists of two types of nodes: key nodes

representing keys and user leaves representing
users. Figure 1

illustrates the concept. A user (N) knows only the keys on the

direct path from his leaf to
the
root node (highlighted). The

root node is the group key. User leaves contain unique user

keys. The
other nodes contain auxiliary keys.



Figure 1: Key
-
Tree

Figure 1 illustrates that all users/group members (N1
-
N8)

possess the group key K
12345678
. The
auxiliary
key K
1234
is

common to N1
-

N4, and K
12
is shared by N1 and N2. K
1


K
8

refer to the individual users’ keys.
Assuming user N8 is to be

expelled; all keys known to N8 (K
12345678,
K
5678
and K
78
) must

be updated. N7
shares all auxiliary keys with N8.

N7 therefore

receives all updated keys encrypted with its individual key.

The new group key and auxiliary key is distributed to N5 and

N6 encrypted with their auxiliary key K
56
.
To N1
-
N4, the

group manager sends the new group key K
1234567
encrypted

with a
uxiliary key K
1234
.
Bandwidth and computational cost is

saved compared to traditional distribution where the new group

key
is encrypted with the individual keys of each remaining

group member.


2.2

Key

Distribution Mode of Operation

2.2.1

Join

Figure 2
outlines the five steps of the Join protocol. The first

three steps are a three
-
way mutual
authentication protocol that

includes a Diffie
-
Hellman key exchange.


Step 1:
The user unicasts a signed “JoinRequest” message

to the GC. It includes information abo
ut the
user identity and

the group security association for which the group key is need.

The signed JoinRequest
message also includes the user’s

public Diffie
-
Hellman value and a nonce for replay detection.


Step 2:
The GC returns its own public Diffie
-
Hel
lman value

in a signed “JoinDistribute” message. The
message also

includes the identity of the GC and a new nonce, plus

information received from the user in
the join message.

Step 3:
The Diffie
-
Hellman based shared secret key
has

now been established betw
een the joining user
and the GC.

The user completes the 3
-
way mutually authenticated Diffie
-
Hellman key agreement by
unicasting a “JoinConfirm”

message. It is a signature calculated over the nonce issued by

the user and the
nonce received from the GC and h
is public

Diffie
-
Hellman value plus the group security association.

N1
N2
N3
N4
K
1
K
2
K
3
K
4
K
12
K
34
K
1234
N5
N6
N7
N8
K
5
K
6
K
7
K
8
K
56
K
78
K
5678
K
12345678
Group Key
Auxiliary Keys
Individual Keys
Users
N1
N2
N3
N4
K
1
K
2
K
3
K
4
K
12
K
34
K
1234
N5
N6
N7
N8
K
5
K
6
K
7
K
8
K
56
K
78
K
5678
K
12345678
Group Key
Auxiliary Keys
Individual Keys
Users

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks


RTO
-
MP
-
IST
-
111

17

-

3




Figure 2: Outline of MIKE Join protocol for Key Distribution mode of operation

Step 4:
The GC unicast the group key and necessary

auxiliary keys to the joining user through the
“Distribute”

message. The information is encrypted with the shared secret

from step 3, and the message is
signed with the aid of the

private key of the GC. The group key can be a new one or the

current one


depending on the group policy.


Step 5:
If the g
roup policy demands backward secrecy, the

last step is key update. The GC multicasts the
group key and

relevant auxiliary keys all group members in the

“UpdateDistribute” message.


The updated keys are encrypted with the auxiliary keys

where possible, and
encrypted with individual user
keys to

those nodes close to the new user in the Key
-
tree. The signed

UpdateDistribute message includes
the identity of the GC,

group security association information and sequence number


all encrypted with
the group key, an
d the new key table and the

signature of the complete message.


2.2.2

Leave

Figure 3 shows the Leave protocol. The user unicasts a

Leave request to the GC
. The GC

confirms it, and
multicasts new

keys to the remaining members of the group.

The GC can re
-
key

immediately, or postpone
the update

until more leave requests have been received. The GC can also

eject a node independently of
leave requests through an

UpdateDistribute message.


Figure 3: Outline of MIKE Leave protocol for Key Distribution mode of ope
ration

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks






17

-

4

RTO
-
MP
-
IST
-
111



2.3

Key Agreement Mode of Operation

In this mode all users participate in the generation of the

group key. They must all know and agree on the
Key
-
tree. It is

built through iterative Diffie
-
Hellman key agreements. Users

N1 and N2 establish a
common secret key
K
12
=
g
ab
mod p

where
a
and
b
are secrets known only by N1 and N2,

respectively. In
the same way users N3 and N4 establish a

common secret key,
K
34
=
g
cd
mod p
.
The
blinded
version of

this
key,
g
K
34

mod p
,
is exchanged w
ith users N1 and N2 and

vice versa. N1 and N2 as well as N3 and N4 can
then calculate

the next key on the path to the root,
K
1234
=
g
K
12
K
34

mod p
.
But

N1 and N2 can not reveal
K
34
,

likewise N3 and N4 cannot

reveal
K
12
.

Through these iterative Diffie
-
Hellman exchanges,

all members
learn the group key and
the
Key
-
tree, but no party get

to know all keys in the tree.

One node is appointed
Transaction Manager (TM). The TM

is responsible for processing subsequent Join and Lea
ve

requests.


Figure 4 shows the join and leave protocols after the initial group key

establishment.

A joining user sends
its public Diffie
-
Hellman value to the

TM. This is done in a tree
-
way mutual authentication

procedure
identical to the one used in the

Key Distribution

mode. The newcomer does not know who the current TM
is,

but posts the JoinRequest to a predefined multicast address.

Only the TM answers this request. After
the three
-
way

handshake, the new node is included in the tree, and the TM

transfers the TM role to the
newcomer in the “TMDistribute

message”. In same message, it also re
-
distributes the Key
-
tree

with all
blind keys. The new TM calculates the tree path by

using Diffie
-
Hellman multiple times. Then the new
TM

multicast the new bli
nd keys on the path from itself to the root

in the “UpdateDistribute” message.
Every user can now

calculate the group key.



Figure 4:
Join and Leave protocols in MIKE Key

Agreement mode of operation

A Leave is initiated by the exiting user. The user
mult
icasts

a

Leave request to the TM. The TM confirms
the Leave and

removes the user from the Key
-
tree. It also sends an

UpdateDistribute message that enables
the remaining users to

calculate the new group key.

The TM has the power to eject nodes without Leave

request.

If the TM leaves, it must transfer the TM role to one of the

remaining group
-
members before it
exits.

A missed UpdateDistribute message has the same effect as

being ejected. All group members
therefore start a timer when

a JoinRequest multicast i
s heard. If the UpdateDistribute has

not been
received within the expected time frame, the group

member assumes it has lost the new group key and
initiates a

new JoinRequest. LeaveRequest is also sent as a multicast and

enables the members to start
their t
imer.


The procedure “AgreeOnTM” is initiated in case the TM is

lost and a new TM must be elected. The
AgreeOnTM is based

on SecureRing communication [5]. First the users flood

presence information. All
users send a Join message. After

some Join messages
all users get a common view of the

available
members. Then they send Commit messages which

trigger the election of a new TM. A token is circled,
and the

TM is uniquely defined during the process.


USER n
TM
Join
Request
JoinDistribute
JoinConfirm
Group
TM
Distribute
USER n
TM
LeaveRequest
LeaveConfirm
Group
UpdateDistibute
New TM
LEAVE
LEAVE
UpdateDistribute
3
-
way
handshake

mutual
authentication
Appoint
new
TM
Distribute
new
group
key
Multicast
Unicast
Unicast
Multicast
Multicast
Multicast
Unicast
Multicast
JOIN
JOIN

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks


RTO
-
MP
-
IST
-
111

17

-

5



3.0

O
UR SCENARIO
:
TACTICAL AD HOC NETW
ORKS

Figure 5 illustr
ates our scenario; a multi
-
hop mobile ad hoc

network (MANET) for the lower tactical
echelons.


Figure 5 Scenario: Wireless communication at the lower

tactical echelons

The network consists of heterogeneous VHF or UHF

wireless tactical communication nodes.

The nodes

are at the

same time both routers and end
-
hosts. The nodes differ in level

of mobility as well as in power
resources and transmission

range. Some are vehicle mounted. Others are battery powered

and carried by
dismounted soldiers. Some of the nod
es may

need to enter radio silence (EMCON mode) for shorter or

longer periods. The MANET connects to a fixed or deployable

infrastructure, but connectivity cannot be
guaranteed at all

times. The number of nodes in the wireless network is

typically from 10
to 50.


The MANET differs from a true ad hoc network in the sense

that it has a planned origin and only
authorized nodes are

included in the network. Communication is protected hop
-
by
-
hop

by a group key.
New members of the network need the

proper key in or
der to communicate. The group key can be pre
-
placed.

But there is also a need for including new members ad

hoc, e.g., coalition partners that move into
the area. For

simplicity, the article assumes a single security domain and

one classification level.


4.
0

A
SSESSMENT CRITERIA

4.1

Security

Secure Protocol:
The protocol must withstand attacks on

the protocol messages and the message
sequence. The protocol

must not fail if put under
analyse

using a formal verification

method. The protocol
should also be robus
t to insiders that do

not behave according to the protocol.

Proper cryptographic
primitives are a necessary

precondition. But as the cryptographic primitives can easily be

replaced by
others with the proper strength, emphasis is put on

the protocol rather
than the primitives.


Forward secrecy:
It must be possible to expel compromised

nodes and leave them incapable of learning
new keys through

their knowledge of earlier keys. Backward secrecy is less

important. That is, hiding
earlier information from a
friendly,

authorized user when he joins the network is rarely needed.

Besides,
much of the information exchanged at the lower

tactical levels has only short
-
lived value.

Deployable and fixed infrastructure
MANET
The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks






17

-

6

RTO
-
MP
-
IST
-
111



4.2

Availability

Add new members dynamically:
Pre
-
configuration is to a

large extent p
ossible in the tactical scenario,
but it must also be

possible to add newcomers and friendly forces ad hoc.


Seamless addition of new member and seamless key

changes:
It must be possible to add new group
members and

change keys without disrupting the other

users’

communication. It should be possible to
include new members

without changing the group key. Nodes that are prevented from

taking active part in
transmissions due to radio silence must

not be excluded due to a group key change.

Group membership
chan
ges and key updates must complete

in a timely manner.

4.3

Bandwidth efficiency

Channel occupation is a natural concern in the wireless

environment. The protocol must scale to the
expected group

size. As a rule of thumb, management traffic should not

occup
y more than 10% of the
available bandwidth. Being only

a fraction of the management traffic, MIKE should not use

more than 1
-
2% of the available bandwidth.

4.4

Robustness

Robust to link losses:
Varying connectivity and temporary

outages can be expected.
The protocol must be
robust to

spurious link losses. It must survive Denial of Service (DoS)

and replay attacks without
disrupting the communication.

No single point of failure:
The network must be operable

even if it is partitioned or specific nodes are
temporarily

unreachable.

4.5

Other

Other assessment criteria include parameters such as

maturity
of the protocol and documentation,
intended and

possible
scope of use,
necessary
preconditions
for the

protocol to work and
power
efficiency
.


5.0

MIKE ASSESS
MENT

Table 1 summarizes the
results and
indicates to

what extent the specific requirement is fulfilled.

The table
also compares MIKE to a pre
-
placed key scheme.

The PPK w/KDC column assumes a pre
-
placed group
key and

a Key Distribution Centre (KDC) that ac
t as a GC. It also

assumes pre
-
installed unique
symmetrical keys for protection

of the communication between each member and the KDC.

The initial
pre
-
placed group key is used until the first member

is expelled.

5.1

Security

Secure protocol:
The formal
security analysis of MIKE is a

topic for further work, but some concerns are:

Link the three
-
way handshake to the rest of the Join

protocol:
The value “Seq” in step 4 in Figure 2 serves
as a

freshness anchor that later receptions can be compared to. But

fr
om the description in [2] it is not
obvious how the joining

user can verify the freshness of the message received in step 4.

Information that
links the first three steps of the protocol to the

fourth is needed. This applies both for the Key Distribution

an
d the Key Agreement modes of operation. Recent

implementations now include the sequence number in
the

three
-
way handshake
.



The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks


RTO
-
MP
-
IST
-
111

17

-

7



Table 1: Result of the Assessment



Vulnerability against insiders/ DoS attacks:
The Key

Distribution mode is more robust than the

Key
Agreement

mode to insiders that
deliberately or unintended
do not behave according to the protocol.

The
GC
(as the KDC in the PPK w/KDC scheme)
is one specific and possibly well protected
and more trusted
node. Key

Agreement mode distributes the TM
role. One or more nodes

that repeatedly try to join and
rejoin may impose a constantly

changing key. The change of TM when a new member joins

also makes it
easier for the illicit node to take over control.


Leave’s replay vulnerability:
The Leave request m
essage is

prone to replay attacks.
Neither t
he GC

nor the
TM can easily determine

the freshness of a Leave Request.


With

this background
Table 1

indicates that
MIKE partially fulfils the security

requirements
.

But the Key
Distribution mode can easily be m
ade compliable.

The PPK w/KDC

scheme is secure under the
assumption that the group key and

pair
-
wise symmetric keys were transferred over a secure

channel (e.g.,
manually distributed by courier).

Forward secrecy:
MIKE enables both forward and

backward secr
ecy, and meets the requirement as
shown in

Table 1. In Key Distribution mode of operation the GC

decides whether the keys are updated or
not on a group change.

This is beneficial. In the wireless environment it is hard to

guarantee that all nodes
receive t
he new key in a timely

manner. Unnecessary key changes should be avoided. They

cost
bandwidth and represent a threat to availability


valid

members that missed the key update have to re
-
join
in order to

continue their communication.

In Key Agreement mode
both forward and backward

secrecy
come intrinsically


it is not possible to include or

exclude a node without changing the group key.
Basically,

bandw
idth and availability is traded
for backward secrecy.
This

is undesirable in the tactical
scenario.

The K
ey Agreement mode of operation should be used with

great caution in such networks.

Key
Distribution mode of

operation is considered a better option where possible.

PPK w/KDC

distribut
es
the

new group key encrypted with the pair
-
wise unique keys
.

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks






17

-

8

RTO
-
MP
-
IST
-
111



5.2

Availa
bility

Dynamically addition of new members:

Both modes of

operation enable dynamic inclusion of new
group members

without the intervention of an administrator. This is a major benefit of MIKE compared to
traditional PPK w/KDC.
With PPK w/KDC new members ca
nnot be included

dynamically.

MIKE only
demands an authenticated channel. That is,
there must

still
be
a trust relationship

established in advance.
B
oth the new member and the TM/GC must present a

certificate that the other party accepts. The
certificates
must be

signed by a certificate authority that the other party knows and

trusts.

Seamless key changes and seamless addition of new members:

The Key Distribution mode of operation
enables

joins without re
-
keying

and

hence


seamless addition of new member
s
. The Key Agreement
mode does not.

The key change is an intrinsic part of the Join.

The reason why Table 1 shows only
partially compliant for the key distribution mode is
the MIKE documentation
indicating that the group key
should be updated on every grou
p change.

MIKE k
ey changes are not seamless.
In both modes of operation, a new key instantly becomes the active
one. Nodes that missed the key update may experience disruption and need to re
-
join.
This is a major
drawback.

B
oth
modes of operation
are
vulnerable to

packet losses.
There is no overlap between the
previous and the next key.
Nodes in radio silence that miss the

transmission are cut off until they exit the
radio silence mode

and again are able to re
-
join. Others can re
-
join immediately.

In e
ither case the key
change is not seamless.


Delays from the initiation of a Join or Leave operation until

all nodes have received the new group key
include processing

delays due to cryptographic operations as well as transmission

delays. The total end
-
to
-
e
nd delays are studied in [2], [4] and

[6]. The repeated DH operations in the Key Agreement mode

make it
significantly more resource consuming than Key

Distribution mode with increasing number of group
members. The auxiliary keys used in the Key

Distribution mode are also shorter than DH values.

Consequently the Key Agreement mode gives longer delays

than the Key Distribution mode.


PPK w/KDC enables distribution of the group key to a new

node without demanding that the others
change their key(s).

And once the group key and pair
-
wise keys are pre
-
distributed,

it is possible to change
the keys while retaining the previous

ones until all has received the new. The challenge is to decide

when
all has received the new key. This demands
signalling

betwee
n every user and the KDC. Alternatively the
KDC must

redistribute the new key multiple times in the hope that after a

number of retransmissions there
is an acceptable probability

that all nodes will have received the new key. Both approaches

increase the
d
elay and bandwidth cost.


5.

3

Bandwidth efficiency

Once the group key has been established, MIKE consumes

little or no bandwidth. It is the group changes
caused by Joins

and Leaves that cause bandwidth consumption. In [9] we

calculate the time
that
the
ch
annel is occupied by a Join operation,

i.e. from the new node sends its Join
R
equest message to the

end
of the UpdateDistribute message.

References [2], [4] and [6] provide calculations and

simulation results
for MIKE focusing on total delay including

proce
ssing. Our focus is the transmission delay


the time the

channel is occupied by transmissions of MIKE protocol

messages. We also included the effect of overhead
added by

the lower layers of the protocol stack and certificate

distribution. Furthermore, we
studied the
consequence of

multi
-
hop communication.


The channel occupation is calculated for different numbers

of nodes in the network, considering both a
1Mbps UHF and

20kbps VHF network. The calculations encounter both a 1
-
hop

all
-
hear
-
all network and
multi
-
hop networks. We compare the

channel occupation for Key Distribution and Key Agreement

modes

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks


RTO
-
MP
-
IST
-
111

17

-

9



of operation. The resulting channel occupation refers to

the bandwidth consumed within the
neighbourhood

(1
-
hop

transmission range) of the transmitting node.


The calculations assume MIKE messages are encapsulated

in UDP over IPv6. IEEE802.11b is the MAC
protocol used for

UHF calculations. For VHF a proprietary MAC protocol has

been used. The IEEE
802.11b adds a delay of 552
μ
s per MAC

frame [8], whereas the pr
oprietary VHF protocol is assumed to

add a delay of 125ms per MAC frame. For simplicity, the UHF

calculations assume that all messages


not only multicast

messages


are sent with the IEEE802.11b broadcast data rate

of 1Mbps. In order to
reduce the bit er
ror rate at the IP
-
layer to

an acceptable level, a Forward Error Control (FEC) system is

assumed at the link layer. This FEC adds 20% overhead to all

MIKE messages. The calculations assume
an error free channel

at the IP layer due to the FEC and no collisi
ons. Additional

details of the calculations
are documented in [9].


Figure 6 shows the results. Figure 6a) compares UHF to

VHF 1
-
hop networks including both Key
Distribution and Key

Agreement modes of operation. The figure demonstrates that a

Join operatio
n in Key
Agreement occupies the channel

significantly longer than a Join in Key Distribution mode.

Figure 6b)
highlights the effect multi
-
hop networks. The figure

includes both Key Distribution and Key Agreement
modes of

operation with 16 to 48 nodes as th
is is what we have

simulation data for. The transmission
times of a Join operation

increases significantly when going from a UHF 1
-
hop to a

multi
-
hop networks. It
also shows that a Join in Key

Distribution mode in a multi
-
hop network demands

approximately
the same
amount of bandwidth as a Key

Agreement Join in a 1
-
hop network.


The simulation in [2] indicates that Key Distribution mode

performs well in networks with the
characteristics of Ethernet

and ISDN, but has problems in lower bandwidth networks such

as VHF. Our
calculations support this. The time the channel is

occupied is significantly longer in VHF networks.



Figure 6: MIKE Join Transmission times

0,01
0,10
1,00
10,00
100,00
0
10
20
30
40
50
60
70
80
90
100
Seconds
Number of users
Channel occupation for MIKE Join 1
-
hop network
VHF Key agreement
VHF Key distribution
UHF Key agreement
UHF Key disribution
a)
0,01
0,10
1,00
10,00
0
10
20
30
40
50
60
Seconds
Number of users
Channel occupation for MIKE Join 1
-
hop and multi
-
hop networks
UHF Key agreement, multi
-
hop
UHF Key distribution, multi
-
hop
UHF Key agreement, 1
-
hop
UHF Key distribution, 1
-
hop
b)
The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks






17

-

10

RTO
-
MP
-
IST
-
111



A single key distribution in the Key Distribution mode is

bandwidth efficient. But all users who miss

the
key update

packet need to re
-
join. Table 1 therefore indicates that the

bandwidth efficiency requirement is
only partially fulfilled.


Acknowledgement messages from each member after key updates in the PPK w/KDC scales badly, but
with
the expected gro
up size of our scenario,

PPK w/KDC is assumed to
partially
fulfil the bandwidth
efficiency

requirement.

5.4

Robustness

Key Agreement cannot include new users without changing

the key. Key Distribution can be made more
robust by

allowing group changes witho
ut key changes. Furthermore,

MIKE demands reliable multicast.
This is hard to achieve. The

timers, acknowledged unicasts and forward error correction

mechanisms that
have been included in MIKE only to some

extent cure the problems caused by packet losses a
nd bit errors.


Protection against link losses:
Timeouts: If the expected

response message is not heard within the
timeout interval after

a J
oin
R
equest, the node tries to re
-
join. This mechanism may

be acceptable in those
cases where a single node suffered

from

temporary loss of network connectivity, but it also has the

potential to trigger a multicast storm. If the JoinRequest was

heard, but the TM suffered from network
connectivity

problems, a major part of the nodes in the network may try to

re
-
join at t
he same time. This
can lead to congestions and

cause additional problems.


FEC:

The correct delivery of multicast messages such as the

Update/UpdateDistribute messages is not
guaranteed. A block

FEC increases the probability of successful reception even if

some of the packets are
lost

or garbled
. The drawbacks are that

FEC adds overhead, and it does not help if a burst of packets

are
lost. Nodes in radio silence must wait until they exit this

mode before they can re
-
join.


The PPK w/KDC is robust to link lo
sses under the

assumption of acknowledged key updates. If the last
key is

repeated periodically instead, it will be at least partially robust

to link losses.


No single point of failure:
Only the distributed TM of the

Key Agreement mode of operation meets
this
requirement.

5.5

Other

Maturity:
MIKE is documented through a number of

publications [2][3][4][6][7]

from the research and
implementation process
.

None of the publications include

the detailed protocol and message formats
needed in order to

implement compatible versions of MIKE.

A consistent and complete specification
remains.

I
t can be argued that
one

single and

generally adopted specification for

the
PPK w/
KDC

also
remains
, but

PPK

w/KDC

is well known
and widely used
.

Applicability
-

scope

of use: MIKE as the initial key

management scheme:
MIKE requires an already
running

network service or a one
-
hop network. A newcomer will

otherwise not be able to communicate
with the GC or the TM.

The nodes in the tactical ad hoc network are at the same
time

both routers and end
hosts. The nodes should not forward

traffic from unauthenticated nodes, and new nodes are not

included
unless the link has been authenticated. A pre
-
shared

key scheme will in either case normally be needed in
addition

to MIKE in o
rder to protect the wireless link and provide a

secure “bootstrap” of the network
service.

If we could assume that any joining node will always be

within direct transmission range of the GC/TM,
MIKE could

be used to establish this basic group key used to p
rotect the

wireless links. But this
assumption does not apply to multi
-
hop

networks in general.
Consequently,
MIKE cannot easily be used
as the only

key management scheme in tactical ad hoc networks. It is more

suitable for establishing group
keys for
secure multicast groups

“on top of” the already protected links.



The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks


RTO
-
MP
-
IST
-
111

17

-

11



Mode of operation in tactical ad hoc networks:
Whereas

[3] suggest Key Agreement mode of operation
for tactical use

and Key Distribution for strategic networks, we believe that

the Key
Distribution mode
will perform better also for tactical

use. Both modes of operation depend on the availability of a

central
entity


the GC or the TM. The Key Agreement mode

demands more bandwidth. It is not possible to
include a new

node without re
-
keyin
g. All nodes must maintain a common

view of the Key
-
tree, and the
operations such as agreeing on a

new TM demands multiple rounds of transmissions from the

members.


Key Agreement can be used as a fall back in the situation

where the army group is isolated

from
deployable and fixed

infrastructure or access to the GC for other reasons is not

possible.


Preconditions:

PKI:
The security of MIKE rests on the

authenticity of the
public keys exchanged in the three way
handshake. MIKE

demands a Public Key Infrast
ructure and a pre
-
shared root

certificate. Alternatively the
public keys can be pre
-
distributed.

In the Key Agreement mode, all members need to know the

public keys
of the others. In Key Distribution mode, it suffices

that any joining member knows the publ
ic key of the
GC, but

the GC needs to know the public key of any user that may join

the group.


A

running network service

is a necessary precondition for

joining users’ communication with the
GC/TM.


Power efficiency:
The change of TM in the Key Agreement

mode for every join means that every
newcomer must be

prepared to take this role independently of whether this is a

battery powered soldier
node or less resource constrained

vehicle mounted node. This is both undesirable and

unnecessary. A
newcomer is also

more likely to exit the

network again shortly
1
. A better idea would be to let the

previous
TM continue to act as TM. An additional

improvement would be to add TM willingness to the three
-
way

handshake.


The Key Distribution mode and PPK w/KDC are power

ef
ficient in the sense that the more demanding
tasks are left to

the less constrained GC and KDC entities.



6.0

PROPOSED OPTIMIZATIO
NS OF MIKE

Table 2 outlines possible optimizations and their

implications. Some relate to both modes of operation,
others to

only one of the operation modes.

Enhance replay protection
:
We suggest the GC and TM include the sequence number in

the three
-
way
handshake. This links the three
-
way handshake

to the next messages of the Join protocol, and enables the

group member to
detect whether later messages from the

GC/TM are fresh or not. In Key Agreement
mode, when a new

node takes over the TM role, it continues to increment the

sequence number last
received from the previous TM.


We also suggest that a
sequence number or other

time
-
variant information

is included in the

LeaveRequest
message to enable the GC/TM’s evaluation of

its freshness. The parties need not be synchronized. It
suffices

that the receiver is able to decide it has not processed this

message earlier. Alternativ
ely the Leave
can be

authenticated trough a three
-
way handshake

(but this consumes more bandwidth), or by the
LeaveRequest being encrypted with the current group key
.






1

Thanks
to Pierre Simon at Cogisys for pointing this out

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks






17

-

12

RTO
-
MP
-
IST
-
111



Table 2: Outline of possible optimizations of MIKE


Retransmit last Ke
y:
Robustness c
an be improved by periodically repeating the

last UpdateDistribute
message. As long as only one node

missed the UpdateDistribute, a re
-
join may be the more

efficient
approach. But if more nodes missed it, repeating it

can prevent multiple re
-
joins. The rat
e of the
repetitions must

be weighed against the added bandwidth cost. Repetitions will

likely be most important
just after the key change. After each

repetition, more nodes will probably have received the update.


In [9] we calculated the channel occupati
on caused by

repeating the UpdateDistribute messages
periodically at

different intervals and with varying numbers of nodes in the

network to find out what
would be the acceptable repetition

frequency under the assumption that MIKE should not take up

more
than 1
-
2% of the total channel capacity. 1
-
hop and multi
-
hop

as well as UHF and VHF networks were
included in the

calculations. We also studied the effect of distributing the

whole Key
-
tree or only the
updated blind keys in the Key

Agreement mode.


Table 3

summarizes the results for the group sizes up to 50

nodes. It indicates that periodically repetitions
is a viable

approach in UHF networks


especially for Key distribution

mode and for Key agreement when
only the updated blinded

keys are repeated. In VHF

networks it should be used with

greater caution.

Table 3: Estimated minimum time between re
-
distributions in order not to exceed 1
-
2% of the
bandwidth




KAM
Opt KAM
KDC
1-hop
20s
2s
1s
Multi-hop
120s
20s
10s
1-hop
1200s
120s
120s
Multi-hop
-
-
-
KAM = Key agreement - re-distribute whole key tree
Opt KAM = Key agreement - re-distribute only updated blind keys
KDC = Key distribution - re-distribute group key and new aux keys
UHF
VHF
Operation mode

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks


RTO
-
MP
-
IST
-
111

17

-

13



Allow Key overlap
:
Allowing the new key to co
-
exist with the previous one

during a transition period

and putting the new key into use

after the message has been repeated a number of times will

reduce the
risk of disruption and contribute to a smoother key

change. At least in Key Distribution this is a viable
approach.


Skip LeaveConfirm:

The LeaveConfirm

message appears to be superfluous. The

leaving node will be
able to detect its successful leave request

as the GC or TM multicasts the next UpdateDistribute

message,
in which it finds no new keys for itself. Nodes that

intend to leave may also have left
the network before
the leave

confirm has been received. We therefore suggest the

LeaveConfirm message is skipped as
illustrated in Figure 7.

Alternatively the LeaveConfirm message can be used as the

second message in the
proposed three
-
way handshake.



Figure 7: Proposed simplification of the Leave protocol

Introduce backup GC/TM
:
A backup GC/TM can to some extent reduce the problem of

the central
entity as a single point of failure. This is a matter of

configuration rather than an optimization of the MI
KE
scheme.

If the backup/hot standby is not co
-
located with the current

GC/TM, it would be beneficial if their
synchronization could

be handled out of band of the wireless network.


The Key Agreement mode already includes a scheme for

electing a new TM whe
n the current fails. But
the election

procedure includes a bandwidth consuming ring

communication. Bandwidth can be saved by
simply using the

previous TM as a backup. If the current TM fails, the previous

takes over. Only if this
one also fails, the TM ele
ction scheme

is used.


Distribute CRL only to the GC
:
Certificate and CRL distribution is not specified as an

integral part of
MIKE. Still, MIKE depends on it. The system

that implements MIKE must also include revocation and

certificate distribution. A PKI

based scheme will usually

require distribution of revocation information to
all participants

in the network. Both distribution of Certificate Revocation

Lists (CRL) and on
-
line
certificate validation have proved to

be bandwidth demanding in ad
-
hoc
networks. In the Key

Distribution
mode, the GC controls which nodes remain

included in the network. The CRL distribution could therefore

be optimized by distributing the CRL (unicast) only to the GC.

Change group key only on ejects
:
The risk of disruption
of communication due to key changes

caused
by Joins and Leaves can be diminished by changing the

group key only when nodes need to be expelled in
Key

Distribution mode. The requirement for forward secrecy is still

fulfilled.


Collapse TMdistribute and Upda
teDistribute
:
After the three
-
way handshake, both the current TM and
the

new node are able to calculate the new group key and the blind

keys on the path between the new node
and the root. In the

existing version of the protocol, the current TM multicasts t
he

unaltered blind keys in
the TMDistribute message. Then the

new TM takes over and distributes the new blind keys in the

UpdateDistribute. We suggest that these two messages are

collapsed as illustrated in Figure 8 in order to
save bandwidth.

What is lost

with this optimization is the new TM’s

simultaneous confirmation that it has
USER n
GC
Leave
request
UpdateDistribute
Group
Unicast
Multicast
USER n
GC
Leave
request
Leave
confirm
UpdateDistribute
Group
Unicast
Unicast
Multicast
Leave
Leave
Current
Current
version
version
Leave
Leave
Proposed
Proposed
optimized
optimized
version
version
(Passive
Confirm
)
The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks






17

-

14

RTO
-
MP
-
IST
-
111



accepted the role as
new

TM
. But this is confirmed when the newcomer answers the

next join or leave
request. The old TM holds the status as

backup TM until it hears the new TM an
swer the next request.


Figure 8:
Key Agreement optimization: collapse

p3TMDistribute and p3UpdateDistribute

Add TM willingness
:
The role as TM should be left to the more powerful and

protected nodes as its tasks
are resource consuming and

demand good
connectivity. It is therefore suggested that TM

willingness is
included in the three
-
way handshake. The

current TM remains TM when a less willing node joins the

network.

Do not retransmit entire Key
-
tree on Join and Leave
:
An optimization pointed out by T.

Aurisch, is
that in the

current MIKE implementation the full Key
-
tree is transmitted.

But only the changes need to be
transmitted to the old nodes.

This idea was included in our calculations in [9] and the effect

is shown in
Table 3.



7.0

RELATED WORK

Th
e efficiency analysis of MIKE in [4] focuses on message sizes and delay. The article presents categories
of requirements with resemblance to the evaluation criteria used in our assessment
.

Reference [4]
discusses security (forward and backward secrecy and
access control), efficiency (scalability and multiple
requests), dependability (fault tolerance and robust key update) and other criteria such as performance
under EMCON and real
-
time characteristics. Our work puts stronger emphasis on tactical ad hoc netw
orks
and evaluates MIKE according to additional criteria.

Reference [2] describes unbalanced Key
-
trees and batched re
-
keying as two possible optimization
techniques. Nodes or clusters of nodes that are likely to be revoked can be placed closer to the root

in the
unbalanced Key
-
tree. This reduces the number of keys that needs to be updated. In batched re
-
keying,
member joins and leaves are collected over some period of time before re
-
keying. This saves bandwidth
and computational cost compared to individual

re
-
keying after each
member Join or Leave request. But it
comes at the price of

delayed member Joins and Leaves, which is generally

undesirable in scenarios such
as ours. It can be also be hard to

foresee which nodes are the most likely ones to be expelle
d.


USER n
TM
Join
Request
JoinDistribute
JoinConfirm
Group
TM
Distribute
UpdateDistibute
New TM
3
-
way
handshake

mutual
authentication
Appoint
new
TM
Distribute
new
group
key
Multicast
Unicast
Unicast
Multicast
Multicast
Join
Join
Current
Current
version
version
USER n
TM
Join
Request
JoinDistribute
JoinConfirm
Group
TM
Distribute
&
UpdateDistibute
New TM
3
-
way
handshake

mutual
authentication
Appoint
new
TM and
distribute
new
group
key
Multicast
Unicast
Unicast
Multicast
Join
Join
Proposed
Proposed
optimized
optimized
version
version

The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks


RTO
-
MP
-
IST
-
111

17

-

15



8.0

C
ONCLUDING REMARKS AN
D
F
URTHER WORK

The Key Agreement mode of operations has been proposed for tactical use and Key Distribution mode for
strategic networks. However, for bandwidth consumption and robustness we believe that Key Distribution
is a be
tter solution also for tactical networks.

Main challenges for the use of
the
Key Agreement mode in tactical mobile ad hoc networks are the forced
key update on group changes and vulnerability to varying connectivity plus bandwidth consumption and
delay. Altogether, the Key Distribution mode fulfils more of the requirements than the

Key Agreement
mode.

A

major benefit of MIKE compared to a traditional PPK w/KDC scheme is its ability to dynamically
include new group members.
Its major drawbacks are
non
-
seamless key updates and
limited
robustness

against packet losses.

Furthermore
,
MI
KE requires an already running

network service or a one
-
hop
network.

Several

improvements

are proposed
, but a

remaining challenge for both modes of operation is the
dependency on reliable multicast. Measures such as FEC, timeouts and periodically repetitio
n of the la
st

UpdateDistribute message reduce the problem, but it is still a topic for further research.

Other t
opics for further work include implementation of proposed optimizations and practical
experimentation to support the theoretical study.
Detaile
d protocol specifications and a formal security
analysis are
additional

topics for further work.

9.0

REFERENCES

[1]

C. Kaufman, P. Hoffman, Y. Nir, and P. Eronen, “Internet Key Exchange Protocol Version 2
(IKEv2),” IETF RFC 5996, 2010.

[2]

T. Aurisch, “Using Key
Trees for Securing Military Multicast Communication,” MILCOM 2004.

[3]

T. Aurisch, “Optimization Techniques for Military Multicast Key Management,” MILCOM 2005.

[4]

T. Aurisch, T. Ginzler, and P. Martini, “Practical Efficiency Analysis of a Dual Mode Group Key
Management”, MILCOM 2008.

[5]

K. P. Kihlstrom, L. E. Moser, P. M. Melliar
-
Smith, “The SecureRing Protocols for Securing Group
Communication,” In Proceedings of the 31th Annual Hawaii International Conference on System
Sciences, 1998, pp. 317
-
326.

[6]

T. Aurisch, “
Tree
-
based Dual Mode Group Key Management for Improving Key Establishment
Scalability,” FKIE, unpublished manuscript.

[7]

T. Aurisch, and J. Krajewski, “System Specification of the IPD MIKE System”, Version 0.2
-

English translation, work in progress, 2010.

[8]

Y.

Xiao, and J. Rosdahl, “Throughput and Delay Limits of IEEE 802.11,” IEEE Communications
letters, Vol.6, No. 8, August 2002.

[9]

A. M. Hegland, and H.
-
A. Ellingsrud, “MIKE assessment, Techical Report,” Document ID:
1/1559/1
-
FCPR10127, Rev B, Kongsberg Defence
& Aerospace AS, 2011.



The Multicast Internet Key Exchange (MIKE)

in tactical Ad Hoc Networks






17

-

16

RTO
-
MP
-
IST
-
111