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

[heer at cs.rwth-aachen.de (Tobias Heer)]

Hi Julien,

Am 24.01.2008 um 09:26 schrieb Julien Laganier:

> On Thursday 24 January 2008, Julien Laganier wrote:
>> On Wednesday 23 January 2008, Miika Komu wrote:
>>> 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.
>>
I also did not get how a stateful HIP firewall would do  
authentication based on HIs without verifying them. Maybe we are  
talking about different scenarios with different assumptions here.  
Let's see if we can get us synchronized :-)

>> Hi Miika,
>>
>> The midbox cannot verify that the ESP packet originates from a node
>> that participated in the BEX. It only verify that the ESP SPI was
>> included in the base exchange, but there is no strong (cryptographic)
>> validation of data origin at the midbox for ESP.
>>
>> Since in the end no strong guarantee on the ESP data origin is
>> provided, IMHO it seems that the (strong) validation of BEX
>> signatures by midboxes hasn't much value. Security strength is
>> determined by the strength of each element of the chain. Here the
>> last element is weak (looking at SPI without verifying data origin)
>> thus I'm not convinced about the strength of the mechanism.
>
> ...and consequently I don't see a need to make BEX inspection security
> even stronger (Tobia's proposal) since the weak admission control of
> ESP packets will remain.
>
It's right that you cannot determine the origin of the ESP packets in  
a cryptographically strong way. However, you can enforce that all  
packets that are forwarded by a certain middlebox fulfill the  
criteria that have been negotiated in the BEX. You can, for example,  
only allow traffic between network identifiers that have been used to  
successfully establish a HIP association. I admit that this does not  
prevent an attacker from  sending packets with the same destination  
IP address, the same source IP address, and the same SPI. However,  
this will only enable an attacker to send invalid ESP packets to an  
authentic HIP host (which will probably just drop the packets). I  
further have to admit that there is a loophole in this scheme.  A  
pair of attackers that can use the same network-level identifiers as  
the authentic peers could inject packets into the payload stream and  
communicate across it. However, such an attack only works in the  
presence of authentic HIP hosts and it will only stay unnoticed if  
the receiving attacker can delete the forged packets before they  
reach the authentic HIP host. Additionally, inconsistencies in the  
IPsec sequence numbers aid the middlebox to identify such injections.  
However, these measures are all payload channel specific. My main  
concern is that HIP does not even support secure authentication of  
the HIP hosts (and the control channel) by middleboxes without  
explicitly performing a HIP handshake with them.





> Again, I think we should discuss first what is the security service we
> want to provide (e.g. admission control), and requirements we place,
> before entering solution space.
>
I guess admission control and access control are two services that  
could benefit from using HIP. I would like to see a system that  
identifies hosts based on their HIs and then decides whether to  
allocate certain resources for the payload stream or to determine  
whether the payload stream will be permitted at all. Mechanisms for  
reverting the resource allocation and for closing the payload stream  
would also be nice.


BR,

Tobias

> --julien




--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer





-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080124/aaf2b4e5/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
Url : https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20080124/aaf2b4e5/attachment-0001.bin