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

julien.IETF at laposte.net (Julien Laganier) Thu, 24 January 2008 08:06 UTC

From: "julien.IETF at laposte.net"
Date: Thu, 24 Jan 2008 09:06:15 +0100
Subject: [Hipsec-rg] next steps with draft-heer-hip-middle-auth-00
In-Reply-To: <Pine.SOL.4.64.0801240020280.1083@kekkonen.cs.hut.fi>
References: <77F357662F8BFA4CA7074B0410171B6D04049B5D@XCH-NW-5V1.nw.nos.boeing.com> <200801231650.52455.julien.IETF@laposte.net> <Pine.SOL.4.64.0801240020280.1083@kekkonen.cs.hut.fi>
Message-ID: <200801240906.18235.julien.IETF@laposte.net>

On Wednesday 23 January 2008, Miika Komu wrote:
> 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.

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.

--julien