INTERNET DRAFT J. Floroiu Date: 20 February 2002 FhG Fokus Expires: August 2002 An Authenticated Key Exchange Protocol in IPv6 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