Cryptography Reference
In-Depth Information
Key Confirmation Attack
Another weakness of the above protocol is that Alice
is not assured that the key material she receives from the KDC is actually for a
session between her and Bob. This attack assumes that Oscar is also a legitimate
(but malicious) user. By changing the session-request message Oscar can trick the
KDC and Alice to set up session between him and Alice as opposed to between
Alice and Bob. Here is the attack:
Key Confirmation Attack
Alice
Oscar
KDC
Bob
KEK:
k
A
KEK:
k
O
KEK:
k
A
,
k
B
,
k
O
KEK:
k
B
RQST
(
ID
A
,
ID
B
)
−−−−−−−−−−→
substitute
RQST
(
ID
A
,
ID
O
)
−−−−−−−−−−→
random
k
ses
y
A
=
e
k
A
(
k
ses
)
y
O
=
e
k
O
(
k
ses
)
y
A
,
y
O
←−−−−−−−
k
ses
=
e
−
1
k
A
(
y
A
)
y
=
e
k
ses
(
x
)
y
,
y
O
−−−−−−−→
intercept
k
ses
=
e
−
1
k
O
(
y
O
)
x
=
e
−
1
kses
(
y
)
The gist of the attack is that the KDC believes Alice requests a key for a session
between Alice and Oscar, whereas she really wants to communicate with Bob. Alice
assumes that the encrypted key “
y
O
”is“
y
B
”, i.e., the session key encrypted under
Bob's KEK
k
B
. (Note that if the KDC puts a header
ID
O
in front of
y
O
which asso-
ciates it with Oscar, Oscar might simply change the header to
ID
B
.) In other words,
Alice has no way of knowing that the KDC prepared a session with her and Oscar;
instead she still thinks she is setting up a session with Bob. Alice continues with the
protocol and encrypts her actual message as
y
. If Oscar intercepts
y
, he can decrypt
it.
The underlying problem for this attack is that there is
no
key confirmation. If key
confirmation were given, Alice would be assured that Bob and no other user knows
the session key.
13.2.2 Kerberos
A more advanced protocol that protects against both replay and key confirmation
attacks is Kerberos. It is, in fact, more than a mere key distribution protocol; its
main purpose is to provide user authentication in computer networks. Kerberos was
standardized as an RFC 1510 in 1993 and is in widespread use. It is also based on
