Internet Draft I. van Beijnum Document: draft-van-beijnum-multi6-redirection-00.txt August 2004 Expires: February 2005 Thoughts About Layer 3.5 Redirection Security 1 Mandatory Statements This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 2 Abstract The new multi6 design team as of august 2004 is chartered to explore multihoming by means of a "layer 3.5 wedge" that allows unmodified applications and transport protocols to become address agile. In order to do this, the two hosts involved must communicate certain parameters. The exact nature of this communication isn't specified at this time. However, this document discusses certain security issues pertaining to such communication. Specifically, the author asserts that: 1. In order to protect multihoming signaling, the exchange of a single session key in each direction suffices, as these keys can be used to protect subsequent interactions with a HMAC, 2. Using strong cryptographic protection of the initial session key exchange for sessions that aren't protected by IPsec, TLS or similar mechanisms is unnecessary if certain precautions are taken, and: Van Beijnum Expires February 2004 [Page 1] Internet-Draft Thoughts About Layer 3.5 Redirection Security August 2004 3. For sessions that are protected by IPsec, TLS or similar, no additional security mechanisms are necessary as the already present IPsec/TLS context can be reused to establish a session key. Based on this, the conclusion must be that it is unnecessary to implement new public key based security mechanisms. 3 Security Considerations 3.1 HMAC HMAC-based integrity mechanisms are in wide use. They are relatively simple and inexpensive performance-wise to implement and offer excellent protection against modification of data in transit. The only downside is that they use a symmetric key that must be established securely. Use of HMAC to protect multihoming signaling has the advantage that the majority of the security complexity is moved to the beginning of a session or association where the session keys are established. It is therefore appropriate to use HMAC protection of all multihoming signaling, in order to simplify implementations. 3.2 Attacker capabilities Depending on the network infrastructure, an attacker may poses three levels of malicious capabilities, where each level is assumed to incorporate the previous ones: 1. Spoofing: the attacker can transmit arbitrary packets, including those with falsified source addresses. 2. Sniffing: the attacker can monitor packets flowing between the intended victim and one or more correspondents. 3. Man in the middle (MITM): the attacker can intercept packets flowing between the intended victim and one or more correspondents, and can change these packets at will. 3.3 Session protection Hosts may protect their sessions end-to-end using IPsec or TLS, if at all. This allows for the following attack/protection matrix: Van Beijnum Expires February 2004 [Page 2] Internet-Draft Thoughts About Layer 3.5 Redirection Security August 2004 3.3.1 Spoofing capability, no session protection Long-lived sessions are vulnerable to being terminated by an attacker to some extend. However, the attacker must guess a lot of information. 3.3.2 Sniffing capability, no session protection Attackers can terminate sessions at will. All information is visible to the attacker. Moderate risk of information being changed by the attacker. 3.3.3 MITM capability, no session protection Attacker can do whatever she wants, including making one correspondent think the session has been terminated while the other continues to communicate (with the attacker). In essence, this is a redirection attack. 3.3.4 Spoofing capability, TLS protection Same as 3.3.1 3.3.5 Sniffing capability, TLS protection Attacker can terminate sessions at will. Attacker can perform CPU exhaustion attack. 3.3.6 MITM capability, TLS protection Same as 3.3.5 3.3.7 Spoofing capability, IPsec protection Attacker can't perform any attacks with reasonable chance of any impact. 3.3.8 Sniffing capability, IPsec protection Attacker can perform CPU exhaustion attack. 3.3.9 MITM capability, IPsec protection Attacker can perform CPU exhaustion attack and terminate communication at will, but only with large (presumably > session) granularity. Packet flooding denial of service attacks are of course always possible, regardless of the protection mechanisms in use. Van Beijnum Expires February 2004 [Page 3] Internet-Draft Thoughts About Layer 3.5 Redirection Security August 2004 3.4 Possibilities for redirection attacks With a to be developed layer 3.5 multihoming solution in effect, there is potential for a new type of attack: an attacker can falsely claim to be a correspondent that has been moved to a different IP address. Assuming that a HMAC session key of sufficient strength is exchanged at the beginning of a session, it is impossible for an attacker with just spoofing capability to guess the session key so there are no new reasonable attack vectors for attackers with only spoofing capability. This leaves cases 3.3.2, 3.3.3, 3.3.5, 3.3.6, 3.3.8 and 3.3.9. These are now all vulnerable to session redirection. However, in the cases 3.3.5 and 3.3.6 where TLS is used, and 3.3.8 and 3.3.9, where IPsec is used, redirection will cause the session to te rminate as the attacker can't supply return traffic that will be accepted by the correspondent. 3.5 Reusing TLS or IPsec infrastructure Although IPsec is currently mostly used for very specific purposes (such as VPNs), TLS is in wide use. Both IPsec and TLS require that the identity of at least one correspondent is established in some way. Usually this is done by presenting a certificate that the other end can check, but the same result can be accomplished with pre-shared keys. Note that for the purposes of setting up session keys that can't be intercepted by an attacker (even one with MITM capability), it is not necessary for the initiat or (client) in a session to prove its identity. Once the initial TLS or IKE/ISAKMP negotiations have been completed, there is a secure channel between the two endpoints in a session. This means that at least in theory, it should be possible to reuse this secure channel to exchange session keys that can subsequently be used to protect multihoming signaling traffic. 3.6 Remaining vulnerabilities If we assume that mechanisms will be developed that will carry multihoming session keys over the IPsec/TLS secured channel, even an attacker with sniffing or MITM capability can't subvert multihoming signaling to launch a redirection attack. This addresses all the cases listed in 3.3, except 3.3.2 and 3.3.2. In these cases, an attacker will now be able to redirect a session to an address of her choosing and then continue the session. However, if the attacker already had MITM capability, she could already have done almost exactly that by simply impersonating the victim rather than allow packets through. So the only thing that's different here is that this vulnerability now also exists if the attacker only has sniffing capability rather than MITM capability. Van Beijnum Expires February 2004 [Page 4] Internet-Draft Thoughts About Layer 3.5 Redirection Security August 2004 The central question is: is this slight difference enough to warrant the creation of hard to deploy public key security mechanisms for multihoming signaling? Also, while "redirection" is a new vulnerability, in essence redirection consists of two parts: the attacker receiving the traffic, and the victim not receiving the traffic. Note that both of these are also possible to accomplish in the absence of multiho ming for an attacker with just sniffing capabilities. (Just not at the same time.) 3.7 Per-session multihoming signaling This document only describes the issues pertaining to a single session or association. In reality, two endpoints are extremely likely to have a larger number of sessions between them. In this case each session must receive its own multihoming processing, in order to make sure that a successful attack against one session doesn't lead to long-time redirection of additional sessions between the same hosts later. 4 Document and Author Information This document expires February, 2005. The latest version will always be available at http://www.muada.com/drafts/. Comments are welcome at: Iljitsch van Beijnum Karel Roosstraat 95 2571 BG Den Haag Netherlands Email: iljitsch@muada.com Van Beijnum Expires February 2004 [Page 5]