Re: Issue 60: Addresses in IKE_SA_INIT/AUTH

Jari Arkko writes:
> 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?

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.

> >>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.
> >>    
> >>
> >
> >NO_NATS_ALLOWED discloses the internal address to the WORLD, not to
> >the peer.
> >  
> >
> 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?

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 protected]