Subject: Re: [Mobike] Issue 60: Addresses in IKE_SA_INIT/AUTH (was: Comments of draft-ietf-mobike-protocol-04.txt)

From: <[email-masked]>
Date: Thu, 20 Oct 2005 10:55:42 +0300

Tero Kivinen wrote:

> 2)
>
> In section 4.2 we should always take the IP-addresses from the
> IKE_AUTH request, as there might be multiple IKE_SA_INIT request,
> and some of those might not create state at all (cookie,
> invalid_ke_payload). I think it would be simplier to say that the
> IP-addresses are always taken from the IP header of the IKE_AUTH
> packet having SA payload (regardless of the NAT-T or no NAT-T).
>
> In normal IKEv2 this does not matter, as if no NAT-T is used then
> the IP address must stay same, and if NAT-T is used then we take the
> last packet seen and use the IP-addresses from there. In Mobike we
> do need to define the exact time what IP-address is used, and I
> think the packet having the ADDITIONAL_*_ADDRESSES would be the most
> logical choise (i.e. the IKE_AUTH packet having the SA payload).

There's a reason why I wrote it that way: when not doing NAT-T, 
the address should be taken from the same packet which contains
NO_NATS_ALLOWED. And it seems that putting NO_NATS_ALLOWED in
IKE_SA_INIT is simpler than IKE_AUTH; see below on this...

> The section 4.8 says that NO_NATS_ALLOWED should be put to the
> IKE_SA_INIT (among other things), but we do want to keep IKE_SA_INIT
> as small as possible, so I think IKE_AUTH is much better place for
> that notify. That would also be in sync with my proposed change to
> the 4.2 where I proposed to say that use the IKE_AUTH packet having
> SA payload to get the IP address tobe used. NO_NATS_ALLOWED is not
> needed in the IKE_SA_INIT like NAT_DETECTION_*_IP notifies are, as
> they do not cause changing of the port numbers for the IKE_AUTH.

NO_NATS_ALLOWED takes less space than NAT_DETECTION_*_IP payloads,
so IMHO it's not unreasonable to put it in IKE_SA_INIT.

The real reason to put NO_NATS_ALLOWED in IKE_SA_INIT is that it's
much simpler to retry the request if we get UNEXPECTED_NAT_DETECTED
error back. In particular, this text from Section 4.8 would need major
revision if we take the address from IKE_AUTH:

   More specifically, when NAT Traversal is not enabled, all messages
   that can update the addresses associated with the IKE_SA and/or IPsec
   SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that
   contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS
   notifications) MUST also include a NO_NATS_ALLOWED notification.  The
   exchange responder MUST verify that the contents of the
   NO_NATS_ALLOWED notification match the addresses in the IP header.
   If they do not match, a response containing an
   UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the
   IKE_SA_INIT exchange, no state is created at the responder).  The
   response message is sent to the address and port that the
   corresponding request came from, not to the address contained in the
   NO_NATS_ALLOWED notification.

   If the exchange initiator receives an UNEXPECTED_NAT_DETECTION
   notification in response to its request, it SHOULD retry the
   operation several times using new IKE_SA_INIT/INFORMATIONAL requests.
   This ensures that an attacker who is able to modify only a single
   packet does not unnecessarily cause a path to remain unused.

> Also moving that NOFITY to the encrypted IKE_AUTH packet will
> prevent passive attackers of getting the information about the IP
> addresses and ports used in case host behind NAT is configured to
> try first with NO_NATS_ALLOWED before falling back and enabling
> NAT-T. It will also make the attacker acting as a NAT between two
> hosts bit harder, as if it is sent inside the IKE_SA_INIT, attacker
> can simply flip a bit inside the NO_NATS_ALLOWED payload to cause
> DoS, otherwise he need to flip bit in the IP-address or ports, which
> requires it to catch the return packet and forward it to the
> original requestor to cause attack. It is not much, but offers again
> a bit more protection against attacks.

A host that is worried about an attack as obscure as this is IMHO
unlikely to have a policy "first try without NAT-T; but if there's 
a NAT, enable NAT-T".

