Internet DRAFT - draft-floroiu-ake-ipv6
draft-floroiu-ake-ipv6
INTERNET DRAFT J. Floroiu
Date: 20 February 2002 FhG Fokus
Expires: August 2002
An Authenticated Key Exchange Protocol in IPv6
<draft-floroiu-ake-ipv6-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes an authenticated key exchange scheme enabling two
nodes to establish a security association in a way robust to man in the
middle attacks. The scheme is based on owner-bound IP addresses and DNS
lookups.
The proposed scheme relies on the fact that an attacker cannot timely
produce a piece of information to match the output of a one way
function.
1. Introduction
This document proposes an authenticated key exchange scheme enabling two
nodes to establish a security association in a way robust to man in the
middle attacks.
The Diffie-Hellman key exchange is used for the shared secret generation.
The authentication of the peers is based on the idea of building
"lightweight certificates" - self signed public key plus the DNS name of
the public key owner.
Self signed public keys are still vulnerable to man in the middle
attacks, we therefore rely on binding IP addresses to public keys, as
indicated in [Nika]. DNS lookups ensure that the name specified by the
sender corresponds to the sender's address. The sender address, on the
other hand, contains a hash of the sender's public key. For owner-bound
IP addresses DNS becomes in this way a database containing the hashes of
the corresponding public keys.
Floroiu [Page 1]
INTERNET DRAFT 20 February 2002
2. Protocol description
The following notations will be used:
X IP address of X (X is one of A, B and M - the Alice, the Bob
and the Mallory)
NX DNS name of X
KX+ Public key of X
KX- Private key of X
g^x DH public information (g^y, g^z likewise)
We will describe the scenario step by step starting from the most
elementary (and vulnerable) exchange.
So, whenever Alice and Bob want to establish a shared secret thay use a
Diffie-Hellman key exchange. If Alice and Bob want to authenticate each
to the other, all they can do in the absence of a third trusted party is
to use self-signed public keys. The exchange will look somehow like:
Alice >> Bob
A->B: { KA+, g^x } KA-
Alice << Bob
B->A: { KB+, g^y } KB-
Bob retrieves KA+ and he is able to authenticate the message containing
g^x and similarly does Alice. If either the message content OR the
signature are modified in transit the authentication fails. This scheme
is sensitive to man-in-the-middle attacks because Mallory can always
intervene in the exchange and modify the message content AND the
signature:
Alice >> Mallory >> Bob
A->B: { KA+, g^x } KA-
M->B: { KM+, g^z } KM-
Alice << Mallory << Bob
B->A: { KB+, g^y } KB-
M->A: { KM+, g^z } KM-
In the next step the DNS name of the host will be introduced because we
consider reasonably to assume that each node is able to identify
"friends" and "enemies" by name. Let Alice and Bob provide their names
and resolve them, this brings us one step closer to the proposed scheme,
although for the time being Mallory can still impersonate Alice and Bob:
Alice >> Mallory >> Bob
A->B: { NA, KA+, g^x } KA-
A->B: { NA, KM+, g^z } KM-
Alice << Mallory << Bob
B->A: { NB, KB+, g^y } KB-
B->A: { NB, KM+, g^z } KM-
Floroiu [Page 2]
INTERNET DRAFT 20 February 2002
However, if A and B were bound to Alice's and respectively Bob's public
keys, then Bob would notice that hash(KM+) does not correspond to A -
expected to be composed of prefix and hash(KA+) - and respectively that
hash(KM+) does not appear in B. If Mallory modified the source address of
the datagram then the DNS lookup would fail, and if Mallory replaced the
names with his own, both Alice and Bob would notice that the peer is not
the one they expect to talk to. Assuming Alice and Bob are two
arbitrary nodes in Internet, they might not necessarly apriori know each
other's name, but, at least, connection attempts coming from suspicious
domains can be refused.
For a sucessfull key exchange to take place, the following 3 steps must
be sucessfully passed:
1) perform DNS lookup;
2) compute hash(K+) and check the sender's IP address;
3) use K+ to check the signature.
Once Alice and Bob concluded the exchange with a shared secret, they can
further negotiate a number of security associations in a similar way IKE
for instance is doing.
For situations when Alice and Bob do not need a
general purpose key exchange protocol but rather seek to negotiate a
number of well defined security associations, security association
proposals may be piggybacked into the exchange in order to reduce the
signaling. A Mobile IP mobile node is a typical example, in which the
initiator may want to establish no more than one AH security association
with an administrative entity in the visited domain, or an ESP security
association with a correspondent node.
4. Reply attacks
In order to avoid reply attacks Alice and Bob could encrypt each other's
name using the generated shared secret. If Mallory replaces a message of
Alice or Bob with an older one, Alice and Bob will end up with different
secrets. This fact will be discovered when attempting to decrypt the
peer's name. This adds only one more message to the exchange, because
Bob can generate the secret after the first message trip and already
piggyback its own name in encrypted form in the reply. If Alice cannot
decrypt correctly Bob's name using the shared secret, she won't send the
third message. If the shared secret appears to be correct, then Alice
encrypts its name using this secret and acknowledges this to Bob.
5. Enlarging the problem space for a potential attacker
What Mallory has to do in order to impersonate Alice and Bob, is to be
able to generate a public key the hash of which conforms to the
interface identifier part of the victim's IP address. In order to make
this even more difficult to Mallory, Alice and Bob may periodically
change their public keys, which translates into changing their IP
addresses (issues related to DNS updates frequency would need to be
addressed at this point).
Floroiu [Page 3]
INTERNET DRAFT 30 November 2001
Alice and Bob can also modify their IP addresses without modifying their
public keys. Since a MD5 hash for instance is 16 bytes long, Alice and
Bob may decide to form the interface identifier part of their IP
addresses by just choosing at different moments of time a different
sequence of 8 bytes out of the 16 bytes of the hash. Thus, a sequence
like <1, 3, 5, 6, 9, 11, 13>, for instance, added into the message Alice
sends to Bob, tells Bob that he has to match the indicated bytes
sequence of the hash(KA+) against the interface identifier part of A.
6. Conclusion
Including cryptographic material into the IP addresses enable secure use
of self signed public keys, without requiring the assistence of trusted
third party entities. Well, there is actually a trusted third party -
the DNS infrastructure itself - which is assumed to not be corrupted.
References
[Nika] Nikander, P., "A Scaleable Architecture for IPv6 Address
Ownership", draft-nikander-ipng-pbk-addresses-00.txt, March 2001,
expired November 2001
Author's Address
Questions about this memo can also be directed to:
John Floroiu
FhG Fokus
31 Kaiserin-Augusta-Allee
10589 Berlin, Germany
Phone: +49 (0)30 3463 7144
Email: floroiu@fokus.fhg.de
