Subject: [NSIS] Security Threats for NSIS : Identity Spoofing

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 15 Apr 2004 15:45:49 +0200

hi all, 

a question regarding identity spoofing:

> 4.4 Identity Spoofing 
>     
>    The ability for an adversary to inject data traffic that matches a 
>    certain flow identifier established by a legitimate user often 
>    requires the ability also to receive the data traffic. This is, 
>    however, true only if the flow identifier consists of values that 
>    contain addresses used for routing. If we imagine using attributes 
>    of a flow identifier that do not require such a property, then 
>    identity spoofing and injecting traffic are much easier. An 
>    adversary can use a nearly arbitrary endpoint identifier to achieve 
>    the desired result. Obviously, though, the endpoint identifiers are 
>    not irrelevant, because the messages have to travel the same path 
>    through the network.  

> This implication of this is that flow identifiers should be hard to
> spoof usefully (e.g. they should contain destination addresses).
> This would be an important point to capture and propagate through into
> the signalling protocol security analysis.

you are right. the flow id should certainly contain a destination address
(particulary a destination address is need to have something like
path-coupled signaling).

i guess we can state that the source address is not necessarily verified. a
response message is only routed backwards (along the nodes where state was
established) but there is no check for the source address (something like a
return-routability) in an end-to-end fashion. 
hence, it might be possible that an entity includes a spoofed source
address. 

based on robert's and cornelia's comments i have tried to rewrite the
section: 

Changed from : 

" 
4.4 Identity Spoofing 
    
   Identity spoofing relevant for NSIS occurs in two forms: first, 
   identity spoofing can happen during the establishment of a security 
   association based on a weak authentication mechanismn and, second, 
   it can consist of spoofing data traffic.   
     
   In the first case, Eve, acting as an adversary, may claim to be the 
   registered user Alice by spoofing Alice's identity. Eve thereby 
   causes the network to charge Alice for the network resources 
   consumed. This type of attack is possible if authentication is based 
   on a simple username identifier (i.e., in absence of cryptographic 
   authentication), or if authentication is provided for hosts, and 
   multiple users have access to a single host. This attack could also 
   be classified as theft of service.  
    
   In the second case, an adversary may be able to exploit the 
   established flow identifiers (required for QoS and middlebox 
   communication [Midcom] specific signaling protocols). Some 
   identifiers, among others, IP addresses, transport protocol 
   identifiers, port numbers, and flow labels (see [RFC1809] and 
   [RC+03]), are transported in these protocols. Modification of these 
   flow identifiers allows adversaries to exploit or to render 
   ineffective quality of service reservations or policy rules at 
   middleboxes. An adversary could mount an attack by modifying the 
   flow identifier of a signaling message. 
    
   NSIS signaling messages contain some sort of flow identifier, which 
   is associated with a specified behavior (e.g., a particular flow 
   experiences QoS treatment or allows packets to traverse a firewall). 
   An adversary might, therefore, use IP spoofing and inject data 
   packets to benefit from previously installed flow identifiers.  
    
   The following threat is carried out by spoofing the identity of 
   transmitted data traffic. The spoofed identity is the IP source 
   address. For this attack to be successful, accounting records are 
   collected based on the IP source address and not on a SPI due to 
   IPsec protection. After the network receives a properly protected 
   reservation request, transmitted by the legitimate user Alice, 
   Traffic Selectors are installed at the corresponding devices (for 
   example, the edge router). These Traffic Selectors are used for flow 
   identification and allow data traffic originated from a given source 
   address to be matched and assigned to a particular QoS reservation. 
   The adversary Eve now spoofs the IP address of the Alice. In 
   addition, Alice's host may be crashed by the adversary with a denial 
   of service attack or may lose connectivity, for example, because of 
   mobility considerations. If both nodes are located at the same link 
   and use the same IP address, then obviously a duplicate IP address 
   will be detected. Assuming that only Eve is now present at the link, 
   she is able to receive and transmit data (for example RTP data 
   traffic) that receives preferential QoS treatment based on the 
   previous reservation. Depending on the installed Traffic Selector 
   granularity, Eve might have more possibilities to exploit the QoS 
   reservation or a pin-holed firewall. Assuming the soft state 
   paradigm, whereby periodic refresh messages are required, the 
   absence of Alice will not be detected until the next signaling 
   message appears and forces Eve to respond with a protected signaling 
   message. Again, this attack is applicable not just to QoS traffic, 
   but the existence of a QoS reservation increases its impact, because 
   this type of traffic is more expensive. The same attack is also 
   applicable to a Middlebox protocol.  
    
   The ability for an adversary to inject data traffic that matches a 
   certain flow identifier established by a legitimate user often 
   requires the ability also to receive the data traffic. This is, 
   however, true only if the flow identifier consists of values that 
   contain addresses used for routing. If we imagine using attributes 
   of a flow identifier that do not require such a property, then 
   identity spoofing and injecting traffic are much easier. An 
   adversary can use a nearly arbitrary endpoint identifier to achieve 
   the desired result. Obviously, though, the endpoint identifiers are 
   not irrelevant, because the messages have to travel the same path 
   through the network.  
    
   Data traffic marking based on DiffServ is such an example. Whenever 
   an ingress router uses only marked incoming data traffic for 
   admission control procedures, then various attacks are possible. 
   These problems have been known in the DiffServ community for a long 
   time and have been documented in various DiffServ-related documents. 
   The IPsec protection of DiffServ Code Points is described in Section 
   6.2 of [RFC2745]. Related security issues (for example denial of 
   service attacks) are described in Section 6.1 of the same document. 