Furthermore, moving the payload doesn't actually prevent anything.
If there's no NAT, the addresses are visible in the IP header.
If there is a NAT, and the host behind NAT falls back to NAT-T, 
the eavesdropper can get the addresses anyway with a quite trivial 
amount of computation (as is already pointed out in the IKEv2 spec,
hashing does not prevent NAT detection payloads from leaking the 
internal addresses).

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Oct 2005 13:23:58 +0300

> IKE_SA_INIT is simpler than IKE_AUTH; see below on this...

That reason is not explained anywhere, thus it is very hard to
understand why it is done that way (i.e. why do we have more
complicated processing here). 

> so IMHO it's not unreasonable to put it in IKE_SA_INIT.

True, not unreasonable, but I still unnecessary to put them there.

> revision if we take the address from IKE_AUTH:

I do not think there is any difference in the complexity of the retry
even if the NO_NATS_ALLOWED is in the IKE_AUTH, you simply delete half
created IKE SA and start over (from the IKE_SA_INIT) when you get
error in both cases. There will be performance penalty, as we need to
do Diffie-Hellman again, but on the other hand we do not need to add
another test matrix case to test the checking that we take the IP
addresses in IKE_AUTH for NAT-T and from IKE_SA_INIT for non-NAT-T
case. 

The question simply is whether this is felt like being important
enough to have performance optimizations when trying to revert this
attack, and costing more in the code complexity and testing time.
Note, that the whole idea of retrying is something that does not
really make attack that much harder especially in the initial contact
step. If someone can modify one packet he can usually modify all the
packets. Also moving them to IKE_AUTH does make the attack a bit
harder, as now the attacker must be able to get the return packets and
forward them to the real destination.

If we know there was no NAT between us in the first place, then it is
quite safe to assume that such thing does not appear on the path
suddenly, thus retrying is ok for the existing IKE SA (i.e. for the
INFORMATIONAL exchanges).

If the initial contact seems to have NAT between, then it is must
likely going to be real NAT, thus retrying by protocol is not really
useful. We could simply say that the IKE SA initiation fails in that
case, and then when the next trigger packets comes in (or user retries
by pressing "connect" again) we retry the exchange from the beginning
again.

>    packet does not unnecessarily cause a path to remain unused.

The change needed would be something like:

    If the exchange initiator receives an UNEXPECTED_NAT_DETECTION
    notification in response to its INFORMATIONAL request, it SHOULD
    retry the operation several times using new INFORMATIONAL
    requests. This ensures that an attacker who is able to modify only
    a single packet does not unnecessarily cause a path to remain
    unused. If initiator receives UNEXPECTED_NAT_DETECTION during IKE
    SA creation (i.e. in IKE_AUTH state), then it should abort the IKE
    SA creation, and retry it later when it gets next trigger for that
    connection.

>From the code point of view, that retry does not need any new code,
simply fail the IKE SA and other parts of the code will already take
care of the retry.

Actually sending UNEXPECTED_NAT_DETECTION during IKE SA creation is
quite useless, as it cannot be authenticated, and also if the
initiator wants to ignore those error notifications and continue
retrying regardless of them. So why do we send those notifies in the
first place? Only benefit they will give is to inform the initiator
that there was attacker between him and the responder. There is
really nothing initiator can do for that, except retry. If his policy
does not allow NATs between, then he will not enable NAT-T even when
there would be NAT between, thus he will be just out of connectivity.

> unlikely to have a policy "first try without NAT-T; but if there's 

I agree that the revealing of the IP addresses is not very serious
case, but there are people who consider that unacceptable (that is why
the NAT-T uses hashes, as people did consider leaking the IP-addresses
a problem). If we leak them again here, there needs to be at least
security considerations section explaining the issue, and also explain
why we require them to be sent in clear when they could also be sent
as encrypted (i.e. hidden from passive attackers).

> hashing does not prevent NAT detection payloads from leaking the 

True, that is mentioned in the IKEv2 spec, and its implications are
explained there. We are now adding another case, so we need to explain
it in the security considerations section. There is nothing about
NO_NATS_ALLOWED in the security considerations now.

