One document matched: draft-van-beijnum-multi6-redirection-00.txt

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]