[Hipsec-rg] next steps with draft-heer-hip-middle-auth-00

[miika at iki.fi (Miika Komu)]

On Wed, 23 Jan 2008, Julien Laganier wrote:

> Hello Tobias,
>
> On Wednesday 23 January 2008, Tobias Heer wrote:
>> Am 23.01.2008 um 15:24 schrieb Julien Laganier:
>>> On Wednesday 23 January 2008, Tobias Heer wrote:
>>>>> I am actually unclear about the goal of BEX inspection by
>>>>> middlebox (e.g. signature verification). What kind of security
>>>>> service does it offer?
>>>>
>>>> The goal is that the middlebox can verify the Identity of the
>>>> hosts that communicate across it unambiguously.
>>>
>>> This is ambiguous in itself :)
>>>
>>> AFAIU, 'communicate' refers only the BEX. The middlebox doesn't
>>> verify identity of the hosts sending payload packets (e.g., ESP).
>>
>> The "communicate" refers to the HIP control packets, e.g. BEX and ?
>> UPDATE and the payload channel associated with the HIP control
>> channel. The middlebox can derive some expected properties for the
>> payload channel from the HIP control messages (e.g. IP address pairs
>> and SPIs). It can use these properties to block certain payload that
>> does not belong to an authenticated HIP association.
>
> Verifying IP addresses and SPIs does not provide a strong insurance that
> the payload packets are indeed exchanged by the parties that
> participated in the BEX.
>
> If no strong insurance is present, what's the value of verifying
> signatures in HIP BEX since in the end payload packets are allowed in
> based on unprotected packet fields (IPs and SPIs). A statefull firewall
> would provide the same level of protection without verifying
> signatures.

Hi Julien,

I didn't get the point with statefull firewalls, can you clarify? The SPI 
field is integrity protected. Also, a fake base exchange (to create a fake 
ESP channel) can pass all ACL checks in the firewall if the firewall does 
not check signatures in a mobile environment.

However, just including signatures is not enough because an authentic base 
exchange can replayed to create a fake ESP channel. Thus, we need the 
middlebox to ensure the uniqueness of the base exchange with middlebox 
nonces that are signed by the end-hosts.

What I am not sure is that what happens with the old middleboxes when both 
of the end-hosts move behind new middleboxes. I guess the old middboxes 
have to expire the state using timers, but attackers working at both ends 
could reuse the ESP channel until it expires. Anyway, this attack does not 
seem very realistic to me.

-- 
Miika Komu                                       http://www.iki.fi/miika/