FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03

Tuomas Aura wrote:

>The security considerations section covers well the important issues. However, I have the following comments and questions.
>
>Comment 1:  
>
>As explained in the security considerations section 6.1, an attacker can spoof the source address of UPDATE_SA_ADDRESSES and, thus, cause the responder to record the wrong address for the initiator. Essentially, the attacker behaves as a NAT for selected messages. I'd like to add the following observations:
>
>- Mobike hosts are more vulnerable to this attack than non-Mobike hosts that are behind a NAT and use IKE NAT-T negotiation (e.g., VPN clients at a home LAN). This is because a mobile host is more likely to visits untrusted access networks and to be exposed to attackers at its local link. 
>
>- The sender-authentication of the address updates in Mobike is weaker than it is in other mobility protocols like Mobile IPv6 or HIP where the mobile's new address is included in the authenticated part of the location update. This may be surprising because Mobike uses the strong authentication provided by IKE.
>
>-  As a possible defense mechanism, the initiator local policy can be configured to send NO_NATS_ALLOWED if and only if the initiator address at the local link is private or link-local. This does not require any changes to the specification. 
>
>- As another defense mechanism, the responder could reject address updates where the initiator moves between two addresses on the same local link. This would prevent attacks by the most likely type of attacker that is on the same local link as the initiator and uses its own address as the spoofed source address. In IPv6, it is obvious which addresses are on the same local link. It should probably be the initiator that makes the decision about such a policy, in the same way as the initiator can decide whether to use NO_NAT_ALLOWED. In IPv4, the address mask would need to be communicated to the responder. I haven't considered the details.
>
>Comment 2:  
>
>If the initiator does not support NAT traversal, is it required to send the NO_NATS_ALLOWED payload? Looks like this would make sense but I cannot find it anywhere in the spec. Or does it make sense for an initiator to behave otherwise. 
>
>Comment 3: 
>
>Does the SA recover from the attack of comment 1 if NAT traversal is not in use?
>
>Consider an initiator and responder at least one of which does not support NAT traversal, or an initiator that sends NO_NATS_ALLOWED. The attacker is located on the route between the initiator and the responder, for example, at the initiator's local link. The attacker intercepts the UPDATE_IP_ADDRESS notification, modifies its source address to be the attacker's address, and forwards the packet to the responder. The attacker receives the response and forwards it to the initiator. That is, the attacker behaves like a NAT for this one address pair. The result is that the responder has records the wrong address for the initiator. Moreover, the result of the NAT traversal negotiation is that NAT traversal will not be used between these two end hosts. The attacker now stops interfering with packets and leaves the network. Can the SA recover? 
>
>The security considerations section 6.1 refers to "IKEv2 and Mobile mechanisms designed to detect NAT mapping changes" as the recovery mechanism. But these mechanisms will not kick in after the above attack because NAT traversal is not in use. It looks like the SA won't recover from this attack. Or is there some other recovery mechanism that I have missed?
>
>Comment 4: 
>
>IPsec SAs are identified by the <destination IP address, SPI> pair. Normally, these identifiers are unique for inbound SAs destination host is responsible for allocating the SPIs and for outbound SAs because the destination address identifies a unique host. In Mobike, the latter is no longer true. That is, identifier collisions may occur for outbound SAs at the responder.
>
>Consider the following example of an accidental collision: I1 and I2 are honest initiators that both have an SA with the same honest responder R. The outbound SAs from R happen, by change, to have the same SPI. (This is ok because the destination IP addresses differ.) I1 is first located at the address A1 and I2 is located at the address A2. Thus, tunnel-mode ESP packets from R to I1 have A1 as the outer destination address and I1 as the inner destination address; tunnel-mode ESP packets from R to I2 have A2 as the outer destination address and I2 as the inner destination address. Now, I2 becomes disconnected from the network and I1 moves to its old address A2. I1 sends the UPDATE_IP_ADDRESS notification to R. R updates the outbound SA to point to A2. It now has two outbound SAs with the same identifier <A2,SPI>. Can Mobike implementations cope with this? (Consider also a situation wher
 e both SAs were created from the same SPD entry with the destination addresses populated f
 rom packets.)
> 
>One policy for dealing with accidental collisions of <dst IP, SPI> is to evict either the unchanged or the changed SA from SAD. Unfortunately, both policies enable a DoS attacks. If the unchanged SA is evicted, an attacker that sees a packet from R to I1 and learns the SPI can intentionally create another SA with the same SPI and then cause the collision. If the changed SA is evicted, the attacker can squat the <dst IP,SPI> pair if it knows the address to which the initiator will next move. In both cases, the result is the loss of the target SA. Both attacks require the attacker to be either at the initiator's local link or on the route between the initiator and the responder. 
>
>While these attacks do not appear very serious, it is better to manage outbound SAs at the responder in such a way that <dst IP, SPI> collisions can be tolerated. Some implementations probably work like this already. 
>
>Tuomas
>
>
>  
>