" 

to 

"
4.4 Identity Spoofing

Identity spoofing relevant for NSIS occurs in three forms: first, identity
spoofing can happen during the establishment of a security association based
on a weak authentication mechanism. Second, an adversary can modify the flow
identifier carried within a signaling message and third, it can spoof data
traffic.  
 
In the first case, Eve, acting as an adversary, may claim to be the
registered user Alice by spoofing Alice's identity. Eve thereby causes the
network to charge Alice for the network resources consumed. This type of
attack is possible if authentication is based on a simple username
identifier (i.e., in absence of cryptographic authentication), or if
authentication is provided for hosts, and multiple users have access to a
single host. This attack could also be classified as theft of service. 

In the second case, an adversary may be able to exploit the established flow
identifiers (required for QoS and NAT/FW NSLP). These identifiers are, among
others, IP addresses, transport protocol type (UDP, TCP), port numbers, and
flow labels (see [RFC1809] and [RC+03]). Modification of these flow
identifiers allows adversaries to exploit or to render ineffective quality
of service reservations or policy rules at middleboxes. An adversary could
mount an attack by modifying the flow identifier of a signaling message.

In the third case, an adversary may spoof data traffic. NSIS signaling
messages contain some sort of flow identifier, which is associated with a
specified behavior (e.g., a particular flow experiences QoS treatment or
allows packets to traverse a firewall). An adversary might, therefore, use
IP spoofing and inject data packets to benefit from previously installed
flow identifiers. 

We will provide an example of the latter threat. After NSIS nodes along the
path between the NSIS initiator and the NSIS receiver processes a properly
protected reservation request, transmitted by the legitimate user Alice, a
QoS reservation is installed at the corresponding NSIS nodes (for example,
the edge router). The flow identifier is used for flow identification and
allows data traffic originated from a given source to be assigned to this
QoS reservation. The adversary Eve now spoofs the IP address of the Alice.
In addition, Alice's host may be crashed by the adversary with a denial of
service attack or may lose connectivity, for example, because of mobility
considerations. If Eve is able to perform address spoofing then she is able
to receive and transmit data (for example RTP data traffic) that receives
preferential QoS treatment based on the previous reservation. Depending on
the installed flow identifier granularity, Eve might have more possibilities
to exploit the QoS reservation or a pin-holed firewall. Assuming the soft
state paradigm, whereby periodic refresh messages are required, the absence
of Alice will not be detected until a refresh message is required and forces
Eve to respond with a protected signaling message. Again, this attack is
applicable not just to QoS traffic and the same attack is also applicable to
a Firewall control protocol, with a different consequence. 

The ability for an adversary to inject data traffic that matches a certain
flow identifier established by a legitimate user and to get some benefit
from injecting that traffic often requires the ability also to receive the
data traffic or to have one's correspondent receive it. For example, an
adversary in an ad hoc network observes a NAT/Firewall signaling message
towards a corporate network. After the signaling message exchange was
successful user Alice is allowed to traverse the company firewall based on
the establish packet filter to contact her internal mail server. Now,
adversary Eve, which was monitoring the signaling exchange is able to build
a data packet towards this mail server which will pass the company firewall.
The packet will hit the mail server and cause some actions and the mail
server will reply with some response messages. Depending on the exact
location of the adversary and the degree of routing asymmetry the adversary
might even see the response messages. Note that for this attack to work
Alice does not need to participate in the exchange of signaling messages. 

If we imagine using attributes of a flow identifier that is not related to
source and destination addresses. As an example, we could think of a flow
identifier where only the 21-bit Flow ID is used (without source and
destination IP address). Identity spoofing and injecting traffic is much
easier since a packet only needs to be marked and an adversary can use a
nearly arbitrary endpoint identifier to achieve the desired result.
Obviously, though, the endpoint identifiers are not irrelevant, because the
messages have to hit some nodes in the network where NSIS signaling messages
installed state (e.g., in the above example they would have to hit the same
firewall.) 

Data traffic marking based on DiffServ is such an example. Whenever an
ingress router uses only marked incoming data traffic for admission control
procedures, then various attacks are possible. These problems have been
known in the DiffServ community for a long time and have been documented in
various DiffServ-related documents. The IPsec protection of DiffServ Code
Points is described in Section 6.2 of [RFC2745]. Related security issues
(for example denial of service attacks) are described in Section 6.1 of the
same document.
"

ciao
hannes

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis