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

>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.

Yes, this is because of support for NAT-T. If you do not want to
support NAT-T you will use NO_NATS_ALLOWED and that will provide
stronger authentication.

>- 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.

I assume you meant to say, that allow NAT-T only for private or
link-local addresses, and use NO_NATS_ALLOWED if initiator have global
routable ip-addresses?

>- 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.

The problem there is to know which one to reject. If you select wrong
one, you block all updates from the real client, not the attacker.
There is not really way to detect which one is correct client. If the
client is not behind NAT, then using NO_NAT_ALLOWED will fix the
situation, and tell the other end which updates to reject.

>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.

-04 says that all if NAT-T is not enabled, then messages which can
update address MUST include NO_NATS_ALLOWED.

>Comment 3: 
>
>Does the SA recover from the attack of comment 1 if NAT traversal
>is not in use?

If NAT traverseal is not in use (i.e. disabled), then that situation
cannot happen, as NO_NAT_ALLOWED will be used, and they will block all
updates by the attacker.

>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.

Responder will reject that packet because the NO_NATS_ALLOWED contents
do not match, and it will return error UNEXPTECTED_NAT_DETECTED. No
update happens. 

> 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?

As no changes to SA happened, there is nothing to recover from. 

>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?

You either have NO_NATS_ALLOWED or NAT_DETECTION_*_IP payaloads in the
updates, so either it enables NAT-T on that attack, or disallows NAT,
thus that should take care of that attack. 

>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.

ESPv3 the IPsec SA is identified by the SPI alone for the unicast SAs.
There is no destination IP address threre anymore. Implementations are
allowed to use SPI and IPsec protocol type also.
(draft-ietf-ipsec-esp-v3-10.txt section 2.1).

>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.)

This is not ok with the mobike, as it requires IKEv2, which requires
RFC2401bis, which requires ESPv3...
-- 
[email protected]