Subject: [Mobike] FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Oct 2005 14:47:13 +0300

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

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 10 Oct 2005 11:45:06 +0300

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

>Does the SA recover from the attack of comment 1 if NAT traversal

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-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 10 Oct 2005 18:51:44 -0700

Tero,

> (draft-ietf-ipsec-esp-v3-10.txt section 2.1).
Yes, but that concerns inbound processing. Here we are talking about outbound
processing i thought.

> RFC2401bis, which requires ESPv3...
Are you saying that this problem cannot happen ? The I1 and I2 are two
different hosts and they *can* choose the same SPI. When R is sending
packets to I1 or I2, it does not use the SPI for lookup. It uses the selectors
from the packet to lookup the SA. The selectors are unique (they are still I1
plus whatever the policy requires) even after I1 moves to A2. But this leads
to two SAs with the same SPI. This should not cause any problem (in theory)
because you never lookup this SA directly. You always lookup the SPD which
points to the SA. But there are implementations (e.g. Linux) where this can cause
problems if you update an SA that will result in the same values (dest address, SPI,
protocol) as another SA. So, can you clarify ?

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 11 Oct 2005 13:08:00 +0300

> Yes, but that concerns inbound processing. Here we are talking about outbound

Ups, I seem to have read the question too quickly.

> Are you saying that this problem cannot happen ? The I1 and I2 are
> two different hosts and they *can* choose the same SPI. When R is
> sending packets to I1 or I2, it does not use the SPI for lookup. It
> uses the selectors from the packet to lookup the SA. The selectors
> are unique (they are still I1 plus whatever the policy requires)
> even after I1 moves to A2. But this leads to two SAs with the same
> SPI.

Same outbond SPI, so that is not a problem.

> This should not cause any problem (in theory) because you never
> lookup this SA directly. You always lookup the SPD which points to
> the SA. But there are implementations (e.g. Linux) where this can
> cause problems if you update an SA that will result in the same
> values (dest address, SPI, protocol) as another SA. So, can you
> clarify ?

When you are sending packets outbound you do lookup from SPD-S based
on the selectors (I1 or I2) and you get SA based on that. Then in the
SA there is the SPI and destination IP to be used for the other end.
Then you simply make tunnel encapsulation and send the packet along. I
do not really see what is the problem there?

So we have case where we have I1 and I2 using addresses A1 and A2
talking to the R and both have selected same SPI for the IPsec SA. Now
if I2 disappears i.e. does not send IKE SA delete to destroy the IKE
SA and the IPsec SA. If the I1 happens to get the same IP-address A2
in the local link, and sends UPDATE_IP_ADDRESSES to the R, we can have
that situation. Note, that this I1 must get A2 before DPD notices that
I2 is dead to this happen. As R uses selectors I1 and I2 to search
from the SPD-S and the SPD-S will then point to the SA, there should
be no problem for the R to send packets out.

The I1 will discard those packets R sends which have keying material
for the I2, and after a while R will start DPD for the I2 IKE SA and
delete it as it does not see any traffic for it.

When finding the SA based on the selectors we match those selectors
against SPD-S, which have the exact selectors based on the SPD and the
PFP flags (populate from packet), so there should not be problem even
when they are using same PFP SPD rule.

The case where we have multiple IKE SAs with the same IP address is
already happening without MOBIKE, in case of NAT-T.

The 4.4.2 of the RFC2401bis says:
...
   For outbound processing, each SAD entry is pointed to by entries
   in the SPD-S part of the SPD cache.
...

The section 4.4.1 describes the SPD-S:
...
       - SPD-S: For traffic that is to be protected using IPsec, the
         entry consists of the values of the selectors that apply to the
         traffic to be protected via AH or ESP, controls on how to
         create SAs based on these selectors, and the parameters needed
         to effect this protection (e.g., algorithms, modes, etc.). Note
         that an SPD-S entry also contains information such as "populate
         from packet" (PFP) flag (see paragraphs below on "How To Derive
         the Values for an SAD entry") and bits indicating whether the
         SA lookup makes use of the local and remote IP addresses in
         addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
         specifications).
...

Does that (correctly) answer the (correct) question?
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 11 Oct 2005 09:54:58 -0700 (PDT)

> be no problem for the R to send packets out.
Yes, this is the case. Now, when R receives the
UPDATE_IP_ADDRESSES, it need to update the information
in SA about where the packets should be tunneled out.
How do you locate the SA to update its peer address ?
If you locate the SA based on peer SPI, destination
address and protocol (it does not matter how the peer
chose the SPI i.e it can be unique for the whole
system etc.), some implementation might have wrongly
assumed that it will be unique. As you point out
below, it does not work for NAT-T. So, you need a
different way to lookup the SA. I am merely *guessing*
that the original question was based on this. 

> delete it as it does not see any traffic for it.
Yes, this is not an issue.
> already happening without MOBIKE, in case of NAT-T.
Agreed. This happens when there are two hosts (I1 and
I2) behind the SAME NAT establishing the SA with a
responder (R). If I1 and I2 picks the same SPI, then
the destination address (public address), SPI and
protocol as seen by the responder R will not be
unique.

> Does that (correctly) answer the (correct) question
?

Yes.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 12 Oct 2005 11:49:13 +0300

> How do you locate the SA to update its peer address ?

The UPDATE_IP_ADDRESSES is IKE SA operation, that is done on the IKE
SA, and each IPsec SA is tied to the IKE SA, thus all IPsec SAs
affected can be found by finding the IPsec SAs created by this IKE SA
(similarly what you do when the IKE SA is deleted, and you need to
find all IPsec SAs created by IKE SA so you can delete them). 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike