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

[julien.IETF at laposte.net (Julien Laganier)]

Hello Tobias,

On Thursday 24 January 2008, Tobias Heer wrote:
> 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 :-)

Let's talk about a security service which is packet filtering.

Let's assume we have no requirement that the decision to let a packet 
thru or not to be based on a strong (cryptographic) verification of 
data origin. Rather, we only have the requirement that the specific 
fields of a packet (e.g. src and dst IPs, SPI) respect some 
constraints, which are derived from state established by looking at 
other packets.

In that case a statefull firewall provide the service:

- For a TCP connection, it can follow the SYN/SYN-ACK/ACK three way 
handshake, and then let thru only TCP segments that 'belong' to that 
TCP connection, in terms of source and destination IP addresses, 
sequence number and acknowledgment.

- For HIP association, it can follow the HIP BEX SPIs, and then let thru 
only ESP packets that 'belong' to that HIP association, in terms of 
source and destination IP addresses, sequence number and SPI.

Both of the above are not base on strong verification of data origin but 
they do satisfy our requirements.

On the other hand, if we do have requirements that the decision to let a 
packet thru or not to be based on a strong (cryptographic) verification 
of data origin, then we need a mechanism for the midbox to verify which 
packets really come from then endpoints that participated in the base 
exchange. In that situation it would make sense for the midbox to 
verify the identities of parties involved in the base exchange, and 
avoid replay attacks. This is not the case AFAICS.

--julien

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