Hmm... I got completely new idea, dont know if it is good or bad, but
how about adding the flag in the IKE generic header flags field to tell
that include IP-addresses and ports to the MAC. Then we wouldn't need
to send those IP-addresses/ports at all, and the responder would
simply ignore all packets having wrong MAC (i.e. modified IP-addresses
or ports).

Either end could put that bit in case they want to make sure the
IP-addresses are protected (i.e when they would send NO_NATS_ALLOWED).
Hmm.. the problem with that is that it is not backward compatible,
i.e. if the other end does not support MOBIKE, then he do not know
about flag, thus will not be able to calculate the MAC correctly.

So ignore that suggestion (this would probably have been the way to do
it if we would still be modifying IKEv2 draft).
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Oct 2005 13:26:51 +0300

>as encrypted (i.e. hidden from passive attackers).
We probably need the security considerations text
in any case, because we have ADDITIONAL_*_ADDRESS.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Oct 2005 13:48:38 +0300

Having read through this thread, I tend to agree with
Pasi on this, i.e., take the addresses from where they
are currently taken from and use NO_NATS_ALLOWED
where its currently in.

I do not think the leakage of addresses is an issue, and
if it is, we are already doing it in ADDITIONAL_*_ADDRESS.
The rest of the issue is really a debate about aesthetics
and complexity of variant 1 or variant 2; personally I think
what's in the document right now seems better.

Here's a suggested addition to the Security Considerations,
Section 6.5, after the fourth paragraph:

The use of NO_NATS_ALLOWED will also disclose the
internal address to the peer, in case NAT was in the path.
However, this has relevance only if the node is configured to first
try with NO_NATS_ALLOWED and only then fallback to
the use of NAT traversal if that fails.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Oct 2005 11:02:29 +0300

> what's in the document right now seems better.

I have really started to hate different variations in the protocol. It
causes lots of different new tests to be done. In the last interop we
already did around 50 different tests to get through the  basic
exchanges. That didn't include testing different ciphers or macs, only
different variations of the IKE protocol (auth methods, rekeying,
cookies, invalid ke notify, liveness, basic NAT). The more versions of
protocol we have for mobike, the more complex test matrix we need to
generate for it too. 

> the use of NAT traversal if that fails.

NO_NATS_ALLOWED discloses the internal address to the WORLD, not to
the peer.

It relevant in case NO_NATS_ALLOWED is ever configured, and that node
is ever behind NAT whose IP-addresses adminstrators are not willing to
disclose. The fallback case is not the only case it is also about
misconfigurations.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Oct 2005 12:31:05 +0300

Tero Kivinen wrote:

>I have really started to hate different variations in the protocol.
>  
>
I hate that too, but is there something we can do in this
specific issue about that? Are you saying that your option
would not create a new variant?

>NO_NATS_ALLOWED discloses the internal address to the WORLD, not to
Hm. I missed this. Why does it reveal the address to the world?
Because its sent in a too early IKE message that is not yet
encrypted?

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Oct 2005 13:10:59 +0300

> would not create a new variant?

At least we take the IP-addresses from the same place regardless if
there is NAT-T enabled or not. Testing whether the MOBIKE will take
the IP-addresses from the correct packet is going to be painfull
anyways (i.e. requires changing the IP-addresses during the exchange
itself and so on). Not sure how big the real impact will be, but still
would avoid it if possible.

> Because its sent in a too early IKE message that is not yet

Yes, it is sent in the IKE_SA_INIT thus it is not encrypted nor
authenticated. It will be authenticated at the end of IKE_AUTH phase,
but not before that. It will not be encrypted at all, thus everybody
along the path can see it.

Moving it to the IKE_AUTH will get it encrypted, thus reading it
requires man in the middle attack, and also changes the protocol so we
can always take the IP address from the IKE_AUTH packet (no need to
separate processing for NAT-T allowed or no NAT-T allowed). 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Oct 2005 13:15:54 +0300

Tero,

>separate processing for NAT-T allowed or no NAT-T allowed). 
Hmm... OK, now I'm starting to like this better. Pasi?

--Jari