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

[miika at iki.fi (Miika Komu)]

On Thu, 24 Jan 2008, Julien Laganier wrote:

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

Hi Julien,

may I ask why? If what we want is to public key-based filtering for HIP 
control packets? I think the draft specifies such behaviour and avoids 
replay attacks on HIP control packets as well. (HIT-only-based filtering 
does not tell us whether the HIT is owned by the end-host)

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